WebSocket连接通过HTTP升级握手建立：客户端发含Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key（16字节Base64）、Sec-WebSocket-Version: 13等头的GET请求；服务端校验后返回101状态码及Sec-WebSocket-Accept响应头，任一缺失或错误均导致握手失败。
WebSocket 连接不是直接建立的，而是通过一次 HTTP 协议升级完成的。这个握手过程本质上是客户端向服务器发起一个特殊的 HTTP GET 请求，请求将当前连接从 HTTP 切换为 WebSocket 协议；服务器验证通过后，返回 101 状态码，双方才正式进入 WebSocket 数据帧通信阶段。
客户端必须发送的关键请求头
浏览器或 ws/websockets 库在发起连接时，会自动构造符合规范的 HTTP 请求，但你得清楚它实际发了什么——漏掉任一必需字段，服务器通常直接返回 400 或静默断连：
- Upgrade: websocket —— 声明要升级的目标协议，大小写敏感，不能写成 WebSocket 或 websocket（小写）
- Connection: Upgrade —— 必须与 Upgrade 头配对出现，写成 keep-alive 或 close 都无效
- Sec-WebSocket-Key —— 16 字节随机数据经 Base64 编码生成，例如 dGhlIHNhbXBsZSBub25jZQ==；服务端靠它计算响应值，不能复用、不能硬编码
- Sec-WebSocket-Version: 13 —— 当前唯一广泛支持的版本，填 12、14 或空都会被拒绝
- Origin（可选但强烈建议） —— 浏览器自动携带，用于服务端做跨域白名单校验；Node.js 客户端需手动设置
服务器响应 101 的校验逻辑
服务端不会直接返回 101，而是先逐项验证请求合法性：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 检查 Upgrade 和 Connection 头是否严格匹配且格式正确
- 解析 Sec-WebSocket-Key 是否为合法 Base64，解码后是否恰好 16 字节原始数据
- 计算 Sec-WebSocket-Accept：把 Key 拼上固定字符串 258EAFA5-E914-47DA-95CA-C5AB0DC85B11，再做 SHA-1 哈希，最后 Base64 编码
- 若客户端声明了 Sec-WebSocket-Protocol，服务端需确认双方有至少一个共同支持的子协议
任意一步失败，就可能抛出 InvalidHandshake 异常，或直接关闭连接——此时客户端只收到 onclose 事件，无具体错误提示。
Nginx/CDN 环境下常见握手失败原因
本地能连通、上线就报 400 或连接挂起，大概率是反向代理或网络中间件未透传关键头部：
- Nginx 默认不转发 Upgrade 和 Connection 头，必须显式配置：
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
并确保 proxy_http_version 1.1 已启用 - Cloudflare、阿里云 CDN 等默认拦截含 Upgrade 头的请求，需在控制台开启「WebSocket 支持」开关
- 部分企业防火墙或运营商网关会主动丢弃带 Upgrade: websocket 的请求，需协调运维策略放行
握手成功后的协议切换本质
一旦收到 101 Switching Protocols 响应，TCP 连接本身没有重建，只是通信语义和数据格式彻底切换：
- HTTP 请求/响应周期结束，不再有状态码、首部、body 等概念
- 后续所有数据都按 WebSocket 帧格式封装：含 FIN、opcode、mask、payload length 等字段
- 连接保持长活，支持双向实时收发，底层仍是同一个 TCP 流
