WebSocket、SSE 与长轮询：实时 Agent UI 的连接管理、断线重连与背压 未开始

题记与说明

• 报告类型：横纵综合报告（纵轴发展史 × 横轴横向对比 × 交叉洞察）
• 完成日期：2026-11-03
• 方法说明：本报告由两份章节研究综合而成——《纵轴发展史（1995–2026）》与《横轴对比报告（2026-11 截面）》。两章均基于当日网络检索与一手文档抓取写成（规范原文、官方博客、官方 changelog 与开发者文档），关键事实附来源 URL；横轴章对 Ably、Socket.IO、Vercel AI SDK 三份文档做了原文抓取核对，纵轴章对 WHATWG/IETF/W3C 规范做了检索核对。综合者未重新独立核实链接，两章标注"模型既有知识/未复核"的条目在本报告中沿用该标注。两章之间的表述矛盾（WebSocket 背压、token 流背压方向、长轮询地位等）已在正文与交叉洞察中显式调和，见 3.1 节。
• 修订说明（最终稿）：本稿按 2026-11-03 独立审读意见逐条修订，逐条处理记录见文末"附2：审读意见处理记录"；除意见涉及处外正文原样保留、未缩短。修订时重新抓取/检索核对过的来源：MCP 官方规范（2024-11-05 版与 2026-07-28 版，镜像域名引用已替换为官方域名）、Socket.IO 连接状态恢复文档、Vercel AI SDK 流协议与恢复流文档、Centrifugo README、Ably《WebSockets on Vercel》、WebKit standards-positions #18、Baseline 定义（经检索核对 Web Platform DX 社区组材料）。

TL;DR

三十年三次范式转移：拉→推（Comet 长轮询）、推→专用协议（WebSocket）、回归 HTTP 语义（SSE 复兴+服务端状态恢复）。2026-11 的结论：SSE 已赢得实时 Agent UI 默认传输位——所对照的主流 LLM API（OpenAI、Anthropic 等）的 token 流一律走 SSE（其余厂商未逐一复核，见 2.3.1）；断线重连的胜负手不在传输层而在会话层——裸传输"三不保证"（投递、连续性、可观测性），差异化在 Socket.IO 状态恢复、Centrifugo 历史恢复、MCP Last-Event-ID 重放；背压是全行业盲区，Agent UI 靠应用层（abort、节流、token 预算）绕开。选型：SSE+POST 起步；高频双向用 WebSocket 但勿裸写（交给框架）；恢复是硬需求时先问"恢复窗口多长、恢复范围多大、状态存哪"。三十年绕了一圈：把 HTTP 拧出汁→造新协议→回到 HTTP、把状态放回服务端。

一、纵轴：发展脉络（1995–2026）

1.1 前史（1995–2004）：HTTP 是"拉"协议，实时是奢侈品

HTTP/1.0 时代每次请求都要建 TCP 连接，浏览器没有任何"被动接收"的 API。早期工程师用过各种奇怪的办法：

• 1995 年：Netscape 在 HTTP 响应中引入 multipart/x-mixed-replace（server push），让一张图片可以被服务器不断替换——Web 上最早的"服务器推"原语（见 Wikipedia: Comet)）。
• 约 2000 年：微软 Outlook Web Access 用隐藏 iframe 承载 HTTP 流式响应实现邮件到达提醒，是业界广为引用的早期大规模案例（模型既有知识，未逐一复核原始出处）。
• 2001 年前后：Flash 的 XMLSocket 提供真正的 TCP 套接字（模型既有知识），但依赖插件，且常被企业防火墙拦截。
• 默认方案仍是定时轮询：浏览器每隔 N 秒问一次"有新东西吗"。

这一阶段显形了贯穿三十年的根本矛盾：延迟与服务器连接成本不可兼得——轮询间隔短了服务器扛不住，间隔长了"实时"名不副实。

1.2 Comet 纪元（2005–2007）：长轮询的黄金时代

• 2005 年 2 月，Jesse James Garrett 发文命名 AJAX，XHR 被重新发现；工程师立刻意识到：XHR 请求可以不发完就挂着。
• 2005–2006 年，Gmail（2004 上线，2006 年 2 月集成 Chat）、Meebo（网页 IM）、Google Docs、后来的 Facebook Chat 等产品用长轮询、forever frame、XHR 流实现"服务器推"。
• 2006-03-03，Alex Russell（Dojo Toolkit）发表《Comet: Low Latency Data for the Browser》正式命名这类技术（原文、Wikipedia: Comet)）。"Comet"不是缩写，只是与 AJAX 一样取个天体名字。
• 2007 年，Cometd 项目与 Bayeux 协议尝试为"实时消息分发"定义元协议——频道订阅、握手、心跳、长轮询/流式双传输。这是第一次把连接管理协议化的尝试。

留下的工程遗产（横轴上今天仍然有效）：长轮询的心跳保活、代理超时规避、重连后靠序号补消息——这正是后来所有断线重连机制的雏形。同时 Apache"一连接一线程"模型在数千个挂起连接下崩溃，倒逼 nginx、Jetty Continuations 等事件驱动方案兴起——实时需求第一次重塑了服务器架构。

1.3 WebSocket 标准化（2008–2011）：破冰、断裂与 RFC 6455

• 2008-06-18，WHATWG 邮件列表出现 "TCPConnection feedback" 讨论：Ian Hickson 最初把提案叫 TCPConnection，Michael Carter 提议改名为 WebSocket（邮件列表原文、Wikipedia: WebSocket）。动机直白：长轮询每条消息都要重付一整套 HTTP 头的"税"，且建连延迟不可接受。
• 2009-12-09，Chrome 4 开发者通道成为第一个内置 WebSocket 的浏览器。
• 2010 年，Guillermo Rauch 在 LearnBoost 发布 Socket.IO 0.6：在 WebSocket 之上提供事件语义，并内置传输协商——WebSocket 不可用时自动回退 Flash socket、XHR 长轮询、JSONP（dev.to/ably 综述）。
• 2010-12-08/09：安全研究者（Adam Barth 等）披露 WebSocket draft-76 握手可被用于代理缓存投毒——升级请求看起来太像 HTTP，透明代理会把攻击者数据缓存为合法站点内容。Firefox 4 与 Opera 随即关闭 WebSocket 支持（Mozilla Hacks, 2010-12-08、Wired 报道、Pusher 评论）。这是协议史上著名的"断裂一周"：整个生态一夜回退到 Comet。
• 2011-12：IETF HyBi 工作组发布 RFC 6455（编辑 Ian Fette、Alexey Melnikov），关键设计是客户端→服务端帧必须加掩码，让中间盒再也无法把 WebSocket 流量误认成 HTTP——直接回应 2010 年的断裂（最终 HyBi 草案、draft-76）。

