计算机网络：WebSocket 如何实现全双工通信

3. 第三步：协议切换完成，TCP 连接'复用'为 WebSocket 连接

之后，浏览器也用同样的公开算法将 Base64 码（Sec-WebSocket-Key）转成另一段字符串，如果这段字符串跟服务器传回来的字符串一致，则验证通过。

此时，底层的 TCP 连接并未断开，但上层协议从 HTTP 完全切换为 WebSocket 协议——这是实现全双工的关键：TCP 本身是全双工的，HTTP 因上层规则限制了双向通信，而 WebSocket 移除了这些限制。

三、WebSocket 实现全双工的核心设计

升级完成后，WebSocket 协议通过以下设计，充分利用 TCP 的全双工特性：

1. 底层依赖：TCP 的全双工特性（基础）

TCP 连接本身就是全双工字节流：

• 每个 TCP 连接有两个独立的字节流通道（客户端→服务端、服务端→客户端）；
• 两端可同时向对方写入数据，操作系统的 TCP 栈会处理数据的有序传输、重传、流量控制等。

HTTP 的问题是上层协议规则（请求 - 响应）浪费了 TCP 的全双工能力，而 WebSocket 完全适配 TCP 的特性，不再限制数据传输的方向和时机。

2. 帧化设计：打破'请求 - 响应'的边界

WebSocket 将数据拆分为帧（Frame），而非 HTTP 的'请求 - 响应'报文，帧是最小传输单元，核心特点：

• 双向帧传输：客户端和服务端可随时发送帧（文本帧、二进制帧、控制帧等），无需等待对方的'请求'；
• 帧类型区分：
  • 数据帧（TEXT/BINARY）：传输业务数据；
  • 控制帧（PING/PONG/CLOSE）：管理连接，无需响应；
• 无头部冗余：帧头仅 2~10 字节（包含操作码、长度、掩码等），远小于 HTTP 头部，且掩码仅客户端需添加（服务端无需），提升传输效率。

示例：客户端和服务端可同时发送帧，TCP 栈会分别在两个方向传输：

客户端 → [TEXT 帧："你好"] → TCP 通道 1 → 服务端
服务端 → [TEXT 帧："世界"] → TCP 通道 2 → 客户端

3. 无'请求 - 响应'绑定：主动推送能力

WebSocket 移除了 HTTP 的'请求必须先于响应'的规则：

• 服务端无需等待客户端请求，可主动向客户端发送帧（如实时消息、状态更新）；
• 客户端也可连续发送帧，无需等待服务端确认；
• 两端的帧传输相互独立，仅受 TCP 流量控制（如滑动窗口）约束。

4. 持久连接：避免重复握手

WebSocket 连接默认是持久的（除非主动关闭或超时），无需像 HTTP 1.1 那样通过 Keep-Alive 维持，且连接期间可双向传输任意数量的帧，避免了重复建立 TCP 连接的开销，进一步保障全双工通信的连续性。

四、关键对比：HTTP vs WebSocket（全双工维度）

五、总结

WebSocket 通过 HTTP 升级实现全双工的核心逻辑是：

1. 借 HTTP 完成握手：利用 HTTP 1.1 的 Upgrade 机制，完成协议切换的身份验证，复用已建立的 TCP 连接；
2. 脱离 HTTP 规则：切换后抛弃 HTTP 的请求 - 响应模型，改用帧化传输；
3. 适配 TCP 全双工：充分利用 TCP 的双向字节流特性，允许双端同时、主动发送帧，无方向和时机限制；
4. 轻量级设计：帧化传输降低开销，持久连接保障连续性，最终实现真正的全双工通信。

简单来说：TCP 是全双工的'硬件基础'，HTTP 因上层规则'禁用'了全双工，WebSocket 则'解锁'了 TCP 的全双工能力。