架构

WebSocket 与 SSE 用于代理通信：MCP 为何两者皆不选

作者：IdeaBosque最后更新：2026年9月11日

关键要点

MCP 2026-07-28 规范弃用了 HTTP+SSE 并以 Streamable HTTP 取而代之 —— 而非 WebSocket —— 因为无状态服务器可以使用标准 HTTP 基础设施（WAF、负载均衡器、认证代理）而无需管理持久连接（MCP specification）。
A2A 使用 JSON-RPC 2.0 over HTTP 配合 SSE 进行任务输出流式传输 —— 传输是管道工程；协议语义（任务生命周期、INPUT_REQUIRED 状态）才是使代理间通信有效运作的关键（A2A protocol）。
CVE-2026-16496（CVSS 10.0）在 Terraform MCP 中利用了有状态 SSE 传输模式 —— 被窃取的会话 ID 让攻击者可以使用其他用户的凭据执行工具调用。无状态传输在架构层面消除了攻击面，而非在补丁层面（NVD）。
WebSocket 可作为自定义 MCP 传输使用，但增加了规范作者刻意避免的会话管理复杂性 —— 协议是传输无关的，但标准传输（stdio、Streamable HTTP）覆盖了生产场景（MCP specification）。
2026年9月17日 AGNTCon+MCPCon Europe 的"Stateless: The Future of MCP Transports"会议是无状态传输方向的首次大型会议验证 —— 由 Google 和 Hugging Face（MCP Transport Working Group 维护者）主讲（Linux Foundation）。

传输问题听起来像是基础设施管道工程，确实如此 —— 但这个选择在生产环境中会产生安全、可扩展性和运维方面的后果。当 Model Context Protocol 在2026年7月28日弃用 HTTP+SSE 并以 Streamable HTTP 取而代之时，规范作者做出了一个深思熟虑的工程决策：无状态服务器优于持久连接，标准 HTTP 优于自定义协议，单一端点优于双端点 SSE 模型。他们没有选择 WebSocket，尽管 WebSocket 是双向的而 SSE 不是。原因并非 WebSocket 是错误的 —— 而是对于 MCP 所服务的特定工作负载（代理和数据源之间的工具调用），双向能力不值得其会话管理开销。

本文将三种传输选项 —— SSE、WebSocket 和 Streamable HTTP —— 映射到使用它们的两个代理协议（MCP 和 A2A），并提供建议的 B2B 代理部署决策矩阵。9月17日的 AGNTCon 会议使时机变得具体：无状态传输正从规范走向会议验证，而运行弃用 SSE 传输的团队有一个12个月的迁移窗口，其中两个月已经过去。

三种传输方式及其功能

SSE（Server-Sent Events）—— 被弃用的默认选项

SSE 是单向协议：服务器通过长生命周期的 HTTP 连接向客户端推送数据，客户端无法通过同一连接发回消息。每个客户端操作 —— 取消生成、在任务中途引导代理、批准工具调用 —— 都需要单独的 HTTP POST 请求（WebSocket.org）。

MCP 在其 2024-11-05 规范中使用 SSE 作为远程服务器的传输方式。该模型需要两个端点：一个用于服务器到客户端消息的 SSE 端点和一个用于客户端到服务器消息的单独 POST 端点。服务器在两个连接之间维护会话状态。三个限制推动了弃用：不支持可恢复流、需要长生命周期高可用连接，以及服务器消息仅通过 SSE 交付（MCP specification PR #206）。

A2A 仍在其流式传输模式中使用 SSE。SendStreamingMessage 方法将任务更新作为 SSE 事件交付 —— token 增量、工件块、状态转换。这对 A2A 是正确的选择，因为流式传输是单向的（服务器到客户端），客户端的控制消息（取消、订阅）通过单独的 JSON-RPC 调用（A2A protocol）。SSE 简单，基于标准 HTTP 工作，对于本质上是服务器推送的工作负载不需要 WebSocket 的会话管理。

WebSocket —— MCP 未标准化的双向选项

WebSocket 提供客户端和服务器之间的持久双向连接。在 HTTP 升级握手后，连接保持打开状态，双方可以随时发送消息。这是需要单一通道上真正双向通信的应用的正确原语：聊天、协作编辑、多人游戏、交易面板（Ably）。

对于 AI 代理，双向场景是真实存在的。代理工作流在执行期间需要客户端到服务器的消息：取消生成、在任务中途引导代理、批准或拒绝工具调用、发送后续上下文。使用 SSE 时，每个这些都是单独的 HTTP 请求。使用 WebSocket 时，它们搭载在与 token 流相同的连接上（WebSocket.org）。

