netty 的 websocket 协议处理自动完成，无需手动解密帧数据；websocketserverprotocolhandler 负责协议升级、utf-8 解码、掩码还原及控制帧过滤，业务加密应在自定义 handler 中处理。
Netty 的 WebSocket 协议处理是自动完成的，不需要手动解密帧数据；所谓“解密”其实是误解，真实需求通常是协议升级验证、帧内容解析或 TLS 加密层配置。
WebSocketServerProtocolHandler 负责协议升级和帧生命周期管理
Netty 不让你直接接触原始字节流做“解密”，而是用 WebSocketServerProtocolHandler 封装了整个 WebSocket 握手与帧处理流程。它会：
- 拦截
Upgrade: websocket请求，校验Sec-WebSocket-Key并返回标准响应头 - 自动丢弃非 WebSocket 请求（比如普通 GET /api），避免 handler 处理脏数据
- 将后续帧（
TextWebSocketFrame、BinaryWebSocketFrame）解包后直接投递给你的SimpleChannelInboundHandler - 内置心跳（
PingWebSocketFrame/PongWebSocketFrame）响应逻辑，无需额外实现
错误做法：绕过 WebSocketServerProtocolHandler，自己用 HttpObjectAggregator + 手动解析 Upgrade 头 —— 这会导致握手失败、浏览器报 ERR_INCOMPLETE_CHUNKED_ENCODING 或直接关闭连接。
收到的 TextWebSocketFrame 已是 UTF-8 解码后的字符串
当你继承 SimpleChannelInboundHandler<textwebsocketframe></textwebsocketframe> 时，frame.text() 返回的是 Java 字符串，不是原始二进制。Netty 在 WebSocketServerProtocolHandler 内部已完成了：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 对 WebSocket 文本帧 payload 的 UTF-8 解码
- 校验掩码（mask）并自动反向异或还原（客户端发送帧必须 mask，服务端不需）
- 过滤掉控制帧（如 Close、Ping），只把数据帧交给你的 handler
常见误区：在 handler 里对 frame.content() 调用 toString(CharsetUtil.UTF_8) —— 这是重复解码，可能抛 IllegalReferenceCountException（因为 content() 是引用计数 ByteBuf，已被前序 handler 释放）。
真正需要“解密”的场景只有 TLS 层或自定义业务加密
如果前端发来的是加密消息（比如 AES 加密的 JSON），那属于业务层加解密，和 WebSocket 协议无关。此时你应该：
- 保持
WebSocketServerProtocolHandler在 pipeline 前置位置（确保协议正确） - 在它之后插入自定义 handler（如
AesMessageDecoder），对TextWebSocketFrame.text()结果做 AES 解密 - 不要尝试修改或替换
WebSocketServerProtocolHandler的行为 —— 它不暴露帧原始字节，也不允许你劫持解码过程 - 若用 WSS（
wss://），则 TLS 解密由SslContext和SslHandler完成，放在 pipeline 最前端，和 WebSocket 协议解码完全解耦
典型错误配置：SslHandler 放在 WebSocketServerProtocolHandler 之后 —— 导致 TLS 握手失败，连接被重置。
最容易被忽略的一点：WebSocket 帧本身没有“加密”概念，只有 mask（掩码），而 mask 是客户端强制行为、服务端自动处理；所有你以为要“解密”的操作，99% 应该落在业务逻辑层，而不是协议层。