1.4 并行的 SSE 与"重连工程"的成熟（2009–2015）

WebSocket 高歌猛进的同时，一条更保守的路线在标准化中成型：

• SSE：前身事件流 API 早在 2006 年由 Opera 实现原型；2009-04-23 W3C 发布第一个 EventSource 工作草案（WD 2009、WD 2011），2015-02-03 成为 W3C Recommendation（Wikipedia: SSE）。Chrome 6、Safari 5、Firefox 6 在 2010–2011 年间先后实现（HTML5 Doctor, 2012），但 IE 与旧版 Edge 长期缺席（直到 2020 年基于 Chromium 的 Edge 79）——这是 WebSocket 此后十年占优的重要原因。
• SSE 的革命性在于断线重连第一次成为"浏览器的承诺"：EventSource 断线后自动重连、自动携带 Last-Event-ID 请求头、服务端可用 retry: 字段控制重连间隔（WHATWG HTML 规范、Atomic Object 解析）。但规范留了个大空白：服务端如何按 Last-Event-ID 续传，完全交给应用自己实现——这个空白直到 Agent 时代才被真正补上。
• 2011-09-13：RabbitMQ 团队发布 SockJS，卖点是受限代理后优雅回退到 XHR 流/iframe/JSONP 等一堆传输（RabbitMQ 博客）。
• 2010 年前后：Pusher、PubNub 创立，把"实时连接"变成托管服务（Matthew O'Riordan 行业评述）。2014-10-21，Google 收购 Firebase（TechCrunch）。
• 2012–2014：Socket.IO 把底层传输拆出 Engine.IO（升级协商、ping/pong 心跳、超时判定），Socket.IO 退居 API 层（房间、广播、ack）；2014-05-28 Socket.IO 1.0 发布（官方公告、InfoQ）。重连策略至此定型：指数退避 + 随机抖动（防止断网恢复时所有客户端同时重连的雪崩）。
• 2014–2015：Slack 将实时消息通道迁移到 WebSocket 并自建 Flannel 边缘缓存，解决"重连后从哪里补齐漏掉的消息"（模型既有知识，原文链接未复核）。

驱动因素：移动互联网普及——NAT 超时、App 切后台、基站切换让断线成为常态；企业代理与负载均衡器让"纯 WebSocket"不可靠；多节点部署要求会话粘性。连接管理从协议问题变成了分布式系统问题。

1.5 云与企业采纳（2015–2019）：HTTP/2 与回退矩阵定型

• 2015-05：RFC 7540（HTTP/2）发布（官方规范）。多路复用消除了 HTTP 层队头阻塞，SSE 的连接数成本问题大幅缓解；但反向代理的响应缓冲成了 SSE 的新敌人——X-Accel-Buffering: no、proxy_buffering off 从此成为运维常识。
• 2018-09：RFC 8441（Bootstrapping WebSockets with HTTP/2），经扩展 CONNECT 把 WebSocket 变成 HTTP/2 连接上的一条流（rfc-editor）。
• 2018-11（AWS re:Invent）：Amazon API Gateway 推出 WebSocket API（AWS 博客, 2018-12-18）——无服务器世界第一次有了"有状态连接"的托管原语（$connect/$disconnect/$default 路由）。
• 2019-10：gRPC-Web 1.0 GA，浏览器 JavaScript 可直接消费 gRPC 服务端流。
• 同期 MQTT 一线：2014 年成为 OASIS 标准、2019-03 MQTT 5.0 发布；Facebook Messenger 等移动应用长期以 MQTT（over WebSockets）承载推送——移动端一直走着"二进制协议 + 会话保持 + 断线重连"的平行路线；至于"其 QoS 分级与会话恢复设计深刻影响实时系统重连语义"这一因果论断，本报告未找到直接来源，存疑待考。

1.6 下一代传输与背压补课（2019–2024）

• 2019 年，Chromium 团队提出 WebTransport 提案；2021-05-04 W3C 发布第一个工作草案（WD 2021）；2022-01 Chrome 97 正式发布支持（Chrome 开发者文档）。其底座是 HTTP/3：2021-05 QUIC（RFC 9000）、2022-06 HTTP/3（RFC 9114）。QUIC 每条流有独立流控——协议层第一次有了"每条流可单独调背压"的能力。
• 2020-11 Socket.IO 3.0、2021-03 Socket.IO 4.0：TypeScript 重写与解析器重构（官方迁移指南）。
• 2023-02 Socket.IO 4.6.0：发布连接状态恢复（Connection State Recovery）——服务端在断连窗口内暂存 socket id、房间、data 与错过的事件包，客户端重连后一键恢复（4.6.0 changelog、官方文档）。连接库的重连语义从"重连策略"升级为"状态恢复协议"。
• 2024-04-16 Chrome 124：WebSocketStream 正式发布——把 WebSocket 连接暴露为 ReadableStream/WritableStream，浏览器侧 WebSocket 终于有了真正的背压（Chrome 124 发布说明、官方解释、MDN）。从 2019 年提案到落地花了五年（2019 提案 → 2024-04 Chrome 124），落地路上 Safari/WebKit 一度缺位——WebKit 于 2022-06 收到立场请求，早期讨论中曾表达保留意见（质疑"为何不做成 WebSocket 的扩展"，认为相互割裂的各协议 API 是反模式），直到 2023-04-12 才正式表态支持（WebKit standards-positions #18，修订时已核对原文）——注意它与 1.1 节"经典 WebSocket API 无背压"（MDN）并不矛盾：前者是 2011 年定型的经典 API，后者是 2024 年才落地的 Streams 系新 API，生态采纳至今有限（详见 2.3.4 与 3.1 节调和）。

1.7 Agent UI 诞生（2022-11–2024）：SSE 复兴与长轮询"还魂"

