SSE与流式传输(Streamable HTTP)

SSE被冷落了十多年，终于随AI火了一把。过去大家宁可用websocket也不愿意使用SSE，以至于AI出来后，很多人认为这是个新技术。实际上它很久以前就是HTML5标准中的一部分了。

MCP兴起后，有些人认为SSE与Streamable HTTP是两个概念，其实不然。本文将理清SSE和Streamalbe HTTP两者的概念与关系，并给出实践中的一些小建议。

SSE

SSE是Streamable HTTP的一个实现:SSE不仅对请求头有要求------必须设置Content-Type: text/event-stream，而且对传输格式、数据解析做了详细约定：

除此之外还有自动重连机制，具体可见HTML5标准 html.spec.whatwg.org/multipage/s...

除了这些具体的规范外，SSE只能发送get请求，并且只能由客户端主动关闭。另外，从"text/event-stream"上可以看出，SSE聚焦于文本内容传输，要传二进制内容就比较麻烦。

总的来说，SSE是由HTML5标准规定，针对前端场景特殊规定的流式传输协议。基于SSE的流式传输，可以通过EventSource对象实现，也可以通过fetch自行处理请求/解析/重连。

Streamable HTTP

Streamable HTTP虽然与SSE一样依赖http协议中的keep-alive，但更底层和中立。

它的核心是Transfer-Encoding: chunked（http1.1），此外没有其他约束。

如果使用http2，可以不声明Transfer-Encoding，只要持续写就行了，因为http2能自动分帧。

当服务器返回的响应中缺少Content-Length头部，且连接保持开放（Connection: keep-alive）时，HTTP/1.1 协议会默认使用Transfer-Encoding: chunked编码来传输响应数据，SSE刚好满足这两个条件，因此也是chunked transfer传输的。

从这个角度来说，SSE就是Streamable HTTP传输的一个实现------SSE = Streamable HTTP + 事件编码规范。

由于Streamable HTTP并没有规定数据格式和解析方法，因此使用者可以根据场景自行协商：

css 复制代码

SSE传输：
data: {"token":"Hello"}
data: {"token":"world"}
data: [DONE]

Streamable HTTP传输：
{"type":"token","content":"Hello"}
{"type":"token","content":"world"}
{"type":"done"}

从内容上可以看出，SSE必须解析data:开头，而Streamable可传输json string line等多种格式。

为什么MCP更青睐Streamable HTTP

原因	说明
🌐 跨语言兼容	SSE 原生仅限浏览器；Streamable HTTP 适配 SDK、CLI、服务端
🧱 结构灵活	支持 NDJSON、JSON Lines、Protocol Buffers
⚙️ 更贴近底层 I/O	方便控制 chunk 大小、流速、关闭机制
🧩 多类型输出	AI 不止发文本，还要发图像、语音、函数调用等
📦 工具链统一	与现代 fetch/Response API 一致

对ai应用来说，SSE过于死板。它规定了传输格式，编码方式，无法以二进制传输。在非浏览器环境中，使用更原始的Streamable HTTP显然更合适。

流式传输的实践建议

如果没有二进制传输需求，可以使用SSE协议，服务端第三方开源工具也较多
浏览器端建议使用fetch而不是EventSource，便于传参和认证
浏览器端使用AbortController取消流式传输
服务端根据请求头的 Accept: 'text/event-stream' 判断是否以SSE格式传输（如果需要同时支持流式传输和普通分页传输）