WebSocket是基于TCP的全双工长连接协议，固有属性即为持久连接，不存在“短连接”形态；其通过HTTP Upgrade握手后脱离HTTP协议栈，实现无请求头、服务端主动推送的实时双向通信。
WebSocket 本身不是“长连接或短连接”的二选一，它是一种独立于 HTTP 连接生命周期的、基于 TCP 的全双工长连接协议。所谓“WebSocket 长连接”，是它的固有属性；不存在“WebSocket 短连接”这种东西。
WebSocket 和 HTTP 长连接根本不是同一层概念
HTTP 长连接（Connection: keep-alive）只是复用底层 TCP 连接来发多个 HTTP 请求，每次请求仍要带完整 headers、走请求-响应流程，服务端依然不能主动推数据。而 WebSocket 在完成一次 HTTP 升级（Upgrade: websocket）后，就脱离 HTTP 协议栈，进入纯 TCP 数据帧通信阶段——没有请求头、无状态、双向随时收发。
常见误解是把“HTTP Keep-Alive”当成和 WebSocket 同级的“长连接方案”，其实它们解决的问题完全不同：
- HTTP 长连接：优化的是「多次请求间的 TCP 握手开销」
- WebSocket：解决的是「服务端无法主动推送 + 轮询延迟高 + 协议冗余大」
为什么你不能用 HTTP 长连接替代 WebSocket 做 IM 或实时通知
即使开启了 keep-alive，HTTP 仍是单向通信模型。客户端不发请求，服务端就完全无法触达它。想实现“新消息来了立刻弹窗”，只能靠轮询（短轮询/长轮询），而这会带来三个硬伤：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 短轮询：
setInterval(() => fetch('/msg'), 2000)—— 每 2 秒建一次连接，99% 请求返回空数据，浪费带宽和服务器并发连接数 - 长轮询：
fetch('/msg?wait=30')—— 服务端 hold 住响应直到有数据或超时，看似省了请求频次，但每个连接长期占用线程/协程，Nginx 默认proxy_read_timeout是 60s，超时后前端还得重连 - 两者都绕不开 HTTP 头部开销（至少几百字节），而 WebSocket 文本帧头部仅 2–14 字节，二进制帧更小
WebSocket 真正的坑不在连接建立，而在连接维持
很多人测通了 new WebSocket('wss://...') 就以为万事大吉，结果上线后大量掉线、重连失败、消息乱序。关键点在于：
- 浏览器对单域名 WebSocket 并发数有限制（通常 6～10 个），不要在页面里反复
new WebSocket不.close() - 网络切换（Wi-Fi ⇄ 4G）、休眠唤醒、NAT 超时都会静默断连，必须自己实现心跳（
ping/pong帧或应用层{type: 'heartbeat'}）+ 重连退避（指数增长延迟，如 1s → 2s → 4s → 最大 30s） - 服务端若用 Node.js 的
ws库，记得监听upgrade事件做鉴权，别等connection触发才检查 token，否则攻击者可耗尽连接数 - CDN 或反向代理（如 Nginx）默认不转发 WebSocket，需显式配置：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"
真正难的从来不是“怎么连上”，而是“怎么让这条连接在各种弱网、代理、防火墙、负载均衡器之间活够 24 小时”。很多项目卡在这里，最后退回到长轮询，并非技术不行，而是没算清运维成本和客户端兼容水位。