• 2022-11-30：ChatGPT 上线，token 逐字流式输出一夜之间成为"AI 产品该有的样子"（上线即百万级用户，ZME Science 报道）。其前端流式传输用的正是 SSE。
• 2023-03：OpenAI Chat Completions API 以 stream: true 把 SSE token 流变成公共 API 契约（模型既有知识，业界广泛记载）。
• 2023-08：LangChain 发布 LCEL，Runnable 协议让任意链式组合天然支持 token 级流式（Artefact 综述）；2023-10 LangServe 让部署应用自动获得流式端点（官方博客）。框架层从此把"流式"当作一等公民。
• 2023-11-06：OpenAI DevDay 发布 Assistants API v1——运行状态必须靠轮询 retrieve run 获取（教程记载、Killed by AI 时间线）。长轮询在 Agent 时代"还魂"：Agent 任务是分钟级长任务，轮询任务状态反而是最朴素可靠的解。
• 2024-03-01：Vercel 发布 AI SDK 3.0，主打 Generative UI（官方公告）；同月 Anthropic Messages API 将语义化 SSE 事件（message_start / content_block_delta / message_stop 等）确立为流式契约（流式文档镜像）。
• 2024-04：Assistants API v2 补上流式事件，Agent UI 从"轮询进度条"全面转向"语义事件流"（OpenAI 官方 FAQ）。
• 2024-10：OpenAI Realtime API 上线，以 WebSocket 承载语音到语音（上线期社区帖），12 月降价并加入 WebRTC 支持；2025 年 3 月 GA 起浏览器端推荐 WebRTC 而非裸 WebSocket。
• 2024-11-25：Anthropic 发布 MCP（规范版本 2024-11-05），首批远程传输是 HTTP + SSE 双端点（SSE 通道收事件、POST 端点发消息）（MCP 传输规范 · 2024-11-05 版，修订时已核对：该版传输规范定义的正是 SSE 端点 + POST 端点双端点形态）。

本轮范式转移的驱动因素：① TTFT（首 token 延迟）物理不可消除——流式是唯一能改善感知性能的手段，且"看着它在想"本身就是产品价值；② 半双工足够——对话 UI 本质是"一次请求、流式回答"，SSE 完美匹配，且过一切代理、可被 CDN/网关无状态扩容，连接不再珍贵；③ 状态外移——上下文与任务状态放在服务端，连接可以随时死掉。三条共同宣告：实时 Agent UI 的主战场从"保住连接"转移到"保住状态流"。

1.8 协议收敛与"可恢复流"成为主战场（2025–2026）

• 2025-03-11：OpenAI 发布 Responses API（与 Agents SDK 同日）：语义化流式事件（response.created、response.output_text.delta、response.completed 等）、服务端存储对话状态、previous_response_id 链式引用——客户端断线后不靠记住"读到第几个字节"，而靠服务端状态重建（官方迁移指南、流式事件社区整理）。此后 Assistants API 走向退役（v1 于 2024-12-18 停用，整体于 2026-08-26 关停，Killed by AI、迁移指南）——轮询时代的句号。
• 2025-03-26：MCP 规范修订：Streamable HTTP 取代 HTTP+SSE——单一端点，POST 响应可升级为 SSE 流，服务端可选纯 JSON 应答；以 Mcp-Session-Id 会话头 + Last-Event-ID 提供可恢复性（MCP 官方传输规范、动机解析）。SSE 从"必需的双端点通道"降级为"可选的流式载体"。
• 2025-04：Google 发布 A2A（Agent2Agent）协议，任务级进度更新用 SSE 流式推送，长任务完成通知可用 webhook push——agent-to-agent 层做出了与 Agent UI 相同的技术选择（InfoQ 报道；后捐给 Linux 基金会，What happened to A2A）。
• 2025-06-18：MCP 再次修订：移除 JSON-RPC 批处理、OAuth 2.1 加固、要求 MCP-Protocol-Version 头；旧 HTTP+SSE 传输进入弃用窗口（至少 12 个月兼容）；后续修订与官方传输博客（2025-12-19）均维持 Streamable HTTP 为标准（修订要点综述）。规范其后仍有 2026-07-28 版修订——标准传输绑定收敛为 stdio 与 Streamable HTTP 两种，Streamable HTTP 地位不变（官方规范 · 2026-07-28 版，修订时已核对）。
• 2025-07-31：Vercel 发布 AI SDK 5：UIMessageStream（结构化消息部件流）+ resumable streams——客户端断线重连后从服务端续播未流完的消息，并明确区分"用户主动 abort"与"意外断连"两种语义（官方公告、恢复流文档）。
• 2025–2026：resumable-stream 等库、assistant-ui、OpenAI ChatKit/AgentKit（2025-10 DevDay）把"可恢复流"产品化；所对照的主流 LLM API（OpenAI、Anthropic）及其官方 SDK 均以 SSE 为流式默认（其余厂商未逐一复核，证据见 2.3.1）。2026-03 WebTransport 达到浏览器 Baseline（Baseline：由 Web 平台 DX 社区组维护的浏览器兼容性标志，表示该特性已在 Chrome、Edge、Firefox、Safari 四大核心浏览器中可用，分"新近可用"与"广泛可用"两档，web.dev/baseline；见 2.3.6）。

1.9 三条子线的三十年小结

一句话收束：实时 Web 的三十年，是从"把 HTTP 拧出汁来"（Comet），到"造一个新协议"（WebSocket），再到"回到 HTTP、把状态放回服务端"（SSE + 可恢复流）。断线重连的进化史，本质是一部状态归属权的迁移史：状态先在客户端连接库里，后被浏览器内置，最终落在服务端的任务状态机上——而这正是 Agent 这一"长任务、有状态"的新负载对传输层提出的最深要求。

二、横轴：横向对比（2026-11 截面）

2.1 对比对象的界定：五层模型

"实时 Agent UI"不是单一技术点，而是一条分层栈。横向对比必须先分层，否则会把"协议 vs 框架 vs 平台"混为一谈：

本课题三个关键词——连接管理、断线重连、背压——分别散落在 L1/L3/L4 层。需要说明分层纪律如何落实到下文两张表：L2 协议随其最常见载体对比——MCP Streamable HTTP 随其 HTTP/SSE 传输载体进入 2.2 主表（表题 L1–L2），AI SDK UI Message Stream 与 AG-UI 随框架/平台进入 2.4 表（表题 L2–L5）；两表括注按实际所含层次标注。

2.2 主对比表（L1–L2）

SSE/长轮询/WebSocket 对比事实来自 Ably 官方博客（WebSockets vs SSE，横轴章已抓取原文核对）与 2025 年多篇对比文；MCP 行来自官方规范；WebTransport 行来自 websocket.org、Ably 等检索。

2.3 逐维度说明

2.3.1 通信模型与协议底座

