什么是 SSE 传输（SSE Transport）？
更新于
SSE 传输（SSE Transport）在 MCP 中通常指旧版 HTTP+SSE Transport：客户端打开长期 GET Event Stream，并把消息发送到另一个 POST Endpoint；该方案已弃用，新实现应使用 Streamable HTTP。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
旧版 HTTP+SSE 契约
旧 Client 先连接 Server 的 GET SSE Endpoint。Server 发送 endpoint Event，告知 Client 应向哪个地址 POST JSON-RPC Message，随后再通过 Event Stream 下发 Server Message。这种 GET 与 POST 分离的设计属于 2024-11-05 协议版本。文档、日志和配置应明确写成 legacy HTTP+SSE，而不是只写 SSE，避免版本歧义。
当前 Streamable HTTP
Streamable HTTP 已取代旧版 HTTP+SSE。在 2026-07-28 版本中，Server 只暴露一个接受 POST 的 MCP Endpoint，每条 JSON-RPC Request 都使用独立 POST。Server 返回单个 JSON Object 或只属于该请求的 SSE Stream；这个版本没有协议握手、Mcp-Session-Id 或通用 GET Event Endpoint。
当前协议仍如何使用 SSE
SSE 仍可作为 Streamable HTTP 内部的 Response 编码，但不再是 Transport 名称。请求级 SSE Response 可在最终 JSON-RPC Response 前发送与该请求相关的 Progress 或 Log Notification；长期变更通知通过 subscriptions/listen POST 的 SSE Response 传递。关闭请求 Response Stream 即取消该请求，且不支持通过 Last-Event-ID 恢复。
迁移与兼容
新实现不应采用旧版 HTTP+SSE。仍需服务旧 Client 的 Server 可在当前 MCP POST Endpoint 之外暂时保留旧 GET 与 POST Route；Client 也只在必要时探测并回退。测试和 Telemetry 必须记录协商后的协议版本，不能仅因响应包含 text/event-stream 就推断 Session、重放策略或 Endpoint 形态。
安全与运维
远程 Transport 需要 TLS、认证、对象级鉴权、请求限制、Tenant 隔离和 Secret-safe Log。当前 Streamable HTTP Server 必须校验 Origin，本地 Server 应只绑定 Loopback。SSE Response 还需按需关闭 Proxy Buffer、为长期 Subscription 使用有界 Keep-Alive、传播取消、限制并发 Stream，并验证 Proxy、Timeout、Backpressure 与滚动发布行为。
主要特点
- 旧版身份：HTTP+SSE 指 MCP 2024-11-05 中独立的 GET Stream 与 POST Message Endpoint
- 弃用状态：新实现应使用 Streamable HTTP，既有部署应制定迁移计划
- 当前区别：SSE 可以编码 Streamable HTTP Response，但不会让 Transport 变回旧版 HTTP+SSE
- 版本化行为：Endpoint、Session、Cancellation 与 Notification 规则取决于协商的 MCP Revision
- 兼容成本：双栈 Server 需要明确 Route、Telemetry、测试与退役计划
- 远程系统控制：Origin 校验、认证、鉴权、Buffer、限额与可观测性不可省略
常见用途
- 识别旧 MCP Client 或 Server 是否仍要求 GET `/sse` 与独立 POST Message Endpoint
- 规划从旧版 HTTP+SSE 到当前 Streamable HTTP 的可度量迁移
- 在收集协议版本 Telemetry 期间暂时维持向后兼容
- 排查 Proxy 缓冲或中断请求级 SSE Response 与 Subscription Stream 的问题
- 在迁移期暴露旧 Route 前审查远程 MCP 安全控制
示例
Loading code...常见问题
SSE Transport 仍是 MCP 推荐的远程 Transport 吗？
不是。MCP 2024-11-05 的旧版 HTTP+SSE Transport 已弃用，新实现应采用 Streamable HTTP。既有系统可暂时保留 Legacy Route 兼容旧 Client，但应度量实际使用并发布迁移与退役计划。
当前 Streamable HTTP 还会使用 SSE 吗？
会。一个 POST Request 可以收到 `application/json` 或只属于该请求的 `text/event-stream` Response；`subscriptions/listen` POST 也可以产生长期 Notification Stream。但这不等于恢复已经弃用的独立 GET `/sse` Transport。
Streamable HTTP 2026-07-28 版本改变了什么？
该版本移除了通用 GET Stream Endpoint 和协议级 Session。每条 JSON-RPC Request 都通过独立 POST 发送并携带协议与路由 Metadata，Response 为 JSON 或请求级 SSE Stream；Server-to-Client Interaction 使用该版本的 Multi Round-Trip 机制。
Server 如何同时兼容新旧 MCP Client？
暴露当前 MCP POST Endpoint，并只在仍有需要时保留旧 GET 与 Message POST Route。采用协议感知的协商或探测，测试两条路径，记录实际协议版本，避免 Route 冲突，并在 Client 完成迁移后删除旧支持。
SSE 路径上线前应测试哪些故障？
应测试 Proxy Buffer、Idle Timeout、Cancellation、慢消费者、并发 Stream 上限、Keep-Alive、部分写入、滚动发布、认证过期与重复重试。日志应包含 Request ID 与协议版本，但不能记录敏感 Payload。