为啥现实世界的服务器更喜欢 gzip 而不是 deflate 编码？

Posted 2023-02-25

【中文标题】为啥现实世界的服务器更喜欢 gzip 而不是 deflate 编码？

【英文标题】：Why do real-world servers prefer gzip over deflate encoding?为什么现实世界的服务器更喜欢 gzip 而不是 deflate 编码？

【发布时间】：2010-10-27 09:33:17

【问题描述】：

我们已经知道deflate encoding is a winner 在编码速度、解码速度和压缩大小方面优于 gzip。

那么为什么没有大型网站（我能找到）发送它（当我使用接受它的浏览器时）？

Yahoo claims deflate “效果较差”。为什么？

我维护的 HTTP 服务器软件更喜欢放气，所以我想知道是否有充分的理由不继续这样做。

【参考方案1】：

规范和HTTP之间的命名有些混淆：

RFC 1951 定义的 DEFLATE 是一种

压缩数据格式

。 RFC 1950 定义的 ZLIB 是一种

压缩数据格式

，它使用 DEFLATE 数据格式。 RFC 1952 定义的 GZIP 是一种使用 DEFLATE 压缩数据格式的

文件格式

。

但是HTTP uses a different naming:

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

deflate RFC 1950 [31] 中定义的“zlib”格式与 RFC 1951 [29] 中描述的“deflate”压缩机制相结合。

总结一下：

gzip 是 GZIP 文件格式。 deflate其实就是ZLIB数据格式。 （但有些客户端也接受 deflate 的实际 DEFLATE 数据格式。）

另见this answer on the question What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?：

“gzip”和“deflate”HTTP 1.1 编码有什么区别？

“gzip”是gzip格式，“deflate”是zlib格式。他们可能应该将第二个称为“zlib”，以避免与原始 deflate 压缩数据格式混淆。虽然 HTTP 1.1 RFC 2616 正确地指向 RFC 1950 中的 zlib 规范以进行“deflate”传输编码，但有报告称服务器和浏览器根据 RFC 1951 中的 deflate 规范错误地生成或期望原始 deflate 数据，最值得注意的是 Microsoft .因此，即使使用 zlib 格式的“deflate”传输编码将是更有效的方法（实际上正是 zlib 格式的设计目的），但由于不幸的选择，使用“gzip”传输编码可能更可靠HTTP 1.1 作者的名字。

【参考方案2】：

从我的最小测试看来，大多数 HTTPds 要么：

不支持动态放气：Apache 的 mod_deflate（一个惊喜），GWS 或者更喜欢发送 gzip：IIS，lighttpd 的 mod_compress

因此，要在最流行的服务器 (Apache) 上发送 deflate，您必须维护预编码文件并使用 mod_negotiate（您甚至可能必须使用类型映射来选择 deflate）。

我猜，由于这种麻烦，deflate 很少使用，因此客户端 deflate 支持中比 gzip 支持中更有可能存在错误。

【参考方案3】：

查看此网站了解更多信息： http://web.archive.org/web/20120321182910/http://www.vervestudios.co/projects/compression-tests

---

根据规范，Deflate 实际上是 zlib（一种专门为在网络上流式传输内容而开发的压缩格式）...它是 deflate 的包装。

但是，Internet Explorer 错误地将 HTTP 1.1 deflate (zlib) 实现为原始 deflate。因此，如果您的服务器向 IE 发送正确的 HTTP 1.1 deflate (zlib) 内容，它就会阻塞。

我已经对该主题进行了一些研究，看起来总是将 raw deflate 发送到现代浏览器是安全的...只要确保它实际上是 raw而不是 zlib。

查看本文了解更多信息 > Gzip vs Deflate (zlib) revisited。

所以我认为有充分的理由继续通过 gzip 发送 deflate。

【讨论】：

另请参阅您的 SO 线程中提到的 Zoompf 的文章zoompf.com/blog/2012/02/lose-the-wait-http-compression，其中提到了（原始）Deflate 的问题。

我现在的推荐是 gzip，因为自 2010 年以来，许多浏览器都放弃了对原始 deflate 的支持。

【参考方案4】：

据我所知（免责声明：我不是这里的专家，只是我听说的），gzip 使用与deflate 相同的算法，但它有更多的标题内容，使其具有更大的尺寸（相对于deflate）。但是，我认为 deflate 受到较少客户端和代理的支持。

【讨论】：

这也符合我的认知。差异不应大于几十个字节...

@ephemient：是的，从大小的角度来看，应该没有太大区别，但似乎这些字节是需要生成和检查时钟周期的校验和，这使得 gzip 比 deflate 慢也是。

截至 6 月 8 日，接受它的机器人数量减少了：computec.ch/projekte/browserrecon/… 我认识的一些：Apache Lucene Nutch、Google Search Appliance Crawler（不是 Googlebot）、某些版本的 Yahoo!啜饮（截至 6 月 8 日）。但是任何不支持 deflate 的代理/客户端都不会在 Accept-Encoding 中列出它，因此在选择时更喜欢发送 deflate 应该不会造成任何伤害。我可能会在 Apache 开发人员列表中提到它。

Mehrdad 是正确的。但是我们没有人需要依赖我们所听到的。规格很小且可用。 ietf.org/rfc/rfc1952.txt 您可以亲眼看到 GZIP 只是带有头字节的 DEFLATE。好吧，不完全正确。在元数据（“headers”）中，GZIP 允许规范不同的压缩方法，但在规范中只定义了一个值：用于 DEFLATE。对于大小，GZIP 标头至少为 10 个字节。此外还有文件名、注释和 CRC16 等可选部分，这些在实践中几乎从未用于流式场景。

【参考方案5】：

我想知道同样的事情:)。我认为这可能与旧版（可能是古老的）浏览器的兼容性有关。我在某处读到，旧版浏览器更有可能在某些情况下使用 mod_gzip 压缩的压缩内容（？），但谷歌搜索这让我得出结论，最好停止谷歌搜索。

【参考方案6】：

ActionScript 3 具有原生 deflate 支持，但对于 gzip，您需要使用外部库