为什么真实世界的服务器更喜欢使用gzip而不是deflate编码？
我们已经知道deflate编码在编码，解码和压缩速度方面比gzip更胜一筹。
那么为什么没有大的网站（我可以find）发送它（当我使用接受它的浏览器）？
雅虎声称放气是“不太有效”。 为什么？
我维护的HTTP服务器软件，宁愿放气，所以我想知道是否有一些真正的理由不继续这样做。
规范和HTTP之间的命名存在一些混淆：
- RFC 1951定义的DEFLATE是一种压缩数据格式 。
- RFC 1950定义的ZLIB是使用DEFLATE数据格式的压缩数据格式。
- RFC 1952定义的GZIP是使用DEFLATE压缩数据格式的文件格式。
但HTTP使用不同的命名 ：
gzip由RFC 1952 [25]中描述的文件压缩程序“gzip”（GNU zip）产生的编码格式。 这种格式是带有32位CRC的Lempel-Ziv编码（LZ77）。
deflateRFC 1950 [31]中定义的“zlib”格式与RFC 1951 [29]中描述的“deflate”压缩机制相结合。
所以总结一下：
-
gzip是GZIP文件格式。 -
deflate实际上是ZLIB数据格式。 （但是有些客户端也接受deflate的实际DEFLATE数据格式。）
另请参阅此问题上的答案“gzip”和“deflate”HTTP 1.1编码有什么区别？ ：
“gzip”和“deflate”HTTP 1.1编码有什么区别？
“gzip”是gzip格式，“deflate”是zlib格式。 他们应该可能已经调用了第二个“zlib”来避免与原始压缩数据格式混淆。 虽然HTTP 1.1 RFC 2616正确地指向RFC 1950中的“deflate”传输编码中的zlib规范，但是有服务器和浏览器错误地产生或期望RFC 1951中每个deflate规范的原始deflate数据，最明显的是Microsoft 。 因此，尽pipe使用zlib格式的“deflate”传输编码将是更有效的方法（实际上zlib格式devise的是什么），但使用“gzip”传输编码可能更可靠，因为不幸的selectHTTP 1.1作者的名字。
从我的最小testing中，它看起来大部分是HTTPds：
- 不支持即时泄气：Apache的mod_deflate（一个惊喜），GWS
- 或者更喜欢发送gzip：IIS，lighttpd的mod_compress
因此，要发送最stream行的服务器（Apache）的deflate，你必须保持预编码的文件，并使用mod_negotiate（你甚至可能需要使用types映射来selectdeflate）。
我猜，由于这种麻烦，deflate只是很less使用，因此在gzip支持中，客户端deflate支持中可能存在错误。
检查这个网站的更多信息： http : //web.archive.org/web/20120321182910/http : //www.vervestudios.co/projects/compression-tests
每种规格的deflate实际上是zlib （专门为通过networking传输内容而开发的一种压缩格式）……这是一种围绕deflate的封装。
但是，Internet Explorer不正确地将HTTP 1.1放缩（zlib）作为原始缩放。 所以，如果你的服务器发送正确的HTTP 1.1 deflate（zlib）内容到IE它扼杀。
我已经研究了这个话题，看起来很安全，总是发送原始的 deflate到现代的浏览器…只要确保它，其实是原始的，而不是zlib。
查阅这篇文章获取更多信息> Gzip vs Deflate（zlib）重新访问 。
所以我认为有一个很好的理由继续通过gzip发送deflate。
据我所知（声明：我不是这里的专家，正如我所听到的）， gzip使用相同的algorithm作为deflate但它有更多的标题，使其具有更大的尺寸（相对于deflate ） 。 不过，我认为deflate是由更less的客户端和代理支持的。
我想知道同样的事情:)。 我认为这可能是与旧的（可能古老的）浏览器的兼容性。 我读过一些地方，老的浏览器更容易蠕变在某些情况下mod_gzipped（？）的瘪的内容，但谷歌search导致我得出结论，可能是最好的停止使用它。
ActionScript 3具有本机deflate支持，但对于gzip，您需要使用外部库
