MCP 使用的传输协议背后的历史
MCP（模型上下文协议）是当今最流行、应用最广泛的人工智能协议之一，它从 2025-03-26 版本开始，用 Streamable HTTP 取代了 HTTP+SSE 传输机制。这标志着该协议架构的重大变革。
现在，在解释这两种传输机制的含义之前，让我们先更好地理解这一变化。
为什么AI协议需要传输机制
像 MCP 这样的 AI 协议需要传输机制来促进协议架构中不同组件之间的信息交换。
具体来说，MCP 使用 JSON-RPC 2.0 作为客户端和服务器之间的连接格式。对于 JSON-RPC 消息的传输，它依赖于标准传输机制，如 HTTP+SSE 或 Streamable HTTP（在 stdio 中 - 用于通过本地服务器上的标准输入和标准输出进行通信）。
这些专用的传输层是必需的，因为传统 HTTP 的请求-响应模型对于实时 AI 通信来说效率低下。这是因为纯 HTTP 频繁建立连接会导致高开销和延迟。相比之下，MCP 需要连续、低延迟的数据流——HTTP+SSE 和 Streamable HTTP 正是为此而设计的。
为什么从 SSE 转变到 Streamable HTTP
MCP 最初使用 HTTP+SSE 来实现远程场景下的服务器到客户端的流式传输。然而，以下三个主要限制使得这一改变变得合理：
- 不支持可恢复流：无法从断开处恢复数据流。
- 需要维护长连接：服务器需要维护长时间的、高可用的连接，消耗资源，尤其是在大 规模部署时。
- 仅允许通过 SSE 传递服务器消息：客户端必须使用单独的 HTTP POST 请求发送消息， 无法在同一通道内双向通信。
Streamable HTTP 解决了这些问题。它支持无状态通信，甚至支持按需升级到 SSE。这提高了与现代基础设施的兼容性，并确保了更稳定、更高效的通信。同时，这一转变体现了 MCP 在追求以下目标：
- 提升可伸缩性：通过支持无状态服务器和减少长连接依赖，MCP 能够更好地应对大规模并发请求，为 AI 服务的爆发式增长提供坚实基础。
- 增强鲁棒性：可恢复流的引入，使得 MCP 在面对不稳定的网络环境时，依然能够保证数据传输的可靠性，减少因网络问题导致的数据丢失或服务中断。
- 优化资源利用：减少长连接的维护成本，使得服务器资源能够更高效地分配和利用，降低运营成本。
- 拥抱未来趋势：Streamable HTTP 与现代 Web 技术栈和云原生架构更加契合，为 MCP 未来的发展和与其他技术的融合提供了更广阔的空间。
SSE
SSE（Server-Sent Events）是一种允许 Web 客户端从服务器接收自动更新的机制。这些更新被称为“事件”，并通过单个长寿命 HTTP 连接发送。
与WebSockets 不同，SSE 是单向的，这意味着数据仅从服务器流向客户端。SSE 的工作原理是服务器通过此开放连接发送事件流，通常格式为text/event-streamMIME类型。
在 MCP 中使用 HTTP+SSE
服务器必须提供两个端点：
- 客户端用于建立连接并从服务器接收消息的
SSE GET端点。 - 客户端向服务器发送
JSON-RPC消息的常规HTTP POST端点。
当客户端连接时，服务器必须发送一个端点事件，其中包含客户端将用于发送消息的 URI。所有客户端 JSON-RPC 消息都将作为 HTTP POST 请求发送到此 URI。
服务器通过打开的 SSE 连接发送流式事件来响应，模拟持久会话。具体来说，服务器消息以 SSE 消息事件的形式传递，其内容在事件数据中以 JSON 格式编码。
对于单个响应，服务器发送消息并关闭流。对于正在进行的通信，连接保持打开状态。
优点和缺点
优点：
- 流式传输大量结果：允许立即发送部分结果，允许立即发送部分结果，避免
MCP工具处理大量数据或等待外部 API 响应时的延迟。 - 事件驱动触发器：支持未经请求的服务器事件，通过警报或状态更新通知客户端有关更改。
- 简单：使用标准 HTTP，无需特殊协议或复杂设置。
缺点：
- 仅限单向：数据只能在 SSE 通道中从服务器流向客户端。客户端必须使用单独的
HTTP POST请求来发送消息。 - 长连接资源使用：维护开放连接会消耗大量服务器资源，尤其是在大规模连接时。
Streamable HTTP
在 MCP 的语境中，Streamable HTTP 是一种使用纯 HTTP 在客户端和服务器之间传输流式数据的方法。它为实时通信打开了大门，无需长连接。
虽然它仍然可以使用 SSE 来实现灵活性和向后兼容性，但不再需要该传输方式。这使得 MCP 能够支持无状态服务器，而无需维护高可用性持久连接的开销。
为什么是Streamable HTTP + 可选 SSE 而不是 WebSockets？
- 避免不必要的开销：对于简单的 RPC 调用或数据流，WebSocket 的全双工特性可能引入不必要的协议开销和复杂性。Streamable HTTP 在保持流式传输能力的同时，更加轻量。
- 更好的 HTTP 兼容性：WebSocket 的协议升级机制有时会与现有的 HTTP 基础设施（如代理、负载均衡器）产生兼容性问题，并且浏览器无法直接在 WebSocket 连接上附加 HTTP 头（如 Authorization）。Streamable HTTP 则完全兼容 HTTP，避免了这些问题。
- POST 请求的灵活性：WebSocket 的升级握手主要基于 GET 请求，这使得基于 POST 的复杂交互流程实现起来较为繁琐。Streamable HTTP 则对 POST 和 GET 请求都提供了良好的支持。
在 MCP 中使用 Streamable HTTP
在 Streamable HTTP 传输中，服务器作为一个独立进程，能够处理多个客户端连接。它使用标准的 HTTP POST 和 GET 请求进行通信。
服务器可以选择使用 SSE 将多条消息流式传输到客户端。这既适用于用于简单请求/响应工具的基本 MCP 服务器，也适用于提供更高级功能（例如流式传输和实时服务器到客户端通知）的服务器。
服务器必须公开一个支持 POST 和 GET 方法的 HTTP 端点（称为 “MCP 端点“）。
下图说明了使用 Streamable HTTP 的 MCP 客户端和服务器之间的通信流程：
为了支持恢复断开的连接并重新传递可能丢失的消息，MCP 服务器会为每个流分配 ID。这些 ID 在每个流中充当游标。
优点和缺点
优点：
- 支持无状态服务器：无需始终在线的长连接。
- 纯 HTTP：可以使用任何标准 HTTP 服务器实现，而无需
SSE。 - 基础设施友好：与常见的 HTTP 中间件、代理和托管平台兼容。
- 向后兼容：在以前的
HTTP+SSE传输基础上逐步构建。 - 可选流式传输：服务器可在需要时升级为
SSE，以实现流式传输响应。 - 解决 SSE 局限性：支持可恢复流，无需维护长连接，且允许客户端和服务器在同一 HTTP 端点进行通信（通过 POST 和 GET）。
- 效率更高：对于大负载或自定义二进制协议，数据传输更高效，没有 SSE 的事件格式 开销。
- 更强的控制力：应用可以更精细地控制缓冲策略，可能减少内存开销。
缺点：
- 暂无
SSE 与Streamable HTTP对比
| 类型 | HTTP+SSE | Streamable HTTP |
|---|---|---|
| 通信类型 | 单向（服务器→客户端） | 双向（客户端通过 GET/POST ↔ 服务器） |
| HTTP 协议的使用 | GET 用于流媒体，POST 用于客户端信息 | 从一个端点使用标准 HTTP POST 和 GET |
| 状态性 | 有状态 | 有状态，但支持无状态服务器 |
| 需要长期 HTTP 连接 | 是 | 否 |
| 要求高可用性 | 是，用于连接持久性 | 否，适用于无状态或临时服务器 |
| 可扩展性 | 有限 | 高 |
| 流媒体支持 | 是（通过文本/事件流） | 是（通过 SSE 作为可选增强功能） |
| 身份验证支持 | 是 | 是 |
| 支持可恢复性和重新交付 | 没有 | 没有 |
| 客户数量 | 多个 | 多个 |
| 在 MCP 中的使用 | 自协议版本 2025-03-26 起已弃用 | 在 2025-03-26 版协议中引入 |
| 向后兼容性 | - | 完全向后兼容基于 SSE 的客户端 |
