websocket数据帧必须严格遵循rfc 6455：客户端发帧mask位须为1并附4字节masking-key，payload length按0–125/126/127三档编码，fin与opcode组合决定分片逻辑，违者将触发关闭或丢包。
WebSocket 数据帧不是“拿来就能用”的黑盒，它有明确的二进制结构、强制掩码规则和分片语义。直接拼 raw bytes 发送，99% 会触发 close 帧或被服务器静默丢弃。
客户端发帧必须带 Masking-key
这是 RFC 6455 的硬性规定：所有从客户端发往服务器的帧，MASK 位必须为 1，且紧随 Payload len 字段后出现 4 字节 Masking-key。服务器收到 MASK=0 的客户端帧会直接断连。
- 掩码不是加密，是防止代理缓存污染的简单异或混淆（用
Masking-key循环异或 payload 每个字节） - 服务端发给客户端的帧
MASK必须为 0，且不能含Masking-key字段 - 常见错误：用 Python
struct.pack手动构造帧时漏写Masking-key，或忘记对 payload 做异或处理
Payload length 编码有三档，不能硬填 7 位
Payload len 字段只有 7 位，但实际支持长度远超 127 字节。它的值决定后续是否需要扩展长度字段：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 0–125：直接作为 payload 长度（例如
0x7B= 123 字节） -
126：接下来 2 字节（网络字节序）表示真实长度（最大 65535） -
127：接下来 8 字节（网络字节序）表示长度（最高 2^64−1，但实际受内存与协议限制） - 错误示范：
len=65536时填126+ 2 字节，会截断成 0；必须用127+ 8 字节
FIN 和 Opcode 共同决定消息边界与类型
WebSocket 消息可跨多个帧传输，FIN 和 Opcode 的组合才是关键：
-
FIN=1, Opcode=0x1：单帧 UTF-8 文本消息 -
FIN=0, Opcode=0x1：文本消息首帧（后续帧Opcode=0x0） -
FIN=1, Opcode=0x0：文本消息续帧（且是最后一帧） -
FIN=0, Opcode=0x2：二进制消息首帧（Opcode=0x2只能出现在首帧） - 错用
Opcode=0x2在非首帧，服务器通常立即关闭连接
MTU 与分片的实际影响比理论更敏感
虽然 WebSocket 支持任意大小消息分片，但底层 TCP 的 MTU（通常 1500 字节）会让大帧被 IP 层分片。一旦某个 IP 分片丢失，整个 TCP 包重传，导致 WebSocket 帧延迟飙升。
- 生产环境建议单帧 payload 控制在 8KB 以内（兼顾吞吐与丢包恢复）
- 不要依赖自动分片：手动分片时，确保每片都遵守
FIN/Opcode规则，并避免跨帧切分 UTF-8 多字节字符 - 浏览器
WebSocket.send()会自动处理分片，但自研 server/client 时，帧级缓冲和重组逻辑极易出 bug
真正难的不是看懂帧格式图，而是把 FIN/Opcode/MASK/Payload length 这四个字段的约束条件同时满足——少一个，连接就掉；错一个，数据就乱。调试时优先抓包看前 2 字节和 MASK 位，比查业务逻辑更快定位问题。
