为什么对 Apache 提供的文本文件使用 deflate 而不是 gzip？
对于由 LAMP 服务器提供服务的 html、css 和 javascript 文件，这两种方法都有哪些优势。 有更好的选择吗？
服务器使用 Json 向地图应用程序提供信息，因此会产生大量小文件。
What advantages do either method offer for html, css and javascript files served by a LAMP server. Are there better alternatives?
The server provides information to a map application using Json, so a high volume of small files.
See also Is there any performance hit involved in choosing gzip over deflate for http compression?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
简单的答案是不要。
RFC 2616 将 deflate 定义为：
zlib 格式在 RFC 1950 为：
因此，一些标头和 ADLER32 校验和
RFC 2616 将 gzip 定义为：
RFC 1952 将压缩数据定义为：
CRC-32 比 ADLER32 慢
所以...我们有两种压缩机制，它们使用相同算法进行压缩，但使用不同算法进行标头和校验和。
现在，底层 TCP 数据包已经相当可靠，因此这里的问题不是 Adler 32与 GZIP 使用的 CRC-32 相比。
事实证明，多年来许多浏览器都实现了不正确的放气算法。 他们没有期待 RFC 1950 中的 zlib 标头，而是只期待压缩的有效负载。 同样，各种网络服务器也犯了同样的错误。
因此，多年来浏览器开始实现模糊逻辑 deflate 实现，它们尝试 zlib header 和 adler 校验和，如果失败，它们会尝试有效负载。
像这样复杂的逻辑的结果是它经常被破坏。 Verve Studio 有一个用户贡献的测试 部分显示情况有多糟糕。
例如：deflate 在 Safari 4.0 中工作，但在 Safari 5.1 中被破坏，它在 IE 上也总是有问题。
因此，最好的办法是完全避免放气，轻微的速度提升（由于 Adler 32）不值得冒损坏有效载荷的风险。
The simple answer is don't.
RFC 2616 defines deflate as:
The zlib format is defined in RFC 1950 as :
So, a few headers and an ADLER32 checksum
RFC 2616 defines gzip as:
RFC 1952 defines the compressed data as:
CRC-32 is slower than ADLER32
So ... we have 2 compression mechanisms that use the same algorithm for compression, but a different algorithm for headers and checksum.
Now, the underlying TCP packets are already pretty reliable, so the issue here is not Adler 32 vs CRC-32 that GZIP uses.
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.
So, over the years browsers started implementing a fuzzy logic deflate implementation, they try for zlib header and adler checksum, if that fails they try for payload.
The result of having complex logic like that is that it is often broken. Verve Studio have a user contributed test section that show how bad the situation is.
For example: deflate works in Safari 4.0 but is broken in Safari 5.1, it also always has issues on 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.
GZip 只是紧缩加上校验和和页眉/页脚。 不过，放气更快，如我经历了惨痛的教训。
（来源：typepad.com）
GZip is simply deflate plus a checksum and header/footer. Deflate is faster, though, as I learned the hard way.
(source: typepad.com)
您可能无法真正选择放气作为选项。 与您可能期望的相反，mod_deflate 没有使用 deflate，而是使用 gzip。 因此，虽然大多数观点都是有效的，但对大多数人来说可能并不相关。
You are likely not able to actually pick deflate as an option. Contrary to what you may expect mod_deflate is not using deflate but gzip. So while most of the points made are valid it likely is not relevant for most.
主要原因是 deflate 的编码速度比 gzip 更快，并且在繁忙的服务器上可能会有所不同。 对于静态页面，这是一个不同的问题，因为它们可以轻松地预压缩一次。
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 之间没有太大区别，因为 gzip 基本上只是包裹在 deflate 周围的标头（参见 RFC 1951 和 1952）。
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).
mod_deflate 在服务器上需要更少的资源，尽管您可能会在压缩量方面付出一些代价。
如果您要提供许多小文件，我建议您对压缩和未压缩的解决方案进行基准测试和负载测试 - 您可能会发现在某些情况下启用压缩不会节省成本。
mod_deflate requires fewer resources on your server, although you may pay a small penalty in terms of the amount of compression.
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.
gzip 和 gzip 应该没有任何区别 放气以减压。 Gzip 只是压缩，周围包裹着几十个字节的标头，包括校验和。 校验和是压缩速度较慢的原因。 但是，当您预压缩无数文件时，您希望将这些校验和作为文件系统中的健全性检查。 此外，您可以利用命令行工具来获取文件的统计信息。 对于我们的网站，我们预压缩了大量静态数据（整个开放目录、13,000 个游戏、数百万个关键字的自动完成等），并且我们的 Alexa 排名比所有网站快 95%。 传真搜索。 然而，我们确实使用了自制的专有网络服务器。 Apache/mod_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.
在已安装 Apache2 且已安装 deflate 模块（默认情况下）的 Ubuntu 上，您可以通过两个简单的步骤启用
deflategzip 压缩：然后就可以了！ 我发现通过 adsl 连接提供的页面加载速度要快得多。
编辑：根据 @GertvandenBerg 的评论，这将启用 gzip 压缩，而不是 deflate。
On Ubuntu with Apache2 and the deflate module already installed (which it is by default), you can enable
deflategzip compression in two easy steps:And you're away! I found pages I served over my adsl connection loaded much faster.
Edit: As per @GertvandenBerg's comment, this enables gzip compression, not deflate.
如果我没记错的话
if I remember correctly