• 长轮询是"用请求挂起模拟推送"：客户端发请求，服务器握住直到有数据或超时才响应，然后立刻再发下一个。它没有连接概念，天然无状态、水平扩展最容易，但每条消息都付一次完整请求成本（TCP/TLS/头部/认证）。
• SSE 是 HTTP 上一个不结束的响应流，MIME 为 text/event-stream，格式由 WHATWG HTML 规范定义（data:、event:、id:、retry: 行）。它是单向的：只从服务器到客户端。Anthropic Messages API 的流式响应逐条带 event: 类型行（message_start/content_block_delta/message_stop），而 OpenAI 只有 data: 行并以 data: [DONE] 结尾——同一编码，两家风格不同（Simon Willison 对照）。
• WebSocket 通过 HTTP Upgrade 握手切换到 RFC 6455 帧协议，之后与 HTTP 无关，是真正的 TCP 全双工通道。这是它强大（低延迟双工、二进制）与昂贵（防火墙、代理、LB 都要特殊处理）的共同来源。
• WebTransport 建在 HTTP/3/QUIC 上：多条独立流互不队头阻塞，外加不可靠数据报，流级背压内建（singhajit 解析）。
• MCP Streamable HTTP（2025-03-26 引入，取代 2024-11-05 的 HTTP+SSE 传输）把所有通信收敛到单一端点：客户端 POST（响应可以是 JSON，也可以升级为 SSE 流），可选开一条 GET SSE 流做服务器主动推送，会话用 Mcp-Session-Id 头维系（机制描述依官方规范 · 2025-03-26 版；其后 2026-07-28 版官方规范中 Streamable HTTP 仍为两种标准绑定之一，见 1.8）。它是"HTTP 语义优先、流式编码可选"的混合形态。

小结：Agent UI 中，上行（用户输入、确认、取消）是低频小消息，下行（token 流、工具事件、进度）是高频主负荷。这个不对称性正是 SSE+POST 组合能以极低成本覆盖大多数 Agent 场景的结构性原因。

2.3.2 连接管理与断线重连

• SSE 的自动重连是唯一"浏览器白送"的：连接断开，EventSource 按 retry: 指示的间隔自动重连并自动携带 Last-Event-ID 头（MDN）。但 2025 年社区讨论反复强调一个前提——只有服务器给每个事件编了号，重连才是免费的；否则浏览器只是重开了一条新流，缺口无人知晓（Reddit 讨论）。
• WebSocket 没有任何重连语义，"断线是你自己的事"（Ably，已抓取原文）。自建重连要处理指数退避、抖动、心跳探测、半开连接、重连风暴——这也是大部分团队最终倒向框架层的第一原因。
• Socket.IO（官方文档已抓取核对）：自动重连内建（可配置退避）；2023 年起提供 connection state recovery——握手时下发私有会话 ID（pid），每个包带 offset，重连时客户端报"会话 ID + 最后 offset"，服务器恢复 rooms/data 并补发错过事件。恢复窗口由 maxDisconnectionDuration 控制（官方示例 2 分钟，文档明确建议不要设为 Infinity）；skipMiddlewares: true 有被封锁用户绕过鉴权的安全警告；Redis PUB/SUB 适配器因无法持久化数据包不支持恢复，Redis Streams 与 MongoDB 适配器支持（官方文档）。
• SignalR（.NET 生态）：自动重连策略内建（.NET 7+ 增强），传输协商按 WebSocket→SSE→长轮询回退（polyxer 对比）。
• Centrifugo：重连后基于 channel 的消息历史与客户端最后已知流位置（offset/epoch，StreamPosition）自动检测并补发丢失的 publication；另有 cache recovery 模式——官方 README 原文为 "deliver latest publication immediately upon subscription"（客户端（重）订阅时立即送达该频道缓存的最新一条 publication；重连即重订阅，故效果为"重连即得最新一条"，适合状态型频道）（GitHub README，修订时已核对原文）。恢复窗口取决于服务端 history retention 配置，可远长于 Socket.IO 的分钟级。

小结：重连能力的真实排序不是"有没有自动重连"，而是三个工程参数——恢复窗口多长（2 分钟 vs 可配置保留期）、恢复范围多大（补发事件 vs 恢复完整会话状态）、恢复依赖什么基础设施（内存 vs Redis Streams/MongoDB vs 服务端历史）。

2.3.3 消息恢复与可靠性：Ably 的"三不保证"

Ably 的对比文（已抓取原文）给出了本维度最重要的框架性结论：无论选哪个裸传输，以下三项都不被保证——

1. 投递（Delivery）：不保证消息到达，也不告知失败。WebSocket 在网络中断期间发出的消息可能静默丢失；SSE 中断留下的是无人知晓的数据空洞。
2. 连续性（Continuity）：刷新页面或换设备，会话状态从零开始。没有任何传输保证跨设备/跨刷新的会话存活。
3. 可观测性（Observability）：不会在用户之前发现问题，排障基本靠事后日志。

因此 Agent UI 的"断线续看历史"必须靠会话层方案补齐：SSE 事件编号 + 服务端事件缓冲、Socket.IO 的 offset 补发、Centrifugo 的 history recovery、或应用层把 agent 运行状态落库、重连后用"查询"代替"补发"。MCP 生态选择的是最后一种思路的变体——Streamable HTTP 让"无长连接也能工作"，流断了重放，重放不可得就重新 GET。

2.3.4 背压与流控：全行业盲区

这是三种基础传输共同的、2026 年仍未被主流框架解决好的盲区：

• 经典浏览器 WebSocket API 不支持背压：MDN 明确指出这一点并把开发者指向 Streams API（MDN WebSockets API）。发送端唯一手段是轮询 socket.bufferedAmount 观察未发出字节数——这是"事后观测"而非"流控"。与 1.6 节的 WebSocketStream（Chrome 124，2024-04）调和如下：经典 WebSocket API 自 2011 年定型至今无背压；WebSocketStream 以 ReadableStream/WritableStream 形式补上了这一课，但它是新 API、Chrome 一家先行，生态采纳有限——所以说"WebSocket 无背压"（对经典 API 成立）与"WebSocket 有背压了"（对 WebSocketStream 成立）同时为真，取决于你用的是哪个 API（详见 3.1 节）。
• Socket.IO 无内置背压：官方 issue #4435 的结论是需要手动实现——服务器发一个包、等客户端 ack、再发下一个（issue #4435）。
• SSE 只有 TCP 层与 HTTP 层的隐式流控：慢客户端最终让服务器写缓冲堆积，需应用层做慢消费者检测（丢弃策略或断开）。HTTP/2 提供流级流控、HTTP/3/QUIC 更进一步，但这属于传输红利而非 SSE 协议设计。
• 服务器端实现各有硬上限：如 uWebSockets 讨论中明确"超限即丢消息，limit is a limit"（uWS 讨论 #1182）。
• Centrifugo 是框架层少数认真做服务端背压控制的：per-channel 节流、消息队列上限等；托管平台（Ably 等）则把背压问题转化为配额、排队与优先级产品能力。
• WebTransport 是唯一把流级背压作为设计目标的方案，这构成它对 WebSocket 最硬的技术优势。

