WebSockets、Server-Sent Events、Long-Polling、WebRTC 与 WebTransport 的比较

原文 ↗ Hacker News 讨论 ↗

长轮询与轮询模式

  • 有些人怀念长轮询，因为它简单、对 HTTP 友好；也有人认为，一旦考虑到超时、代理、重试和消息顺序，真实部署中它就并不“傻瓜式简单”。
  • 长轮询因其与通用 HTTP 工具和 API 的互操作性而受到称赞。
  • 一些人指出，任何推送式系统都需要一种机制来重新加载完整状态并处理遗漏的更新；到了这一步，直接轮询或带游标的“events 端点”就会很有吸引力。
  • 关于可扩展性存在争论：一方认为长轮询像其他技术一样是线性扩展；另一方则指出，额外的订阅抖动以及 RTT/数据包开销使它在实践中“最不具扩展性”。

Server-Sent Events（SSE）

  • 因其简单、易于与基础技术栈集成（例如 Apache + PHP），以及对 CDN 友好而广受欢迎。
  • 被视为通过分块响应实现的“标准化长轮询/Comet”。
  • 局限性：仅支持文本（二进制需要 base64 或特殊编码）、HTTP/1.1 下受浏览器施加的连接限制，以及原生 EventSource API 对请求头控制有限。
  • 变通方案包括 HTTP/2/3 多路复用、域名分片、SharedWorkers/broadcast channels，以及带有更丰富选项的自定义 SSE 客户端。
  • 一些人报告在受限/企业环境以及某些服务器框架下，SSE 可靠性存在问题。

WebSockets

  • 作为双向实时通信的默认选择很受欢迎，通常上层使用 JSON-RPC。
  • 批评点包括：更难扩展和运维、缺乏内建多路复用和背压（不过新的 WebSocketStream 旨在有所帮助），以及在某些环境中持续存在的防火墙/企业网络问题。
  • 许多人会使用提供回退机制（长轮询、SSE 等）的库，以应对损坏的代理和旧浏览器。

WebRTC 与 WebTransport

  • WebRTC 在实践中对 NAT 穿越表现可靠，并且部署广泛；最适合 P2P 和丰富媒体场景，不太适合简单的服务器推送。
  • WebTransport 因其流、背压以及避免队头阻塞而受到青睐；有些人已经把它用于游戏。
  • 担忧点：某些网络可能会阻止 UDP/HTTP/3，从而迫使同时维护与 WebSockets 的双实现。

HTTP 流式传输及其变体

  • 一些人强调通用 HTTP 响应流式传输（例如通过 fetch streams 传输 JSONL、HTTP-streaming transports）是一个强大但常被低估的选择，有时对于有限长度的流会比 SSE 更受青睐。

认证、后台与移动端

  • SSE/WebSockets 的浏览器 API 使自定义认证头变得别扭；通常的变通办法是使用 cookie，或者改用自定义客户端。
  • 移动端和后台行为存在问题：无线电模块、超时以及 worker 生命周期都可能破坏“始终在线”的连接；推送 API 和刷新按钮仍然是重要的回退手段。