为什么对 Apache 提供的文本文件使用 deflate 而不是 gzip？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/388595/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why use deflate instead of gzip for text files served by Apache?
提问by Ken
What advantages do either method offer for html, css and javascript files served by a LAMP server. Are there better alternatives?
对于 LAMP 服务器提供的 html、css 和 javascript 文件，这两种方法都有什么优势。有更好的选择吗？
The server provides information to a map application using Json, so a high volume of small files.
服务器使用 Json 向地图应用程序提供信息，因此会产生大量小文件。
See also Is there any performance hit involved in choosing gzip over deflate for http compression?
回答by Sam Saffron
Why use deflate instead of gzip for text files served by Apache?
为什么对 Apache 提供的文本文件使用 deflate 而不是 gzip？
The simple answer is don't.
简单的答案是不要。
RFC 2616defines deflate as:
RFC 2616将 deflate 定义为：
deflate The "zlib" format defined in RFC 1950 in combination with the "deflate" compression mechanism described in RFC 1951
deflate RFC 1950 中定义的“zlib”格式与 RFC 1951 中描述的“deflate”压缩机制相结合
The zlib format is defined in RFC 1950as :
zlib 格式在RFC 1950 中定义为：
0 1
+---+---+
|CMF|FLG| (more-->)
+---+---+
0 1 2 3
+---+---+---+---+
| DICTID | (more-->)
+---+---+---+---+
+=====================+---+---+---+---+
|...compressed data...| ADLER32 |
+=====================+---+---+---+---+
So, a few headers and an ADLER32 checksum
因此，一些标头和 ADLER32 校验和
RFC 2616 defines gzip as:
RFC 2616 将 gzip 定义为：
gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
gzip 由文件压缩程序“gzip”（GNU zip）生成的编码格式，如 RFC 1952 [25] 中所述。此格式是具有 32 位 CRC 的 Lempel-Ziv 编码 (LZ77)。
RFC 1952defines the compressed data as:
RFC 1952将压缩数据定义为：
The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods.
该格式目前使用 DEFLATE 压缩方法，但可以轻松扩展以使用其他压缩方法。
CRC-32 is slower than ADLER32
CRC-32比 ADLER32 慢
Compared to a cyclic redundancy check of the same length, it trades reliability for speed (preferring the latter).
与相同长度的循环冗余校验相比，它以可靠性换取速度（更喜欢后者）。
So ... we have 2 compression mechanisms that use the samealgorithm for compression, but a differentalgorithm for headers and checksum.
所以……我们有 2 种压缩机制，它们使用相同的压缩算法，但对标头和校验和使用不同的算法。
Now, the underlying TCP packets are already pretty reliable, so the issue here is not Adler 32 vs CRC-32that GZIP uses.
现在，底层 TCP 数据包已经非常可靠，所以这里的问题不是GZIP 使用的Adler 32 与CRC-32。
Turns out many browsers over the years implemented an incorrect deflate algorithm. Instead of expecting the zlib header in RFC 1950 they simply expected the compressed payload. Similarly various web servers made the same mistake.
事实证明，多年来许多浏览器实施了不正确的放气算法。他们没有期待 RFC 1950 中的 zlib 标头，他们只是期待压缩的有效负载。同样，各种网络服务器也犯了同样的错误。
So, over the years browsers started implementing a fuzzy logicdeflate implementation, they try for zlib header and adler checksum, if that fails they try for payload.
因此，多年来浏览器开始实施模糊逻辑deflate 实现，他们尝试 zlib 标头和 adler 校验和，如果失败，他们尝试有效载荷。
The result of having complex logic like that is that it is often broken. Verve Studio have a user contributed testsection that show how bad the situation is.
拥有这样复杂的逻辑的结果是它经常被破坏。Verve Studio 有一个用户贡献的测试部分，显示情况有多糟糕。
For example: deflate works in Safari 4.0 but is broken in Safari 5.1, it also always has issues on IE.
例如：deflate 在 Safari 4.0 中有效，但在 Safari 5.1 中被破坏，它在 IE 上也总是有问题。
So, best thing to do is avoid deflate altogether, the minor speed boost (due to adler 32) is not worth the risk of broken payloads.
因此，最好的办法是完全避免放气，轻微的速度提升（由于阿德勒 32）不值得冒有效载荷损坏的风险。
回答by Jeff Atwood
GZip is simply deflate plus a checksum and header/footer. Deflate is faster, though, as I learned the hard way.
GZip 只是 deflate 加上校验和和页眉/页脚。放气速度较快，虽然，因为我学到了艰辛的道路。
回答by Amblyopius
You are likely not able to actually pick deflate as an option. Contrary to what you may expect mod_deflateis not using deflate but gzip. So while most of the points made are valid it likely is not relevant for most.
您可能无法实际选择放气作为选项。与您可能期望的相反，mod_deflate不是使用 deflate，而是使用 gzip。因此，尽管提出的大多数观点都是有效的，但对大多数人来说可能并不相关。
回答by schnaader
I think there's no big difference between deflate and gzip, because gzip basically is just a header wrapped around deflate (see RFCs 1951 and 1952).
我认为 deflate 和 gzip 之间没有太大区别，因为 gzip 基本上只是一个包裹在 deflate 的标头（参见 RFC 1951 和 1952）。
回答by Joachim Sauer
The main reason is that deflate is faster to encode than gzip and on a busy server that might make a difference. With static pages it's a different question, since they can easily be pre-compressed once.
主要原因是 deflate 比 gzip 编码更快，并且在繁忙的服务器上可能会有所作为。对于静态页面，这是一个不同的问题，因为它们可以轻松地预压缩一次。
回答by Dave R.
mod_deflate requires fewer resources on your server, although you may pay a small penalty in terms of the amount of compression.
mod_deflate 在您的服务器上需要更少的资源，尽管您可能会在压缩量方面付出一些代价。
If you are serving many small files, I'd recommend benchmarking and load testing your compressed and uncompressed solutions - you may find some cases where enabling compression will not result in savings.
如果您提供许多小文件，我建议您对压缩和未压缩的解决方案进行基准测试和负载测试 - 您可能会发现在某些情况下启用压缩不会节省成本。
回答by Steven
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.
用于解压的 gzip 和 deflate 应该没有任何区别。Gzip 只是压缩了几十个字节的标头，包括校验和。校验和是压缩较慢的原因。但是，当您预压缩数以万计的文件时，您希望将这些校验和作为文件系统中的完整性检查。此外，您可以利用命令行工具获取文件的统计信息。对于我们的网站，我们预压缩了大量静态数据（整个开放目录、13,000 个游戏、数百万个关键字的自动完成等），我们的排名比 Alexa 的所有网站快 95%。 传真搜索. 但是，我们确实使用了本土专有的网络服务器。Apache/mod_deflate 只是没有削减它。当这些文件被压缩到文件系统中时，不仅文件系统块大小最小，而且文件系统中管理文件的所有不必要的开销，网络服务器可能不太关心。您关心的应该是总磁盘占用空间和访问/解压缩时间，其次是能够预压缩这些数据的速度。占用空间很重要，因为即使磁盘空间很便宜，您也希望尽可能多地放入缓存。
回答by aidan
On Ubuntu with Apache2 and the deflate module already installed (which it is by default), you can enable deflategzip compression in two easy steps:
在带有 Apache2 和已经安装了 deflate 模块（默认情况下）的 Ubuntu 上，您可以通过两个简单的步骤启用deflategzip 压缩：
a2enmod deflate
/etc/init.d/apache2 force-reload
And you're away! I found pages I served over my adsl connection loaded much faster.
你走了！我发现我通过 adsl 连接提供的页面加载速度要快得多。
Edit:As per @GertvandenBerg's comment, this enables gzip compression, not deflate.
编辑：根据@GertvandenBerg 的评论，这将启用 gzip 压缩，而不是 deflate。
回答by JimmyJ
if I remember correctly
如果我没记错的话
- gzip will compress a little more than deflate
- deflate is more efficient
- gzip 会比 deflate 压缩更多一点
- 放气更有效
