目录

1.STDIO —— 本地进程通信（稳定）

工作原理

工作原理图

优点

缺点

适用场景

2.HTTP+SSE —— 历史远程传输（已废弃）

工作原理

工作原理图

优点（历史贡献）

缺点（致命缺陷）

适用场景

3.Streamable HTTP —— 当前远程传输标准（标准推荐）

工作原理

工作原理图

优点

缺点

适用场景

4.WebSocket —— 全双工实时通信（可用，社区成熟）

工作原理

工作原理图

优点

缺点

适用场景

5.gRPC —— 企业级微服务复用（谷歌贡献）

工作原理

工作原理图

优点

缺点

适用场景

6.快速选型总表

---

MCP（Model Context Protocol，模型上下文协议）是一种标准化的AI模型通信协议，旨在让不同模型及外部系统之间高效共享上下文，实现工具调用、插件扩展、多模态处理等功能。它的核心是上下文管理，通过统一接口让模型在执行任务时动态获取外部数据与能力。

核心架构包括：

• Host（主机）：发起请求的AI应用，如IDE、聊天机器人。

• Client（客户端）：负责与Server通信、路由消息、管理能力。

• Server（服务器）：提供外部数据源、工具或服务。

• Base Protocol（基础协议）：定义消息格式（基于JSON-RPC 2.0）、生命周期和传输机制（如Stdio、SSE）。

MCP将应用层协议与传输层分离，保证核心语义一致性的同时适应不同部署环境。

1.STDIO —— 本地进程通信（稳定）

工作原理

STDIO 传输将 MCP Server 作为客户端应用的子进程启动，通过父子进程间的标准输入（stdin）和标准输出（stdout）管道传输 JSON-RPC 消息，标准错误（stderr） 独立输出日志，与协议消息完全隔离。

核心机制

1. 进程生命周期：Client 通过 fork/exec（或 CreateProcess）启动 Server 子进程，并持有其 stdin/stdout 句柄。Server 进程的生命周期与 Client 绑定。

2. 消息边界：使用换行符（\n） 作为 JSON-RPC 消息的分隔符（JSON Lines 格式）。每条消息必须是一行完整的 JSON 字符串。

3. 请求-响应模型：

   1. Client 向 Server 的 stdin 写入请求 JSON（末尾加换行符）。

   2. Server 从 stdin 读取请求，处理后向 stdout 写入响应 JSON（末尾加换行符）。

   3. Client 异步监听 stdout，通过 JSON-RPC 的 id 字段关联请求与响应。

4. 主动通知：Server 可随时向 stdout 写入无 id 的通知消息，Client 需实现相应的监听器。

5. 终止：Client 关闭 stdin 或主动终止子进程，通信结束。

关键设计

• 零网络栈开销，通信延迟为微秒级。

• 天然隔离：Server 仅能访问 Client 授予的权限，无远程攻击面。

• 调试友好：stderr 独立输出，不影响协议数据流。

工作原理图

优点

• 极致性能：进程内管道，无网络栈开销，延迟极低。

• 本质安全：不暴露网络端口，无远程攻击面，权限继承自父进程。

• 部署极简：无需 HTTP 服务器、端口配置、跨域处理。

• 资源经济：随 Client 生命周期启停，无闲置资源占用。

• 调试友好：三通道分离（输入/输出/日志），日志与协议互不干扰。

缺点

• 单客户端绑定：一个 Server 进程只能服务一个 Client，无法多路复用。

• 分布式更新困难：每台终端需单独安装/升级，无法集中热更新。

• 跨平台兼容成本：需为 Windows/Linux/macOS 分别构建/测试二进制包。

• 无原生远程能力：如需远程调用，必须自行封装代理隧道。

适用场景

• IDE 插件：Cursor、Windsurf、VS Code 等编辑器中的本地智能体。

• CLI 工具：命令行交互式 Agent。

• 桌面应用：Claude Desktop 等本地 MCP 客户端。

• 开发调试：快速验证 MCP Server 功能，无需网络配置。

---

2.HTTP+SSE —— 历史远程传输（已废弃）

工作原理

HTTP+SSE 是 MCP 早期的远程传输方案，采用双端点、双连接架构，将请求与响应通道彻底分离。

