为什么真实世界的服务器更喜欢gzip而不是deflate编码？

Question

我们已经知道deflate编码在编码,解码和压缩大小方面比gzip更胜一筹.

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

雅虎称,收缩率"不太有效".为什么？

我维护的HTTP服务器软件更喜欢放气,所以我想知道是否有一些非常好的理由不继续这样做.

Answer 1

关于规范和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"压缩机制相结合.

总结一下:

• gzip是GZIP文件格式.
• deflate实际上是ZLIB数据格式.(但是有些客户端也接受实际的DEFLATE数据格式deflate.)

另请参阅关于问题的答案"gzip"和"deflate"HTTP 1.1编码之间的区别是什么？:

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

"gzip"是gzip格式,"deflate"是zlib格式.他们应该调用第二个"zlib"来避免与原始deflate压缩数据格式混淆.虽然HTTP 1.1 RFC 2616正确地指向RFC 1950中用于"deflate"传输编码的zlib规范,但是有报告称服务器和浏览器根据RFC 1951中的deflate规范错误地生成或期望原始deflate数据,最明显的是Microsoft .因此,即使使用zlib格式的"deflate"传输编码将是更有效的方法(事实上正是zlib格式的设计),使用"gzip"传输编码可能更可靠,因为不幸的选择HTTP 1.1作者的名称.

Answer 2

从我的最小测试看,大多数HTTPds出现:

1. 不支持即时通信:Apache的mod_deflate(一个惊喜),GWS
2. 或者更喜欢发送gzip:IIS,lighttpd的mod_compress

因此,要在最流行的服务器(Apache)上发送deflate,您必须维护预编码文件并使用mod_negotiate(您甚至可能必须使用类型映射来更喜欢deflate).

我猜,由于这个麻烦,deflate很少被使用,因此客户端deflate支持中存在的bug 比gzip支持更可能存在.

Answer 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)内容,它就会窒息.

我已经对这个主题进行了一些研究,并且总是将原始 deflate 发送到现代浏览器看起来很安全......只是确保它实际上是原始的而不是zlib.

查看本文以获取更多信息> 重新访问Gzip vs Deflate(zlib).

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

Answer 4

据我所知(免责声明:我不是这里的专家,正是我所听到的),gzip使用相同的算法,deflate但它有更多的标题,使其具有更大的尺寸(相对于deflate).但是,我认为deflate较少的客户端和代理支持.