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

简单的答案是不要。

RFC 2616将通缩定义为:

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

在RFC 1950中，zlib格式被定义为:

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

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

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

因此，有一些报头和一个ADLER32校验和

RFC 2616将gzip定义为:

gzip由文件压缩程序产生的编码格式 RFC 1952[25]中描述的“gzip”(GNU zip)。此格式是 32位CRC的Lempel-Ziv编码(LZ77)。

RFC 1952将压缩数据定义为:

该格式目前使用DEFLATE压缩方法，但可以很容易地扩展到使用其他压缩方法。

CRC-32比ADLER32慢

与相同长度的循环冗余检查相比，它以可靠性换取速度(更倾向于后者)。

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

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

事实证明，多年来许多浏览器实现了错误的deflate算法。在RFC 1950中，他们只是期望压缩的有效负载，而不是期望zlib报头。类似的，各种网络服务器也犯了同样的错误。

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

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

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

所以，最好的办法就是完全避免泄气，轻微的速度提升(由于adler 32)不值得承担破坏有效载荷的风险。

GZip只是deflate加上一个校验和和页眉/页脚。不过，我从惨痛的教训中学到，通缩的速度更快。

(来源:typepad.com)

如果我没记错的话

Gzip将压缩比deflate多一点 通缩更有效

实际上，你可能无法选择通缩作为一个选项。与你所期望的相反，mod_deflate使用的不是deflate而是gzip。因此，虽然大多数观点都是正确的，但可能与大多数人无关。

主要原因是deflate的编码速度比gzip快，而且在繁忙的服务器上，这可能会产生不同。对于静态页面，这是一个不同的问题，因为它们可以很容易地预压缩一次。

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

简单的答案是不要。

RFC 2616将通缩定义为:

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

在RFC 1950中，zlib格式被定义为:

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

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

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

因此，有一些报头和一个ADLER32校验和

RFC 2616将gzip定义为:

gzip由文件压缩程序产生的编码格式 RFC 1952[25]中描述的“gzip”(GNU zip)。此格式是 32位CRC的Lempel-Ziv编码(LZ77)。

RFC 1952将压缩数据定义为:

该格式目前使用DEFLATE压缩方法，但可以很容易地扩展到使用其他压缩方法。

CRC-32比ADLER32慢

与相同长度的循环冗余检查相比，它以可靠性换取速度(更倾向于后者)。

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

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

事实证明，多年来许多浏览器实现了错误的deflate算法。在RFC 1950中，他们只是期望压缩的有效负载，而不是期望zlib报头。类似的，各种网络服务器也犯了同样的错误。

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

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

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

所以，最好的办法就是完全避免泄气，轻微的速度提升(由于adler 32)不值得承担破坏有效载荷的风险。