MCP传输层对比：HTTP+SSE与streamable HTTP的差异与实践

如果你最近在折腾MCP服务端或者把Agent接入各种工具,大概率见过这么一条报错:stream disconnected before completion: idle timeout waiting for sse。我第一次看到这行日志的时候,整个人是懵的——服务端明明没崩,客户端也没报业务错,但连接就这么断了,翻日志翻半天才发现是传输层的问题。这事说到底,是MCP的两种HTTP传输方式在背后的行为差异导致的,也就是很多人经常混淆的HTTP+SSE和streamable HTTP。

MCP(模型上下文协议)的远程调用里,传输层一直是个容易被忽略但坑最多的环节。早期大家习惯用SSE实现服务器到客户端的推送,后来规范引入streamable HTTP作为推荐传输,但SSE也没有退出历史舞台——它变成了一种响应的承载格式。这篇就针对两者的区别做个彻底拆解:为什么改、握手长什么样、生产环境里怎么踩坑、最后怎么选型。内容基于我实际部署多个MCP服务端的经验,也结合了现在社区里比较常见的报错和兼容性问题。

1. 为什么MCP传输层从独立SSE改成了streamable HTTP

1.1 SSE当初能扛起MCP的原因

MCP本身跑的是JSON-RPC 2.0,客户端往服务端发请求,服务端返回响应。这个模式如果放在普通的HTTP请求-响应模型里,本来没问题——你发一个POST /mcp,等响应回来就行。但MCP不是单纯的"调用一下拉倒",它还有个很关键的能力:服务端要向客户端主动推送消息,比如进度提醒、工具执行中的状态通知、资源的变更通知。

问题就出在这。传统HTTP模型里,服务器想把数据推给客户端,不外乎轮询、WebSocket、SSE这几种。轮询浪费请求,WebSocket重量级且改造大。SSE胜在简单——它本质是一段HTTP长连接,服务端往这条连接里一段一段写文本事件流,客户端用EventSource或者fetch的方式读取就完事。MCP早期就选了SSE作为服务端主动推送的通道,配合一个独立的POST接口让客户端往回发请求。

这个设计在当时很合理,至少把"双向通信"在HTTP语义里跑通了:客户端发JSON-RPC请求走POST,服务端把结果和通知都塞回SSE流里。很多早期的MCP SDK和参考实现都是这么做的,双端点模式——一个/sse端点供客户端连接,一个/messages端点供客户端发送实际请求,中间通过session_id把两者绑起来。

1.2 双端点设计在生产环境里暴露的问题

接入真实项目之后,这套设计开始暴露出一堆让人头疼的问题。

第一个问题是每个客户端都需要一条常驻长连接。SSE连接不是用完即走的,它从建立到会话结束会一直占着。你想想,如果有几百个客户端都没事干地挂着,光连接数就够呛。对网关、容器平台、负载均衡器来说,长连接意味着保活参数、超时时间、连接上限都要单独调。而且SSE长连接最喜欢的路径是直线一路通到服务端,中间只要隔了一层代理,代理的超时策略就可能把连接切了。

第二个问题是session_id的传递方式。旧方案里,session_id是放在URL查询参数里的,比如/messages?session_id=abc123。放在URL里会导致几个副作用:网关日志会完整记录下来,不友好;很多API网关做路径鉴权时,没法很自然地把这个参数纳入标准化流程;调试的时候复制粘贴URL也容易带上一堆无关参数,丑陋且易错。

第三个问题是连接状态让水平扩展变得很尴尬。SSE连接生命周期内,请求必须路由到持有这条连接的同一台实例,不然服务端推送给客户端的消息就没法保证到达。这就是所谓的"粘性会话"。在K8s多副本、弹性伸缩的环境下,粘性会话几乎是反模式——节点扩容缩容、副本重启都可能打断正在进行的SSE会话。

1.3 streamable HTTP做对了什么

streamable HTTP作为新版推荐传输,核心思路是:回归HTTP本身。

它把MCP端点收敛成单个URL,客户端发请求就用一个POST,服务端的响应直接在HTTP响应体里返回;如果服务端需要异步推消息,也可以把这个响应变成SSE流。也就是说,SSE不再是一个"独立的传输通道",而是变成了"一种响应格式"。老版那种双端点、每个客户端一条常驻连接、session_id挂URL里的设计,被统一成普通HTTP语义加可选的流式响应。

这种变化带来的好处很直接:单个URL对网关配置友好;请求和响应尽可能在同一个HTTP事务里完成;支持无状态模式,会话信息通过Mcp-Session-Id请求头传递,而不是埋进URL。整个模型从"两条通道、一个标识符强行配对"变成"一个端点、按需流式返回",至少从接入成本的角度看,干净了很多。

