WebSocket 压缩扩展演示 - permessage-deflate 效果

permessage-deflate 是 WebSocket 协议的一个扩展（定义在 RFC 7692），它使用 deflate 算法对每条 WebSocket 消息进行压缩传输。它的关键特性是跨消息共享压缩上下文（context takeover），这意味着连续发送相似结构的消息时，压缩效率会越来越高，因为压缩器能复用之前建立的字面量字典。这对于 JSON API、实时数据推送、聊天应用等场景特别有效，通常能节省 50%-80% 的带宽。

实际节省量取决于消息内容：

• JSON 数据（高重复结构）：通常压缩率 60%-85%，即节省 60%-85% 带宽
• 纯文本聊天：通常压缩率 40%-60%
• 日志流（高度重复格式）：压缩率可达 80%-95%
• 已压缩的二进制数据（图片、视频等）：几乎无效果，甚至可能略微增大

使用本工具上方的预设场景，可以直观感受不同类型数据的压缩效果。

在以下场景强烈建议启用：

• 传输 文本类消息（JSON、XML、HTML、纯文本）
• 消息包含大量重复结构或字段名
• 带宽受限的环境（移动网络、物联网设备）
• 高频小消息推送场景（如实时行情、游戏状态同步）
• 需要降低网络流量成本的生产环境

• 已压缩的二进制数据：图片（JPEG/PNG/WebP）、视频、音频、ZIP 文件等已经过压缩，再次压缩效果极差且浪费 CPU
• 极低延迟要求：压缩和解压缩需要 CPU 时间，如果延迟要求是微秒级别，压缩开销可能不可接受
• 极短消息（<100字节）：deflate 的头部开销可能让压缩后反而更大
• CPU 极度受限的设备：低功耗嵌入式设备可能无法承受压缩的 CPU 开销

压缩上下文接管是 permessage-deflate 的核心特性。deflate 压缩算法会在内存中维护一个滑动窗口字典，记录最近出现过的字节序列。当启用 context takeover 时：

• 压缩器在处理完一条消息后不重置字典
• 下一条消息可以引用之前消息中出现的重复模式
• 这意味着第 1 条消息压缩率一般，但第 2、3、4...条消息的压缩率逐渐提升
• 本工具中"上下文压缩"列就模拟了这种效果——后续消息能利用前面消息建立的字典

不过，context takeover 也有代价：如果连接中断，双方需要重新建立压缩上下文。

deflate 压缩是相对轻量的算法：

• 现代 CPU 上，压缩 1KB 消息通常只需几十微秒
• 对于每秒数千条消息的场景，CPU 开销通常在 1%-5% 之间
• 解压缩比压缩更快，客户端开销通常可忽略
• 带宽节省带来的延迟降低通常远超压缩本身的 CPU 开销

总体而言，对于绝大多数 Web 应用，启用 permessage-deflate 的性价比非常高。

大多数 WebSocket 库都内置支持：

• 浏览器客户端：使用 new WebSocket(url) 时浏览器自动协商 permessage-deflate（现代浏览器默认启用）
• Node.js (ws 库)：new WebSocket.Server({ perMessageDeflate: true })
• Python (websockets)：serve(handler, host, port, compression="deflate")
• Go (gorilla/websocket)：upgrader.EnableCompression = true

握手时通过 Sec-WebSocket-Extensions: permessage-deflate 头协商参数。

是的，所有主流现代浏览器都支持：Chrome 32+、Firefox 37+、Safari 9+、Edge 所有版本。浏览器的 WebSocket 实现在握手时默认自动协商 permessage-deflate 扩展，无需开发者手动配置。对于服务端 WebSocket，需要确保使用的库支持该扩展并已启用。