MCP 协议迎来重大更新：走向完全无状态化，简化 HTTP 通信

mcp协议的重大革新：拥抱无状态的“流式http”

近期，消息通道协议(MCP) 核心技术迎来重大升级，采用“流式HTTP”传输方案，彻底告别有状态模式，简化通信，拓展应用前景。此举旨在解决原有HTTP+SSE方案的局限性。

HTTP+SSE的不足之处

之前的MCP协议依赖HTTP+SSE(服务器发送事件)进行数据传输，存在以下不足：

• 缺乏断线重连机制。
• 服务器需维持持久连接，增加负载。
• 服务器消息只能通过SSE发送。

“流式HTTP”：核心改进

为克服这些限制，“流式HTTP”方案应运而生，其关键改进包括：

• 统一接口：所有客户端与服务器的通信都通过/message(或类似接口)进行。
• SSE请求升级：服务器可将客户端请求升级为SSE连接，实现实时数据推送。
• 会话ID管理：客户端通过HTTP请求头提供会话ID，服务器可选择性地利用该ID识别会话。
• SSE流启动：客户端发送空GET请求到/message接口，建立SSE数据流。

这些改进使得MCP服务器实现完全无状态，无需维持持久连接，显著降低服务器复杂度和资源消耗，并提升了协议的兼容性。

社区积极参与

该改进方案得到了MCP社区的广泛支持，Shopify、Pydantic、Cloudflare、LangChain、Vercel和Anthropic等机构都提供了宝贵的反馈。

无状态化的优势

无状态化是本次升级的核心，它带来诸多益处：

• 简化部署和维护：无需管理会话数据的持久化和同步，简化服务器部署和扩展。
• 提升系统稳定性：单个服务器故障不会影响整体系统运行，易于实现高可用性。
• 降低资源消耗：无需维护长连接和会话状态，降低服务器资源占用和成本。

应用场景展望

无状态MCP为以下应用场景提供了新的可能性：

• 无状态工具服务器：构建无需状态管理的MCP服务器，简化工具调用流程。
• 支持流式响应的无状态服务器：即使是无状态服务器，也能利用SSE提供流式响应，例如实时推送工具执行进度。

为何选择“流式HTTP”而非WebSocket？

社区在传输方案选择上也曾考虑WebSocket，但最终选择了“流式HTTP”，原因如下：

• RPC场景的开销：对于简单的RPC(远程过程调用)场景，WebSocket会增加不必要的开销。
• 浏览器兼容性：浏览器环境下，SSE在HTTP请求头设置和第三方库实现方面更灵活。
• 协议升级复杂性：WebSocket仅支持GET请求升级，POST请求升级过程更复杂。
• 协议规范精简：MCP协议规范倾向于限制传输协议种类，避免兼容性问题。

安全性考量

无状态化也带来安全性方面的挑战，特别是会话ID管理和授权。

开发者建议将会话ID与授权环境绑定，防止滥用。 对于追求极简服务器的开发者，复杂的认证机制可能并不适用。 一些开发者建议引入HTTP-only Cookie来管理客户端会话，并实现分层会话管理，平衡安全性和灵活性。

总结与展望

MCP协议向无状态化的转变是其走向实用化和易用化的关键一步。“流式HTTP”方案的采用，有望降低MCP的部署门槛，吸引更多开发者和应用场景。虽然安全性仍需进一步完善，但MCP协议的未来发展值得期待。

相关提案:

[RFC] Replace HTTP+SSE with new "Streamable HTTP" transport #206