这也解释了为什么你在2025年后的MCP规范文档里,看到推荐传输方式变成了streamable HTTP。它不是要彻底消灭SSE,而是把SSE从主导者降为工具——需要长推送的时候用它,不需要的时候就老老实实返回一个JSON。这一点特别重要,后面很多坑和选型判断都围绕它展开。

2. 同一个请求,两份报文:两种方式的连接与握手过程

2.1 老版HTTP+SSE的握手全流程

想要真正理解区别,最好的方式是亲手把一次MCP交互跑出来看。我先说老方案,也就是HTTP+SSE双端点模式。

第一步,客户端发一个GET到SSE端点,比如GET /sse。这个请求的关键在于它不会被立即响应——连接挂起,服务端准备好往下推数据。如果服务端需要会话标识,它会在SSE连接建立后,在事件流里发送一个endpoint事件,里面带着客户端的回发地址,通常是/messages?session_id=xxx。

第二步,客户端解析到这个endpoint之后,往这个地址发POST,内容是一个JSON-RPC 2.0请求。比如初始化的时候就是这样的报文:

json复制{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {},
    "clientInfo": {"name": "test-client", "version": "1.0.0"}
  }
}

第三步,服务端不是直接在POST的响应里返回初始化结果,而是把JSON-RPC响应封装成一个message事件,塞回那条SSE连接里推给客户端。也就是说,客户端的请求和丢过来的结果,根本不在同一个HTTP事务里。

完整的结果响应在SSE流里长这样:

text复制event: message
data: {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","serverInfo":{"name":"test-server","version":"1.0.0"},"capabilities":{}}}

整个过程中,客户端看到的SSE连接是唯一的"下行通道",POST只是"上行通道"。任何响应、通知都走下行。这就是为什么代理和网关一旦对长连接不友好,整个通信就崩了——它们的超时逻辑根本不知道这条连接是一个持续性的会话通道。

2.2 streamable HTTP的握手和调用

换成streamable HTTP之后,整个流程简单多了。

客户端直接向单一MCP端点发起POST,内容同样是那封initialize请求:

bash复制curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test-client","version":"1.0.0"}}}'

服务端直接在HTTP响应里返回结果,如果走JSON格式就是:

json复制{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "serverInfo": {"name": "test-server", "version": "1.0.0"},
    "capabilities": {}
  }
}

注意这时候响应头里可能会多一个Mcp-Session-Id字段。如果服务端返回了这个字段,说明它开启了有状态模式,后续的请求都要带上这个头;如果没返回,那就是无状态模式,每次请求都独立处理,这直接影响后面负载均衡的配置策略。

之后的工具调用、资源读取等请求,客户端都往同一个端点POST,只需要在请求头里带上Mcp-Session-Id就行。服务端可以纯JSON返回,也可以返回Content-Type: text/event-stream的SSE响应。两种返回方式客户端都要能解析,这也是为什么streamable HTTP的客户端在手握"普通响应"和"流式响应"两种形态时,代码要比老版多一层判断。

2.3 服务端主动通知:streamable HTTP里怎么做

MCP场景里服务端主动发起通知,最典型的就是服务端能力变更或者进度事件。老方案里,这事天然由SSE长连接承载——连接在,推送就一直通。换成streamable HTTP之后,这层能力不是凭空消失的,而是需要客户端主动发起一个GET请求,把连接挂起作为事件流,服务端才能借此推消息。

也就是说,如果服务端想用"服务端推动"的能力,客户端得先开一个GET流,比如:

bash复制curl -N http://localhost:3000/mcp \
  -H "Accept: text/event-stream" \
  -H "Mcp-Session-Id: session-abc"

这条GET连接保持打开,服务端往里面写事件。它和响应POST请求时返回的SSE流在概念上有区别:POST流的生命周期跟着单个请求走,GET流的生命周期跟着整个会话走,更像老版SSE连接在新协议里的对应物。

这里有个实用的判断标准:如果你的MCP客户端主要做工具调用、喂结果给Agent,不太需要服务端推消息,那streamable HTTP配合普通JSON响应就够用;如果你依赖服务端主动通知,那仍然要处理和长连接相关的超时、重连、代理兼容问题——即使换了协议,这类问题不会自动消失。

3. 真正要记住的差异:逐项对照streamable HTTP与HTTP+SSE

3.1 差异对照表

几个核心维度的区别,我用一张表直接列出来,看完这张表基本就能回答"MCP中streamable HTTP与SSE协议的区别"了:

3.2 响应的形态:JSON、SSE流、还是通知

很多人纠结一个问题:streamable HTTP都叫这名了,它和SSE到底还算不算一伙的?我的理解是:它用STREAMING的形式承载HTTP响应,但不再是老版那种"所有响应都从SSE连接里流出来"的模型。它给了服务端一个选择权:

