WebSocket 提供了一种在单个 TCP 连接上进行全双工、双向实时通信的协议。它是为现代 Web 应用实现高效、低延迟交互而设计的，完美替代了传统的 HTTP 轮询或长轮询技术。
核心概念详解
目的与诞生背景：
- 解决 HTTP 的短板： HTTP 是无状态、单向的（请求-响应）。服务器无法主动向客户端推送数据。实现“实时”效果（如聊天、游戏、股票行情）需要客户端不断轮询（频繁请求），效率低下、延迟高、浪费资源。
- 需求驱动： 随着 Web 应用复杂化（在线游戏、协作编辑、实时通知、金融交易等），对低延迟、高吞吐量、服务器主动推送的需求激增。
- 标准化： WebSocket 协议 (RFC 6455) 在 2011 年最终定稿，提供了一个标准化的解决方案。
关键特性：
- 全双工通信： 客户端和服务器可以同时、独立地向对方发送数据。
- 基于 TCP： 建立在可靠的 TCP 传输层之上（默认端口 80 - ws, 443 - wss）。
- 持久连接： 建立连接后（通过一次 HTTP 握手），连接会保持打开状态，直到显式关闭。避免了 HTTP 的重复连接开销。
- 低延迟： 数据帧直接在已建立的连接上传输，无需 HTTP 请求头等冗余信息，显著降低延迟。
- 轻量级： 数据传输帧头部开销极小（最低 2 字节 + 扩展头 + 应用数据）。
- 支持文本和二进制数据： 原生支持 UTF-8 文本和任意二进制数据（如 Protobuf, ArrayBuffer, Blob）。
- 支持扩展和子协议：
- 扩展： 如
permessage-deflate提供数据压缩。 - 子协议： 允许应用层协商使用特定的协议（如
soap,wamp,mqtt,sip或自定义协议如myapp-v1.0），规范数据格式和交互逻辑。
- 扩展： 如
连接建立 - 握手 (Opening Handshake)
这是 WebSocket 连接开始的关键步骤，利用 HTTP/1.1 Upgrade 机制：客户端请求 (HTTP GET)：
1
2
3
4
5
6
7
8
9GET /chat
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== (随机生成的 16 字节 Base64 编码值)
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat, superchat (可选，客户端支持的子协议列表)
Sec-WebSocket-Extensions: permessage-deflate (可选，客户端支持的扩展)
(其他可能的 HTTP 头，如 Origin, Cookie 等)Upgrade: websocket和Connection: Upgrade：表明客户端希望升级协议到 WebSocket。Sec-WebSocket-Key：客户端生成的随机密钥，用于服务器构造响应中的Sec-WebSocket-Accept。Sec-WebSocket-Version：指定协议版本 (通常是 13)。Sec-WebSocket-Protocol：客户端希望使用的子协议列表。Sec-WebSocket-Extensions：客户端希望使用的扩展列表。
服务器响应 (HTTP 101 Switching Protocols)：
1
2
3
4
5
6101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= (基于客户端 Key 计算得出的值)
Sec-WebSocket-Protocol: chat (可选，服务器从客户端列表中选择的一个子协议)
Sec-WebSocket-Extensions: permessage-deflate (可选，服务器同意使用的扩展)101 Switching Protocols：状态码表示协议切换成功。Upgrade: websocket和Connection: Upgrade：确认升级到 WebSocket。Sec-WebSocket-Accept：服务器将客户端的Sec-WebSocket-Key与固定的 GUID258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接后，进行 SHA-1 哈希，再将哈希值进行 Base64 编码得到。客户端会验证此值以确保握手有效且对方理解 WebSocket 协议。Sec-WebSocket-Protocol：服务器选择的一个子协议（如果客户端请求了）。Sec-WebSocket-Extensions：服务器最终确定使用的扩展（如果协商成功）。
成功与失败：
- 如果服务器返回 101，握手成功，TCP 连接被“升级”为 WebSocket 连接，后续通信使用 WebSocket 数据帧格式。
- 如果服务器返回任何非 101 的 HTTP 状态码（如 200, 404, 500），则表示握手失败，连接仍是普通的 HTTP 连接。
数据传输 - 数据帧 (Data Framing)
握手成功后，所有通信都使用WebSocket 数据帧格式在同一个 TCP 连接上进行。帧结构精简高效：0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+- FIN (1 bit)： 指示这是消息的最后一个分片。消息可以由多个帧组成。
- RSV1, RSV2, RSV3 (各 1 bit)： 保留位，用于协议扩展。除非协商了扩展，否则必须为 0。
- Opcode (4 bits)： 定义帧的类型：
%x0(0): 连续帧 (Continuation frame - 表示这是一个分片消息的一部分)%x1(1): 文本帧 (Text frame - UTF-8 编码数据)%x2(2): 二进制帧 (Binary frame - 任意二进制数据)%x8(8): 连接关闭帧 (Connection Close)%x9(9): Ping 帧 (用于心跳检测/保活)%xA(10): Pong 帧 (对 Ping 的响应)%xF(15): 保留操作码
- Mask (1 bit)： 指示
Payload Data是否被掩码 (masked)。客户端发送给服务器的帧必须置为 1（掩码），服务器发送给客户端的帧必须置为 0（不掩码）。掩码是为了防止代理缓存污染攻击。 - Payload Len (7 bits, 7+16 bits, 7+64 bits)：
- 0-125：表示有效载荷长度。
- 126：表示接下来的 2 个字节（16 位无符号整数）是实际长度。
- 127：表示接下来的 8 个字节（64 位无符号整数）是实际长度。
- Masking-Key (0 or 4 bytes)： 如果 Mask 位为 1，则包含一个 32 位的掩码密钥。用于对
Payload Data进行异或 (XOR) 解码/编码。 - Payload Data (长度由 Payload Len 决定)： 实际的应用数据。如果 Mask 为 1，则数据是经过掩码处理的，接收方需要用
Masking-Key进行 XOR 解码才能得到原始数据。
连接生命周期管理
- 打开： 握手成功 (101) 后连接打开。
- 数据传输： 双方通过发送数据帧（文本、二进制）进行通信。可以使用 Ping/Pong 帧进行心跳检测和保活。
- 关闭：
- 任何一方都可以发起关闭握手。
- 发送一个 Close 帧 (
opcode=0x8)。Close 帧可以包含一个状态码（2 字节）和一个可选的关闭原因（UTF-8 字符串）。 - 接收到 Close 帧的一方，必须响应一个 Close 帧（如果还没发送过）。
- 发送了 Close 帧并接收到对方的 Close 帧响应后，或者底层 TCP 连接断开后，连接正式关闭。TCP 连接应由发起关闭方首先关闭。
- 错误处理： 如果发生协议错误（如接收到格式错误的帧、违反安全规则等），接收方可以发送 Close 帧（带适当状态码）并关闭连接。也可能直接关闭底层 TCP 连接（不优雅关闭）。
WebSocket API (浏览器端)
现代浏览器提供了WebSocket对象供 JavaScript 使用：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28// 创建连接 (URL 使用 ws:// 或 wss://)
const socket = new WebSocket('wss://example.com/chat');
// 监听连接打开事件
socket.addEventListener('open', (event) => {
console.log('WebSocket 连接已打开');
socket.send('Hello Server!'); // 发送文本消息
// socket.send(new Blob(['binary data'])); // 发送二进制数据
});
// 监听服务器发送的消息
socket.addEventListener('message', (event) => {
console.log('收到消息: ', event.data); // data 可能是字符串(文本帧) 或 Blob/ArrayBuffer(二进制帧)
// 处理数据...
});
// 监听连接关闭事件
socket.addEventListener('close', (event) => {
console.log('连接关闭: ', event.code, event.reason);
});
// 监听错误事件
socket.addEventListener('error', (error) => {
console.error('WebSocket 错误: ', error);
});
// 主动关闭连接 (可选状态码和原因)
// socket.close(1000, 'Normal closure');服务器端实现
几乎所有主流后端语言和框架都有成熟的 WebSocket 库/模块：- Node.js:
ws,socket.io(提供了更多功能如房间、广播、自动重连),uWebSockets.js(高性能) - Java:
Java API for WebSocket (JSR 356),Spring WebSocket,Netty - Python:
websockets(asyncio),Django Channels,Flask-SocketIO - Go:
gorilla/websocket,nhooyr.io/websocket - .NET:
System.Net.WebSockets,SignalR(类似 socket.io) - C++:
libwebsockets,Boost.Beast
- Node.js:
优点
- 真正的双向实时通信： 服务器可以随时推送数据。
- 低延迟： 避免了 HTTP 请求的开销和往返延迟。
- 高效： 小数据帧头，持久连接复用。
- 减少带宽和服务器负载： 相比频繁的 HTTP 轮询。
- 标准化： 广泛支持，跨平台/语言。
缺点/注意事项
- 协议复杂性： 比简单的 HTTP GET/POST 更复杂。
- 状态管理： 需要管理连接状态（开/关/错误）。
- 代理和防火墙问题： 一些旧的代理或防火墙可能不理解或错误处理 WebSocket 流量（使用 wss 通常能更好穿透）。
- 无状态： WebSocket 连接本身没有内置应用层状态概念（需要自行管理会话）。
- 安全：
- 必须使用
wss://(WebSocket Secure)： 类似于 HTTPS，提供传输层加密和认证，防止中间人攻击和数据窃听。强烈不建议在生产环境使用ws://。 - 验证
Origin头： 服务器应检查握手请求中的Origin头，防止跨站点 WebSocket 劫持 (CSWSH)。 - 输入验证： 像处理任何用户输入一样严格验证通过 WebSocket 接收的数据。
- 限制连接和资源： 防止 DoS 攻击。
- 必须使用
- 扩展性： 大规模部署时需要设计连接管理和状态共享机制（通常结合消息队列/发布订阅系统）。
典型应用场景
- 实时聊天应用
- 在线多人游戏
- 协同编辑工具
- 实时数据仪表盘（股票行情、监控系统、IoT 数据流）
- 体育赛事实时比分更新
- 在线拍卖/竞标
- 地理位置实时追踪
- 任何需要服务器主动、即时向客户端推送数据的场景。
相关库/框架
- Socket.IO: 非常流行，提供自动重连、房间、广播、命名空间、二进制支持等高级功能，并具有多种后端实现。它首先尝试 WebSocket，如果不可用则优雅降级到轮询。
- SockJS: 提供类似 WebSocket 的 API，并在底层自动选择最佳传输方式（WebSocket, XHR-Streaming, XHR-Polling 等）。
- SignalR (.NET): ASP.NET 的实时库，功能类似 Socket.IO。
- MQTT over WebSocket: 在浏览器中使用轻量级物联网协议 MQTT。
总结
WebSocket 是现代 Web 开发中实现高效、低延迟、双向实时通信的基石协议。它通过一次 HTTP 握手建立持久连接，之后使用轻量级数据帧直接在 TCP 连接上进行全双工通信，彻底解决了传统 HTTP 轮询在实时性、效率和资源消耗上的瓶颈。理解其握手过程、数据帧结构、API 使用以及相关的安全注意事项和扩展库，对于构建交互性强、体验流畅的实时 Web 应用至关重要。选择 wss:// 并实施良好的安全实践是生产环境部署的必要条件。