MCP 规范未标准化 WebSocket。它可作为自定义传输使用 —— 规范说"客户端和服务器可以实现额外的自定义传输机制"，只要它们保留 JSON-RPC 消息格式 —— 但标准传输是 stdio（用于本地服务器）和 Streamable HTTP（用于远程服务器）（MCP specification）。一个 GitHub issue（#493）提议将 WebSocket 添加为标准传输以简化 HTTP 模型；它在未被采纳的情况下关闭，规范转向了 Streamable HTTP（GitHub）。

MCP 未标准化 WebSocket 的原因是运维性的，而非技术性的。WebSocket 要求服务器维护持久连接、管理会话健康、处理重连逻辑并处理断开连接。这与使 SSE 成为负担的有状态连接负担相同。MCP 作者想要无状态服务器 —— 任何实例可以处理任何请求，没有共享会话存储，简单的轮询负载均衡 —— 而 WebSocket 的持久连接模型与该目标背道而驰。

Streamable HTTP —— MCP 的替代选择

Streamable HTTP 是 MCP 规范对 SSE 与 WebSocket 问题的回答。服务器暴露单一 HTTP 端点（例如 https://example.com/mcp），同时处理 POST 和 GET。客户端将每个 JSON-RPC 消息作为 POST 发送。服务器可以用普通 JSON 正文响应，或者如果结果是长时间运行的，则将响应升级为 SSE 流。关键设计选择：服务器不需要维护持久连接。每个请求都是自包含的（MCP specification）。

这使 MCP 获得 SSE 的流式传输能力而无需长生命周期连接要求，并获得 WebSocket 的双向能力而无需会话管理开销。客户端通过 POST 发送消息（标准 HTTP），服务器通过可选 SSE 流式传输响应（标准 HTTP），服务器可以是无状态的（标准 HTTP 基础设施）（Bright Data；Auth0）。

安全论点是具体的。Auth0 的分析：使用 Streamable HTTP，"我们可以在每个信封上盖一个标准的 `Authorization: *** 头。邮件室检查每条消息上的印章，而不仅仅是第一条。" 使用旧的 SSE 传输时，认证令牌在连接时建立一次，持久连接承载所有后续消息 —— 包括来自窃取会话 ID 的攻击者的消息（Auth0）。

决策矩阵

标准	SSE（已弃用）	WebSocket（自定义）	Streamable HTTP（MCP 标准）
方向	仅服务器 → 客户端	双向	客户端 → 服务器通过 POST；服务器 → 客户端通过可选 SSE
连接模型	长生命周期，持久	长生命周期，持久	按请求（无状态）
服务器状态	有状态（每连接一会话）	有状态（每连接一会话）	无状态（请求间无会话）
负载均衡	需要粘性会话	需要粘性会话	简单轮询
扩展	有限（每客户端一连接）	有限（每客户端一连接）	高（任何 HTTP 基础设施）
认证	连接时	握手时	按请求（每个 POST 上 Bearer）
可恢复性	否	否	否（但无状态意味着没有需要恢复的会话）
基础设施	需要 SSE 感知代理	需要 WebSocket 感知代理	标准 HTTP（WAF、LB、CDN、认证代理）
安全面	会话 ID 窃取（CVE-2026-16496）	持久连接上的会话劫持	传输层无（无会话可窃取）
MCP 状态	已弃用，12个月日落期	自定义传输（未标准化）	自 2026-03-26 起标准远程传输
A2A 状态	用于流式传输模式	未使用	未使用（A2A 使用 JSON-RPC over HTTP + SSE）
最适合	简单服务器推送（A2A 任务流式传输）	真正双向（聊天、协作）	代理到工具调用（MCP）

该表回答了大多数 B2B 团队提出的问题：如果你的代理需要调用远程 MCP 服务器上的工具，使用 Streamable HTTP。如果你的代理需要将任务输出流式传输到另一个代理，使用 A2A 的 SSE 流式传输模式。如果你正在构建一个客户端与服务器发送消息频率相同的实时协作界面，WebSocket 是正确的原语 —— 但它是自定义传输，不是协议标准。

三种传输方式对比：

安全维度 —— 为什么无状态很重要

