For the complete documentation index, see llms.txt. This page is also available as Markdown.

9.2 传输层:stdio 与 Streamable HTTP

MCP 是协议层的规范,但消息需要通过某种传输方式在 Client 和 Server 间流通。传输层的选择影响性能、可靠性和部署方式。

当前 MCP 规范定义的标准传输是 stdio 与 Streamable HTTP。旧版 HTTP+SSE 属于历史兼容路径,不应再作为与 Streamable HTTP 并列的第三种标准传输来介绍。

9.2.1 stdio - 本地进程间通信

工作原理:

  • Client 启动 Server 进程作为子进程

  • 通过 stdin 向 Server 发送 JSON-RPC 消息(每行一个)

  • 通过 stdout 从 Server 读取 JSON-RPC 消息(每行一个)

  • 通过 stderr 接收 Server 的日志和错误

图 9-1:stdio 传输架构 —— 通过标准 I/O 进行本地进程间通信

特点:

特性
说明

架构

本地进程间通信

延迟

最低(<1ms)

实现

最简单

部署

仅支持本地

扩展性

单 Client 单 Server

容错

Server 崩溃需要重启 Client

stdio 不等于会话:进程一直开着,并不意味着 Server 可以把上一次请求的状态带到下一次。2026-07-28 修订版要求 Server 不得从同一连接上的历史请求推断状态;需要跨请求保留的状态,必须表达为一个显式标识符,由 Client 每次显式传入。下面的 stdio 客户端示例按当前修订版 2026-07-28 编写:没有握手,协议版本与客户端能力随每个请求的 _meta 传入,并可用 server/discover 一次性发现对端能力——在 stdio 上它同时是判断对端讲新版还是旧版的探针。

实现示例:

何时使用:

  • 本地开发和测试

  • 单机应用

  • 工具的快速原型

  • 性能最优的场景(<100ms 延迟要求)

限制:

  • 只能本地部署

  • Server 崩溃需要重启 Client

  • 不支持多 Client 访问同一 Server

  • 网络分区完全不适用

9.2.2 Streamable HTTP - 双向 HTTP 流传输

工作原理:

  • Server 是一个 HTTP 服务器,只暴露单一 MCP 端点,且只接受 POST;每条 JSON-RPC 消息都是一次独立的 POST

  • Client 的 Accept 必须同时列出 application/json 与 text/event-stream

  • 每个请求必须带 MCP-Protocol-Version(其值必须与 params._meta 中的协议版本一致,否则返回 -32020 HeaderMismatch 与 HTTP 400)和 Mcp-Method(等于 method);tools/call、resources/read、prompts/get 还必须带 Mcp-Name(等于 params.name 或 params.uri)

  • Server 对一个请求的响应,要么是 application/json 单个对象,要么是仅作用于该请求的 text/event-stream 流:流上先送该请求相关的通知,最后送响应。Server 不得在这条流上发送独立的 JSON-RPC 请求

  • 长期的变更通知不再靠常驻连接推送,而是由 Client POST subscriptions/listen,其响应本身就是一条长连 SSE,只承载客户端订阅的通知类型;进度、日志一类请求内通知不走这条流

  • 关闭 SSE 响应流,就是 HTTP 上的取消信号

  • 2026-07-28 版删除了 GET 流端点、协议级会话(Mcp-Session-Id 及其 DELETE 终止)与基于 Last-Event-ID 的断点续传

  • 与旧版本共存:现实中大量服务器仍只说 2025-11-25,GET 流端点、Mcp-Session-Id 会话与 Last-Event-ID 续传在那一版仍然有效。Client 应先按新版发一个请求做探测:若收到 HTTP 400,就检查响应体——是可识别的新版 JSON-RPC 错误,说明对方是新版服务器,按错误修正后重试;响应体为空或无法识别,则退回 initialize 握手走旧版。反过来,只支持 2026-07-28 的服务器对该端点上的 GET/DELETE 应返回 405 Method Not Allowed,并忽略 Mcp-Session-Id 与 Last-Event-ID

图 9-2:Streamable HTTP 传输架构 —— 单一 POST 端点,响应可为 JSON 或请求内 SSE

特点:

特性
说明

架构

单一 POST 端点,响应可为 JSON 或 SSE

延迟

低(<100ms)

实现

中等复杂度

