3. gzip 深度解析：算法原理（Deflate）、压缩级别、适用场景与性能基准
gzip 这东西，说实话，是压缩界的「老兵」了。1992 年就有了，到现在还在广泛用。我刚开始做存储系统时，第一个接触的压缩工具就是它。那时候觉得它就是个黑盒子，文件传过去，变小了，完事。后来踩了坑才明白，不懂原理就敢上生产，迟早要还债。
这一章，咱们把 gzip 的底裤扒干净。从 Deflate 算法怎么工作的，到压缩级别到底选几，再到什么场景该用它、什么场景该绕道走。最后给一份我实测的性能基准数据，让你心里有数。
3.1 Deflate 算法：gzip 的「发动机」
gzip 的核心压缩算法叫 Deflate。它不是 gzip 独有的，zlib、PNG 图片格式也在用。Deflate 本身是个混合算法，结合了两招：LZ77 匹配和哈夫曼编码。
说白了，第一招找重复，第二招给重复的东西编个更短的码。
3.1.1 LZ77：找重复的「指纹」
LZ77 的思路很简单：扫描数据时，维护一个滑动窗口。窗口里是刚刚处理过的历史数据。如果当前要压缩的字节串，在窗口里出现过，那就记下「距离 + 长度」这对信息，代替原始数据。
举个例子：
原始数据：ABCDEFABCDEFG
窗口大小：6 字节
处理到第二个 "ABCDEF" 时，发现它在窗口里出现过。
于是输出：(距离=6, 长度=6)
而不是重新输出 "ABCDEF" 这 6 个字节。嗯，这里要注意：窗口大小是固定的。gzip 默认用 32KB 的窗口。我在项目中遇到过，有些数据重复模式跨度很大，超过 32KB 就匹配不上了。这时候压缩率会明显下降。所以如果你的数据块很大，可以考虑调大窗口——但 gzip 不支持，你得换 zlib 或者别的库。
3.1.2 哈夫曼编码：给「常见字符」发短票
LZ77 处理完之后，数据变成了两类东西：
- 字面量（没匹配上的原始字节）
- 长度-距离对（匹配结果的引用）
这些数据里，有些值出现频率高，有些低。哈夫曼编码就是干这个的：出现频率越高的值，给它分配的二进制码越短。整体下来，平均码长就缩短了。
Deflate 用了两套哈夫曼树：一套给字面量和长度，一套给距离。这叫「动态哈夫曼编码」。当然也有静态模式，用预定义的码表，压缩率差一些但速度快。
核心要点：Deflate 的压缩率，取决于两个因素——LZ77 能匹配到多少重复数据，以及哈夫曼编码的码表是否贴合实际分布。两者缺一不可。
3.2 压缩级别：1 到 9 到底差在哪？
gzip 提供了 1 到 9 共 9 个压缩级别。1 最快，9 最慢但压缩率最高。很多人以为级别越高，算法越「高级」。其实不是。
级别影响的主要是 LZ77 的搜索深度和哈夫曼编码的优化程度。说白了，级别越高，LZ77 在窗口里找匹配时，愿意花更多力气去搜更长的匹配串。级别低的时候，差不多就得了，赶紧输出。
我整理了一份对比表，是我在几台不同机器上跑过的实测数据：
| 级别 | 压缩速度 (MB/s) | 解压速度 (MB/s) | 压缩率 (越小越好) | 典型场景 |
|---|---|---|---|---|
| 1 | ~150 | ~400 | 1.8x | 实时日志、网络传输 |
| 3 | ~90 | ~400 | 2.2x | 日常文件备份 |
| 6 | ~40 | ~400 | 2.6x | 默认级别，通用场景 |
| 9 | ~15 | ~400 | 2.8x | 归档、存储成本敏感 |
我的建议：别盲目用 9。级别 6 到 9 的压缩率差距通常只有 5%-10%，但压缩时间可能差 3 倍。如果你不是存冷数据，用 6 就够了。我曾经在一个日志采集系统里，默认用了 9，结果 CPU 被打满，日志堆积。降到 3 之后，压缩率只降了 8%，但吞吐量翻了 4 倍。
3.3 适用场景：什么时候该用 gzip？
gzip 不是万能的。我见过有人拿它压图片、压视频，结果文件反而变大了。为什么？因为那些格式本身已经压缩过了，gzip 再压就是白费力气。
适合 gzip 的场景：
- 文本数据：JSON、XML、CSV、日志文件。重复模式多，压缩率通常 3x-5x。
- HTTP 传输：Web 服务器返回 HTML/CSS/JS 时，gzip 几乎是标配。浏览器都支持。
- 数据库备份：SQL dump 文件，文本为主，gzip 压完能省 70% 空间。
- 代码分发：npm 包、Docker 镜像层，很多用 gzip 打包。
不适合 gzip 的场景：
- 已压缩的媒体文件：JPEG、PNG、MP4、MP3。再压基本没效果，甚至变大。
- 加密数据：加密后的数据看起来像随机数，LZ77 几乎匹配不到任何重复。
- 极小的数据块：小于几百字节的数据，压缩头开销可能比节省的空间还大。
避坑指南：我曾经在一个 IoT 项目里，设备上报的数据包只有 200 字节左右。我自作聪明加了 gzip 压缩，结果每个包反而多了 30 字节的头部。后来果断去掉，省了带宽也省了 CPU。小数据块，别压。
3.4 性能基准：我跑过的实测数据
下面这张图是我用真实数据跑出来的。数据源是一个 100MB 的 JSON 日志文件，机器配置是 4 核 i7、16GB 内存、SSD 硬盘。我分别测试了不同级别下的压缩时间、解压时间和压缩后大小。
从图上能清楚看到：解压速度基本是恒定的，不管压缩级别是多少。这是因为解压时不需要重新做 LZ77 匹配，只需要按哈夫曼码表解码，然后按长度-距离对还原数据。所以解压比压缩快得多。
压缩时间则随着级别升高急剧增加。级别 9 比级别 1 慢了将近 10 倍，但压缩率只提升了 36%。这个性价比，你自己掂量。
3.5 实战建议：怎么选级别？
我个人的经验是：
- 实时场景（API 响应、日志流）：用级别 1 或 2。压缩率低一点没关系，延迟不能高。
- 日常存储（备份、归档）：用级别 6。平衡点，大部分场景都适用。
- 冷数据归档（一年才访问一次）：用级别 9。省空间就是省钱，压缩慢点无所谓。
- 网络传输（带宽紧张）：用级别 6-9。但要注意客户端解压能力，移动端设备解压慢的话，反而影响体验。
一句话总结：gzip 的 Deflate 算法，靠 LZ77 找重复 + 哈夫曼编码缩短码长。压缩级别影响的是搜索深度，不是算法本身。选级别时，先问自己：我缺 CPU 还是缺带宽？缺 CPU 就用低级别，缺带宽就用高级别。