• 服务端可以立刻处理完,返回一个普通JSON响应。客户端和网关都不用管什么流不流,最省事。
• 服务端想分批吐结果,比如一次工具调用要长时间执行、日志一堆,那就声明Content-Type: text/event-stream,在响应体里流出多条JSON-RPC消息。

这个差异直接影响编程模型。老版方案里,客户端要解码SSE事件流,从一堆event: message里剥出data,再解析data里的JSON-RPC报文,每一天都像在和一个文本协议较劲。新版方案里,客户端更常见的是直接拿到完整JSON,只有特定场景才启用流解析。代码的复杂度也从"默认开SSE解析"变成"根据Content-Type判断解析方式",这本身就少了很多无谓的坑。

3.3 会话的创建、维持与终止

会话管理在两种方式里的差别,是生产运维最关心的一块。

老版方案没有标准的会话终止方式。客户端想结束会话,大概率直接断开SSE连接,服务端靠连接断开感知会话结束。如果客户端没有断开干净,服务端就得靠超时回收,很容易堆积残留会话。

streamable HTTP把会话生命周期拉回到HTTP语义里。服务端在initialize响应里给出Mcp-Session-Id,客户端在后续请求里带这个头,会话终止时可以发一个DELETE请求,服务端回收资源。这个设计对运维友好,因为释放时机的语义明确了;对API网关也友好,因为认证、限流、日志都可以通过在HTTP层识别一个标准化Header来完成,而不是去解析URL里的裸参数。

当然,引入Mcp-Session-Id之后也有新的问题:跨多个副本时,如果服务端是有状态的,那么session必须能够被所有副本共享,或者负载均衡器要做会话保持。这也是为什么streamable HTTP特意支持无状态模式——如果你处理的请求不带Mcp-Session-Id,服务端就不维护会话,每个请求都独立,负载均衡平滑多了。代价是你没法享受服务端为会话缓存的上下文。MCP本身就是无状态应用层协议,无状态MCP很少,但认证和授权是要处理的,这个取舍得自己衡量。

4. 部署环境里最容易踩的坑:代理、超时与连接复用

4.1 那个让我怀疑人生的报错:stream disconnected before completion

回到文章开头那个报错:stream disconnected before completion: idle timeout waiting for sse。这行日志我查了很久,最后定位到是代理层的问题。

当时我的架构是:客户端 → Nginx反代 → MCP服务端。Nginx对上游连接有一个read超时,默认值是60秒;SSE长连接挂那儿等事件,超过60秒没有新数据,Nginx就把连接切了。服务端认为会话断了,客户端还在等推送,于是日志里就出现这句"idle timeout waiting for sse"。

排查链路可以按下面几步来,如果你也遇到类似情况,可以参考:

1. 先确认断开具体发生在哪一跳。分别直连服务端、绕过代理测试,如果直连没问题,多半是代理或负载均衡的锅。
2. 看代理的超时配置。Nginx关注proxy_read_timeout;云厂商的LB/CDN关注各自的idle timeout。SSE这类长连接事件的间隔越长,越容易触发空闲超时。
3. 关注代理层对响应流的缓冲策略。Nginx如果开启了proxy_buffering on,它会把上游的SSE数据攒到一定量再发给客户端,导致客户端看到的事件延迟异常,甚至等不到数据。这种情况需要proxy_buffering off或者对text/event-stream响应禁用缓冲。
4. 如果中间的代理会自动拦截长连接,考虑用streamable HTTP的按需流特性,把连接占用压到最小。

这个报错本质不是MCP特有的问题,而是SSE长连接在大规模部署时都会遭遇的宿命。streamable HTTP能在一定程度上缓解,因为很多响应是普通的、立刻返回的JSON请求—响应,不需要长时间挂连接;但只要你开了SSE响应或GET通知流,超时、代理缓冲、重连逻辑就依然是绕不开的功课。

4.2 网关路径重写对事件流的隐形伤害

还有一个常见坑,很多时候是网关干的:路径重写。

老版双端点设计对网关特别敏感。比如你把MCP服务挂在/mcp前缀下,网关把前缀strip掉再把请求转发给上游。POST消息端点也许没问题,但SSE端点建立时,endpoint事件里返回的那个回发URL是服务端生成的。如果服务端不知道外部前缀,生成的URL就可能指向内网路径,客户端拿着地址根本发不通。

streamable HTTP因为只有一个端点,服务端从请求头里的Host和前缀构造URL时会少一些歧义。但如果你在网关层把请求路径改掉了,服务端拿到的还是内部路径,此时客户端要么配置里硬编码完整外网URL,要么由网关在转发时改写Location、SSE事件里的URL引用,操作起来依然不轻松。我的建议是:在网关调试MCP接口时,先开debug把实际转发路径和上游看到的原始路径打出来看一遍,不然后面排查CORS和路径问题会非常头痛。

4.3 会话亲和与水平扩展的取舍

