该文章已被 Model Context Protocol(MCP) 中文教程讲解 收录，欢迎 star 收藏。
前言
2025 年 3 月 26 日 ，模型上下文协议（Model Context Protocol，简称 MCP）引入了一项关键更新：用 Streamable HTTP 替代原先的 HTTP + SSE 作为默认传输方式。
这一变更在解决原有方案中连接不可恢复、服务端长连接压力大等问题的同时，依然保留了 SSE 带来的流式响应优势。
本文将深入解析这次更新背后的动因、技术细节以及实际应用场景。
准备好了吗？准备一杯你最喜欢的咖啡或茶，随着本文一探究竟吧。
HTTP + SSE 的缺陷
远程 MCP 通过 HTTP + SSE 的传输方式工作，存在以下问题，这也是它所被替换的根本原因：
- 不支持恢复连接
- 要求服务器保持高可用的长连接
- 服务器只能通过
SSE发送消息
不支持恢复连接
如果客户端和服务器之间的 SSE 连接中断了，就无法 "从端点继续"，只能重新开始新的连接，之前的上下文可能会丢失。
要求服务器保持高可用的长连接
服务器必须一直保持一个稳定、不中断的 SSE 长连接，否则通信就中断。
服务器只能通过 SSE 发送消息
服务器无法在已有的请求之外，主动地发送消息给客户端，除了通过专门的 /sse 通道。换句话说，它是"单向被动响应"，而不是"任意时机推送"。
Streamable HTTP
Streamable HTTP 并不是传统意义上的 流式 HTTP （Streaming HTTP），它指的是一种 兼具以下特性的传输机制：
-
以普通
HTTP请求为基础，客户端用POST/GET发请求； -
服务器可选地将响应升级为
SSE流，实现 流式传输 的能力（当需要时）； -
去中心化、无强制要求持续连接，支持
stateless模式； -
客户端和服务端之间的消息传输更加灵活，比如同一个
/message端点可用于发起请求和接收SSE流； -
不再需要单独的
/sse端点，一切通过统一的/message协议层处理。
Streamable HTTP 的优势
-
支持无状态服务器：无需维持高可用的长连接
-
纯
HTTP实现：MCP可在纯HTTP服务中实现，无需SSE支持 -
兼容基础设施：因为 "只是 HTTP"，可以与中间件和现有基础设施良好集成
-
向后兼容：是当前
HTTP+SSE传输方式的渐进式改进 -
灵活的传输方式：服务器可选择是否使用
SSE进行流式响应
从 HTTP+SSE 到 Streamable HTTP 的变化
-
移除了
/sse端点 -
所有客户端 → 服务端的消息都通过
/message（或类似端点）发送 -
所有客户端 → 服务端的请求都可以被服务器升级为
SSE，以发送通知或请求 -
服务器可以选择建立会话
ID以维护状态 -
客户端可以通过对
/message发送一个空的GET请求启动SSE流 -
该方法兼容旧版本的实现，并允许服务器保持无状态（如果有需要）
为什么不用 WebSocket？
官方团队曾认真探讨过是否应该将 WebSocket 作为远程通信的主要方式，并尝试在其基础上实现断线重连等功能。但最终决定暂时不采用 WebSocket，主要原因如下：
-
想要以
RPC风格使用MCP（例如构建一个无状态、只暴露基础工具的服务）时，如果每次调用都依赖WebSocket，将引入不必要的维护和网络开销。 -
在浏览器环境中，
WebSocket连接无法像普通HTTP请求那样附加请求头（比如Authorization），而且不同于SSE，WebSocket在浏览器中也无法由第三方库完全"模拟"实现。 -
只有
GET请求可以自动升级为WebSocket，而POST等其他HTTP方法并不支持直接升级。这就意味着如果要让POST请求使用WebSocket，需要一个额外的 两步升级 过程，增加了实现的复杂度和延迟。 -
也避免在
MCP规范中增加WebSocket的可选支持，以减少客户端与服务器间可能的兼容性组合问题（但不阻止社区自己扩展非官方的WebSocket实现） -
官方也有意避免在
MCP协议中引入WebSocket作为官方选项，以避免客户端和服务器之间因传输方式组合过多而导致的兼容性问题（当然，这并不妨碍用户基于WebSocket自行实现非官方版本）。
当然，如果将来实践中发现 SSE 并不理想，官方仍会考虑重新评估 WebSocket 的可能性。
MCP Server 示例
无状态服务器（Stateless Server）
Streamable HTTP 支持构建完全无状态、无需保持长连接的服务器架构。
以一个仅提供大语言模型（LLM）工具的服务为例，不依赖其他高级功能，可以按以下方式实现：
- 始终响应初始化请求，但无需持久化任何状态；
- 对所有传入的
ToolListRequest，直接返回一个标准的JSON-RPC响应； - 对
CallToolRequest，执行对应工具，等待其完成后，将结果通过HTTP响应体以CallToolResponse的形式返回。
支持流式输出的无状态服务器（Stateless Server with Streaming）
即使服务器完全无状态、且不支持长连接，也仍然可以利用此设计进行流式响应。
以工具调用时的进度反馈为例：
- 当收到
POST的CallToolRequest时，服务器通过响应头声明该响应将以SSE（Server-Sent Events）格式返回； - 启动工具执行逻辑；
- 在执行过程中，服务器可以通过
SSE向客户端持续发送多个ProgressNotification（进度通知）； - 执行完成后，服务器通过
SSE发送最终的CallToolResponse； - 最后，服务器关闭
SSE流，整个交互完成。
有状态服务器（Stateful Server）
对于需要维护客户端会话的服务器，整体架构可以保持与 http+SSE 的实现类似。
主要区别在于：服务器需要为客户端生成唯一的会话 ID，并要求客户端在后续所有请求中携带该 ID。
服务器可以利用会话 ID 实现 粘性路由 或消息总线中的会话定位。例如，在水平扩展的部署中（部署多台相同的 mcp server），某个 POST 请求可能被路由到任意一个节点，此时可以通过 Redis 等中间件将请求路由到关联的会话上下文，确保状态一致性。
小结
Streamable HTTP 是对 MCP 协议传输层的一次重要优化。它在保留原有 HTTP + SSE 模式优势的基础上，解决了连接不可恢复、长连接负担重、传输不灵活等问题，带来了更高的可用性与灵活性。
参考资料
你好，我是陈明勇，一名热爱技术、乐于分享的开发者，同时也是开源爱好者。
我专注于分享 Go 语言相关的技术知识，同时也会深入探讨 AI 领域的前沿技术。
成功的路上并不拥挤，有没有兴趣结个伴？