8.4 SSE 传输:旧版的遗留

文档摘要

8.4 SSE 传输:旧版的遗留本节摘要:本节讲 MCP 的旧版 HTTP 传输——SSE(Server-Sent Events)。它在 2025-03-26 协议被流式 HTTP 取代,但仍能工作。本节讲清它的工作机制(双连接模型:POST 发请求 + SSE 收响应)、它为什么被取代(双连接复杂、基础设施不友好)、以及新代码该选什么。这一节相对短——SSE 是历史包袱,知道它存在、理解它为何被弃就够了,新项目别用。

8.4 SSE 传输:旧版的遗留

本节摘要:本节讲 MCP 的旧版 HTTP 传输——SSE(Server-Sent Events)。它在 2025-03-26 协议被流式 HTTP 取代,但仍能工作。本节讲清它的工作机制(双连接模型:POST 发请求 + SSE 收响应)、它为什么被取代(双连接复杂、基础设施不友好)、以及新代码该选什么。这一节相对短——SSE 是历史包袱,知道它存在、理解它为何被弃就够了,新项目别用。

一、SSE 的工作机制

SSE 传输用了一个双连接模型——一个连接发请求,另一个连接收响应:


客户端                              服务端
┌──────────────┐                   ┌──────────────┐
│              │   POST /message   │              │
│   Client     │ ────────────────► │ MCPServer    │
│              │                   │              │
│              │   GET /sse        │              │
│              │ ◄──────────────── │              │
│              │   (SSE 长连接)    │              │
└──────────────┘                   └──────────────┘

客户端先开一个 GET /sse 长连接,服务端通过这个连接持续推送消息(SSE 流)
客户端要发消息时,用 POST /message 发送

这个模型源于「SSE 是单向的(服务端→客户端)」,所以要单独开一个 POST 通道发客户端→服务端的消息。

二、SSE 的双连接问题

双连接模型带来几个实际问题:

问题	说明
状态协调难	两个连接要共享会话状态,实现复杂
基础设施不友好	很多反代/防火墙对长连接 SSE 处理不好
连接管理重	要维护两个连接的生命周期、断线重连
错误处理复杂	哪个连接断了?怎么恢复?

这些问题在流式 HTTP(单端点)里都不存在。这就是 SSE 被取代的核心原因。

三、流式 HTTP 如何解决

回顾第 8.3 节,流式 HTTP 用单一端点(POST /mcp),响应既可以是 JSON 也可以是 SSE 流——一个连接双向:


流式 HTTP(取代 SSE):
   客户端 POST /mcp(带请求体)
   服务端响应:
      - 简单场景:普通 JSON
      - 流式场景:SSE 流(同一个响应里)
   → 单端点、单连接、双向

对比 SSE 的双连接,流式 HTTP 的单端点模型简单得多,且与普通 HTTP 服务无异,基础设施友好。

四、SSE 的现状

SSE 在当前 SDK 里:

维度	现状
能否工作	✅ 仍能工作,SDK 支持
官方推荐	❌ 不推荐,已弃用
新代码	❌ 别用,用流式 HTTP
未来	可能逐步移除


# SSE 服务端启动(不推荐,仅展示)
mcp.run("sse")    # 能跑,但新代码别这么写

⚠️ 注意:别在新项目里用 SSE。如果你看到老教程或存量代码用了 SSE,理解它在干什么,但规划迁移到流式 HTTP。流式 HTTP 在所有方面都比 SSE 好,没有理由新项目还用 SSE。

五、什么时候还会遇到 SSE

虽然不推荐,你仍可能在这些场景遇到 SSE:

场景	说明
维护老项目	存量代码用了 SSE,得理解
老教程/资料	网上旧文章可能讲 SSE
特定客户端	某些老客户端只支持 SSE
过渡期	迁移过程中 SSE 与 HTTP 并存

遇到时记住两点:

SSE 是双连接模型(POST 发、SSE 收),与流式 HTTP 的单端点不同
新代码用流式 HTTP,SSE 是过渡

六、从 SSE 迁移到流式 HTTP

如果你有存量 SSE 代码,迁移到流式 HTTP 通常很顺——因为业务代码不变(传输解耦,第 8.1 节):


# 迁移前(SSE)
mcp.run("sse")

# 迁移后(流式 HTTP)
mcp.run("streamable-http")

业务代码(工具/资源/提示词)完全不动,只改传输配置。客户端侧也类似,从 SSE 客户端改成流式 HTTP 客户端(第 10 章)。

迁移的注意点:

注意点	说明
端点路径	SSE 用 `/sse` + `/message`,流式 HTTP 用 `/mcp`,客户端连接地址要改
双连接→单端点	客户端不再需要开两个连接
会话管理	流式 HTTP 的会话模型不同,测试要验证

💡 技巧:迁移时先在测试环境验证,别直接改生产。虽然业务代码不变,但传输行为细节(连接、会话、断线)可能有差异,测试能发现潜在问题。

七、SSE 与流式 HTTP 的完整对照

用一张表收尾,把两者的差别压缩:

维度	SSE(旧,弃用)	流式 HTTP(新,主力)
连接模型	双连接(POST + SSE)	单端点(POST 或 SSE 响应)
端点	`/sse` + `/message`	`/mcp`
复杂度	高	低
基础设施	不友好	友好
无状态支持	难	易
状态	已弃用	主力
新代码	❌ 别用	✅ 推荐

本节要点回顾

SSE 是旧版 HTTP 传输,2025-03-26 被流式 HTTP 取代,仍能工作但已弃用。
双连接模型:GET /sse 收响应 + POST /message 发请求,复杂且基础设施不友好。
被取代的原因:双连接状态协调难、基础设施不友好、连接管理重。
流式 HTTP 用单端点解决,一个连接双向,简单且与现代基础设施兼容。
新代码别用 SSE,用流式 HTTP;遇到存量 SSE 理解即可,规划迁移。
迁移很顺:业务代码不变(传输解耦),只改传输配置。
迁移注意:端点路径变(/sse→/mcp)、双连接→单端点、测试会话行为。

SSE 清楚了,最后一节讲内存传输与传输安全。