websocket是tcp层面真正全双工通信，握手需http升级以兼容基础设施；ws/wss端口与tls绑定，数据帧极轻量，高频小消息带宽节省超90%，但生命周期管理才是可靠关键。
WebSocket 的全双工通信不是“看起来像双向”，而是 TCP 层面上真正允许客户端和服务器同时发、同时收，互不阻塞。
这和 HTTP 的「请求→等待响应→再请求」有本质区别。你不需要等对方回消息才能发下一条，也不用靠轮询假装实时。
WebSocket 握手阶段为什么必须走 HTTP？
- 客户端发起的第一次连接是标准
GET请求，带Upgrade: websocket和Sec-WebSocket-Key等头 - 服务端返回
101 Switching Protocols，确认升级成功，之后同一 TCP 连接就切换协议语义 - 这样设计是为了兼容现有基础设施：代理、CDN、防火墙都认得 HTTP，不会拦截或复位这个连接
常见错误现象：
- 返回
400 Bad Request或直接断连 → 检查Origin头是否被代理篡改，或服务端未正确响应Sec-WebSocket-Accept - 浏览器控制台报
Failed to construct 'WebSocket': The URL's scheme must be either 'ws' or 'wss'→ 用了http://前缀而非ws://
ws:// 和 wss:// 的端口与 TLS 关系
-
ws://example.com默认走 TCP 80 端口，明文传输，不能用于生产环境 -
wss://example.com默认走 TCP 443 端口，底层是 TLS 加密的 WebSocket，浏览器强制要求证书有效 - 不要试图在
wss://上配自签名证书然后忽略校验 —— 现代浏览器会直接拒绝连接，连握手请求都不发出
注意点：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Nginx 反向代理
wss时，需显式配置proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade - 如果后端服务监听的是非 443 端口（比如 8080），
wss://仍必须由前端 HTTPS 终结，否则浏览器认为不安全
数据帧比 HTTP Header 轻多少？
一次典型 WebSocket 数据帧（非分片、非压缩）只有：
- 2 字节基础帧头（含 FIN、opcode、MASK 标志）
- 可选 4 字节掩码键（客户端→服务端必带）
- 实际 payload（比如发送
"ping"，总长度仅 10 字节左右）
对比 HTTP POST 同样内容：
- 至少 200+ 字节的 headers（
Host、Connection、Content-Length、User-Agent等） - 即使启用 HTTP/2 头部压缩，仍远高于 WebSocket 帧开销
这意味着：
- 高频小消息场景（如心跳、坐标更新、按键事件）下，
WebSocket带宽节省可达 90% 以上 - 但若误把大文件切分成大量小帧发送，反而因频繁系统调用降低吞吐 —— 这时候该用
BLOB分片或换 HTTP/2 流式上传
真正的难点不在建立连接，而在于连接生命周期管理：超时判断、重连退避、消息积压缓冲、连接复用边界。这些细节不写进业务逻辑，WebSocket 很快就会变成不可靠通道。
