websocket不提供应用层数据完整性校验，仅保证帧级结构完整；需在协议层用帧头长度校验、业务层加长度前缀与协议头、内容层嵌入crc32/sha-256摘要、传输层结合序列号与ack实现端到端可信交付。
WebSocket 本身不提供应用层数据完整性校验，它只保证帧（Frame）级的结构完整——即每个 BinaryWebSocketFrame 或 TextWebSocketFrame 的 payload 长度、掩码、FIN 标志等符合 RFC 6455 规范。真正需要你主动设计和实现的，是业务消息层面的完整性保障。
协议层：利用 WebSocket 帧头长度字段做基础校验
WebSocket 协议在帧头中明确携带了 payload length 字段（支持 7/7+16/7+64 位编码），解码器（如 Netty 的 WebSocket13FrameDecoder）会据此严格重组 TCP 流中的分片，确保你收到的每个帧内容字节数与协议声明一致。这意味着：
- 收到的
frame.content().readableBytes()值，就是该帧实际有效载荷长度，可直接信任 - 若客户端发送时帧头长度与真实 payload 不符（如故意篡改或序列化错误），Netty 默认会抛出
CorruptedFrameException - 这是最轻量、最底层的完整性防线，但仅限于“帧没被截断或错乱”，不涉及业务逻辑是否合法或完整
业务层：添加长度前缀 + 自定义协议头
当一个 WebSocket 帧内承载多条业务消息（例如批量推送、Protobuf 多条记录拼接），或消息体本身无天然分隔符（如二进制结构），就必须在 payload 内部定义子协议。典型做法是加固定长度前缀：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 结构示例：
[len:4][cmd:2][body]，其中len是 body 字节数（网络字节序），不含 cmd 字段 - 服务端用
LengthFieldBasedFrameDecoder解析，关键配置：lengthFieldOffset=0、lengthFieldLength=4、lengthAdjustment=2（因 len 不含 cmd，需补上） - 校验动作：解码后检查
len是否非负、是否 ≤ 当前可读字节数；若超出，说明数据损坏或被恶意填充
内容层：消息级摘要校验（如 CRC32 / SHA-256）
适用于对一致性要求极高的场景（如金融指令、配置下发），在业务消息体中嵌入摘要值：
- 发送方：序列化消息体 → 计算 CRC32 或 SHA-256 → 将摘要附加在消息尾部或独立字段
- 接收方：提取 body（不含摘要）→ 本地重算摘要 → 与收到的摘要比对 → 不一致则丢弃并记录告警
- 注意：JSON 消息需统一编码（如 UTF-8）、忽略空白、固定字段顺序，否则哈希结果不稳定；二进制消息无此问题
传输层：结合序列号 + ACK 实现端到端可信交付
单纯校验无法解决丢包、重复、乱序问题，需叠加应用层确认机制：
- 每条业务消息带单调递增
seq（非时间戳），客户端维护全局自增计数器 - 服务端收到即返回
{"ack": seq}，客户端仅对已 ack 的消息进入本地有序队列 - 重连时客户端带上
last_seq，服务端据此续推未确认消息，避免漏传或重发 - 配合滑动窗口缓存乱序消息（如窗口大小设为 64），用 Map 实现 O(1) 查找与推进
