WebSocket连接模型为全双工持久通道，HTTP/2本质仍是请求-响应驱动；前者握手后直传数据、状态轻、延迟稳，后者需维护流状态、Server Push已弃用，且错误处理与部署兼容性更差。
WebSocket 与 HTTP/2 的连接模型差异直接决定高并发表现
HTTP/2 虽支持多路复用（HTTP/2 multiplexing），但本质仍是请求-响应驱动：每个逻辑流（stream）仍需客户端先发 HEADERS 帧，服务器才能回传数据；而 WebSocket 一旦握手完成（Upgrade: websocket），就进入无协议帧约束的裸数据通道，没有流 ID、优先级或头部压缩开销。
这意味着在 10k 并发连接下：
- HTTP/2 服务端必须维护每个 stream 的状态、依赖树、流量控制窗口 —— 内存占用随并发线性增长
- WebSocket 服务端只需维护 socket fd + 少量元数据（如
ws.readyState），状态极轻 - 当推送频率达 50msg/s/连接时，HTTP/2 的帧调度和流复用反而成为瓶颈；WebSocket 则直写 TCP 缓冲区，延迟更稳
HTTP/2 Server Push 不等于实时推送，且已被主流浏览器弃用
很多开发者误以为 server push 能替代 WebSocket 推送，但实际它只适用于「资源预加载」场景：比如客户端请求 /index.html，服务器可顺带 push /style.css。它不支持任意时机向已建立连接的客户端发送业务消息。
更重要的是：Chrome 96+ 和 Firefox 90+ 已默认禁用 server push，因为实测中它常导致缓存冗余、带宽浪费，且无法按业务逻辑条件触发。Nginx 1.21+ 也移除了 http_v2_push 指令。
所以所谓“HTTP/2 推送”在 2026 年已基本不可用，更无法支撑聊天、行情等需动态 payload 的实时推送。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
WebSocket 在真实推送场景中的错误处理更可控
HTTP/2 连接异常时，错误往往静默：比如流重置（RST_STREAM）可能只表现为某次 fetch() 的 NetworkError，但连接本身仍显示 open；而 WebSocket 的 onerror 和 onclose 事件明确对应连接生命周期，且 readyState 值（0–3）可直接用于重连决策。
典型问题包括：
- HTTP/2 下长轮询（
fetch(..., { keepalive: true })）遇到中间代理超时，客户端无感知，直到下次请求才暴露失败 - WebSocket 握手失败会立即触发
onerror，且event.target.url可定位具体 endpoint - 心跳保活：WebSocket 可用
ping/pong帧（由底层自动处理），HTTP/2 需手动构造空HEAD请求，易被 CDN 或 WAF 拦截
别忽略部署链路上的兼容性断层
HTTP/2 要求 TLS 1.2+ 且依赖 ALPN 协商，而大量企业级网关（如 F5 BIG-IP 14.x）、旧版 Nginx（nginx ）或某些运营商 DPI 设备，会对 HTTP/2 流量做深度解析甚至降级为 HTTP/1.1 —— 导致推送失效却无日志报错。
WebSocket 则不同：它复用 HTTP/1.1 握手（Upgrade: websocket），后续流量是二进制帧，绝大多数中间设备仅透传，只要 TCP 层通，上层就大概率可用。这也是为什么金融、政企类项目在混合网络环境下仍首选 WebSocket 的关键原因。
真正难的不是选协议，而是确认你的 CDN、WAF、LB 是否对 Connection: Upgrade 头放行，以及是否限制了 WebSocket 连接时长（例如阿里云 SLB 默认 60s 空闲超时，需显式调大 idle_timeout）。
