WebSocket并非万能，其低延迟优势依赖稳定连接与合理实现；长轮询虽带宽开销大，但兼容性强、部署简单，适合秒级容忍场景。
WebSocket 更好，但“更好”只在它被正确用对场景时成立——不是所有实时需求都该无脑切 WebSocket。
WebSocket 延迟低，但延迟不等于“快”
WebSocket 的端到端延迟理论值接近 t传输（纯网络传播时间），实测局域网常低于 10ms，公网也多在 20–50ms。但这前提是连接没断、没卡在代理或防火墙后。
- 真实延迟受
onmessage处理逻辑拖累：比如收到消息后同步执行复杂 JSON 解析 + DOM 更新，会把“接收完成”和“用户看到”拉开几百毫秒 - 某些企业内网出口强制拦截
Upgrade: websocket请求，连接直接 fallback 到 400 或超时，此时你连“低延迟”的边都摸不到 - 移动端弱网下，TCP 连接保活比 HTTP 请求更难：一次丢包可能触发底层重传，而轮询只是某次请求失败，下次重试成本更低
HTTP 长轮询不是“落后技术”，而是兼容性兜底方案
长轮询的 /api/wait-for-messages 接口本质仍是标准 HTTP，能穿绝大多数 CDN、反向代理、审计网关，连 IE11 都跑得稳。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 超时时间（如 30s）必须和服务端
keep-alive timeout对齐，否则连接可能被 Nginx 静默断开，前端却还在等响应 - 客户端需主动控制并发请求数：不能同时发 10 个长轮询请求，否则服务端线程/连接池容易耗尽
- 消息体里建议加
timestamp字段，避免因重试或乱序导致前端状态错乱（WebSocket 本身不保证消息顺序，除非你自己加序列号）
带宽和服务器资源消耗差异是硬指标
每秒推送一条 100 字节消息，1000 个在线用户：
- HTTP 长轮询：每次请求带完整 Header（约 800B），实际带宽 ≈
1000 × 800B = 800KB/s，且每个 pending 请求占一个服务端线程 - WebSocket：帧头仅 6 字节（含掩码），心跳包可压缩到 2 字节，实际带宽 ≈
1000 × (100 + 6)B ≈ 106KB/s，单连接内存占用通常 - 注意：如果业务要求“每秒 10 条消息”，轮询方案的带宽和连接数会线性爆炸，而 WebSocket 仍稳定在
~1MB/s和千级连接
别忽略重连和心跳的实现成本
一个没加心跳的 WebSocket 实例，在 NAT 超时（常见 30–60s）后会静默断开，前端 onclose 可能几小时都不触发；而轮询天然具备“探测”能力——每次请求失败就是一次明确的故障信号。
- 心跳建议用服务端主动
ping+ 客户端pong，不要依赖setInterval发空消息，后者在页面休眠时会堆积 - 重连策略必须指数退避：
1s → 2s → 4s → 8s，否则网络抖动时全量客户端集体重连，会把服务端打挂 - 轮询方案的“重连”就是下一次
fetch，逻辑天然简单；WebSocket 却要管理readyState、排队未发送消息、恢复订阅状态等一堆细节
真正卡住多数人的，从来不是协议选型，而是没想清楚：你的“实时”到底要多实？用户能否感知 200ms 和 800ms 的差别？有没有运维团队能扛住 WebSocket 连接层的监控和排障？这些比 new WebSocket() 多敲两行代码重要得多。
