WebSocket传输慢主因是未启用permessage-deflate压缩，开启后文本消息体积可降60%~80%；需握手时协商Sec-WebSocket-Extensions头，且合理配置threshold、serverNoContextTakeover及zlib参数。
WebSocket传输慢，90%不是网络或服务器问题，而是没开 permessage-deflate 压缩——它能让JSON、日志、信令等文本类消息体积直降60%~80%，且对延迟几乎无额外影响。
为什么开了压缩还是没效果？检查Sec-WebSocket-Extensions协商头
压缩必须在WebSocket握手阶段通过HTTP头完成协商，如果客户端或服务端任一方没发/没认 Sec-WebSocket-Extensions: permessage-deflate，后续所有消息都按明文走。
- 用浏览器开发者工具的 Network → WS → Headers 查看请求和响应头，确认双方都含该字段
- Node.js
ws库默认不启用，必须显式传perMessageDeflate: true或对象配置 - Java
Java-WebSocket必须在Draft_6455构造时传入new PerMessageDeflateExtension()，光加依赖不注册等于没开 - Go 的
gorilla/websocket需手动设置EnableCompression: true，且客户端（如Chrome）需支持该扩展（现代浏览器均支持）
threshold参数设太小反而拖慢性能
threshold 是决定“多大消息才压缩”的开关，默认值通常是 1024（1KB），但设得过低会导致大量小消息反复进zlib压缩流程，CPU反升、延迟反增。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 纯文本消息（如聊天JSON）建议设为
512~2048；二进制消息（如protobuf序列化体）通常无需压缩，可设为8192或更高 - Node.js
ws中若未指定threshold，实际行为是「所有消息都压缩」，容易踩坑 - Java
PerMessageDeflateExtension不直接暴露threshold，需包装自定义WebSocketAdapter拦截onMessage前判断长度
serverNoContextTakeover=true 不是省内存，是防状态污染
DEFLATE压缩依赖滑动窗口和字典状态，serverNoContextTakeover 表示每次压缩完立刻丢弃上下文，而不是复用到下一条消息。
- 设为
true可避免长连接中因某条异常消息污染后续压缩状态（典型表现：某条消息解压失败后，后面全乱码） - 设为
false虽略省CPU，但要求客户端也配clientNoContextTakeover: true，否则协商失败会退回到无压缩 - Goim 和 ShareDrop 生产配置都默认开启双端
NoContextTakeover，这是稳定性优先的实际选择 -
zlibDeflateOptions.level推荐用6（平衡点），1虽快但压缩率差，9在高并发下易触发线程阻塞
移动端弱网下压缩反而更卡？检查zlibInflateOptions.level
服务端压缩快，但客户端解压慢——尤其低端Android设备用默认 zlibInflateOptions.level: 15（最大窗口）时，解压耗时可能翻倍。
- 客户端解压性能瓶颈常被忽略：Node.js
ws默认zlibInflateOptions为空，实际使用系统默认窗口（15），应显式设为{ level: 8 }或更低 - SocketRocket（iOS）原生不支持
permessage-deflate，必须手动集成zlib并限制MAX_WBITS，否则解压可能卡主线程 - 浏览器环境虽自动处理，但若用
WebSocket.onmessage接收后立即JSON.parse()大量数据，仍会阻塞UI——压缩只是减体积，不解决主线程解析压力
真正卡顿往往出在「以为开了压缩就万事大吉」，结果没验协商头、阈值乱设、解压参数放任默认。压缩不是银弹，而是需要两端对齐参数、按消息类型分级控制的精细操作。
