这两种方法为LAMP服务器提供的html,css和javascript文件提供了哪些优势.还有更好的选择吗?
服务器使用Json向地图应用程序提供信息,因此大量的小文件.
另请参阅为压缩选择gzip over deflate是否有任何性能损失?
为什么对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)不值得破坏有效载荷的风险.
GZip只是deflate加上校验和和页眉/页脚.但是,当我学到很多困难时,收缩速度会更快.
您可能无法选择deflate作为选项.与你可能期望的相反mod_deflate不使用deflate而是使用gzip.因此,尽管所提出的大多数观点都是有效的,但它可能与大多数观点无关.