WebSocket 协议与 HTTP 协议的依赖关系可精准概括为：WebSocket 在连接建立阶段单向依赖 HTTP/HTTPS 协议完成握手升级，但连接建立后的通信完全脱离 HTTP，使用独立的二进制帧协议。二者并非父子协议或全程绑定关系。

🔑 核心依赖细节

1. 握手阶段（唯一依赖点）

   • 客户端发起标准 HTTP/1.1 GET 请求（含关键头）：

     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Key: [随机值]
     Sec-WebSocket-Version: 13
     

   • 服务器验证后返回 HTTP/101 Switching Protocols 响应，完成协议切换。
   • 此过程必须通过 HTTP/HTTPS 语义实现，是 WebSocket 唯一依赖 HTTP 的环节。

2. 连接建立后（完全独立）

   • TCP 连接被复用，但通信协议切换为 WebSocket 专属帧格式（含文本/二进制数据帧、Ping/Pong 心跳、关闭帧等）。
   • 不再解析 HTTP 头、无请求-响应模型、无状态管理，与 HTTP 协议栈彻底解耦。

🌐 设计意图与优势

• 基础设施兼容：复用 HTTP 默认端口（80/443），轻松穿越防火墙、代理、负载均衡器（这些设备通常放行 HTTP 流量）。
• 平滑演进：利用现有 HTTP 服务器生态（如 Nginx 反向代理 WebSocket 握手），降低部署成本。
• 安全延续：wss:// 基于 HTTPS（TLS 加密），握手在加密通道内完成，继承 TLS 安全性。

⚠️ 常见误区澄清

⚠️ 为什么不能绕过 HTTP 握手？

1. 安全机制

   • Sec-WebSocket-Key/Origin 头防止跨协议攻击（如缓存投毒、代理混淆）。
   • 早期草案（hixie-76）因安全缺陷被废弃，HTTP 握手是安全加固结果。

2. 基础设施兼容

   • 复用 80/443 端口，穿越防火墙/代理/CDN（这些设备识别 HTTP 语义）。
   • 若自定义握手，会被中间设备（如 Squid 代理）丢弃或篡改。

3. 标准化要求

   • IETF 将 WebSocket 定义为 HTTP 的协议升级机制（RFC 6455 §1.9），非独立传输层协议。

💡 附加说明

• URI 对应：ws:// ≈ HTTP（明文），wss:// ≈ HTTPS（加密）。
• 代理挑战：部分老旧代理可能丢弃 Upgrade 头，导致握手失败（需配置代理支持）。
• 协议定位：HTTP 适用于无状态请求-响应场景；WebSocket 专为全双工、低延迟、长连接场景设计（如实时聊天、游戏、金融行情）。

总结：WebSocket 巧妙“借用” HTTP 完成初始握手以提升部署可行性，但其核心价值恰恰在于摆脱 HTTP 的语义束缚，实现高效双向通信。这种“握手依赖、通信独立”的设计是协议工程中兼容性与创新性的经典平衡。