如果你部署的是多副本MCP服务,大方向上有两种玩法:

一种是走streamable HTTP的有状态模式。服务端在initialize响应里返回Mcp-Session-Id,后续请求都往同一个服务端实例路由,这就需要负载均衡器开启会话保持(比如Nginx的ip_hash、云LB的sticky session)。优势是服务端可以缓存每个会话的上下文;劣势是节点重启后会话失效、扩缩容时要小心已有的连接被打断。

另一种是走无状态模式。服务端不返回Mcp-Session-Id,每个请求都独立、无上下文依赖,任何副本都能处理。这让水平扩展轻松很多,但你也放弃了服务端对会话上下文的优化。对大多数"一次调用、马上返回"的工具型MCP服务来说,无状态是更省心的选择;只有需要服务端持续维护上下文的长流程任务,才值得选择有状态模式并接受粘性会话的约束。

4.4 客户端SDK兼容性

还有一个很容易忽略的坑,是SDK版本和服务端实现的匹配问题。

老版本的MCP客户端SDK默认走双端点SSE,拿到/sse端点就去连,服务端如果已经升级到streamable HTTP的单一端点,它可能找不到/sse这个路径,或者连上之后拿不到预期的事件流。反过来,新版本SDK的老服务端也可能触发兼容性问题。

解决办法并不复杂,部署的时候先确认两个事:第一,服务端支持的MCP规范版本和传输方式;第二,客户端SDK里面对应传输配置的开关或构造器。很多SDK已经同时支持两种传输,但默认值和配置名不太一样。我自己的习惯是,服务端注册到网关之后,第一件事就是拿curl手动跑一遍initialize和tools/list,确认响应格式是期望的JSON或SSE,再把这套请求模板作为后续排查的依据。宁可先手动验证,不要直接上代码,否则报错会混在一起。

5. 迁移与选型:是全部都换成streamable HTTP,还是按场景来

5.1 什么时候值得升级

看到这里的读者,大概率已经有一个基于老版HTTP+SSE的MCP服务,或者正打算新建一个。我不建议你听风就是雨、立刻全量迁移,先看几点。

如果你的服务只是给本地局域网里的单机客户端用,SSE双端点和streamable HTTP的差别其实没那么大,长连接占用一两百条也不至于压垮机器。此时迁移的主要收益是代码结构统一和去掉URL参数鉴权,迁移优先级不高。

如果你的服务要暴露到公网、要走CDN或API网关、要面对大量客户端连接,那么streamable HTTP带来的收益就很实际:单端点、无状态支持、减少常驻连接、会话头标准化,这几个特性直接命中生产环境的痛点。此时迁移是划算的,因为它能大幅降低中间环节的故障概率。

5.2 两种传输方式的场景对照

为了帮助你快速判断,我按典型场景列个对照,你可以自己对号入座:

坦白说,现在的社区趋势是兼容并包:主流SDK普遍保留对两种传输的支持或至少提供转换路径。你在迁移时不用删掉老端点,可以先把新端点跑通,再逐步切流量,切完观察会话建立和推送行为,再关闭老端点。

5.3 我实际的操作顺序

最后分享一下我自己在做这类迁移时的一套固定操作顺序,踩过几次坑之后沉淀下来的:

1. 先确认当前MCP Server实现了哪个版本的规范,是只支持SSE,还是支持streamable HTTP。这决定了后面所有动作。
2. 在服务端配置里启用streamable HTTP端点,保留老端点临时共存。很多SDK的构造器里会区分"HTTP+SSE"和"Streamable HTTP"两种模式,配置项一眼能找到。
3. 用curl手动走一遍完整生命周期:initialize拿到Mcp-Session-Id,带这个头调tools/list,再调一个实际能执行的操作,观察返回的是普通JSON还是SSE流。这个过程能确认服务端的批处理和流式路径都没问题。
4. 如果要用服务端推送通知,再单独验证GET事件流能否正常建立、收到ping或通知事件。很多代理会在这里出问题,前面讲的idle timeout就是典型。
5. 流量切换之前,先把网关的超时、缓冲、会话保持策略调好。不提前做这一步,切完必出事。
6. 观察一段时间日志,确认没有stream disconnected、message not received、session not found这类错误,再移除老端点。

这套流程走下来,我还没有一次翻车过。比起一上来就改代码改SDK,先手动摸清服务端行为,再动客户端代码,往往能省下好几个小时的排查时间。

说到底,streamable HTTP和SSE在MCP里的区别,不只是一个技术选型问题,它映射的是"把AI工具调用接入真实线上系统"这件事的复杂度——连接怎么管、会话怎么认、代理怎么过、扩展怎么做。把传输层理解透了,后面把MCP服务接入IDE、接入Agent平台、接入自动化流水线这些更上层的应用,都会顺手很多。