WebSocket

是什么，为什么存在

WebSocket 是建立在可靠字节流之上的双向消息协议。连接建立后，客户端和服务端都能主动发送消息，不必为每次更新创建新的 HTTP 请求。浏览器中的 WebSocket API 把连接表现为 open、message、error 和 close 事件，以及 send() 与 close() 两个主要操作。

它解决的是频繁双向更新与 HTTP 请求—响应模型之间的不匹配。聊天、协作编辑、多人游戏状态和实时监控通常既有服务器推送，也有客户端命令。轮询可以实现这些功能，但空响应、轮询间隔和重复请求头都会成为协议负担；WebSocket 把这段通信放在一条持续连接上。

WebSocket 并不自动提供房间、事件名称、请求标识、重试、持久化或「恰好一次」交付。它保留消息边界，却不理解消息的业务含义。应用仍需定义消息结构、授权规则和恢复协议。

如果数据只从服务器流向浏览器，而且普通 HTTP 语义更合适，Server-Sent Events 可能更简单。如果交互稀疏、缓存很重要，普通 HTTP 往往更容易运维。WebSocket 适合双方都需要低等待时间地持续发消息，并且团队愿意管理长连接状态的场景。

传输方式不是按「实时」标签选择的。先写清消息方向、更新频率、中间代理、离线恢复和容量上限，再决定 WebSocket 是否合适。

工作原理

一个 WebSocket 会经历连接、开放、关闭中和关闭几个状态。网络连接成功只表示传输路径可用；应用通常还要完成身份认证、子协议确认和状态恢复，才应把连接视为可用会话。

线上的经典握手

下面是经典 HTTP/1.1 路径的核心字段。真实请求还可能带有 Origin、cookie、扩展和其他 HTTP 字段；字段顺序没有语义。

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

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat.v1

客户端为每次握手生成随机 key，服务端不能把示例中的固定值写死。客户端必须校验状态、Upgrade、Connection 和接受值；请求了子协议时，还要校验服务端选择的值。

握手失败仍是 HTTP 响应。服务端可以在升级前返回认证失败、来源拒绝或版本不支持，连接也不会进入 OPEN 状态。

开启握手

WebSocket 握手（WebSocket handshake） 从 HTTP/1.1 请求开始。客户端发送 Upgrade: websocket、版本和随机的 Sec-WebSocket-Key；服务端接受后返回 101 Switching Protocols，并给出由该 key 与固定 GUID 计算出的 Sec-WebSocket-Accept。这个计算证明响应方理解 WebSocket 握手，它不是身份认证。

客户端可以在 Sec-WebSocket-Protocol 中提供一组 WebSocket 子协议（WebSocket subprotocol） 。服务端只能选择其中一个或不选择，浏览器随后通过 socket.protocol 暴露结果。子协议适合固定消息格式或应用协议版本，不能拿来传访问令牌。

生产环境通常使用 wss://，让握手和后续帧都受 TLS 保护。RFC 8441 还定义了经由 HTTP/2 扩展 CONNECT 建立 WebSocket 的方式，因此真实代理路径不一定出现字面上的 HTTP/1.1 101。应用 API 会隐藏这层差异，但网关配置与观测工具必须理解实际使用的路径。

帧、消息与顺序

WebSocket 把应用消息编码成一个或多个帧。文本消息必须是有效 UTF-8，二进制消息的含义由应用决定。分片允许一条消息跨越多个帧；接收 API 通常在完整消息组装好之后才触发 message 事件。

帧头包含结束位、操作码、掩码位和负载长度。浏览器客户端发往服务端的帧必须掩码，服务端帧不得掩码；掩码用于避免特定的基础设施攻击，并不提供加密。库会处理这些规则，应用代码不应自行拼帧。

文本帧与二进制帧承载应用数据。关闭、Ping 和 Pong 属于 控制帧（control frame） ，可在分片消息之间出现。浏览器 API 不提供发送协议级 Ping 的方法；如果应用要确认事件循环和业务处理仍然存活，需要定义应用级心跳。

WebSocket 保留消息顺序和消息边界，但底层仍是一个有序字节流。丢包会让后续字节等待重传，一条很大的消息也可能占住应用的处理路径。一个 WebSocket 不会自动变成多个相互独立的通道。

文本与二进制负载

文本适合可检查的控制消息和体积受限的 JSON envelope，二进制适合已有明确编码的负载。选择二进制不会自动压缩数据；编码、压缩扩展和应用内容类型是不同决策。

接收方应在解码前检查消息类型和大小。把二进制无条件转成字符串，或把文本无条件交给 JSON 解析器，都会让协议错误进入业务代码。

浏览器的 binaryType 决定二进制消息以 Blob 还是 ArrayBuffer 交付。连接建立后就固定这一选择，能让消息处理器保持单一输入契约。

关闭与失败

正常关闭是一次双向握手。发起方发送带状态码和可选原因的 Close 帧，对端回复 Close 帧，随后底层连接结束。1000 表示正常关闭；应用使用私有状态码时，应从 4000–4999 范围选择并记录其含义。

关闭状态码（close code） 描述协议端点看到的结束原因，不证明最后一条业务消息是否提交。1006 是 API 用来报告异常关闭的保留值，不能放进 Close 帧发送。error 事件也故意不暴露丰富的网络细节，避免浏览器泄露跨源信息。

网络中断、进程退出和代理超时可能跳过关闭握手。此时客户端只能知道连接失效，不能仅凭 close 事件判断对端处理到了哪条消息。恢复必须依赖应用层确认、可重放性和服务器保存的进度。

