[技术调研/Agent/数据传输] AI 应用的数据传输方案：SSE / Streamable HTTP(MCP) / WebSocket‑Transport(RFD‑MCP) / 标准 WebSocket

1 AI 应用的数据传输方案

术语简释

  • SSE：Server‑Sent Events，HTTP 单向流式，服务端推、客户端不能发

  • WebSocket：标准双向长连接协议

  • Streamable HTTP（MCP 协议定义）：MCP 规范里的流式 HTTP 传输，单请求多 chunk 流式响应，支持会话复用

  • WebSocket Transport(RFD)：MCP 的 WebSocket transport，底层就是 WebSocket，MCP 封装后的传输层

综合对比

特性 SSE(Server‑Sent Events) 标准 WebSocket Streamable HTTP(MCP) WebSocket Transport(RFD‑MCP)
底层协议 HTTP/1.1~HTTP2，基于普通 HTTP 响应 HTTP 握手后升级为 WS 二进制帧 标准 HTTP POST，chunked 分块响应 HTTP 握手升级为 WebSocket 帧
通信方向 单向：服务端→客户端，客户端只能初始请求，连接建立后客户端无法发送新消息 全双工双向：客户端、服务端随时互发消息 半双工，请求‑流式响应；一轮请求返回多段流式 chunk；如需客户端发消息，需要发起新 HTTP 请求 全双工双向，和原生 WebSocket 能力一致，MCP 消息封装
连接模型 长连接，单个 HTTP 响应持续打开 持久长连接，一条连接持续交互 无持久长连接；每个客户端发送消息都发起新 POST 请求，响应为 chunk 流；会话靠 header/cookie 维护 单条 WebSocket 长连接，整个会话复用同一连接
消息编码 文本，data: xxx\n\n事件格式 文本 / 二进制都支持 MCP JSON 消息，HTTP chunk 分片 MCP JSON 消息，WebSocket 帧分片
浏览器原生支持 ✅原生 EventSource API ✅原生 WebSocket API ❌无原生 API，需要手动 fetch + 读取 response stream ✅浏览器原生 WebSocket API
跨域 受 CORS 限制，简单跨域 需要服务端配置 ws 跨域 受 CORS 限制 ws 跨域配置
网络中断重连 浏览器 EventSource 自带简单重连 需要业务自己实现重连逻辑 业务层自己处理重试、会话恢复 业务层实现重连
适用 AI 场景 LLM 流式输出，只需要看返回，不需要频繁向服务端发指令 AI Agent 双向交互，工具调用、多轮实时对话，客户端频繁发消息 MCP 协议推荐传输；适合服务端不方便开放 WebSocket；云环境、网关 / 代理友好；无长连接占用 MCP 双向交互；Agent 实时工具调用；频繁双向消息交互
网关 / 代理兼容性 绝大多数网关、CDN 支持 部分老旧代理会切断长连接 最好，完全普通 HTTP，几乎所有代理、负载均衡、云服务商兼容 部分代理对 ws 长连接有超时切断策略
缺点 客户端无法推送消息；只能文本；不能二进制；无法双向交互 长连接资源占用，负载均衡需要会话保持；容易被防火墙拦截 每一次客户端发消息都要新建 HTTP 请求；有 HTTP 握手开销；不是真正实时双向 长连接运维，需要处理心跳、断线、会话保活
典型使用场景 简单大模型流式问答，只输出不交互 MCP WebSocket、实时 AI 对话、语音实时交互 MCP Streamable HTTP，云函数、serverless 环境部署 MCP 本地 MCP 客户端对接 MCP 服务，双向 Agent 工具调用
  • AI 开发选型小结
  1. 只需要看大模型流式输出，客户端不用发消息：选 SSE
  2. Serverless / 云函数，网关不支持 WebSocket，做 MCP：选 Streamable HTTP
  3. 需要双向高频交互（Agent、工具调用、多轮实时），环境允许长连接：优先 WebSocket Transport(RFD‑MCP)
  4. Streamable HTTP 不是长连接，每次客户端发送指令都要发起新 POST 请求，靠会话 ID 维持上下文；WebSocket Transport 是真正长连接，一条连接来回收发。

