在本指南中，您将看到
- MCP 传输技术的历史，以及从 SSE 到 Streamable HTTP 转变的原因。
- 什么是 SSE，以及旧版 MCP 中如何使用 SSE。
- 什么是流式 HTTP，以及如何在当前版本的 MCP 中应用。
- SSE 和可流式 HTTP 的比较汇总表。
- 如何随时了解协议规范的最新发展。
让我们深入了解一下！
MCP 使用的传输协议背后的历史渊源
MCP（模态上下文协议）是当今最流行、使用最广泛的人工智能协议之一，从协议版本 2025-03-26 开始，它用可流 HTTP取代了HTTP+SSE传输机制。这标志着该协议的架构发生了重大变化。
现在，在解释这两种传输机制是什么之前，让我们先来更好地理解这种变化。
人工智能协议为何需要传输机制
人工智能协议（如 MCP）需要传输机制来促进协议架构中不同组件之间的信息交换。
具体来说，MCP 在客户端和服务器之间使用JSON-RPC 2.0作为线格式。JSON-RPC 消息的传输依赖于标准传输机制，如 HTTP+SSE 或 Streamable HTTP（其中stdio用于本地服务器上的标准输入和标准输出通信）。
之所以需要这些专门的传输层，是因为传统HTTP 的请求-响应模型对于实时人工智能通信来说效率低下。这是因为普通 HTTP 会因频繁的连接设置而带来高开销和延迟。相比之下，MCP 需要连续、低延迟的数据流，而 HTTP+SSE 和 Streamable HTTP 正是为处理这些数据流而设计的。
为何做出改变
MCP 最初使用 HTTP+SSE 在远程场景中实现服务器到客户端的流媒体传输。然而，这三个主要限制因素证明了改变的合理性：
- 不支持可恢复流。
- 要求服务器保持长期、高度可用的连接。
- 只允许通过 SSE 发送服务器信息。
可流 HTTP 解决了这些问题。它实现了无状态通信，甚至支持 SSE 的按需升级。这提高了与现代基础设施的兼容性，并保证了更稳定、更高效的通信。
从 HTTP+SSE 过渡到可流 HTTP 的影响
从 HTTP+SSE 过渡到流式 HTTP 作为传输协议对 MCP 来说是一个重要的变化。它为协议的实现带来了显著的变化，要求许多第三方 MCP 客户端和服务器库进行调整。
不过，截至本文撰写之时，MCP 客户端和服务器仍可保持与过时的 HTTP+SSE 传输的向后兼容性。
SSE（服务器发送事件）
SSE（服务器发送事件）是一种允许网络客户端从服务器接收自动更新的机制。这些更新被称为 “事件“，通过单个长期 HTTP 连接发送。
与WebSockets 不同，SSE 是单向的，即数据只从服务器流向客户端。SSE 的工作原理是服务器通过打开的连接发送事件流，通常格式为text/event-streamMIME类型。
在 MCP 中使用 HTTP+SSE
这就是 MCP 在2024-11-05 版本中对 SSE 的依赖：
服务器必须提供两个端点：
- SSE GET 端点，供客户端建立连接并从服务器接收信息。
- 常规 HTTP POST 端点，供客户端向服务器发送 JSON-RPC 消息。
当客户端连接时，服务器必须发送一个端点事件，其中包含客户端用来发送信息的 URI。然后，所有客户端 JSON-RPC 消息都会以 HTTP POST 请求的形式发送到该 URI。
服务器通过打开的 SSE 连接流式传输事件，模拟持久会话。具体来说，服务器消息以 SSE消息事件的形式发送，其内容在事件数据中编码为 JSON。
对于单次响应，服务器会发送信息并关闭数据流。对于持续通信，连接保持打开。
优点和缺点
这些是在 MCP 中使用 SSE 的主要利弊：
👍流式传输大量结果：允许立即发送部分结果，避免在 MCP 工具处理大型数据或等待外部 API 响应时出现延迟。
事件驱动触发器：支持非调用服务器事件，通过警报或状态更新通知客户端有关变化。
简单：使用标准 HTTP，无需特殊协议或复杂设置。
👎仅限单向：数据只能在 SSE 通道中从服务器流向客户端。客户端必须使用单独的 HTTP POST 请求来发送信息。
👎长期使用连接资源：保持开放连接会消耗大量服务器资源，尤其是在大规模情况下。
可流式 HTTP
就 MCP 而言，可流 HTTP 是一种使用纯 HTTP 在客户端和服务器之间进行数据流传输的方法。它为实时通信打开了大门，而无需长期连接。
虽然它仍可使用 SSE 以获得灵活性和向后兼容性，但已不再需要这种传输方式。这样，MCP 就能支持无状态服务器，而无需维护高可用性的持久连接。
ℹ️号外：为什么是可流式 HTTP + 可选 SSE 而不是 WebSockets？
- 使用 WebSockets 进行简单的无状态 RPC 调用会增加不必要的网络和运行开销。
- 浏览器无法在 WebSockets 上附加
授权等标头，而且与 SSE 不同，WebSockets 无法用标准 HTTP 工具重新实现。 - WebSocket 升级仅适用于 GET 请求，由于需要升级步骤，基于 POST 的流量变得复杂和缓慢。
MCP 中的可流式 HTTP
在可流 HTTP 传输中，服务器作为一个独立进程，能够处理多个客户端连接。它使用标准的 HTTP POST 和 GET 请求进行通信。
服务器可选择使用 SSE 将多条信息流传输到客户端。这既适用于简单请求/响应工具的基本 MCP 服务器，也适用于提供流媒体和服务器到客户端实时通知等更高级功能的服务器。
服务器必须公开一个支持 POST 和 GET 方法的 HTTP 端点（称为 “MCP 端点“）。
下图说明了使用可流 HTTP 的 MCP 客户端和服务器之间的通信流：
为了支持恢复中断的连接和重新传送可能丢失的信息，MCP 服务器会按数据流分配 ID。这些 ID 在每个数据流中充当光标。
鉴于可能的交互作用多种多样，完整的实施细节请参阅 MCP 官方文档。
优点和缺点
这些是在 MCP 中使用可流 HTTP 的主要优势：
支持无状态服务器：无需始终在线的长期连接。
👍普通 HTTP：可使用任何标准 HTTP 服务器实现，无需 SSE。
基础设施友好：与常见的 HTTP 中间件、代理和托管平台兼容。
向后兼容：在以前的 HTTP+SSE 传输基础上逐步发展。
👍可选流式传输：服务器可在需要时升级为 SSE，以获得流式响应。
注：在撰写本文时，Streamable HTTP 传输机制没有值得一提的缺点。
SSE 与可流式 HTTP：简要比较
请比较下表中的 SSE 与可流 HTTP 两种传输机制：
| 方面 | HTTP+SSE | 可流式 HTTP |
|---|---|---|
| 通讯类型 | 单向（服务器 → 客户端） | 双向（客户端通过 GET/POST ↔ 服务器） |
| HTTP 协议的使用 | GET 用于流媒体，POST 用于客户端信息 | 从一个端点使用标准 HTTP POST 和 GET |
| 状态性 | 有状态 | 有状态，但支持无状态服务器 |
| 需要长效 HTTP 连接 | 是 | 没有 |
| 要求高可用性 | 是，用于持续连接 | 否，适用于无状态或短暂服务器 |
| 可扩展性 | 有限公司 | 高 |
| 流媒体支持 | 是（通过文本/事件流） |
是（通过 SSE 作为可选增强功能） |
| 身份验证支持 | 是 | 是 |
| 支持延期和重新交付 | 没有 | 没有 |
| 客户数量 | 多个 | 多个 |
| 在 MCP 中的使用 | 自协议版本2025-03-26起已停用 |
在2025-03-26版协议中引入 |
| 向后兼容性 | – | 与基于 SSE 的客户端完全向后兼容 |
未来的 MCP 运输方法
MCP 于 2024 年 11 月发布，因此仍是一个非常年轻的协议。从这个角度来看，HTTP 1.1–使用最广泛的版本–已经存在了近 20 年。
因此，MCP 规范仍在不断发展也就不足为奇了。就像推出几个月后，社区决定从 SSE 过渡到 Streamable HTTP 一样，更多的变化可能很快就会发生。
请查看MCP 官方 GitHub 存储库上的讨论页面，了解最新信息。您还可以通过 MCP 网站查看即将发布的协议版本的最新草案。
结论
在这篇 SSE vs Streamable HTTP 对比博文中，您了解了 MCP 从 SSE 过渡到 Streamable HTTP 的原因。特别是，您了解了这两种传输机制是什么，以及它们如何影响流行人工智能协议 MCP 中的信息传输。
正如这里所解释的，第三方 MCP 服务器如果想遵循最新的、非过时的 MCP 规范，就必须实施 Streamable HTTP。如果您正在寻找一款最新、功能强大、特性丰富的 MCP 服务器，请访问Bright Data 的 MCP 服务器。
Bright Data 的 MCP 服务器基于最新版本的fastmcp 构建，确保完全支持 Streamable HTTP，同时保持与 SSE 的向后兼容性。它提供 20 多种工具，可利用新鲜的网络数据、任何网页上的代理浏览器交互等扩展您的人工智能工作流程。
如需完整教程，请参阅我们的文章：将 Google ADK 与 MCP Server 集成用于人工智能代理开发。
立即免费创建 Bright Data 账户，测试我们的基础架构，为您的人工智能代理和应用提供动力！
支持支付宝等多种支付方式
