一、历史背景 + 时间轴
网页一旦需要'实时'，麻烦就开始了：数据在不断变化，用户却只能等下一次刷新；
- 刷新解决不了的延迟，用短轮询凑数，又被无数空请求反噬；
- 再加长轮询，试图把'有了新数据再说'变成一种伪推送，却仍困在请求—响应的笼子里。
- 开发者于是继续前探：让连接不再频繁重建，尝试分块直输，把事件像水一样持续送达，于是有了更顺滑的 Streaming 与标准化的 SSE。
直到某一刻，我们不再满足于'更聪明的单向'，而是迈向真正的'同时说话与倾听'——WebSocket 把通信从一次次请求，变成一条持久而通透的通道。此后，HTTP/2、HTTP/3 与 QUIC 又在底层为效率和时延开了绿灯，甚至提供了可选可靠与无序传输的更多可能。
接下来，我们就沿着这条主线，层层展开：它们各自解决了什么、在哪些场景最合拍、又如何在你的系统里形成清晰的选型边界。
[图示：技术演进对比图]
01｜从整页刷新出发：减少浪费的一条链路
这一块是为了解决'整页刷新导致的高延迟与带宽浪费'，逐级细化与优化。
a. 早期网页：整页刷新
- 背景与问题：每次更新都整页请求，体验割裂、带宽浪费、延迟高。
- 直接影响：促使前端与服务端思考'只取变化'。
b. 短轮询（Short Polling）为解决整页刷新的低效
- 解决：改为'隔一段时间拉一次'，显著减少整页重载带来的浪费。
- 局限：高频请求带来大量空响应与服务器开销。
- 承接改进：为减少空转，演进到长轮询；同时催生更流式的思路（Streaming/SSE）。
c. 长轮询（Comet/挂起请求）为减少短轮询的空转
- 解决：请求挂起，服务器有新数据才返回，接近'伪推送'，显著降低空转。
- 局限：本质仍是请求 - 响应；连接频繁重建；难做真正双向。
- 承接改进：
- 单向推送更稳：SSE 标准化单向事件流。
- 若要真双向与二进制：交给 WebSocket（见独立块）。
d. HTTP Streaming（分块传输/持续输出）为进一步降低重连与延迟
- 解决：保持连接，分块持续输出，适合连续文本/事件流，重连更少、延迟更低。
- 局限：多为单向，受代理/中间件影响，兼容性不一。
- 承接改进：单向事件由 SSE 标准化；双向场景仍需 WebSocket。
e. SSE（Server-Sent Events）单向推送的标准化终点
- 解决：以标准事件流语义提供单向推送，浏览器原生支持，资源占用低。
- 适配范围：通知、进度、日志/监控等文本或事件流。
- 位置关系：在'只需单向推送'的场景中，SSE 是这一链条的稳定落点，而非过渡技术。
02｜范式跃迁：WebSocket（独立大块）
这不是前面链条的'又一改良'，而是从请求 - 响应转向全双工持久连接的范式变化。
WebSocket（全双工、持久、低开销）
- 解决：真正的双向实时通信，降低握手与头部开销，支持文本与二进制，端到端延迟低。
- 典型场景：聊天、协同编辑、在线游戏、行情推送、IoT。
- 与上一链条的关系：
- 在'需要双向实时'的主战场，实质上取代了短轮询/长轮询等过渡方案。
- 与 SSE 并存：若只有单向通知/事件流，SSE 更简单更省资源；若需要双向或二进制，WebSocket 更合适。
- 运维关注：连接状态管理、容量与反压、企业代理/负载均衡兼容。
03｜底座升级与新选项：HTTP/2·HTTP/3·QUIC 家族
这部分不是替代前两块，而是提供更高效的承载与更灵活的传输语义。
WS over H2/H3
- 价值：与同域请求复用连接、更好穿透与效率、更低握手成本。
- 作用：让 WebSocket 的部署与网络效率更优。
WebTransport（基于 QUIC）
- 价值：可选可靠与有序/无序、更低延迟，适合实时媒体、游戏、定制协议。
- 关系：不是取代 WebSocket/SSE 的通吃方案，而是当你需要'更细粒度的可靠性与顺序控制'时的新工具。