落地占比的统计（预估）

  • 说明：
  1. 通用 LLM 对话场景（公有 API、普通 AI 聊天产品）：不含 MCP；
  2. MCP 生态场景（Agent 工具调用）：公开 MCP Registry 统计数据；
  3. WebSocket‑Transport (RFD‑MCP)：MCP 规范中该传输实际公开部署占比很低，多为实验 / 内网场景，公开 registry 统计没有单独统计该条目。

1）通用 LLM 对话场景（普通 AI 聊天、大模型 API，非 MCP）

传输方案 落地占比 主要场景 备注
SSE 75%‑80% 公有大模型 API（OpenAI/Anthropic/ 国内各家）、网页端流式问答 行业绝对主流，单向 token 输出；客户端发消息走普通 POST，SSE 只管返回流IETF Datat...
标准 WebSocket 15%‑20% 实时语音对话（OpenAI Realtime）、需要中途打断输出、浏览器端 Agent 双向交互 适合高频双向；防火墙 / 代理兼容性差，运维成本高CSDN博...
Streamable HTTP(MCP) <5% 只有接入 MCP 远程服务的业务才会使用 不属于普通 LLM API，是 MCP 专用传输
WebSocket‑Transport(RFD‑MCP) <1% 几乎只在内网 POC、本地调试；公开业务极少 MCP 的 WebSocket 封装，生产公开部署很少

2）MCP 生态公开服务统计（MCP‑Scorecard 2026‑03 公开 registry 数据）

注意：MCP 本地绝大多数是stdio（进程内，不属于网络传输）；下面只统计网络传输（排除 stdio）

MCP 网络传输方案 在网络 MCP 服务中占比 说明
Streamable HTTP 82% MCP 官方主推远程传输，Serverless、网关友好，新 MCP 远程服务绝大多数选它
遗留 SSE（旧版 MCP SSE） 15% 老项目存量，规范标记为 deprecated，新项目不再推荐
WebSocket‑Transport (RFD‑MCP) 3% 几乎是实验项目，公开 registry 登记数量极少；多用于内网、桌面客户端直连
  • 完整 MCP 全量（含本地 stdio）：stdio 66.7%，Streamable‑HTTP 33.9%，遗留 SSE 6.2%（可同时声明多种 transport，总和 > 100%）。

3）综合落地选型判断表

业务类型 首选 备选 避坑
普通网页 AI 聊天，文本流式输出 SSE WebSocket（语音场景） 不要盲目上 WebSocket，增加运维负担
MCP 远程服务、Serverless、云函数、网关环境 Streamable HTTP 遗留 SSE（存量） 不选 WebSocket‑Transport，长连接在云网关容易超时断开
内网 Agent、桌面客户端直连 MCP、高频双向消息 WebSocket‑Transport(RFD‑MCP) Streamable HTTP 不适合公网多用户，连接保活、会话粘滞成本高

关键趋势小结

  1. 普通 LLM 流式：SSE 垄断公有 API，绝大多数 C 端 AI 产品采用；WebSocket 主要用于语音实时交互场景。
  2. MCP 远程服务：Streamable HTTP 快速替代旧 SSE，成为远程 MCP 事实标准；MCP‑WebSocket‑Transport 目前还是小众实验选项，公网生产落地很少。
  3. WebSocket‑Transport (RFD‑MCP) 能力最强，但长连接运维、代理超时、会话保持代价高，优先内网 POC，公网大规模生产谨慎选择。

Z FAQ for AI 应用的数据传输方案

Q: 如何理解 JSON-RPC 、SSE、Streamable HTTP、stdio 的关系？（必读）

核心分层理解

  • JSON‑RPC 2.0：消息格式层（语义）：定义消息长什么样（request/response/notification），与传输无关。
  • stdio / Streamable‑HTTP / SSE：传输层（管道）：负责把 JSON‑RPC 字节搬运到对端，是承载 JSON‑RPC 的不同通道。
  • SSE 既是独立传输，又是 Streamable‑HTTP 内部用于流式返回的响应格式（旧版MCP是独立transport；新版嵌入在Streamable‑HTTP内部）。