验证无状态传输选择的 CVE 是 CVE-2026-16496，这是 HashiCorp Terraform MCP Server 中一个 CVSS 10.0 的授权绕过漏洞。该漏洞影响了有状态 streamable-HTTP 传输模式：获取其他用户 MCP 会话 ID 的用户可以使用该用户的 Terraform 凭据执行工具调用。攻击向量存在仅仅是因为服务器持有攻击者可以窃取和重用的会话状态。无状态服务器没有可窃取的会话（NVD；The Hacker News）。

这是有状态传输模式是安全责任的生产证据，不仅仅是运维复杂性。SSE 的12个月弃用窗口现在是一个安全期限，而不仅仅是运维期限。仍在运行弃用 HTTP+SSE 传输的 1,227 个服务器是受影响最严重的群体 —— 也是承载会话劫持攻击面的群体。

关于无状态协议和替换服务器端会话状态的显式句柄模式的更深入处理，请参见 MCP 2026-07-28：无状态协议对 B2B 代理部署意味着什么。

A2A 有何不同 —— 以及为何有效

A2A 使用 SSE 进行流式传输，而不是 Streamable HTTP。区别在于工作负载。MCP 工具调用是短的请求/响应操作 —— 查询数据库、获取记录、运行计算。服务器处理请求并返回结果。流式传输是可选且罕见的。A2A 任务是具有显式生命周期管理的长时间运行操作 —— 一个耗时两分钟的定价评估，一个耗时一小时的合规检查。流式传输是进度更新，不是结果本身。

A2A 的 SSE 流式传输仅是服务器推送，这对任务进度是正确的方向：处理任务的代理向调用代理发送更新。调用代理的控制消息（取消、订阅更新）通过单独的 JSON-RPC 调用。流式传输通道上不需要双向通信，因为控制通道是单独的标准 HTTP 请求（A2A protocol；Google Developers Blog）。

这就是为什么传输问题是管道工程，不是架构。MCP 和 A2A 使用不同的传输因为它们有不同的工作负载，但两者都基于标准 HTTP。协议语义 —— MCP 的无状态工具调用和 A2A 的有状态任务生命周期 —— 才是使代理通信有效运作的关键。传输承载消息；它不定义消息。

完整的协议级比较（范围、传输、认证、状态、人机交互），请参见 A2A vs MCP：为代理通信选择正确的协议。

何时 WebSocket 是正确的答案

WebSocket 不是错误的。它是 MCP 和 A2A 未标准化的特定工作负载的正确传输：

实时协作界面，客户端与服务器发送消息频率相同 —— 多个操作员同时引导同一代理的共享代理面板。
高频双向通信，其中每条消息的 HTTP 请求开销过高 —— 在同一通道上接收市场数据并发送订单的交易代理。
自定义 MCP 传输，标准传输不适合 —— 规范明确允许自定义传输，只要它们保留 JSON-RPC 消息格式和生命周期要求（MCP specification）。

权衡是运维复杂性。维护长生命周期双向连接需要针对会话健康、重试、断开连接和消息协议的显式逻辑（Nimble Way）。对于大多数 B2B 代理部署 —— 一个调用 NetSuite 的代理，一个委托给定价代理的采购代理 —— 这种复杂性不被工作负载所证明。

无状态趋势

行业方向是明确的。MCP 于2026年7月28日转向无状态。A2A 使用有状态任务机但无状态传输（HTTP + SSE，服务器上无持久会话）。9月17日的 AGNTCon+MCPCon Europe 会议 —— "Stateless: The Future of MCP Transports"，由 Kurtis Van Gent（Google）和 Shaun Smith（Hugging Face，MCP Transport Working Group 维护者）主讲 —— 是第一个专门致力于无状态传输方向的大型会议会议（Linux Foundation；sched.com）。

Shaun Smith 还将在同一会议上发表主题演讲："Getting to Stateless MCP: In Production" —— 这标志着无状态传输正从规范转向生产部署指导。对于运行弃用 SSE 传输的团队，12个月迁移窗口（到2027年7月结束）是运维期限。安全期限更早：服务器运行有状态 SSE 传输的每一天都是它承载 CVE-2026-16496 所利用的会话劫持面的一天。

WebSocket vs SSE 的问题，对于代理通信，有一个明确的答案：都不是，如果你基于 MCP 构建。使用 Streamable HTTP。如果你在流式传输 A2A 任务输出则使用 SSE。仅当工作负载是真正双向的且运维复杂性被证明时才使用 WebSocket。传输是管道工程。协议语义 —— 无状态工具调用、有状态任务生命周期、显式句柄、人机交互状态 —— 才是使代理系统在生产中有效运作的关键。