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

如果我没记错的话

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

我认为deflate和gzip之间没有太大的区别，因为gzip基本上只是一个包在deflate周围的头文件(参见rfc 1951和1952)。

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

(来源:typepad.com)

Mod_deflate需要更少的服务器资源，尽管您可能会在压缩量方面付出一些代价。

如果您正在处理许多小文件，我建议您对压缩和未压缩的解决方案进行基准测试和负载测试——您可能会发现在某些情况下启用压缩并不能节省成本。

在已经安装了Apache2和deflate模块的Ubuntu上(这是默认的)，你可以在两个简单的步骤中启用deflate gzip压缩:

a2enmod deflate
/etc/init.d/apache2 force-reload

你走了!我发现我通过adsl连接访问的页面加载得更快。

编辑:根据@GertvandenBerg的评论，这支持gzip压缩，而不是deflate。

There shouldn't be any difference in gzip & deflate for decompression. Gzip is just deflate with a few dozen byte header wrapped around it including a checksum. The checksum is the reason for the slower compression. However when you're precompressing zillions of files you want those checksums as a sanity check in your filesystem. In addition you can utilize commandline tools to get stats on the file. For our site we are precompressing a ton of static data (the entire open directory, 13,000 games, autocomplete for millions of keywords, etc.) and we are ranked 95% faster than all websites by Alexa. Faxo Search. However, we do utilize a home grown proprietary web server. Apache/mod_deflate just didn't cut it. When those files are compressed into the filesystem not only do you take a hit for your file with the minimum filesystem block size but all the unnecessary overhead in managing the file in the filesystem that the webserver could care less about. Your concerns should be total disk footprint and access/decompression time and secondarily speed in being able to get this data precompressed. The footprint is important because even though disk space is cheap you want as much as possible to fit in the cache.

为什么对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)不值得承担破坏有效载荷的风险。

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