MCP社区新提案：Streamable HTTP 将取代HTTP SSE

Model Context Protocol (MCP) 社区正在提议以 Streamable HTTP 传输协议取代现有的 HTTP+SSE 方案。这项改进旨在解决现有方案的局限性，同时保留其优势，并吸纳了包括 Shopify、Pydantic、Cloudflare、LangChain、Anthropic 等团队的宝贵反馈。

新协议的核心在于简化和增强 HTTP 的使用，主要体现在以下几个方面：

• 移除 /sse 端点： 不再有专门的 SSE 端点，所有客户端到服务器的消息都通过 /message (或类似路径) 端点发送。

• 统一消息入口 /message： 客户端所有请求，包括初始化、工具调用等，均通过 POST 请求发送至 /message 端点。

• 服务器按需升级 SSE： 服务器可以根据需要，将客户端发往 /message 的请求升级为 SSE 连接，用于推送通知或请求。客户端可通过空的 GET 请求 /message 主动发起 SSE 流。

• 客户端会话 ID 机制： 客户端在请求头中携带 Mcp-Session-Id，服务器可选择利用此 ID 维护会话状态，实现有状态或无状态服务器。

替代原因和收益

替代当前 HTTP+SSE 方案的原因在于：SSE 不支持会话恢复，服务器需维护长连接和高可用，服务器消息通道单一。Streamable HTTP 旨在解决这些问题，带来以下优势：

• 支持无状态服务器：  无需维护长期连接，降低服务器高可用性要求，简化服务器实现，特别适用于仅提供 LLM 工具的场景。
• 纯 HTTP 实现：  摆脱对 SSE 的依赖，降低服务器技术栈要求，方便在普通 HTTP 服务器中集成 MCP。
• 基础设施兼容性：  “Just HTTP” 的设计使其与现有 HTTP 中间件和基础设施天然兼容，易于部署和集成。
• 向后兼容性：  协议演进平滑，现有客户端和服务端可逐步升级。
• 灵活的流式响应：  服务器可根据需要选择是否升级为 SSE 流式响应，例如在工具执行过程中推送进度通知。

示例用例：

• 无状态服务器 (LLM 工具)：  服务器无需持久化任何状态，接收 ToolListRequest 直接返回工具列表，处理 CallToolRequest 执行工具并返回 CallToolResponse，所有交互均通过单次 HTTP 请求完成。
• 无状态服务器 (流式响应)：  对于耗时操作如 CallToolRequest，服务器可升级为 SSE 连接，在工具执行期间通过 SSE 推送 ProgressNotification，完成后通过 SSE 发送 CallToolResponse 并关闭连接。
• 有状态服务器：  类似于现有方案，但需利用 Mcp-Session-Id 头进行会话管理。水平扩展部署时，通过消息总线和持久化存储 (如 Redis) 将请求路由至对应会话。

为何不选择 WebSocket？

团队曾深入讨论将 WebSocket 作为主要传输协议，但最终放弃，原因如下：

• RPC 场景开销过大：  对于类似 RPC 的无状态工具调用，WebSocket 的握手和连接维护开销不必要。
• 浏览器端限制：  浏览器 WebSocket 无法附加请求头 (如 Authorization)，且第三方库无法在浏览器端完全重写 WebSocket。
• 升级限制和复杂性：  WebSocket 仅支持 GET 请求升级，POST 请求升级需两步过程，增加复杂性和延迟。
• 避免协议碎片化：  限制官方支持的传输协议数量，避免客户端和服务端兼容性问题。

尽管当前不采用 WebSocket，但未来仍可能根据 SSE 的实际效果重新评估。

关于 Session ID 的讨论：

提案中客户端负责生成 Mcp-Session-Id 引发了关于安全性和易用性的讨论。部分开发者认为应由服务器生成 Session ID 以确保安全性，并避免客户端生成可能造成的冲突和安全风险。备选方案包括服务器在初始化握手时生成并返回 Session ID，或通过 HTTP-only Cookie 管理会话。最终方案仍在讨论中，目标是在安全性、易用性和灵活性之间取得平衡。

小结：

随着MCP的热度越来越高，协议的迭代对于生态发展都非常重要。Streamable HTTP 传输协议为MCP带来了许多优势，包括无状态服务器、与现有基础设施的兼容性以及向后兼容性。这些变更将有助于简化服务器架构、提高可伸缩性，并为开发者提供更灵活的选项，进一步提高MCP协议的竞争力。

进一步阅读，感兴趣的朋友也可以参与讨论。

• MCP协议规范^[1]
• MCP社区讨论^[2]

参考资料