为什么在Apache服务器中提供文本文件时要使用Deflate而不是Gzip？

Question

为什么在Apache服务器中提供文本文件时要使用Deflate而不是Gzip？

apachecompressiongziplampdeflate

218

这两种方法对于由LAMP服务器提供的HTML、CSS和JavaScript文件有什么优势？是否有更好的替代方案？

该服务器使用Json向地图应用程序提供信息，因此存在大量小文件。

另请参阅选择HTTP压缩中gzip和deflate有何性能影响？

- Ken

已切换接受的答案...目前的共识是2:1支持gzip。 - Ken

1

mod_deflate适用于Apache 2，mod_gzip适用于Apache 1.3。 - SPRBRN

9个回答

175

GZip 就是 Deflate 加上校验和、头部和尾部。然而 Deflate 更快，正如我曾经吃过的亏。

_{（来源: typepad.com）}

- Jeff Atwood

13

更不用说zlib不支持这个扩展，即使支持，SSE 4.2中的CRC32指令使用的是多项式1EDC6F41，而gzip格式使用的是多项式EDB88320，两者算法完全不同。 - Jack Lloyd

7

既然deflate更快，那么SO为什么使用gzip呢？ - David Murdoch

41

好的，这个答案结果是不正确的...参见：http://zoompf.com/blog/2012/02/lose-the-wait-http-compression...特别是客户端有两种方式可以“解释”deflate，即无头/无校验和和带有zlib标头。在浏览器中实现正确的deflate存在问题，应避免使用deflate。 - Sam Saffron

5

@sam，此外，我刚刚重新运行了基准测试，在现代英特尔芯片上，gzip的压缩速度为1441/692，解压速度为1286/531。第二个数字是解压缩，第一个是压缩。所以deflate确实仍然更快，你的基准测试结果是否显示相反的情况？（我同意出于其他原因可能没有用，但答案是正确的，deflate更快..） - Jeff Atwood

7

但问题并没有更快吗？ - Ken

显示剩余7条评论

17

您可能无法实际选择deflate作为选项。与您可能期望的相反，mod_deflate并不使用deflate，而是使用gzip。因此，尽管大多数观点都是有效的，但它可能对大多数人无关紧要。

- Amblyopius

4

主要原因是deflate的编码速度比gzip更快，在繁忙的服务器上可能会有所区别。对于静态页面来说，情况不同，因为它们可以轻松地预先压缩一次。

- saua

大概使用gzip时，直到获得、存储并压缩了所有数据之后，才能开始传输头部吗？（因为您需要校验和来创建头部） - OJW

9

在gzip格式中，校验和位于文件末尾，这样在处理时可以一边生成deflate块，一边进行校验，无需等待所有块都生成完毕。 - Jack Lloyd

4

我认为deflate和gzip之间没有太大的区别，因为gzip基本上只是在deflate的基础上添加了一个头部（请参阅RFC 1951和1952）。

- schnaader

2

mod_deflate可以减少服务器资源的使用，但是在压缩量方面可能会有一些小的性能损失。

如果您正在提供许多小文件，则建议对压缩和非压缩解决方案进行基准测试和负载测试-您可能会发现某些情况下启用压缩不会节省空间。

- Dave R.

对于那些好奇的人，使用压缩算法deflate后，我的文本文件从30KB变成了10KB - 因此文件必须比这更小才能不产生任何节省。我猜测少于1KB或类似的大小。 - GChuf

1

解压缩gzip和deflate没有任何区别。gzip实际上只是在deflate周围包装了几十个字节的头，其中包括校验和。这个校验和是导致压缩速度变慢的原因。然而，当你预压缩数以百万计的文件时，你想要这些校验和作为文件系统的检查。此外，你可以利用命令行工具来获取文件的统计数据。对于我们的网站，我们预压缩了大量的静态数据（整个开放目录，13000个游戏，数百万个关键词的自动完成等），我们排名得到了Alexa网站95%以上的快速访问。Faxo搜索。然而，我们使用了一个自主研发的专有Web服务器。Apache/mod_deflate并不能满足我们的需求。当这些文件被压缩到文件系统中时，不仅会因为最小文件系统块大小而受到影响，还会产生所有无关紧要的管理文件的额外开销，而这些开销对于Web服务器来说毫不重要。你应该关注的是总磁盘占用空间和存取/解压缩时间，其次是能够快速获取这些预压缩数据的速度。磁盘占用空间很重要，因为尽管磁盘空间很便宜，但你希望尽可能多地将其放入缓存中。

- Steven

GZip 可能会在解压缩时检查校验和，因此解压缩速度会有所差异。 - Seun Osewa

-1

在已经安装了Apache2和deflate模块的Ubuntu上（默认情况下已经安装），您可以通过两个简单的步骤启用gzip压缩，如下所示：

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

完成了！我发现通过我的adsl连接提供的页面加载速度更快。

编辑：根据@GertvandenBerg的评论，这启用了gzip压缩，而不是deflate。

- aidan

6

除了启用gzip，因为mod_deflate仅混淆gzip压缩... - Gert van den Berg

@GertvandenBerg 我已经更新了我的答案，但是为了记录，gzip就是deflate，只不过有额外的头部和校验和。 - aidan

@aiden 是的，但校验和会影响性能...(而原始压缩不符合标准) - Gert van den Berg

-5

如果我没记错的话

gzip 压缩比 deflate 更高一些
deflate 更加高效

- JimmyJ

2

gzip是带有头部的deflate。而HTTP 1.1中的deflate实际上是zlib（也是对deflate的封装）。 - David Murdoch

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Sam Saffron · Accepted Answer

为什么在Apache服务器中提供文本文件时要使用deflate而不是gzip？简单的答案是不要这样做。

RFC 2616将deflate定义为：

deflate是RFC 1951中描述的"deflate"压缩机制与RFC 1950中定义的"zlib"格式相结合的结果。

RFC 1950中定义了zlib格式：

     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]中所述。该格式是使用Lempel-Ziv编码（LZ77）和32位CRC的。

RFC 1952将压缩数据定义为：

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

CRC-32比ADLER32更慢

与相同长度的循环冗余校验相比，它为速度（而非可靠性）而交换可靠性。

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

现在，底层的TCP数据包已经非常可靠, 所以这里的问题并不是Adler 32与GZIP使用的CRC-32之间的比较。

多年来，许多浏览器实现了一个错误的deflate算法。他们期望压缩有效负载而不是RFC 1950中的zlib头部。同样，各种Web服务器也犯了同样的错误。

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

这样复杂的逻辑结果往往是错误的。Verve Studio有一个用户贡献测试部分，展示了情况有多糟糕。

例如：在Safari 4.0中deflate可以工作，但在Safari 5.1中会出现问题，在IE上也经常出现问题。

所以，最好的做法是完全避免使用deflate，由于adler 32带来的微小速度提升不值得冒损坏有效载荷的风险。