一篇读懂 WebSocket：全双工通信与服务端推送

HTTP 的请求-响应模式有一个天然限制：服务端无法主动向客户端推送消息——客户端不发请求，服务端的响应就无处投递。传统的 workaround 是长轮询（long polling）：客户端发一个请求，服务端「握住不回」直到有数据或超时——效率低、延迟高、服务端维护大量挂起连接。WebSocket 在 HTTP 的基础上升级为全双工通信：一次握手（Upgrade 请求），升级为持久连接，此后双向实时收发，没有 HTTP 的头部开销。本篇讲清 WebSocket 的机制与工程实践。

握手过程：从 HTTP 到 WebSocket 的「升级」

WebSocket 的握手是一个 HTTP Upgrade 请求：客户端发送一个特殊的 HTTP 请求，请求将连接「升级」为 WebSocket 协议：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务端如果支持 WebSocket，返回 HTTP 101（Switching Protocols），携带 Sec-WebSocket-Accept 头（客户端 Key 的 SHA-1 哈希——安全校验），此后这条 TCP 连接就变成了 WebSocket 通道：双方都可以随时发送消息，没有 HTTP 的头部开销，帧格式更轻量。WebSocket 的 URL 协议是 ws://（明文）与 wss://（加密——生产环境必须使用，类似 HTTPS）。一个重要的安全考虑：WebSocket 不受同源策略限制（握手是 HTTP 但后续是自定义协议），服务端必须验证 Origin 头防止跨站劫持。

对比：WebSocket vs SSE vs 长轮询

选择的决策框架：需要双向实时通信 → WebSocket（聊天室、协作编辑、多人游戏）；只需要服务端推送 → SSE（更简单——基于 HTTP、自动重连、EventSource API 原生支持，本库《SSE 流式输出实战》详述）；兼容性要求极高或只需偶尔更新 → 长轮询。

工程实践：心跳保活、断线重连与消息可靠性

心跳保活（heartbeat/ping-pong）：WebSocket 连接可能被中间代理或防火墙静默断开（空闲超时），客户端需要定期发送 ping 帧、服务端回复 pong 帧——通常 30 秒一次——连续多次未收到 pong 则判定连接断开，触发重连。断线重连（reconnection）：网络波动或服务端重启会导致连接断开，客户端需要自动重连——重连策略通常用指数退避（第一次 1 秒、第二次 2 秒、第三次 4 秒……上限如 30 秒——防止服务端恢复时被瞬间涌入的连接冲垮）。消息可靠性：WebSocket 的消息送达是「尽力而为」的——连接断开时未发送的消息会丢失。需要可靠投递的场景需要自行实现：消息 ID + 客户端 ACK + 服务端重发队列（类似 MQ 的可靠投递三方合同——本库有专篇）。水平扩展的挑战：多个 WebSocket 服务实例之间需要消息路由（用户 A 连在实例 1，用户 B 连在实例 2——A 发给 B 的消息需要跨实例路由）——解决方案是Redis Pub/Sub 或消息队列做跨实例广播——这是 WebSocket 集群化最大的工程挑战。

WebSocket 的消息格式与帧类型

WebSocket 的通信基于帧——协议定义了多种帧类型。文本帧（opcode 0x1）：传输 UTF-8 编码的文本消息——最常见的帧类型。二进制帧（opcode 0x2）：传输二进制数据。控制帧：Close（关闭连接）、Ping（心跳请求）、Pong（心跳响应）——Ping/Pong 用于保活检测。消息分片：大消息可以拆为多个帧传输（第一帧 FIN=0 表示未完，最后一帧 FIN=1 表示结束）——接收方将多个帧组装为完整消息。WebSocket 的消息没有内置的消息边界语义——协议层面只保证字节流的可靠传输，消息的边界由应用层自行定义。了解帧类型有助于调试——Wireshark 抓包时可以按帧类型过滤，定位连接问题。

WebSocket 的「水平扩展」：跨实例消息路由

WebSocket 的水平扩展是最大的工程挑战之一：用户 A 连接在实例 1，用户 B 连接在实例 2——A 发给 B 的消息需要跨实例路由。解决方案：Redis Pub/Sub 做跨实例广播——每个实例订阅一个频道（如 user_messages），A 发消息给 B 时，实例 1 将消息发布到 Redis 频道，实例 2 收到消息后查找 B 的连接并投递。更精确的方案：Redis 的哈希结构存储「用户 → 实例」的映射——发送消息时先查 B 在哪个实例，然后定向转发到该实例（通过实例间的内部通信或消息队列——比广播更精准，减少不必要的网络开销）。Sticky Session 的问题：负载均衡器的会话粘性（同一用户总是连到同一实例）可以减少跨实例路由的需求，但不能消除（实例重启或扩容时用户会重新分配）。WebSocket 集群的最佳实践：Redis Pub/Sub 做跨实例广播（简单场景）+ 一致性哈希做用户到实例的映射（大规模场景）+ Sticky Session 做会话粘性（减少跨实例路由的频率）——三者组合，覆盖从百人聊天室到百万用户实时系统的全部场景。

WebSocket 的水平扩展：跨实例消息路由

