为什么 MCP 传输机制要从 SSE 转到 Streamable HTTP

为什么 MCP 传输机制要从 SSE 转到 Streamable HTTP

很久没关注 MCP 了，最近才知道 MCP 的传输机制从 2025 年 3 月 26 日版本开始，就已经使用 Streamable HTTP 替换了 HTTP + SSE。本篇文章将介绍我对 MCP 传输机制转到 Streamable HTTP 的理解。

1. SSE（Server-Sent Events）的特点与局限性

Server-Sent Events，顾名思义，是一种服务器向客户端单向推送事件的机制。它基于标准的 HTTP 连接，通过 text/event-stream MIME 类型实现。SSE 的优势在于其简洁性、浏览器原生支持以及对自动重连的内置支持，这使得它在早期实时数据推送场景中表现出色，例如股票行情、新闻更新等。

图片

然而，随着 AI 应用对数据交互复杂性和效率要求的提升，SSE 的局限性也逐渐显现：

  • 不支持可恢复流：无法从断开处恢复数据流。
  • 需要维护长连接：服务器需要维护长时间的、高可用的连接，消耗资源，尤其是在大规模部署时。
  • 仅允许服务器通过 SSE 发送消息：客户端必须使用单独的 HTTP POST 请求发送消息，无法在同一通道内双向通信。
  • 开销：每个事件都需要特定的格式化，对于高频更新的小消息会引入额外开销。

1.1 SSE 特点

  • 单向通信：服务器到客户端的单向实时通信。
  • 基于 HTTP：在标准 HTTP 连接上运行，但有专门的事件流协议。
  • 内置事件格式：支持事件类型、自动重连（带 last-event-ID 跟踪）和连接管理。
  • 浏览器原生支持：EventSource API 处理连接建立、自动重连和事件解析，简化客户端复杂性。
  • 轻量级：与 WebSocket 相比，连接更轻量，兼容现有代理、负载均衡器和安全策略。

2. Streamable HTTP 的特点与优势

Streamable HTTP 并非一个全新的协议，而是对 HTTP 协议原生流式传输能力的巧妙运用。它利用 HTTP/1.1 的 chunked transfer encoding 或 Content-Length 头部，允许服务器在不关闭连接的情况下，分块、渐进地向客户端发送数据。这种方式赋予了 MCP 协议更大的灵活性和更强的适应性。

图片

2.1 Streamable HTTP 特点

  • 基于 HTTP 分块传输：利用 HTTP 的 chunked transfer encoding 或 content-length 头部进行渐进式数据传输。
  • 数据格式灵活：不定义特定事件格式或协议结构，数据表示完全由应用定义。
  • 可选择性使用 SSE：可以继续使用 SSE 进行流式传输，但不再强制要求。
  • 支持无状态服务器：无需维护长连接，降低服务器开销。
  • 兼容性强：与现代基础设施兼容，支持 HTTP 中间件、代理和托管平台。

2.2 Streamable HTTP 优势

  • 解决 SSE 局限性：支持可恢复流，无需维护长连接，且允许客户端和服务器在同一 HTTP 端点进行通信（通过 POST 和 GET）。
  • 效率更高：对于大负载或自定义二进制协议，数据传输更高效，没有 SSE 的事件格式开销。
  • 更强的控制力：应用可以更精细地控制缓冲策略，可能减少内存开销。
  • 简化架构：一个 HTTP 端点同时支持 POST 和 GET，简化了服务器端点管理。
  • 向后兼容：在旧的 HTTP+SSE 传输协议基础上增量构建，可以保持向后兼容性。

3. MCP 切换协议的原因

MCP 从 SSE 转向 Streamable HTTP，并非简单的技术替换，而是对 AI 通信未来趋势的深刻洞察。AI 应用对实时性、数据量和交互复杂度的要求不断提高，传统的单向、长连接模式已无法满足需求。Streamable HTTP 以其灵活性、高效性和对无状态架构的良好支持，成为了更符合 AI 时代需求的传输协议。

这一转变体现了 MCP 在追求以下目标：

  • 提升可伸缩性：通过支持无状态服务器和减少长连接依赖，MCP 能够更好地应对大规模并发请求，为 AI 服务的爆发式增长提供坚实基础。
  • 增强鲁棒性：可恢复流的引入，使得 MCP 在面对不稳定的网络环境时，依然能够保证数据传输的可靠性，减少因网络问题导致的数据丢失或服务中断。
  • 优化资源利用：减少长连接的维护成本，使得服务器资源能够更高效地分配和利用，降低运营成本。
  • 拥抱未来趋势：Streamable HTTP 与现代 Web 技术栈和云原生架构更加契合，为 MCP 未来的发展和与其他技术的融合提供了更广阔的空间。

4. 与 WebSocket 的比较

在实时通信领域，WebSocket 常常被认为是全双工通信的理想选择。然而，对于 MCP 这类主要以服务器到客户端流式传输为主，偶尔需要客户端发送请求的场景，WebSocket 并非总是最佳方案。Streamable HTTP 在与 WebSocket 的权衡中展现出独特的优势：

  • 避免不必要的开销：对于简单的 RPC 调用或数据流，WebSocket 的全双工特性可能引入不必要的协议开销和复杂性。Streamable HTTP 在保持流式传输能力的同时，更加轻量。
  • 更好的 HTTP 兼容性：WebSocket 的协议升级机制有时会与现有的 HTTP 基础设施（如代理、负载均衡器）产生兼容性问题，并且浏览器无法直接在 WebSocket 连接上附加 HTTP 头（如 Authorization）。Streamable HTTP 则完全兼容 HTTP，避免了这些问题。
  • POST 请求的灵活性：WebSocket 的升级握手主要基于 GET 请求，这使得基于 POST 的复杂交互流程实现起来较为繁琐。Streamable HTTP 则对 POST 和 GET 请求都提供了良好的支持。

5. 总结

MCP 从 Server-Sent Events 到 Streamable HTTP 的演进，是其在 AI 通信领域不断探索和优化的结果。Streamable HTTP 以其对无状态、可恢复流和现有 HTTP 基础设施的良好支持，为 MCP 带来了更高的灵活性、效率和可伸缩性。

6. 参考文献