WebSocket通信严格遵循RFC 6455， handshake需HTTP升级头与正确Sec-WebSocket-Accept签名，帧结构含FIN/RSV/Opcode/MASK等精确字段，控制帧须满足opcode、长度、MASK等多重校验。
WebSocket 的协议解析与帧封装不是简单的“编码-发送”两步，而是一套严格遵循 RFC 6455 的字节级协作机制。核心在于握手建立连接后，所有通信都依赖结构精确、语义明确的帧（Frame）——它既是数据载体，也是控制指令的唯一形式。
握手：HTTP 升级为 WebSocket 连接
连接起点是标准 HTTP 请求，但必须携带特定头部才能触发协议升级：
- Upgrade: websocket 和 Connection: Upgrade 告知服务器这是协议切换请求
- Sec-WebSocket-Key 是客户端生成的 16 字节随机 Base64 字符串，用于防缓存和身份验证
- Sec-WebSocket-Version: 13 表示采用 RFC 6455 规范（当前唯一通用版本）
- 服务器响应必须是 HTTP/1.1 101 Switching Protocols，且 Sec-WebSocket-Accept 需通过 SHA-1(Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11") 计算并 Base64 编码
任意字段缺失、值错误或签名不匹配，连接都会在握手阶段失败。
帧结构：二进制布局决定合法性
每个帧由固定头部 + 可变负载组成，字段位置与含义被 RFC 精确定义：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- FIN（1 bit）：标识是否为消息终结帧；控制帧（如 Close/Ping/Pong）必须置 1，禁止分片
- RSV1–RSV3（各 1 bit）：保留位，必须全为 0；非零将被对端视为协议错误
- Opcode（4 bits）：决定帧类型；仅 0x01（文本）、0x02（二进制）、0x08（Close）、0x09（Ping）、0x0A（Pong） 合法；其他值（如 0x03、0x07）直接导致断连
- MASK（1 bit）：客户端发帧必须为 1 并附带 4 字节掩码密钥；服务端发帧必须为 0，否则被拒绝
- Payload length：7/16/64 位编码，支持三种长度格式；控制帧负载不得超过 125 字节
控制帧封装：安全发送的关键约束
Close、Ping、Pong 是唯一合法的控制帧，封装时需同时满足语义与二进制规则：
- 主动关闭必须用 websocket.FormatCloseMessage(code, reason) 生成 payload：它自动写入 2 字节状态码 + UTF-8 编码的原因字符串，裸传字符串会违反协议
- Ping 帧 payload 可为空或 ≤125 字节任意数据；Pong 帧通常由库自动响应，一般无需手动构造
- 使用 gorilla/websocket.WriteControl() 是最稳妥方式——它内置 opcode 校验、长度截断、mask 逻辑及错误分类（如区分 io.ErrClosed 与真正异常）
- 手动生成二进制帧时，服务端帧首字节第 8 位（MASK 位）必须为 0；客户端则必须为 1，且后续 4 字节为有效掩码密钥
帧解析：逐字段校验不可跳过
底层读取原始字节流时，解析控制帧不能只看 opcode，必须同步验证多项条件：
- 检查 FIN 是否为 1 —— 控制帧不允许分片
- 确认 RSV 全为 0 —— 非零即非法
- 核实 Opcode 是否属于 0x08/0x09/0x0A —— 其他值立即断连
- 计算 payload 长度是否 ≤125 —— 超长 Ping 帧多数服务端（如 gorilla）直接拒收
- 比对 MASK 位与角色是否匹配：客户端帧 MASK=1 且含密钥；服务端帧 MASK=0 且无密钥
任一检查失败，都应按 RFC 要求发送 Close 帧并终止连接，而非静默忽略。
