WebSocket

WebSocket 在 HTTP 握手升级成功后，建立一条可由客户端和服务端双向发送消息的长连接。它适合聊天、协作编辑、实时控制、在线状态与游戏等低延迟双向场景。

连接过程

浏览器先发送带 Upgrade: websocket 的 HTTP 请求。服务端同意后返回 101 Switching Protocols；后续数据按 WebSocket 帧传输，不再是 HTTP 请求/响应。

• ws:// 对应未加密连接。
• wss:// 对应 TLS 加密连接；生产环境与 HTTPS 页面应使用 wss://。
• HTTP 与 WebSocket 都基于 TCP，但 HTTP 本身并非“单向通信”：HTTP 是客户端发起请求、服务端返回响应的请求/响应模型。

生命周期

CONNECTING → OPEN → CLOSING → CLOSED

• CONNECTING：正在握手，不能发送业务消息。
• OPEN：连接可用。
• CLOSING：已开始关闭。
• CLOSED：连接结束；需要重新连接时必须创建新实例。

关闭码 1000 表示正常关闭。自定义业务关闭码应使用 3000–4999，并避免将敏感信息放入关闭原因。

工程要点

• WebSocket 没有浏览器原生自动重连；客户端应实现带退避和抖动的重连，避免集体断线后同时重连。
• 网络中断不会总是立即触发 close。应用层应设计心跳与超时检测；浏览器客户端通常用业务 ping/pong 消息，Node 服务端可使用协议级 ping/pong。
• send() 只表示数据已进入发送缓冲区，不代表对端已处理。高频发送时观察 bufferedAmount，必要时限流或丢弃可再生成的数据。
• 握手时校验 Origin 与身份；浏览器 WebSocket API 不能自定义握手请求头，通常用 Cookie、短期票据或首条认证消息完成鉴权。
• 单连接的消息顺序可保持，但断线重连后需要业务层序号、幂等键或确认机制保证一致性。

与 SSE 的选择

需求	选择
双向实时消息	WebSocket
服务端单向推送、希望浏览器自动重连	SSE
普通请求/响应或一次性流式响应	HTTP / Fetch

参阅

• WebSocket API - MDN
• The WebSocket Protocol - RFC 6455