WebSocket 是一种在单个 TCP 连接上进行全双工（Full-Duplex）通信的协议。它打破了传统 HTTP 请求-响应模式的限制，使得服务器能够主动向客户端推送数据，是实现现代 Web 实时应用（如即时通讯、在线游戏、股票行情看板）的核心技术。
以下从背景、原理、协议细节、与 HTTP 对比、心跳机制及实践建议六个维度进行深度解析。
1. 为什么需要 WebSocket？（背景与痛点）
在 WebSocket 出现之前，Web 通信主要基于 HTTP 协议，其核心特征是"无状态"和"半双工"（客户端发起请求，服务器响应，连接关闭）。这种模式在处理实时数据时存在显著缺陷：
被动性：服务器无法主动推送消息。若需获取最新状态，客户端必须不断询问。
高延迟：每次交互都需要建立连接或等待轮询间隔。
资源浪费：HTTP 头部信息较大，若频繁发送小数据包（如聊天消息），有效载荷占比低，带宽利用率差。
为了解决这些问题，早期开发者采用了以下替代方案，但均有局限：
短轮询（Short Polling）：客户端每隔几秒发送一次 HTTP 请求。缺点是高频率请求导致服务器压力大，且大部分请求返回空数据。
长轮询（Long Polling/Comet）：客户端发送请求后，服务器挂起连接直到有数据才返回。缺点是服务器维持大量悬挂连接消耗资源，且实现复杂。
WebSocket 的出现彻底解决了上述问题，实现了真正的低延迟、双向实时通信。
2. WebSocket 核心原理
2.1 定义与标准
标准：RFC 6455（2011年标准化）。
传输层：基于 TCP 协议。
协议标识：ws://（非加密）或 wss://（基于 TLS/SSL 加密，生产环境推荐）。
通信模式：全双工。连接建立后，客户端和服务器可以随时互相发送数据，无需等待对方请求。
2.2 握手过程（Handshake）
WebSocket 连接始于一个标准的 HTTP 请求，通过"协议升级"机制转换为 WebSocket 连接。
客户端发起请求：
客户端发送一个包含特殊头部的 HTTP GET 请求：
http
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Upgrade: websocket：告知服务器希望切换协议。
Sec-WebSocket-Key：随机生成的 Base64 编码字符串，用于防止缓存和非 WebSocket 客户端误连。
服务器响应：
服务器验证请求后，返回状态码 101 Switching Protocols：
http
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Accept：由服务器将客户端的 Key 加上固定魔术字符串（258EAFA5-E914-47DA-95CA-C5AB0DC85B11），经过 SHA-1 哈希和 Base64 编码生成。客户端验证此值以确认服务器支持 WebSocket。
连接建立：
握手成功后，HTTP 连接升级为 WebSocket 连接，后续数据传输不再使用 HTTP 格式，而是使用 WebSocket 自定义的数据帧格式。
3. 数据帧结构（Frame Structure）
WebSocket 数据以"帧（Frame）"为单位传输。每个帧包含头部和数据负载。主要字段包括：
FIN (1 bit)：表示是否为消息的最后一帧。支持消息分片（Fragmentation）。
Opcode (4 bits)：操作码，定义数据类型：
0x0：延续帧（Continuation Frame）。
0x1：文本帧（Text Frame）。
0x2：二进制帧（Binary Frame）。
0x8：关闭连接帧（Connection Close）。
0x9：Ping 帧（心跳检测）。
0xA：Pong 帧（心跳响应）。
Mask (1 bit)：表示数据是否经过掩码处理。客户端发送给服务器的数据必须加掩码，服务器发送给客户端的数据不加掩码。这是为了防止代理缓存污染和安全攻击。
Payload Length：数据负载长度，支持 7 位、7+16 位或 7+64 位扩展，以适应不同大小的数据。
Masking Key：如果 Mask 位为 1，则包含 4 字节的掩码密钥，用于解码数据。
Payload Data：实际传输的数据。
4. WebSocket vs HTTP vs WebRTC
特性 HTTP/1.1 & 2.0 WebSocket WebRTC
通信方向 半双工（请求-响应） 全双工（双向实时） 全双工（P2P为主）
连接持久性 短连接（或 Keep-Alive） 长连接（持久化） 临时会话连接
数据开销 高（每次携带完整 Header） 低（仅少量帧头） 低（针对媒体优化）
适用场景 网页浏览、REST API 聊天、通知、协作编辑 音视频通话、屏幕共享
穿透能力 极强（所有防火墙允许） 强（通常通过 80/443 端口） 弱（需 STUN/TURN 服务器）
注意：WebSocket 适合可靠的消息传递；若需超低延迟的音视频流，应结合使用 WebRTC。
5. 关键机制：心跳与保活（Ping/Pong）
由于 WebSocket 建立在 TCP 之上，而 TCP 连接可能因网络中间设备（如路由器、防火墙、NAT）超时而被静默切断，因此需要应用层的心跳机制。
Ping/Pong 帧：
WebSocket 协议原生定义了 Ping (0x9) 和 Pong (0xA) 控制帧。
机制：一方发送 Ping 帧，另一方必须尽快回复 Pong 帧。
作用：检测连接是否存活，防止中间设备因空闲超时断开连接。
实现策略：
客户端心跳：客户端定时发送 Ping，若未收到 Pong 则判定断线并重连。
服务端心跳：服务端定时向所有活跃连接发送 Ping，清理失联客户端以释放资源。
双向心跳：最稳健的做法是双方都实施心跳检测。
注意：协议本身不提供自动发送心跳的功能，必须由开发者在应用代码中实现定时器逻辑来触发 Ping/Pong 的发送。
6. 开发实践与注意事项
6.1 前端使用示例
浏览器原生支持 WebSocket API：
javascript
// 创建连接
const socket = new WebSocket('wss://example.com/chat');
// 连接打开
socket.onopen = function(event) {
console.log("连接已建立");
socket.send("Hello Server!");
};
// 接收消息
socket.onmessage = function(event) {
console.log("收到消息:", event.data);
};
// 连接关闭
socket.onclose = function(event) {
console.log("连接关闭", event.code, event.reason);
};
// 错误处理
socket.onerror = function(error) {
console.error("WebSocket 错误", error);
};
6.2 后端选型
Node.js: ws, Socket.IO（Socket.IO 不是纯 WebSocket，它提供了 fallback 机制和房间概念，适合复杂场景）。
Java: Spring WebSocket, Tomcat JSR-356 实现。
Python: websockets, Django Channels.
Go: gorilla/websocket.