Agent UI 语境的调和说明：纵轴章强调"服务端一分钟产完的 agent 步骤，客户端可能还要渲染三十秒，且 EventSource 无法感知缓冲积压"；横轴章观察到"token 流的生产速度即 LLM 生成速度，客户端消化速度远快于生成速度"。两者不矛盾，是两个不同层面的背压：token 级流受生成速度天然限速，渲染不是瓶颈；事件级/任务级流（高频工具事件、日志、多 agent 扇出、服务端已产完而客户端未播完的长任务）才是真正的积压风险——而 EventSource 没有标准反压信号，使这种积压不可见。目前主流应对不是传输层背压，而是应用层手段：abort（AI SDK 有专门的 abort chunk 语义，已抓取原文）、分批发送、渲染节流与打字机式平滑输出。

2.3.5 代理、防火墙与基础设施成本

• WebSocket 需要 Upgrade 支持，企业环境中深度包检测防火墙可能让功能整体不可用（Ably，已抓取原文）；服务端还需处理 sticky 路由、空闲超时（LB 默认几十秒断空闲连接，需心跳保活）。
• SSE 穿透性好，但有三个著名部署坑：① nginx 默认 proxy_buffering on 会缓冲掉流式响应——需 proxy_buffering off 或应用层回 X-Accel-Buffering: no 头；② 需 proxy_http_version 1.1 + 清空 Connection 头 + 调大 proxy_read_timeout；③ HTTP/1.1 下浏览器每域仅约 6 个并发连接，多标签页即触顶——上 HTTP/2 多路复用后解除（Stack Overflow、ServerFault、OneUptime、Portalzine）。
• 长轮询兼容性最好但服务器资源最贵：每个"等待中的消息"都占用一个完整请求槽位。
• WebTransport 需要端到端 HTTP/3，nginx 与多数负载均衡的支持仍是最大摩擦。
• MCP Streamable HTTP / 托管平台：前者无长连接也能工作，部署面最省；后者把全部运维成本转化为按量付费。

2.3.6 生态成熟度（2026-11 截面）

• WebSocket：最成熟，RFC 6455（2011），全语言、全监控栈、全托管平台支持。选它不承担技术风险，承担的是自建重连/恢复的工程风险。
• SSE：WHATWG HTML 标准的一部分，浏览器支持完整。2025 年被多篇技术评论称为"SSE 复兴之年"（Portalzine 标题即 "SSE's Glorious Comeback"）；驱动力正是 LLM/Agent——所对照的主流 LLM API 的 token 流均走 SSE，主流 Agent UI 普遍在转发 SSE。
• 长轮询：仅作为框架回退兜底存在（Engine.IO 以轮询起步再升级 WebSocket；SignalR 协商回退的最后一极）。
• WebTransport：2026-03 达到浏览器 Baseline，但瓶颈换位到服务端生态（框架、代理、LB 未跟上）；媒体流/MoQ 场景先行。
• 框架层：Socket.IO 拥有最大的 JS 实时社区；SignalR 是 .NET 官方；Centrifugo 是 Go 生态多协议实时服务器代表。
• Agent 协议层：Vercel AI SDK 的 UI Message Stream 协议 v1 事实上是 Next.js 系 Agent UI 的默认（Pydantic AI 等第三方也做了适配器）；AG-UI 由 CopilotKit 主导，定位为"MCP/A2A 的前端互补协议"，已接 LangGraph 等后端。此外，Ably 在《WebSockets on Vercel: native support, limits, and your options》中记载：Vercel 于 2026-06-22 起公测（public beta）原生 WebSocket 能力，但①受函数时长限制（默认 5 分钟上限，Pro/Enterprise 计划在 beta 中可延至 30 分钟）；②连接绑定单实例（"future connections aren't guaranteed to land on the same instance"）；③无跨实例/跨设备 fan-out（"no built-in way to broadcast a message to connections held by other instances"）（修订时已抓取该页核对）。

2.4 框架层与协议层横向对比（L2–L5）

读表要点：Socket.IO 与 Centrifugo 代表两种恢复哲学——前者恢复"这个连接的会话状态"（rooms/data/offset，分钟级窗口），后者恢复"channel 的消息流"（服务端历史 + 流位置，窗口可配到更长）；AI SDK 代表第三种——不做传输级恢复，靠 SSE 编码语义 + 服务端持久化让流"可续"（已抓取原文）。

2.5 Agent UI 场景适配矩阵

三、交叉洞察

3.1 两轴结合说明了什么

洞察一：断线重连三十年史 = 状态归属权迁移史；横轴上的当代形态是"评估实时方案的三问"。
纵轴显示，重连责任经历四次迁移：应用代码记序号（Comet）→ 浏览器承诺（EventSource + Last-Event-ID，2009）→ 连接库的状态恢复（Socket.IO 4.6，2023-02）→ 服务端状态恢复协议（previous_response_id、resumable streams、MCP 事件重放，2025–2026）。横轴印证了迁移的终点：今天所有主流方案——Socket.IO 的 offset 补发、Centrifugo 的 history recovery、MCP 的 Last-Event-ID 重放、AI SDK 的流恢复——本质是同一思想（流位置 + 服务端保留 + 重连续传）在不同抽象层的实现，且没有谁把状态放在传输层。纵轴的"终局"与横轴的"格局"互为证明：评估任何实时方案，该问的不是"支持 WebSocket 吗"，而是恢复窗口多长、恢复范围多大、状态存在哪。

洞察二：负载变迁每次都重写"哪个协议更强"的答案——选型由场景不对称性决定，而非协议优劣。
三十年里同样的争议（延迟 vs 成本 vs 可靠性）换了三种负载重演了三次：社交信息流时代长轮询胜出（Comet）、移动 IM 时代 WebSocket 胜出（双工+二进制+移动网络）、token 流时代 SSE 胜出（所对照的主流 LLM API 用脚投票，Simon Willison）。每一次，胜者都不是"技术上最强"的协议，而是与当期负载的不对称性（上行低频/下行高频、文本/二进制、单向/双向）最匹配的协议。Agent UI 的不对称性是：上行是低频小消息（输入、确认、取消），下行是高频主负荷（token 流、工具事件）——这决定了 SSE+POST 的结构性优势，也决定了语音 agent 必然回到 WebSocket/WebTransport。