部署

网络部署

扩展性

单 Server 多 Client

容错

请求无状态,失败可直接重发

实现示例:

何时使用:

  • 网络部署(Client 和 Server 在不同机器)

  • 多 Client 访问同一 Server

  • Server 需要高可用(可以前置负载均衡器)

  • 支持跨机房部署

  • 大文件和流式数据传输

优点:

  • 灵活的部署架构

  • 请求无状态,天然适配多副本部署与负载均衡

  • 统一的端点,简化配置

  • 支持大型文件流式传输

  • 标准 HTTP,易于代理和监控

缺点:

  • 实现复杂度中等

  • 每个请求都要重复携带元数据

向后兼容:与仍在使用 initialize 握手的旧版 Server 互通

无状态模型是 2026-07-28 版才引入的,而线上大量 Server 仍然只会说 2025-11-25:先发 initialize 请求、再发 notifications/initialized 通知,随后用 Mcp-Session-Id 维持会话。规范本身给出了互通规则,客户端需要同时能走这两条路。

HTTP 上的探测顺序:先按新版发一个正常请求;如果返回 HTTP 400,就检查响应体——能识别出现代 JSON-RPC 错误码(如 -32020、-32022、-32602)说明对方就是新版 Server,按错误纠正后重试;只有响应体为空或无法识别时,才回落到 initialize 握手,按旧版流程继续。

stdio 上的探测:把 server/discover 当作探针,能正常返回就按无状态模型继续,否则回落到 initialize。

只支持新版的 Server 面对旧流量:端点上的 GET 与 DELETE 应返回 405 Method Not Allowed,忽略请求里的 Mcp-Session-Id,忽略 Last-Event-ID。

旧 HTTP+SSE 传输(2024-11-05)已进入废弃期,但不是被删除:规范承诺至少 12 个月的过渡窗口,这期间它仍然可用。新实现一律用 Streamable HTTP,存量实现按窗口期迁移即可,不必紧急下线。

不同的传输方式各有其优缺点,选择合适的传输协议对系统的整体性能和部署成本有重大影响。本节介绍了如何根据具体的网络部署场景做出传输层决策,以及连接管理的最佳实践。

9.2.3 传输层选择决策与连接管理

传输方式的选择决策

传输方式的选择决策过程如下:

图 9-3:传输方式选择决策树 —— 根据部署需求选择合适的传输方式

连接管理与池化

无论采用哪种传输方式,都需要考虑连接的管理和复用。

stdio 情况下的连接管理:

stdio 传输方式的连接管理实现如下:

HTTP 情况下的连接管理: HTTP 传输方式的连接管理实现如下:

OAuth 认证流程: 在 HTTP 传输中,现代 MCP Server 不应假设固定的 /oauth/authorize / /oauth/token 路径。客户端应先处理 Server 返回的 401 与 WWW-Authenticate 挑战,读取 OAuth Protected Resource Metadata,再发现授权服务器元数据,并在令牌请求中带上 resource 参数。另外,在 2026-07-28 修订版中,OAuth 2.0 动态客户端注册(DCR)进入至少 12 个月的弃用期(仍然可用,但新实现不建议采用),官方建议改用 Client ID Metadata Documents 标识客户端。

9.2.4 本小节小结

传输层的选择是设计 MCP 集成架构的关键决策。stdio 提供最高性能但不支持网络部署,Streamable HTTP 是网络部署的推荐方案:单一端点、逐请求 POST,响应可以是 JSON,也可以是该请求专属的 SSE 流。

关键要点:

  • 本地/单机 → stdio

  • 网络/多 Client → Streamable HTTP

  • 两种传输都已没有握手:协议版本与客户端能力随每个请求放在 params._meta 里

  • Streamable HTTP 只接受 POST,请求必带 MCP-Protocol-Version 与 Mcp-Method,tools/call、resources/read、prompts/get 还要带 Mcp-Name

  • 长期变更通知走 subscriptions/listen;Mcp-Session-Id 与 Last-Event-ID 已被删除

  • SSE 是 Streamable HTTP 的流式响应格式之一;旧 HTTP+SSE 传输处于废弃期,仍可用但不应新采用

  • 总是考虑连接池复用

  • HTTP 环境中实现 OAuth 认证

下一节将深入 MCP Server 的实现。

最后更新于