WebSocket握手必须通过HTTP Upgrade流程，因浏览器禁止裸TCP连接；客户端发Upgrade请求头、服务端回101状态码，缺一不可，否则握手失败。
WebSocket 握手不是独立协议，而是 HTTP 的一次 Upgrade 请求处理过程；客户端发对头、服务端回 101 Switching Protocols，缺一不可。
为什么 WebSocket 必须走 HTTP Upgrade 流程
因为浏览器不允许直接建裸 TCP 连接，所有 Web 通信必须始于 HTTP。WebSocket 复用已有 TCP 连接，在 HTTP 层“申请换协议”，而不是新建连接。这保证了兼容性（能过防火墙、代理、CDN），也避免了跨域等额外限制。
- 不走 Upgrade → 浏览器直接报
Failed to construct 'WebSocket': The URL's scheme must be either 'ws' or 'wss' - 服务端没返回
101→ 控制台显示Error during WebSocket handshake: Unexpected response code: 200或400 - 中间有 Nginx / CDN 拦截 Upgrade 头 → 表现为连接秒断、握手失败，但错误码可能是
502或静默失败
Upgrade 和 Connection 头为什么必须同时存在
这两个是 RFC 6455 明确要求的逐跳（hop-by-hop）头，语义不可拆分：Upgrade: websocket 是“我要换什么协议”，Connection: Upgrade 是“请别关这个连接，我要接着用”。HTTP/1.1 规范规定：任何逐跳头都必须被中间设备显式透传，否则会被丢弃。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 只设
Upgrade不设Connection→ Nginx 默认把Connection改成close，连接立即断开 - 硬编码
Connection: upgrade（小写）→ 某些旧版网关会忽略，推荐用map动态映射：map $http_upgrade $connection_upgrade { default upgrade; '' close; }再配proxy_set_header Connection $connection_upgrade -
Sec-WebSocket-Key必须是 Base64 编码的 16 字节随机值，服务端要用它计算Sec-WebSocket-Accept；若客户端伪造或复用该值，服务端校验失败会拒绝升级
Sec-WebSocket-Version 和 Sec-WebSocket-Accept 的作用
Sec-WebSocket-Version: 13 是强制字段，表示使用 RFC 6455 标准；服务端不支持该版本就应返回 426 Upgrade Required。Sec-WebSocket-Accept 不是签名也不是加密，而是对客户端 Sec-WebSocket-Key 拼接固定字符串 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 后做 SHA-1 + Base64 得到的校验值——纯粹防误配，不防攻击。
- 服务端算错
Sec-WebSocket-Accept→ 浏览器直接关闭连接，控制台报Unexpected response header "Sec-WebSocket-Accept" - 漏掉
Sec-WebSocket-Version或填错（如写成12）→ 大部分现代浏览器拒绝发起握手 - 子协议
Sec-WebSocket-Protocol是可选协商字段，前后端不一致不会导致握手失败，但后续消息可能被服务端静默丢弃
真正容易被忽略的是：整个握手过程必须在单次 TCP 连接内完成，且不能有任何缓冲、重写、超时干预。哪怕 Nginx 把 proxy_buffering 开着，或者 proxy_read_timeout 没调大，都可能导致帧粘连或连接被提前终止——这时候你看到的往往不是明确错误，而是连接建立后立刻断开，查日志却一切正常。
