WebSocket 是一次 TCP 连接上的 HTTP Upgrade 握手，建立后转为二进制帧通信，不走 HTTP 路由；长轮询则是周期性 HTTP 请求-响应循环，兼容性好但开销大、有空窗期。
WebSocket 是一次 Upgrade 握手，不是 HTTP 请求
很多人误以为 new websocket('ws://...') 是发了个 http 请求，其实它底层是 tcp 连接 + 协议升级。客户端先发一个带 upgrade: websocket 和 connection: upgrade 的 http 请求，服务器返回 101 switching protocols 后，这条 tcp 连接就“脱钩”http，变成纯 websocket 帧通道。
这意味着：
-
ws://和wss://不走 HTTP 路由逻辑，后端不能用 Express 的app.get('/ws')直接处理，得用专门的 WebSocket 服务（如ws、socket.io或 Nginx 配置upgrade） - 握手阶段有 Cookie、Authorization 等 HTTP 头可传，但连接建立后，这些头就失效了，身份需靠首次消息或 token 字段传递
- 代理（尤其是老版 Nginx、CDN）可能默认不透传
Upgrade请求，导致连接卡在 pending 或直接 400/502
长轮询本质还是 HTTP 请求-响应循环
fetch('/api/wait') 发出去，服务器没数据就 hold 住连接，直到超时（比如 30s）或有新消息才 res.json() 返回 —— 这整个过程仍是标准 HTTP，每次响应完连接就断，下一次请求是全新连接。
所以它天然兼容：
- 所有 CDN、反向代理（只要支持 HTTP/1.1）
- 浏览器离线缓存、CORS 配置、HTTP/2 多路复用（但实际很少用上）
- 后端无须额外协议栈，Spring Boot 写个
@GetMapping加Thread.sleep()就能模拟
但代价是：每个请求都带完整 HTTP 头（平均 800+ 字节），每秒 10 次长轮询 ≈ 8KB/s/连接纯开销；而 WebSocket 建连后帧头仅 2~6 字节。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
延迟和重连行为完全不同
WebSocket 连接建立后，服务器可毫秒级 ws.send() 推送；长轮询必须等客户端发起下一轮请求，中间存在“空窗期”。这个空窗期 = 客户端收到响应到发出下个请求的时间（JS 执行+网络延迟），通常 50~200ms。
更关键的是失败恢复逻辑：
- WebSocket 断连后，前端需自己实现心跳（
ws.ping）、重连退避（指数增长间隔）、连接状态同步（避免重复订阅） - 长轮询天然“自愈”：某次请求失败，下次
fetch()自动重试，无需额外状态管理 - 移动端切网（Wi-Fi → 4G）时，WebSocket 往往静默断连且不触发
onclose，而长轮询因请求超时会立刻感知并重试
选型别只看“实时性”，先看部署链路是否支持
WebSocket 理论性能碾压长轮询，但真实项目里，卡点往往不在代码，而在基础设施：
- Nginx 默认不转发
Upgrade请求，漏配proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";就连不上 - 某些企业防火墙/上网行为管理设备会主动 kill 长时间空闲连接，WebSocket 的 idle 连接比长轮询更容易被掐断
- 如果业务已跑在 Serverless（如 AWS Lambda），长轮询可直接用 HTTP 函数，而 WebSocket 需搭配 API Gateway 的 WebSocket 支持，配置复杂度陡增
真正需要 WebSocket 的场景，其实是“服务端必须主动推、且频率高、数据小”——比如协同编辑光标位置、实时语音转文字流、高频行情推送。其余多数通知类需求（未读数、订单状态变更），长轮询反而更稳、更省事。