核心机制

1. SSE 持久连接（GET）：

   1. Client 发起 GET /sse 请求，Server 保持该 HTTP 连接长期打开（不立即返回）。

   2. Server 通过此连接以 Server-Sent Events（SSE） 格式单向推送数据（响应、通知）。

   3. 首个 SSE 事件中，Server 下发 endpoint 字段，告知 Client 后续 POST 请求的目标 URL（通常携带 sessionId）。

2. POST 短连接：

   1. Client 每次发送请求时，另起一个独立的 HTTP POST 请求到上述 endpoint，请求体为 JSON-RPC。

   2. Server 收到 POST 后立即返回 HTTP 202 Accepted（表示已接收），不在此连接中返回响应。

3. 异步响应：

   1. Server 处理完请求后，通过已建立的 SSE 连接将响应以 event: message 的形式推送给 Client。

   2. Client 需根据响应中的 id 字段，与先前 POST 请求关联。

4. 会话绑定：SSE 连接与 POST 请求通过 sessionId 关联，Server 需维护会话状态。

关键缺陷

• 双向语义割裂：请求走 POST，响应走 SSE，逻辑链路断裂，客户端实现复杂。

• 强制长连接：SSE 连接必须长期挂起，Serverless 平台无法维持空闲连接。

• 无恢复机制：SSE 连接一旦中断，已推送但未消费的消息永久丢失，无法续传。

工作原理图

优点（历史贡献）

• 首次实现远程流式响应：支持长任务进度推送。

• 标准 HTTP 技术栈：无需 WebSocket，防火墙友好。

缺点（致命缺陷）

• 双向语义割裂：请求与响应走不同连接，Client 需维护请求 ID 与 SSE 事件的映射表。

• 强制长连接：Server 必须为每个 Client 维持长期挂起的 HTTP 连接 → Serverless 无法部署。

• 无恢复流：SSE 连接中断后，已推送但未消费的消息永久丢失。

• 双端点运维：需同时管理 SSE 监听端和 POST 发送端，配置复杂。

• 已正式废弃：自 MCP 2025-03-26 规范起，新项目严禁使用。

适用场景

仅限向后兼容，维护 2025 年 3 月之前部署的遗留 MCP 客户端。

• 新项目：绝对禁止选择此传输方式。

---

3.Streamable HTTP —— 当前远程传输标准（标准推荐）

工作原理

Streamable HTTP 是 MCP 协议定义的一种特定的、基于 HTTP 的传输机制或模式。Streamable HTTP 描述了如何利用 HTTP（特别是 POST 和 GET 方法）和可选的 SSE 技术，在 MCP 客户端和服务器之间实现双向的、可具备流式交互能力的消息交换。

核心机制

1. 单端点统一语义：

   1. Client 与 Server 的所有交互（请求、响应、流式推送）均通过同一个 URL（例如 POST /mcp）完成。

   2. 不再需要 SSE 专用监听端点，运维配置极简。

2. 两种工作模式：

   1. 模式 A：普通请求-响应

      • Client 发送 POST /mcp，请求体为标准 JSON-RPC。

      • Server 同步处理，直接返回 HTTP 200，响应体为 JSON-RPC 结果。

      • 适用于结果小、无需中间进度的场景。

   2. 模式 B：流式响应（可选升级）

      • Client 在请求头携带 Accept: text/event-stream，或在 JSON-RPC 请求的 _meta.progressToken 中声明需流式返回。

      • Server 识别后将同一 HTTP 连接升级为 SSE 流，返回 Content-Type: text/event-stream。

      • Server 通过此连接分块推送 event: message 数据，最后以标准 JSON-RPC 响应或 [DONE] 标识结束。

3. 无状态原生支持：

   1. Server 可以不保留任何会话上下文，每个请求独立处理 → 完美适配 Serverless 平台（Cloudflare Workers、AWS Lambda）。

   2. 若需会话状态，可通过 Set-Cookie 或 _meta.sessionId 方式由 Client 携带，Server 按需恢复。

4. 向后兼容：可降级为纯 SSE 模式服务旧版客户端，迁移平滑。

关键设计价值

• 彻底解决 SSE 的“强制长连接”和“双端点”问题。

