为什么真实世界的服务器更喜欢使用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)。

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

所以总结一下:

  • gzipGZIP文件格式。
  • 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:

  1. 不支持即时泄气:Apache的mod_deflate(一个惊喜),GWS
  2. 或者更喜欢发送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,您需要使用外部库