示例

下面三个示例依次检查握手、完成一次真实的本地消息交换，再把重连与发送缓冲限制写成可测试的纯函数。所有输出均在 Node 24.14.0 中实际生成；第二个示例的服务端使用 ws 8.21.3。

完成本地双向交换

这个程序用 ws 创建本地服务端，用 Node 24 的全局 WebSocket 作为客户端。先安装 ws，再执行 node loopback_websocket.js；程序选择 codewiki.v1 子协议，交换一个 join 与一个 ack，最后完成正常关闭。

import { WebSocketServer } from 'ws';

const server = new WebSocketServer({ port: 0, host: '127.0.0.1' });

server.on('connection', (socket) => {
  console.log(`server protocol: ${socket.protocol}`);
  socket.on('message', (data) => {
    const message = JSON.parse(data.toString());
    console.log(`server received: ${message.type} ${message.room}`);
    socket.send(JSON.stringify({ type: 'ack', id: 7 }));
  });
});

server.on('listening', () => {
  const address = server.address();
  const socket = new WebSocket(
    `ws://127.0.0.1:${address.port}`,
    ['codewiki.v1'],
  );

  socket.addEventListener('open', () => {
    console.log(`client protocol: ${socket.protocol}`);
    socket.send(JSON.stringify({ type: 'join', room: 'blue' }));
  });
  socket.addEventListener('message', ({ data }) => {
    const message = JSON.parse(data);
    console.log(`client received: ${message.type} ${message.id}`);
    socket.close(1000, 'done');
  });
  socket.addEventListener('close', ({ code, reason }) => {
    console.log(`closed: ${code} ${reason}`);
    server.close();
  });
});

server protocol: codewiki.v1
client protocol: codewiki.v1
server received: join blue
client received: ack 7
closed: 1000 done

服务端监听随机端口，所以示例不会占用固定端口。connection 回调中的 socket.protocol 与客户端的 socket.protocol 相同，说明双方接受了同一个应用协议版本。

open 之后才能调用 send()。收到 ack 后，客户端以 1000 和原因 done 发起关闭；服务端库回复 Close 帧，因此最终 close 事件保留了相同的状态码与原因。

代码刻意只演示连接生命周期。生产处理器还必须验证 JSON 结构、检查房间权限、限制消息大小，并在每种退出路径释放监听器和会话状态。

限制重连与待发送数据

重连延迟和发送准入最好是纯策略，而不是散落在事件回调中的计时器。下面的函数使用有上限的指数退避，并以固定随机输入得到可重复输出；maySend() 则同时检查连接状态与 bufferedAmount。

const limits = {
  baseDelayMs: 500,
  maxDelayMs: 8000,
  maxBufferedBytes: 64 * 1024,
};

function reconnectDelay(attempt, random = 0.5) {
  const ceiling = Math.min(
    limits.maxDelayMs,
    limits.baseDelayMs * 2 ** attempt,
  );
  return Math.round(ceiling * (0.5 + random * 0.5));
}

function maySend(socket, bytes) {
  return socket.readyState === WebSocket.OPEN &&
    socket.bufferedAmount + bytes <= limits.maxBufferedBytes;
}

const fakeSocket = {
  readyState: WebSocket.OPEN,
  bufferedAmount: 60 * 1024,
};

console.log([0, 1, 2, 3].map((attempt) => reconnectDelay(attempt)));
console.log(maySend(fakeSocket, 2 * 1024));
console.log(maySend(fakeSocket, 8 * 1024));

[ 375, 750, 1500, 3000 ]
true
false

固定的 random = 0.5 让每次执行得到相同延迟；真实客户端应为每次尝试采样随机值，使大量客户端不会同时重连。达到延迟上限后，策略仍应保留随机扰动，并接受取消信号。

bufferedAmount 是已经交给 API、尚未发到网络的应用数据字节数。它不是服务器确认，也不是往返时延。false 分支必须有明确动作，例如暂停上游、拒绝可重试命令，或按产品规则关闭慢连接。

这个策略没有保存任意数量的待发消息。若产品需要离线队列，应明确条目和字节上限、过期时间、持久化位置，以及哪些消息允许在新连接上重放。

陷阱

修复方法： 只在 OPEN 状态发送，并给队列同时设置条目上限与字节上限。达到上限时执行明确的过载策略；不要把「暂存以后再发」当成天然安全的默认行为。

修复方法： 使用带随机扰动和上限的退避。为有副作用的命令分配稳定消息标识，让服务端去重并返回可恢复的确认；只有协议明确允许时才重放。

修复方法： 把 源（origin） 允许列表与身份认证作为两项独立检查。使用 wss://，避免把长期令牌放进 URL，并对每类消息执行授权，而不是只在连接时授权一次。

修复方法： 若业务需要端到端存活检测，定义包含时间或序号的应用级心跳，并设定总超时。服务端库可以另用协议级 Ping/Pong 检测传输端点；两种心跳解决的问题不同。

修复方法： 在解析前限制消息大小，捕获解码错误，再按消息类型校验结构和权限。未知类型应产生受控错误或策略关闭，而不是落入默认业务分支。

修复方法： 让服务端确认稳定的消息标识，并为服务器推送维护单调递增的恢复游标。重连后先恢复身份与订阅，再从最后确认位置补齐缺口。

延伸阅读

• RFC 6455：WebSocket 协议
• WHATWG WebSockets 标准
• MDN：WebSocket API
• MDN：bufferedAmount
• Node.js 24：全局 WebSocket
• ws API 文档