• 流式能力变为可选特性，非流式场景零额外开销。

工作原理图

优点

• 无状态服务器支持：不强制长连接，Serverless 原生，扩缩容零成本。

• 单端点运维：一个 URL 搞定所有，负载均衡、监控、代理零适配成本。

• 双向语义完整：上行 POST，下行普通响应或 SSE 流，逻辑清晰。

• 按需流式：只有需要实时推送的场景才升级 SSE，资源开销最优。

• 向后兼容：可降级为纯 SSE 模式服务旧客户端。

• HTTP 标准：无特殊协议依赖，企业基础设施全兼容。

缺点

• 流恢复非原生：断点续传需应用层自行实现（通过 stream ID）。

• 非对等全双工：上行 POST、下行 SSE，仍不是真正的全双工（但 95% 场景足够）。

适用场景

• SaaS 化 MCP 公共服务：多租户、云端部署，需集中更新。

• Serverless 架构：Cloudflare Workers、AWS Lambda、Azure Functions。

• 通用远程 Agent：任何需要远程调用 MCP 工具的场景。

• 新项目默认选项：不确定选哪个时，Streamable HTTP 是安全答案。

4.WebSocket —— 全双工实时通信（可用，社区成熟）

工作原理

WebSocket 传输在单个持久化 TCP 连接上建立全双工通信通道，Client 与 Server 可随时主动向对方发送消息，无请求-响应固定顺序。

核心机制

1. 协议升级：

   1. Client 发起标准 HTTP GET 请求，携带 Upgrade: websocket 和 Connection: Upgrade 头。

   2. Server 同意升级后返回 HTTP 101 Switching Protocols，此后连接切换为 WebSocket 协议，同一 TCP 连接持续保持打开。

2. 全双工消息交换：

   1. 双方通过 WebSocket 文本帧（Text Frame） 发送 JSON-RPC 消息。

   2. 帧头部自带消息长度，无需换行符分割。

   3. 任意时刻，任何一方均可主动发送消息。

3. 请求-响应关联：仍通过 JSON-RPC 的 id 字段匹配请求与响应。

4. 主动推送：Server 可在无请求的情况下，随时向 Client 推送通知（如进度更新、状态变更）。

5. 连接保活：通过 WebSocket 内置的 Ping/Pong 帧维持连接活跃，检测断线。

6. 断线重连：应用层需自行实现重连逻辑及会话恢复。

与 Streamable HTTP 的本质区别

• WebSocket 是真正对等的全双工，Server 可随时随地主动发起消息。

• Streamable HTTP 的 SSE 流仅允许 Server 在响应一个 POST 请求的过程中推送消息，无法独立发起。

工作原理图

优点

• 真正的全双工：Server 可随时主动推送，Client 也可随时发起请求。

• 极低延迟：单连接持久化，无每次请求的握手开销。

• 批量操作优化：可在同一连接内流水线式发送多个请求/响应，吞吐量高。

• 状态天然保持：连接即会话，无需额外 session 管理。

• 流式原生：任意方向均可分块发送大文件/长结果。

缺点

• 基础设施兼容成本：负载均衡需显式开启 WebSocket Upgrade 支持，某些企业代理可能拦截 Upgrade 头。

• 浏览器 Header 限制：WebSocket 握手无法携带自定义 Header（如 Authorization），认证信息需通过 URL 参数或连接后第一条消息发送。

• 运维复杂：长连接心跳、断线重连、会话恢复均需应用层精细实现。

• 非 RPC 原生：JSON-RPC over WebSocket 无标准封装规范，需自行设计消息信封。

• Serverless 不友好：需维持长连接，与无状态架构冲突。

---

适用场景

• 实时协同工具：如 Cursor + Figma 双向同步、多人文档协作。

• 高频双向交互：金融行情推送、实时监控面板、游戏服务器。

• 浏览器内 Agent：需与后端保持长期双向通信的 Web 应用。

• 已有 WebSocket 基础设施的企业。

5.gRPC —— 企业级微服务复用（谷歌贡献）

gRPC 简介 | gRPC 框架

工作原理

gRPC 传输将 MCP 的 JSON-RPC 语义映射到 gRPC 服务方法，使用 Protocol Buffers 作为接口定义语言（IDL）和消息序列化格式，底层承载于 HTTP/2。

