mcp协议的重大革新：拥抱无状态的“流式http”
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
近期，消息通道协议(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
