文章目录
- 一、先理清基础:HTTP 为什么不支持全双工?
- 二、WebSocket 升级的核心流程:从 HTTP 到全双工的'切换'
- 三、WebSocket 实现全双工的核心设计
- 四、关键对比:HTTP vs WebSocket(全双工维度)
- 五、总结
要理解 WebSocket 通过 HTTP 升级后实现 全双工通信 的核心逻辑,需先明确 HTTP 的通信特性,再拆解 WebSocket 升级的本质、协议设计的关键改动,以及底层传输层的支撑作用。
一、先理清基础:HTTP 为什么不支持全双工?
HTTP(1.1/2)的核心限制决定了它无法原生全双工:
- 请求 - 响应模型:通信由客户端发起请求,服务端被动响应,响应完成后连接通常关闭(或复用但仍以'请求 - 响应'为单位);
- 单向性:同一连接上,同一时刻只能由一端(客户端→服务端)发送数据,服务端无法主动向客户端推送;
- 头部冗余:每次请求需携带大量 HTTP 头部,且无'帧化'设计,无法高效复用连接传输双向数据。
而全双工的定义是:通信双方在同一连接上,可同时向对方发送数据(如同电话,双方可同时说话)。WebSocket 的升级本质是'借 HTTP 的握手流程,切换到全新的全双工协议'。
二、WebSocket 升级的核心流程:从 HTTP 到全双工的'切换'
WebSocket 并非修改 HTTP,而是以 HTTP 1.1 的 Upgrade 机制为'敲门砖',完成协议切换后,彻底脱离 HTTP 的请求 - 响应模型:
1. 第一步:HTTP 握手(协议升级请求)
客户端向服务端发送 HTTP 请求,核心头信息如下:
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Upgrade: websocket:核心,请求升级为 WebSocket 协议Connection: Upgrade:标识这是升级连接的请求Sec-WebSocket-Key:随机生成的 Base64 码(防伪造)Sec-WebSocket-Version:固定版本(主流为 13)
2. 第二步:服务端确认升级
服务端验证密钥(用 Sec-WebSocket-Key + 固定魔法字符串 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 做 SHA-1 哈希并 Base64 编码),返回 HTTP 101 响应:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=