核心机制

1. IDL 定义：

   1. 通过 .proto 文件声明 MCP 核心服务（如 CallTool、ReadResource）。

   2. 方法参数和返回值定义为 Protobuf 消息结构。

   3. 当前预览方案（谷歌贡献）在 .proto 中使用自定义 Option 扩展，为每个方法嵌入自然语言描述，以解决 gRPC 缺乏语义元数据的根本矛盾。

2. 代码生成：

   1. 使用 protoc 编译器生成客户端 Stub 和服务器骨架，支持 10+ 语言。

   2. 强类型契约，编译期类型安全。

3. 协议转换适配层：

   1. 客户端适配层：将 MCP Client 的 JSON-RPC 请求转换为 Protobuf 消息，通过 gRPC Stub 发送。

   2. 服务端适配层：接收 Protobuf 请求，转换回 JSON-RPC 格式，调用 MCP Server 逻辑，再将结果封为 Protobuf 返回。

4. 传输：

   1. 基于 HTTP/2，支持一元、服务端流、客户端流、双向流四种 RPC 模式。

   2. 流式模式直接映射 MCP 的流式能力（如长任务进度推送）。

   3. Header 映射：MCP 的 _meta 元数据放入 gRPC 的 Metadata（即 HTTP/2 Header）。

5. 性能优势：

   1. Protocol Buffers 二进制序列化，体积比 JSON 减少 40-60%，解析速度提升 5-10 倍。

   2. HTTP/2 多路复用，单个连接并发处理多个请求。

当前状态：预览，已由谷歌贡献核心传输包，社区正在推进生态工具链适配。

工作原理图

优点

• 极致性能：Protobuf 二进制 + HTTP/2 多路复用，带宽/CPU 开销显著低于 JSON。

• 强类型契约：编译期类型安全，消除手写 JSON 错误，API 文档自动生成。

• 基础设施复用：企业已有 gRPC 监控、负载均衡、链路追踪体系可直接为 MCP 服务。

• 多语言原生：自动生成 10+ 语言客户端，跨语言调用零成本。

• 流式原生：完美支持 MCP 流式场景（服务端流、双向流）。

缺点

• 语义层缺失（根本矛盾）：

  • gRPC 方法签名只有结构化参数，缺少 MCP Tool 必需的 description 字段。

  • 当前预览方案通过自定义 Option 在 .proto 中嵌入描述，但生态工具（如 gRPC UI、文档生成器）尚未广泛支持。

• 生态锁定：非 gRPC 环境引入它是过度工程，增加技术栈复杂度。

• 浏览器支持麻烦：需 gRPC-Web 代理，无法直接调用。

• 学习曲线：Protocol Buffers、HTTP/2 特性需团队掌握，新人 onboarding 成本高。

• JSON-RPC 语义转换开销：适配层引入额外 CPU 消耗（但通常远低于序列化收益）。

适用场景

• 已全面采用 gRPC 的大型企业：如 Google、Spotify 等，已有成熟 gRPC 微服务治理体系。

• 需复用现有 gRPC 基础设施：监控（Prometheus）、鉴权（OAuth）、负载均衡（Envoy）等。

• 对性能极致敏感且团队熟悉 Protobuf 的特定场景。

• 新项目不建议：除非已有强 gRPC 依赖，否则 Streamable HTTP 更轻量、更普适。

6.快速选型总表

传输方式	状态	核心定位	工作原理核心词	推荐指数（远程）	典型场景
STDIO	稳定	本地单租户	父子进程、管道、换行符分割	★★★★★（本地）	IDE、CLI、桌面应用
HTTP+SSE	已废弃	历史遗留	双端点、双连接、异步响应	⚠️ 禁止新项目	仅维护旧客户端
Streamable HTTP	标准	远程通用	单端点、可选流式、无状态原生	★★★★★	所有新远程 MCP 服务
WebSocket	可用	实时全双工	协议升级、全双工文本帧	★★★★☆	协同工具、高频双向
gRPC	预览	企业 gRPC 复用	Protobuf、HTTP/2、适配层转换	★★★☆☆	已有 gRPC 基础设施的大型企业