洞察三：两章关于背压的"矛盾"是 API 分层的真实写照——背压每次栈上移一层就丢失一次，再由更高层补课。
纵轴说"WebSocketStream（2024）给浏览器 WebSocket 补上了背压"，横轴说"浏览器 WebSocket API 无背压（MDN）"——两者都对，只是对象分别是 2024 年的新 API 与 2011 年定型的经典 API（完整调和见 1.6 与 2.3.4，此处不重复）；Agent 场景 token 级 vs 事件级/任务级两层背压之分同理（见 2.3.4）。把这个分歧展开，是一条贯穿三十年的规律：TCP 有流控 → Comet 把它藏进了 HTTP 挂起 → 经典浏览器 API 丢失它 → WebSocketStream/WebTransport 在新 API 里补回 → Agent 时代又在应用层重建它（token 预算、渲染节流、abort 语义）。收束成一句话：EventSource 没有标准反压信号、事件级积压不可见——这是 2026 年 SSE 体系最明确的未完成项。

洞察四："常驻连接"的理想三次都没赢到底——部署友好性一再击败连接姿态。
Comet 的常驻挂起被 WebSocket 的常驻双工取代；WebSocket 的常驻双工被企业防火墙、无服务器函数模型、多实例扩容不断削弱（LB 空闲超时、sticky 路由、Vercel 原生 WebSocket 的函数时长限制——见 2.3.6）；2025-03-26 MCP 干脆弃用常驻 SSE 端点，改用单端点 Streamable HTTP（动机解析）——弃用的是"SSE 端点"而非"SSE 编码"。三次范式转移中，"常驻连接"每次都是更优雅的姿态，每次都输给了"没有长连接也能正确工作"的部署现实。把协议先设计成无长连接可正确工作、再把流作为性能增强，是三十年沉淀下来的设计铁律，也是 Streamable HTTP 被选为 MCP 标准的根本原因。

洞察五：协议成功靠生态兼容而非技术优越——2010 年的断裂与 2026 年的 Baseline 互为镜像。
WebSocket 在 2010 年因 draft-76 代理缓存投毒遭遇"断裂一周"，RFC 6455 用帧掩码换回中间盒的信任才得以存活；三十年后的 WebTransport 技术上最全面（多流、数据报、流级背压），2026-03 达到浏览器 Baseline，但瓶颈换位到 nginx/负载均衡/服务端框架——"最大的摩擦点在后端而非浏览器"。两个事件互为镜像：传输协议的胜负手从来不在协议本身，而在它与部署生态（代理、防火墙、LB、函数平台）的兼容成本。参照 WebSocket 从 2011 规范到成为默认花了约十年，短期内 WebTransport 不会改变 Agent UI 格局；它最可能的突破口是语音/多模态 agent（数据报 + 无队头阻塞 + 流级背压）。

洞察六：长轮询的四次身份变化，说明"淘汰一种技术容易，淘汰它的思想很难"。
长轮询的一生：Comet 时代的主角（2005–2007）→ 连接库时代的回退兜底（Engine.IO 起步传输、SignalR 协商最后一极）→ Agent 时代的"还魂"（2023-11 Assistants API v1 靠轮询 retrieve run 获取分钟级任务状态——长任务下轮询反而最朴素可靠）→ Responses API（2025-03）以服务端状态 + 流式事件终结轮询，Assistants API 于 2026-08-26 关停。它退场了，但两个设计遗产被正式继承："无长连接也能工作"的降级思想（Streamable HTTP 的核心主张）与"以请求节奏实现天然限速"（某种意义上是背压的最朴素解）。给选型者的启示：不要按"技术是否过时"排除选项，要按"负载需要什么思想"重新组合它们。

洞察七（总收束）：Agent UI 的主战场从"保住连接"转移到"保住状态流"，两轴在此汇合。
纵轴的三条驱动因素（TTFT 不可消除、半双工足够、状态外移）解释了为什么转移发生；横轴的 Ably"三不保证"解释了转移后竞争在哪里——裸传输层已无差异化空间，胜负全在会话层（恢复窗口、恢复范围、状态存哪）与语义层（审批、打断、跨设备续会话）。三十年前的问题"浏览器如何第一时间拿到新数据"，在 Agent 时代的答案变成了："连接随时可以死，只要状态流能续上。"

3.2 对用户的判断与建议

默认路径（多数 Agent UI 项目从这里开始）：

1. 下行以 LLM token 流为主 → SSE（HTTP/2 部署）+ 普通 POST 上行。给每个事件编号并实现 Last-Event-ID 重放端点（SSE 的自动重连只有在此前提下才"免费"）；或直接采用 AI SDK UI Message Stream v1 / MCP Streamable HTTP 这类现成会话协议，别自造编码。
2. 断线恢复是硬需求（付费用户、长任务 agent）→ 先回答三问：恢复窗口（分钟级够吗？Socket.IO 官方示例 2 分钟，Centrifugo 可配保留期）、恢复范围（补发事件还是恢复完整会话状态）、恢复依赖（内存 / Redis Streams / MongoDB / 服务端历史）。长任务 agent 另加应用层 checkpoint：agent 运行状态落库，重连后用"查询"代替"补发"——这是唯一能覆盖"刷新页面/换设备"的方案。
3. 存在高频客户端上行或二进制上行（语音、协作、实时画布）→ WebSocket，但不要裸写：引入 Socket.IO/SignalR/Centrifugo 之一，把重连、恢复、心跳、回退外包给框架；语音 agent 优先考虑服务端推荐的 WebRTC/WebTransport 形态。
4. 需要支持多端、离线、后台完成通知 → 长连接之外补 Web Push；agent 状态必须外置到服务端，因为没有任何传输保证跨设备 continuity。
5. 绿地项目、基础设施可控、追求极致延迟 → 可试点 WebTransport，同时保留 WebSocket 回退；2026-11 时点不建议把 WebTransport 作为唯一路径。

三个高频误区的提醒：

