WebSocket是基于TCP的全双工通信协议，通过HTTP握手升级建立持久连接，实现客户端与服务器间双向、低延迟、低开销实时通信。
WebSocket 连接为什么必须走 HTTP 握手？
因为绝大多数企业防火墙、CDN、反向代理（如 Nginx）只认 HTTP 流量。直接裸连 TCP 端口会被拦截或重置。所以 WebSocket 设计了“升级机制”：客户端先发一个合法的 HTTP 请求，带特定头部，告诉服务器“我想换协议”，服务器确认后返回 101 Switching Protocols，之后同一 TCP 连接就切换成 WebSocket 帧协议——这个过程叫 handshake。
关键请求头必须包含：
Upgrade: websocketConnection: Upgrade-
Sec-WebSocket-Key（由客户端随机生成，服务端需用固定算法拼接响应） -
Sec-WebSocket-Version: 13（当前唯一广泛支持的版本）
漏掉任意一项，服务端大概率拒绝升级，浏览器控制台会报 Failed to connect to WebSocket server: Error during WebSocket handshake 或类似错误。
WebSocket.onmessage 收不到数据？先检查帧类型和编码
WebSocket 数据不是裸字符串，而是按帧（frame）结构传输的。服务端发过来的如果是二进制数据（比如 ArrayBuffer、Blob），但前端用 event.data.toString() 强转，会得到乱码或空字符串；反过来，如果服务端期望接收 UTF-8 文本帧，你却用 socket.send(new Uint8Array([...])) 发二进制帧，可能被静默丢弃或触发 close 事件。
判断方式很简单：
- 文本消息：
event.data类型是string - 二进制消息：
event.data类型是ArrayBuffer或Blob（取决于socket.binaryType设置） - 发送前显式指定：
socket.binaryType = 'arraybuffer'或'blob'
常见坑：socket.send(JSON.stringify(obj)) 没问题，但 socket.send(obj) 会直接报错——WebSocket 只接受 string、ArrayBuffer、Blob、ArrayBufferView 四种类型。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
连接突然断开却没触发 onclose？可能是心跳或代理超时
WebSocket 连接看似“持久”，实则非常脆弱。中间任何一层（Nginx、ALB、公司防火墙、甚至某些运营商网关）都可能在空闲几秒后主动断开 TCP 连接，且不发 FIN 包。此时浏览器不会立刻感知，onclose 也不会触发，直到你下一次 send 或收到服务端心跳失败才报 onerror + onclose。
解决方案只有两个：
- 服务端定期发
ping帧（或自定义{"type":"ping"}消息），客户端收到后回pong（或{"type":"pong"}） - 客户端自己定时
socket.send('')或发保活消息，并监听超时（例如 30 秒没收到响应就socket.close()）
Nginx 默认 proxy_read_timeout 是 60 秒，若你的业务允许空闲，务必在配置里调大，否则它会在 60 秒无数据时单方面断连。
ws:// 和 wss:// 的区别不只是加了个 S
ws:// 走明文 TCP，开发调试可以，但生产环境基本不可用：现代浏览器（Chrome/Firefox/Safari）在 HTTPS 页面中禁止新建 ws:// 连接，会直接抛 SecurityError；同时，所有中间设备都能看到传输内容。
wss:// 是 WebSocket over TLS，等价于 HTTPS 之于 HTTP。它要求服务端有有效 TLS 证书（不能是自签名），且必须监听在 443 端口（或显式指定端口如 wss://example.com:8443）。Nginx 反向代理 wss 时，需配置 proxy_pass https://backend 并透传 TLS，不能只 proxy 到 ws 后端再自己 terminate TLS——那样握手阶段就会失败。
容易忽略的一点：wss:// 的证书域名必须和 URL 中的 host 完全一致（包括子域），否则浏览器会拒绝连接，控制台显示 net::ERR_CERT_COMMON_NAME_INVALID 或类似错误。
new WebSocket(url)，而是理解它背后那条 TCP 连接在真实网络中如何被层层代理、超时、重置、加密。每一次 onclose 都该查三件事：服务端日志有没有 close 帧记录、Nginx access log 有没有 499/502、浏览器 Network 面板里 WebSocket 请求的 Response Headers 里有没有 101。 
