为什么对 Apache 提供的文本文件使用 deflate 而不是 gzip？

简单的答案是 不要 。

RFC 2616将 deflate 定义为：

deflate RFC 1950 中定义的“zlib”格式与 RFC 1951 中描述的“deflate”压缩机制相结合

zlib 格式在RFC 1950中定义为：

     0   1
     +---+---+
     |CMF|FLG|   (more-->)
     +---+---+

       0   1   2   3
     +---+---+---+---+
     |     DICTID    |   (more-->)
     +---+---+---+---+

     +=====================+---+---+---+---+
     |...compressed data...|    ADLER32    |
     +=====================+---+---+---+---+

所以，一些标头和一个 ADLER32 校验和

RFC 2616 将 gzip 定义为：

gzip 由文件压缩程序“gzip”（GNU zip）产生的一种编码格式，如 RFC 1952 [25] 中所述。此格式是具有 32 位 CRC 的
Lempel-Ziv 编码 (LZ77)。

RFC 1952将压缩数据定义为：

该格式目前使用 DEFLATE 压缩方法，但可以轻松扩展以使用其他压缩方法。

CRC-32比 ADLER32 慢

与相同长度的循环冗余校验相比，它以可靠性换取速度（更喜欢后者）。

所以......我们有 2 种压缩机制，它们使用 相同 的压缩算法，但对标头和校验和使用 不同 的算法。

现在，底层的 TCP
数据包已经相当可靠了，所以这里的问题不是
GZIP 使用的 Adler 32 vs CRC-32。

事实证明，多年来许多浏览器实施了不正确的放气算法。他们不期望 RFC 1950 中的 zlib
标头，而是期望压缩的有效负载。同样，各种网络服务器也犯了同样的错误。

因此，多年来，浏览器开始实现 模糊逻辑 deflate 实现，他们尝试 zlib 标头和 adler 校验和，如果失败，他们尝试有效负载。

具有这样复杂逻辑的结果是它经常被破坏。Verve Studio
有一个用户贡献的测试部分，显示情况有多糟糕。

例如：deflate 在 Safari 4.0 中工作，但在 Safari 5.1 中被破坏，它在 IE 上也总是有问题。

所以，最好的办法是完全避免放气，轻微的速度提升（由于 adler 32）不值得冒有效载荷损坏的风险。