WebSocket 协议支持通过扩展(Extension)机制来实现数据压缩。目前最广泛使用的压缩扩展是Per-message Deflate(每个消息独立压缩),它使用zlib库提供的DEFLATE算法来压缩每个WebSocket消息。该扩展需要在握手阶段通过HTTP头协商:客户端在握手请求中添加Sec-WebSocket-Extensions: permessage-deflate头,服务端如果支持该扩展,会在响应头中返回相同的扩展名。协商成功后,客户端和服务器在发送消息时可以选择是否对该消息进行压缩(通常通过阈值设置,只对超过一定大小(如1024字节)的消息启用压缩,避免小消息压缩后体积反而变大)。
根据OWASP 2026年最新安全指南,建议禁用permessage-deflate压缩,除非特别需要。原因是压缩可能与秘密数据结合使用时引入类似CRIME/BREACH攻击的安全漏洞。当压缩数据与秘密数据(如认证令牌、CSRF令牌)混合时,攻击者可以通过观察压缩后消息的大小来推断秘密数据的内容。Microsoft ASP.NET Core的WebSocketAcceptContext.DangerousEnableCompression属性甚至明确标注为"Dangerous",警告开发者启用压缩会使应用容易受到CRIME/BREACH攻击。此外,permessage-deflate扩展还存在拒绝服务攻击风险:恶意客户端可以发送小型压缩帧("解压缩炸弹"),在服务器端解压后占用大量内存,导致服务崩溃。CVE-2026-39804和CVE-2026-1526都涉及permessage-deflate相关的安全漏洞。
除了使用协议层的压缩扩展外,还可以在应用层采取措施来减少WebSocket 传输的数据量:选择更紧凑的序列化格式(如用MessagePack或Protocol Buffers替代JSON ,可以减少30-50%的数据体积)、设计精简的消息协议(避免发送冗余字段,只传输必要的数据)、对高频重复的数据使用字典编码或差分传输(如只传输变化的部分,而不是每次都发送完整状态)。在微服务架构中,如果使用腾讯云API网关来管理WebSocket连接,还可以结合腾讯云的内容分发网络(CDN )来缓存静态资源,减少回源请求。