我们已经知道deflate 编码在编码速度、解码速度和压缩大小方面胜过 gzip。
那么为什么没有大型网站(我能找到)发送它(当我使用接受它的浏览器时)?
雅虎声称通货紧缩“效果较差”。为什么?
我维护喜欢放气的 HTTP 服务器软件,所以我想知道是否有一些非常好的理由不继续这样做。
我们已经知道deflate 编码在编码速度、解码速度和压缩大小方面胜过 gzip。
那么为什么没有大型网站(我能找到)发送它(当我使用接受它的浏览器时)?
雅虎声称通货紧缩“效果较差”。为什么?
我维护喜欢放气的 HTTP 服务器软件,所以我想知道是否有一些非常好的理由不继续这样做。
规范和 HTTP 之间的命名存在一些混淆:
但是HTTP 使用不同的命名:
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
。)另请参阅关于“gzip”和“deflate”HTTP 1.1 编码有什么区别?:
“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 作者的名字。
从我的最小测试来看,大多数 HTTPd 都是:
因此,要在最流行的服务器 (Apache) 上发送 deflate,您必须维护预编码文件并使用 mod_negotiate(您甚至可能必须使用类型映射来选择 deflate)。
我猜,由于这种麻烦,deflate 很少使用,因此客户端 deflate 支持中比 gzip 支持中更可能存在错误。
查看此网站以获取更多信息: 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) revisited。
所以我认为有充分的理由继续通过 gzip 发送 deflate。
据我所知(免责声明:我不是这里的专家,只是我听说的),gzip
使用相同的算法,deflate
但它有更多的标题内容,使其具有更大的大小(相对于deflate
)。但是,我认为deflate
受到较少客户和代理的支持。
我想知道同样的事情:)。我认为这可能与旧版(可能是古老的)浏览器的兼容性有关。我在某处读到,旧版浏览器更有可能在某些情况下使用 mod_gzip 压缩的压缩内容(?),但谷歌搜索这让我得出结论,最好停止搜索它。
ActionScript 3 具有原生 deflate 支持,但对于 gzip,您需要使用外部库