• 不要因为"WebSocket 更强"就默认选它——在 token 流场景它是纯负担（Upgrade、sticky 路由、防火墙风险、自建重连），SSE 过一切代理且浏览器白送重连。
• 不要把"SSE 自动重连"当成"断线恢复"——没有事件编号与服务端缓冲，重连只是重开一条新流，中间的数据空洞无人知晓（Ably 三不保证）。
• 不要指望传输层解决背压——2026 年没有任何主流方案提供开箱即用的端到端背压；用应用层手段（abort 语义、分批发送、渲染节流、token 预算）管理它，并把"慢消费者检测"写进服务端设计（丢弃策略或断开，Centrifugo 的 per-channel 节流是现成参考）。

3.3 开放问题

1. 可恢复性标准不齐：MCP 的 Last-Event-ID 重放是可选能力，OpenAI 的 previous_response_id 是私有契约，AI SDK 的 resumable streams 是框架自有方案——尚无跨厂商的"agent 任务流断点续传"标准。
2. SSE 端到端背压缺位：HTTP 流控对 EventSource 不可见，agent 长任务中"服务端已产完、客户端还在渲染"的事件级积压没有标准反压信号；WebSocketStream 只解决了 WebSocket 一侧且生态未普及。
3. 多 Agent 扇入：A2A 中 webhook 推送与 SSE 并存，推送模型重新抬头，协议收敛尚未完成。
4. WebTransport 服务端生态：浏览器已 Baseline，nginx/LB/框架未跟上；若突破，语音/多模态 agent 将是第一落点。
5. 鉴权与安全在"可恢复流"上的欠账：EventSource 无法自定义请求头，Cookie 之外的鉴权（如 Authorization: Bearer）只能退到查询参数、一次性 URL 或 Cookie 方案——各有泄露与 CSRF 权衡，业界并无统一范式；按 3.2 建议自建"事件编号 + Last-Event-ID 重放端点"时，天然引入越权面：该头完全由客户端控制、可伪造，重放端点必须校验事件归属（会话/用户），否则可被枚举拉取他人事件流。MCP 的 Mcp-Session-Id、Socket.IO 恢复所用的私有会话 ID 同理——恢复路径必须置于鉴权之后（Socket.IO 仅以 skipMiddlewares 警告点到为止，见 2.3.2）。MCP 规范早在 2024-11-05 版就写有安全警告（校验 Origin 头防 DNS rebinding、本地服务只绑 localhost、所有连接应实现鉴权），但跨框架的"恢复路径鉴权"最佳实践至今缺位。

四、参考来源

以下来源由两份章节研究提供：标注"（已抓取原文）"者为横轴章在会话内以 WebFetch 直接抓取核对的一手文档；其余为两章检索核对或转述来源。纵轴章标注"模型既有知识"的条目（微软 OWA iframe 流约 2000、Flash XMLSocket 2001、OpenAI stream:true 2023-03、Slack WebSocket 迁移与 Flannel 2014–2015）沿用未复核标注。标注"（修订时核对）"者为 2026-11-03 修订时重新抓取/检索核对的条目。

规范与标准

• WHATWG 邮件列表，WebSocket 命名与起源（2008-06-18）：https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Jun/0186.html
• RFC 6455（HyBi 最终草案）：https://www.ietf.org/archive/id/draft-ietf-hybi-thewebsocketprotocol-17.html ；draft-76（2010 断裂源头）：https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76
• WHATWG HTML 规范 · Server-sent events（自动重连/Last-Event-ID/retry:）：https://html.spec.whatwg.org/multipage/server-sent-events.html
• W3C EventSource 工作草案（2009 / 2011）：https://www.w3.org/TR/2009/WD-eventsource-20090423/ 、https://www.w3.org/TR/2011/WD-eventsource-20110208/
• RFC 7540（HTTP/2）：https://httpwg.org/specs/rfc7540.html ；RFC 8441（WebSocket over HTTP/2）：https://www.rfc-editor.org/info/rfc8441
• WebTransport W3C 工作草案（2021）：https://www.w3.org/TR/2021/WD-webtransport-20210504/
• WebKit standards-positions · WebTransport（2022-06 开题、早期讨论曾表达保留意见、2023-04-12 定为 support；修订时核对）：https://github.com/WebKit/standards-positions/issues/18
• Baseline 定义（Web Platform DX 社区组；修订时检索核对）：https://web.dev/baseline
• MCP 传输规范：2024-11-05 版（HTTP+SSE 双端点；修订时核对）：https://modelcontextprotocol.io/specification/2024-11-05/basic/transports ；2025-03-26 版（Streamable HTTP 取代 HTTP+SSE）：https://modelcontextprotocol.io/specification/2025-03-26/basic/transports ；2026-07-28 版（标准绑定收敛为 stdio 与 Streamable HTTP；修订时核对）：https://modelcontextprotocol.io/specification/2026-07-28/basic/transports （另有 mcpcn.com 镜像存档：https://mcpcn.com/en/specification/2026-07-28/basic/transports/streamable-http ）；MCP 官方博客 · Transport Future（2025-12-19）：https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future

官方文档与工程一手来源

• Comet 开山文：Alex Russell（2006-03-03）：https://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/
• WebSocket 2010 断裂：Mozilla Hacks：https://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ ；Wired：https://www.wired.com/2010/12/security-flaws-force-firefox-opera-to-turn-off-websockets/ ；Pusher 评论：https://pusher.com/blog/its-not-websockets-its-your-broken-proxy/
• Socket.IO：1.0 公告（2014-05-28）：https://socket.io/blog/introducing-socket-io-1-0/ ；连接状态恢复文档（已抓取原文；修订时再次核对：maxDisconnectionDuration 无默认值表述、仅官方示例 2 分钟）：https://socket.io/docs/v4/connection-state-recovery/ ；4.6.0 changelog：https://socket.io/docs/v4/changelog/4.6.0 ；背压 issue #4435：https://github.com/socketio/socket.io/issues/4435
• SockJS（RabbitMQ 博客，2011-09-13）：https://www.rabbitmq.com/blog/2011/09/13/sockjs-websocket-emulation
• 托管实时：Google 收购 Firebase（2014-10-21）：https://techcrunch.com/2014/10/21/google-acquires-firebase-to-help-developers-build-better-realtime-apps/ ；Scaling WebSockets（Ably/Matthew O'Riordan）：https://blog.mattheworiordan.com/p/scaling-websockets-to-billions-of
• AWS API Gateway WebSocket API（2018-12-18）：https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/
• WebSocketStream（Chrome 124）：https://developer.chrome.com/release-notes/124 、https://developer.chrome.com/docs/capabilities/web-apis/websocketstream 、https://developer.mozilla.org/en-US/docs/Web/API/WebSocketStream
• WebTransport（Chrome 97 文档）：https://developer.chrome.com/docs/capabilities/web-apis/webtransport ；Ably · Can WebTransport replace WebSockets：https://ably.com/blog/can-webtransport-replace-websockets ；singhajit · How WebTransport works：https://singhajit.com/how-webtransport-works ；Baseline 讨论：https://www.reddit.com/r/webdev/comments/1ssu3bs/webtransport_is_now_baseline_as_of_march_2026
• Ably · WebSockets vs SSE（"三不保证"，已抓取原文）：https://ably.com/blog/websockets-vs-sse
• Ably · WebSockets on Vercel（2026-06-22 原生 WebSocket 公测及其限制；修订时抓取核对）：https://ably.com/vercel/websockets-on-vercel
• MDN：WebSockets API（无背压说明）：https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API ；Using server-sent events：https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
• Centrifugo（history/StreamPosition 恢复；cache recovery 原文 "deliver latest publication immediately upon subscription"；修订时核对）：https://github.com/centrifugal/centrifugo/blob/master/README.md
• uWebSockets 背压上限讨论：https://github.com/uNetworking/uWebSockets/discussions/1182