WebSocket 的水平扩展是最大的工程挑战之一：用户 A 连接在实例 1 用户 B 连接在实例 2——A 发给 B 的消息需要跨实例路由。解决方案：Redis Pub/Sub 做跨实例广播——每个实例订阅一个频道A 发消息给 B 时实例 1 将消息发布到 Redis 频道实例 2 收到后查找 B 的连接并投递。更精确的方案：Redis 的哈希结构存储用户到实例的映射——发送消息时先查 B 在哪个实例然后定向转发到该实例。WebSocket 集群的最佳实践：Redis Pub/Sub 做跨实例广播简单场景加一致性哈希做用户到实例的映射大规模场景加 Sticky Session 做会话粘性——三者组合覆盖从百人聊天室到百万用户实时系统的全部场景。

WebSocket 的心跳保活与断线重连

WebSocket 连接可能被中间代理或防火墙静默断开。心跳保活：客户端定期发送 ping 帧服务端回复 pong 帧——通常 30 秒一次——连续多次未收到 pong 则判定连接断开。断线重连：网络波动或服务端重启会导致连接断开客户端需要自动重连——重连策略通常用指数退避（第一次 1 秒第二次 2 秒上限如 30 秒——防止服务端恢复时被瞬间涌入的连接冲垮）。消息可靠性：WebSocket 的消息送达是尽力而为的——需要可靠投递的场景需要自行实现消息 ID 加客户端 ACK 加服务端重发队列。

WebSocket 的适用场景判断：什么时候用 WebSocket 什么时候不用

WebSocket 的选择可以用一棵决策树总结。需要双向实时通信则 WebSocket（聊天室、协作编辑、多人游戏）。只需要服务端推送则 SSE（更简单——基于 HTTP、自动重连、EventSource API 原生支持）。兼容性要求极高或只需偶尔更新则长轮询。不适用 WebSocket 的场景：偶尔更新状态（用轮询就够了——WebSocket 的连接维护成本高于轮询的收益）、非实时的数据同步（用消息队列或 Webhook——WebSocket 是过度设计）。WebSocket 的核心价值是「实时性」——如果你的场景对实时性没有要求（延迟几秒都可以接受），WebSocket 就是过度设计。

WebSocket 的 Socket.IO 选择

Socket.IO 是 WebSocket 之上最流行的封装库它解决了原生 WebSocket 的多个工程问题。自动重连：断线后自动重连指数退避策略重连后自动恢复之前的房间与订阅。房间：将连接分组按聊天室分组可以向特定房间广播消息。降级支持：如果 WebSocket 不可用自动降级为 HTTP 长轮询兼容性更好。命名空间：在同一端口上复用多个逻辑通道。代价是自定义协议意味着不是标准 WebSocket非 Socket.IO 客户端无法连接且引入了额外依赖。选择建议需要跨语言兼容用原生 WebSocket；前后端都用 JavaScript 且需要房间与自动重连 Socket.IO 是省时省力的选择。

WebSocket 的消息压缩与安全考虑

WebSocket 支持 permessage-deflate 扩展（压缩 WebSocket 帧——文本消息的压缩比通常很高，二进制消息的收益取决于内容）。压缩的安全考虑：CRIME 攻击类似 TLS 压缩的攻击方式——攻击者通过观察压缩后的长度推断加密前的内容——安全敏感场景应禁用压缩。WebSocket 的认证：握手阶段通过 HTTP Cookie 或查询参数传递 Token，握手后消息级别的认证需要自行设计。跨域考虑：WebSocket 不受 CORS 限制（握手是 HTTP GET 不做 preflight），服务端需要验证 Origin 头防止跨站 WebSocket 劫持（CSWSH）。

WebSocket 与 SSE 的选择决策

WebSocket 与 SSE 的选择取决于通信的方向性需求。需要双向实时通信选 WebSocket（聊天室协作编辑多人游戏——客户端与服务端都需要实时收发）。只需要服务端推送选 SSE（更简单——基于 HTTP 自动重连 EventSource API 原生支持——通知推送状态更新 LLM 流式输出）。SSE 的优势是更简单更轻量且自动重连是内置的；WebSocket 的优势是双向通信与更低的延迟。如果一个应用只需要服务端推送通知，SSE 是更好的选择——它更简单且不会有 WebSocket 的连接管理负担。

小结

WebSocket 收成四条：一次握手升级为全双工持久连接——没有 HTTP 头部开销，双向实时收发；与 SSE 的选择——双向实时用 WebSocket、只需服务端推送用 SSE（更简单，自动重连）；工程三件套——心跳保活（30 秒 ping/pong）、断线重连（指数退避）、消息可靠性（ID + ACK + 重发）；水平扩展的挑战——跨实例消息路由需要 Redis Pub/Sub 或消息队列。WebSocket 让实时互联网成为可能——从聊天到协作到游戏，一切「实时」的体验都建立在它之上。

参考资料

• RFC 6455: The WebSocket Protocol —— WebSocket 协议的权威规范
• 本库前篇：《SSE 流式输出实战》《一篇读懂消息不丢》
• Socket.IO 官方文档 —— WebSocket 之上封装了重连/房间/广播的库