为什么对Apache提供的文本文件使用deflate而不是gzip？
Ken*_*Ken 208 compression apache lamp gzip deflate
这两种方法为LAMP服务器提供的html,css和javascript文件提供了哪些优势.还有更好的选择吗？
服务器使用Json向地图应用程序提供信息,因此大量的小文件.
Sam*_*ron 310
为什么对Apache提供的文本文件使用deflate而不是gzip？
简单的答案是不.
RFC 2616将deflate定义为:
deflate RFC 1950中定义的"zlib"格式与RFC 1951中描述的"deflate"压缩机制相结合
zlib格式在RFC 1950中定义为:
0 1
+---+---+
|CMF|FLG| (more-->)
+---+---+
0 1 2 3
+---+---+---+---+
| DICTID | (more-->)
+---+---+---+---+
+=====================+---+---+---+---+
|...compressed data...| ADLER32 |
+=====================+---+---+---+---+
所以,一些标头和一个ADLER32校验和
RFC 2616将gzip定义为:
gzip由RFC 1952 [25]中描述的文件压缩程序"gzip"(GNU zip)生成的编码格式.该格式是具有32位CRC的Lempel-Ziv编码(LZ77).
RFC 1952将压缩数据定义为:
目前的格式使用DEFLATE压缩方法,但可以很容易地扩展为使用其他压缩方法.
CRC-32 比ADLER32慢
与相同长度的循环冗余校验相比,它交换速度的可靠性(优选后者).
所以...我们有2个压缩机制,使用相同的压缩算法,但头和校验和的算法不同.
现在,底层TCP数据包已经非常可靠,因此这里的问题不是GZIP使用的Adler 32与CRC-32.
多年来,许多浏览器都实现了不正确的deflate算法.而不是期望RFC 1950中的zlib头,他们只是期望压缩的有效载荷.同样,各种Web服务器也犯了同样的错误.
因此,多年来浏览器开始实现模糊逻辑 deflate实现,他们尝试zlib头和adler校验和,如果失败,他们尝试有效负载.
具有复杂逻辑的结果是它经常被打破.Verve Studio有一个用户贡献的测试部分,显示情况有多糟糕.
例如:deflate适用于Safari 4.0,但在Safari 5.1中已经破解,它在IE上也总是存在问题.
因此,最好的办法是完全避免放气,小速度提升(由于adler 32)不值得破坏有效载荷的风险.
- 另一个非常小的区别是 zlib 包装器为 6 个字节，而 gzip 为 18 个字节。因此，对于非常小的数据包，少发送 12 个字节可能会有优势。然而，结论并没有改变，那就是，由于微软误解了他们在 IIS 服务器上提供的内容中“deflate”的含义，从而为大家搞砸了，因此使用 gzip 格式会更容易。 (2认同)
Jef*_*ood 170
GZip只是deflate加上校验和和页眉/页脚.但是,当我学到很多困难时,收缩速度会更快.
- 好吧,这个答案结果证明是错误的...请参阅:http://zoompf.com/blog/2012/02/lose-the-wait-http-compression ...特别是客户有两种方式可以"解释"deflate,headerless/checksumless和zlib标头.跨浏览器实现正确的deflate是不好的.应该避免放气. (39认同)
- 更不用说zlib不支持扩展,即使它确实如此,SSE 4.2中的CRC32指令使用多项式1EDC6F41,而gzip格式使用多项式EDB88320 - 完全不同的算法,有效. (12认同)
- 由于deflate更快,为什么SO使用gzip？ (7认同)
- @JeffAtwood但问题不是更快？ (6认同)
- @sam另外我只是重新运行基准测试,在现代的英特尔芯片上,我得到gzip 1441/692并放弃1286/531.第二个数字是解压缩,首先是压缩.所以deflate*仍然更快,你的基准测试显示不然吗？(我同意它可能因其他原因没用,但答案*是正确的*,deflate更快..) (4认同)
- @Ken您的问题是:`LAMP服务器提供的文件有什么优势？`.对于那些成功吸引大量请求的人来说,**性能是服务器端*的*问题之一.所以杰夫的表现比较 - 他的答案的要点 - 是恰当的.巧合的是,Sam的评论根本没有解决.我猜他只是在批评`GZip只是deflate加上校验和和页眉/页脚`介绍,这可能在技术上是错误的. (3认同)