Agent 时代来源

• ChatGPT 上线报道：https://www.zmescience.com/future/chatgpt-launched-just-a-week-ago-and-rocked-the-world-heres-what-you-need-to-know-about-it/
• Simon Willison · How streaming LLM APIs work（OpenAI/Anthropic 均为 SSE）：https://til.simonwillison.net/llms/streaming-llm-apis
• OpenAI：Streaming API responses：https://developers.openai.com/api/docs/guides/streaming-responses ；Responses API 迁移指南：https://developers.openai.com/api/docs/guides/migrate-to-responses ；流式事件社区整理：https://community.openai.com/t/responses-api-streaming-the-simple-guide-to-events/1363122
• OpenAI Assistants API：v1 轮询教程：https://gettingstarted.ai/blog/openai-ai-assistants-api-function-calling-tool-tutorial/ ；v2 FAQ：https://help.openai.com/en/articles/8550641-assistants-api-v2-faq ；关停时间线：https://killedbyai.net/dead/openai-assistants-api 、https://uxcontinuum.com/blog/saas-development/openai-assistants-api-shutdown-migration-guide
• Anthropic Messages 流式事件（文档镜像）：https://github.com/hkai-ai/LLM_OFFICIAL_DOCUMENTATION/blob/main/anthropic/messages-streaming.md
• Vercel AI SDK：3.0（Generative UI）：https://vercel.com/blog/ai-sdk-3-generative-ui ；5.0（resumable streams）：https://vercel.com/blog/ai-sdk-5 ；恢复流文档（修订时核对：重连由 GET 端点续播、首个 start chunk 后重建响应）：https://ai-sdk.dev/docs/ai-sdk-ui/chatbot-resume-streams ；流协议文档（已抓取原文；修订时核对：tool-input-start 的可选 inputEncoding 及其随 input-streaming 部件保留、SSE 选型理由含 ping 保活）：https://ai-sdk.dev/docs/ai-sdk-ui/stream-protocol
• LangChain：LCEL 综述：https://www.artefact.com/blog/unleashing-the-power-of-langchain-expression-language-lcel-from-proof-of-concept-to-production/ ；LangServe：https://www.langchain.com/blog/introducing-langserve/
• MCP：弃用 SSE 的动机解析：https://blog.fka.dev/blog/2025-06-06-why-mcp-deprecated-sse-and-go-with-streamable-http/ ；2025-06-18 修订要点：https://www.linkedin.com/pulse/top-5-mcp-updates-june-18-2025-enterprise-ready-faster-balram-prasad-zbppc
• A2A：InfoQ 报道：https://www.infoq.com/news/2025/04/google-agentic-a2a/ ；协议现状：https://blog.fka.dev/blog/2025-09-11-what-happened-to-googles-a2a
• AG-UI 协议仓库：https://github.com/ag-ui-protocol/ag-ui ；Pydantic AI 对 AI SDK 流协议的适配：https://pydantic.dev/docs/ai/integrations/ui/vercel-ai
• OpenAI Realtime API（WebSocket 语音，2024-10 社区帖）：https://community.openai.com/t/realtime-speech-to-speech-the-web-socket-gets-closed-shortly-after-agent-speaks/974472

综述与部署经验

• SSE 部署（nginx）：https://stackoverflow.com/questions/13672743/eventsource-server-sent-events-through-nginx 、https://serverfault.com/questions/801628/for-server-sent-events-sse-what-nginx-proxy-configuration-is-appropriate 、https://oneuptime.com/blog/post/2025-12-16-server-sent-events-nginx/view 、https://objectgraph.com/blog/optimizing-sse-nginx-streaming
• Portalzine · SSE's Glorious Comeback（6 连接上限与 HTTP/2）：https://portalzine.de/sses-glorious-comeback-why-2025-is-the-year-of-server-sent-events
• 2025 年三传输对比综述：https://dev.to/haraf/server-sent-events-sse-vs-websockets-vs-long-polling-whats-best-in-2025-5ep8 、https://hinterbuild.com/blog/websockets-vs-sse-vs-long-polling-2026-guide 、https://www.fratepietro.com/2025/websocket-sse-longpolling
• SignalR vs Socket.IO 对比：https://polyxer.com/blogs/signalr-vs-socket-io-the-differences-you-need-to-know
• Socket.IO/Engine.IO 综述（dev.to/ably）：https://dev.to/ably/everything-you-need-to-know-about-socket-io-16nf
• SSE 自动重连解析（Atomic Object）：https://spin.atomicobject.com/server-sent-events/ ；HTML5 Doctor（2012）：http://html5doctor.com/server-sent-events/
• 社区重连前提讨论（"发送 event id 重连才免费"）：https://www.reddit.com/r/programming/comments/1x2r88r/stop_reaching_for_websockets_by_default
• 百科条目：Wikipedia · WebSocket：https://en.wikipedia.org/wiki/WebSocket ；Wikipedia · Server-Sent Events：https://en.wikipedia.org/wiki/Server-sent_events ；Wikipedia · Comet：https://en.wikipedia.org/wiki/Comet_(programming)

附：两章矛盾的调和记录（供修订者参考）

附2：审读意见处理记录（2026-11-03 独立审读意见，逐条对照）