概念对比表

名称 层级 本质 JSON‑RPC承载方式 状态 典型场景
JSON‑RPC 2.0 消息协议层 消息语义规范，定义请求/响应/通知 被所有传输承载，不是传输通道 标准 MCP上层消息格式，不负责网络/IPC收发
stdio 传输层（本地IPC） 子进程标准输入输出管道 换行分隔JSON‑RPC，stdin读、stdout写；stderr做日志 MCP官方标准传输 本地MCP服务，子进程调用，桌面客户端
SSE(HTTP+SSE旧MCP传输) 传输层（已废弃） 双端点：GET长连接收流，POST发消息 POST body放JSON‑RPC；SSE event包裹JSON‑RPC Deprecated，旧版MCP 历史老版本的MCP远程服务，不要新项目使用
Streamable HTTP 传输层（MCP新标准） 单端点HTTP，兼容普通JSON / SSE流式响应 POST请求body携带JSON‑RPC；响应可返回普通JSON，或切换SSE流返回多条JSON‑RPC；Mcp‑Session‑Id维持会话 MCP官方标准远程传输 公网/Serverless MCP远程服务；SSE作为它内部流式能力，不是独立transport

关键澄清：

  1. Streamable‑HTTP 不等于SSE：SSE只是它的其中一种响应模式；【短请求】直接返回普通JSON，此时不需要SSE。
  2. stdio 不走网络，是【本地本机的进程间管道】；JSON‑RPC消息以换行分割，没有HTTP。
  3. JSON‑RPC 本身可跑在 stdio、HTTP、WebSocket、TCP任意通信通道上。

Mermaid图示

1）协议栈分层图

graph TD subgraph 消息格式层 A[JSON‑RPC 2.0<br/>Request / Response / Notification] end subgraph 传输层Transport T1[stdio<br/>本地子进程stdin/stdout管道] T2[Streamable‑HTTP<br/>单端点HTTP<br/> ├─普通JSON响应<br/> └─SSE流式响应（内部能力）] T3[旧版废弃:HTTP+SSE Transport<br/>GET（/sse）+POST（/message）双端点] end A -->|JSON‑RPC消息被封装在不同管道| T1 A -->|JSON‑RPC消息被封装在不同管道| T2 A -->|JSON‑RPC消息被封装在不同管道| T3

2）3种传输的消息流转对比

sequenceDiagram note over Client,Server:🔹stdio（本地子进程） participant Client participant Server[MCP‑Server子进程] Client->>Server: stdin → JSON‑RPC\n Server->>Client: stdout ← JSON‑RPC\n note over Client,Server:🔹Streamable‑HTTP（现代MCP远程） participant C participant S C->>S:POST /mcp body=JSON‑RPC<br/>Mcp‑Session‑Id alt短请求 S-->>C:HTTP 200 JSON‑RPC结果 else长任务流式 S-->>C:Content‑Type:text/event‑stream<br/>SSE event包裹多条JSON‑RPC end note over Client,Server:🔹旧废弃HTTP+SSE Transport participant CC participant SS CC->>SS:GET /sse（建立SSE长连接） CC->>SS:POST /message body=JSON‑RPC SS-->>CC:SSE event推送JSON‑RPC消息

极简总结

  1. JSON‑RPC = 说话的语法；stdio / Streamable‑HTTP / SSE = 传话的管道。语法不变，管道可以换。
  2. stdio：本机进程管道，无网络；Streamable‑HTTP：现代MCP远程标准，内部按需启用SSE做流式；旧HTTP+SSE双端点已废弃。
  3. SSE现在更多是Streamable‑HTTP内部的流式响应手段，不再作为独立顶层transport。

Y 推荐文献

X 参考文献

posted @ 2026-08-25 01:36  数据知音  阅读(7)  评论(0)    收藏  举报