Sec-WebSocket-Key验证是挑战-响应式校验：客户端发送16字节随机数Base64编码值，服务器解码后拼接固定magic string并SHA-1哈希再Base64编码生成Accept值，客户端反向校验一致才完成握手。
Sec-WebSocket-Key 的验证机制不是由服务器“检查密钥本身是否合法”，而是通过它触发一次确定性计算，用以证明服务器确实收到了客户端的原始握手请求，并具备协议理解能力。这个过程不涉及密钥存储或比对，本质是挑战-响应式校验。
Sec-WebSocket-Key 的生成要求
客户端必须生成一个16 字节随机数据，再经 Base64 编码后作为 Sec-WebSocket-Key 发送。常见错误包括：
- 使用非随机字符串（如固定值、时间戳、短字符串填充）
- Base64 解码后长度不等于 16 字节（说明原始随机字节数不对）
- 编码过程中引入空格、换行或非法字符
服务器如何验证：只算一次，但必须精准
服务器收到 Sec-WebSocket-Key 后，不做“合法性判断”，而是严格执行以下步骤：
- Base64 解码该字段，确认得到 16 字节二进制数据（否则拒绝）
- 将解码结果与固定 magic string
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"拼接 - 对拼接后的字符串做 SHA-1 哈希
- 将哈希结果进行 Base64 编码，作为
Sec-WebSocket-Accept返回
只要任意一步偏差（比如 magic string 写错一位、用了 SHA-256、漏掉拼接），客户端就会校验失败并断连。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
客户端的反向校验才是最终关卡
浏览器或 WebSocket 客户端在收到 101 响应后，会独立重算 Sec-WebSocket-Accept：
- 用自己当初发送的
Sec-WebSocket-Key - 套用相同公式：Base64(SHA1(key + magic))
- 比对响应头中的值是否完全一致（区分大小写、无空格）
不一致即报错 Error during WebSocket handshake，连接终止——这是唯一生效的“验证”。
为什么不用签名或密钥对？
这个机制设计初衷是轻量、无状态、防缓存污染：
- 无需服务器保存任何会话密钥或上下文
- 避免代理/CDN 缓存 101 响应后复用到其他请求（因每个 key 唯一）
- 不提供加密或身份认证，仅保证“本次升级请求被原样处理”
真正的鉴权需放在后续消息层（如首次 send 的 token 或子协议协商）。
