WebSocket 握手全流程详解：从 HTTP Upgrade 到 Sec‑WebSocket‑Accept 的逐步剖析

• 为什么要关注 WebSocket 握手的每一步
• 从 HTTP Upgrade 开始：握手的基本流程
• 关键请求头及其含义
• 服务器如何响应：Sec‑WebSocket‑Accept 的生成逻辑
• 中间件与代理常见问题
• 安全校验与防护要点
• 诊断步骤与实战排查思路
• 工具与实现差异（非代码示例）
• 未来演进与注意点

为什么要关注 WebSocket 握手的每一步

对于追求实时性和双向通信的应用，WebSocket 是现代浏览器与服务器之间的重要桥梁。表面上看，建立连接只是一条 HTTP 请求和一条响应，但细看每一个头部字段和校验步骤，你会发现协议在兼容性、安全性和中间件处理上的许多细节。作为网络调试或翻墙工具开发者，理解握手全流程能帮助你定位问题、评估安全风险并优化代理策略。

从 HTTP Upgrade 开始：握手的基本流程

WebSocket 握手实质上是一次特殊的 HTTP/1.1 请求升级。客户端发起一个含有 Upgrade: websocket 的 HTTP GET 请求，服务器在确认后返回 101 Switching Protocols，连接从 HTTP 升级为 WebSocket。这个“升级”过程既要满足协议语义，也要防止中间件误处理——很多代理或负载均衡器会因为非标准头部而丢弃或拦截请求。

关键请求头及其含义

客户端请求包含若干必需头部，每一项都承担特定职责：

• Upgrade: websocket：明确表明客户端希望切换到 WebSocket 协议。
• Connection: Upgrade：告诉中间节点这是一次连接级别的升级请求，而非普通的转义头部。
• Sec-WebSocket-Key：一个随机生成的 Base64 字符串，服务器用来生成响应的校验值，防止缓存或回放攻击。
• Sec-WebSocket-Version：常见为 13，表明客户端支持的协议版本。
• Host / Origin / Sec-WebSocket-Protocol（可选）：Host 指目标主机，Origin 可用于同源或跨域校验，Sec-WebSocket-Protocol 用于子协议协商。

服务器如何响应：Sec‑WebSocket‑Accept 的生成逻辑

服务器在确认升级后返回 101 状态码，并且必须在响应头中包含 Sec-WebSocket-Accept。这个值的生成规则看似简单但意义重大：服务器将客户端提供的 Sec-WebSocket-Key 与固定 GUID（“258EAFA5‑E914‑47DA‑95CA‑C5AB0DC85B11”）拼接，然后对结果进行 SHA-1 摘要，再将摘要结果做 Base64 编码。这个流程确保响应是针对该次握手请求即时生成的，防止重放并与 HTTP 缓存机制相区分。

中间件与代理常见问题

实际部署中，握手失败的原因很多，常见有：

• 反向代理未正确转发 Upgrade/Connection 头部，导致服务器无法识别为升级请求。
• HTTP/2 环境下直接用 HTTP/2 发送 WebSocket 握手会失败，因为标准 WebSocket 握手基于 HTTP/1.1 的 Upgrade 机制（虽然存在 WebSocket over HTTP/2 的扩展，但并非通用）。
• 缓存或安全设备错误地缓存了握手响应，或者对 Sec-WebSocket-Key 做了不当处理。
• TLS（wss://）配置问题导致握手在 TLS 层被截断或被 MITM 检测拦截。

安全校验与防护要点

几条实用但重要的原则：

• 校验 Origin：如果服务只面向特定前端，强制校验 Origin 可以防止恶意网页在第三方域名下发起连接。
• 使用 TLS：对敏感数据或跨公网的实时通道，应使用 wss://，防止窃听和中间人攻击。
• 子协议与扩展的安全考量：当使用 Sec-WebSocket-Protocol 或扩展（例如 permessage-deflate）时，服务器应显式同意并验证参数，避免被滥用。
• 客户端掩码：WebSocket 标准要求客户端发送的每一帧都必须进行掩码（masking），服务端不能依赖未掩码的帧，这在握手阶段虽不显式体现，但对于后续数据安全至关重要。

诊断步骤与实战排查思路

1. 捕获握手请求和响应（浏览器 DevTools / 抓包工具）。
2. 检查请求是否为 HTTP/1.1 且包含 Upgrade/Connection 头。
3. 验证 Sec-WebSocket-Key 是否存在；若存在，确认服务器响应中 Sec-WebSocket-Accept 与之匹配（通过 SHA-1+GUID+Base64 规则）。
4. 如果有中间代理，逐层排查是否有头部被删改或连接被降级到 HTTP/1.0。
5. 在 wss 场景下检查 TLS 握手是否成功，以及证书链是否完整。

工具与实现差异（非代码示例）

调试时可以使用浏览器开发者工具查看握手细节；命令行工具或专用 WebSocket 客户端（如 websocat、wscat）在抓取原始头部时更直观。不同服务器实现（例如 Nginx、Apache、Node.js 框架）对 Upgrade 的处理方式与默认超时、连接保持策略可能不同，调试时需要参考各自对 WebSocket 的文档。

未来演进与注意点

随着 HTTP/2/3 的普及，WebSocket 在新一代传输协议上的适配正在推进，但当前大规模部署仍基于 HTTP/1.1 的 Upgrade 机制。对开发者和运维来说，关注代理兼容性、TLS 配置和对握手头部的完整转发是确保稳定连接的关键。理解握手每一步的意图，能让你在面对连接失败或性能问题时更快定位并修复。