【Web优化】Yslow优化法则(四)启用Gzip压缩
Yslow的第4个经验法则指出:启用gzip压缩功能,能够降低HTTP传输的数据和时间,从而降低client请求的响应时间。
本篇是Yslow法则的第四个,主要包含三个方面的内容:
1. 什么是gzip
2. gzip与HTTP
3. nginx启用gzip
什么是gzip?
Gzip最早出如今Unix系统中,是GNU的文件压缩工具。我们今天所说的Gzip,并非特指Linux/Unix中的压缩工具,而是指HTTP中普遍使用的内容编码格式(内容编码,这里指的是内容的压缩)。因为Gzip具有较好的压缩性能, 且差点儿全部的主流浏览器都支持Gzip的压缩方式,使得Gzip差点儿成为现代webserver的标配。通过对HTTP响应实体的压缩,Gzip能够:
1. 降低网络传输的时间和数据量,从而降低server的流量。
2. 因为减少了传输时间,使得web页面能够更快的渲染。
3. 以上两者,不仅降低了server端的压力和成本,并且改善了用户体验。
以本博客http://blog.csdn.net/ohmygirl为例,firebug抓取请求能够看出,csdn网站启用了Gzip的压缩方式:
Gzip与HTTP
因为Gzip是须要client和server共同遵守的编码规则,这意味着,假设client不支持Gzip或者server端不支持Gzip的压缩方式,一定是不能启用Gzip压缩的,否则便会出现client接收到压缩后的内容主体却无法解码的情况。为了避免这样的不必要的情况,通常须要编码协商。
1. Accept-Encoding请求首部。
为了避免server使用client不支持的编码压缩方式对响应主体进行编码,client在发送请求的时候,须要把自己能够支持的内容编码方式列表放在请求的Accept-Encoding首部中发送出去,server便能够从中选择一种合适的编码压缩方式。假设HTTP请求中没有包括Accept-Encoding首部,server能够假定client能够接受不论什么的编码压缩方式(类似于Accept-Encoding:*)。标准的内容编码压缩方式包括Gzip、compress、deflate、identity等,当中Gzip, compress , deflate都是无损压缩算法,而Gzip一般是压缩效率最高的,也是最普遍支持的压缩算法。相同以本博客为例,下图展示了client在请求时发送的Accept-Encoding内容编码协商首部:
图中的请求首部表明,client支持的内容编码方式是deflate和Gzip。
2. Content-Encoding响应首部
与Accept-Encoding请求首部相相应,Content-Encoding响应首部用于表明server实际选择的内容编码方式。在上面的样例中,CSDN网站便是使用Gzip的压缩方式。
另外,假设响应首部中同一时候出现了Content-length头部,这时的Content-length指的是内容编码之后的长度。
3. 内容编码过程。
由以上两点能够看出,启用了Gzip内容编码压缩的步骤例如以下:
a. client请求,当中包括Accept-Encoding首部表明client支持的编码方式。
b. Webserver生成原始的响应报文,当中包括未编码的Content-Type和Content-length首部。
c. Gzip编码server(通常就是webserver)创建Gzip压缩后的报文。压缩后的报文有相同的Content-type首部,可是Content-Length首部不同。
d. client接收Gzip编码后的报文,採用相同的算法解码,获取原始的报文。
整个步骤例如以下图所看到的:
Nginx启用Gzip
眼下比較经常使用的HTTP server包含Apache, IIS和Nginx本文以Nginx的配置为例,说明怎样在web服务器中启用Gzip压缩。关于Apache和IIS的启用方式,能够參考百度百科中提供的方法:链接接地址是:
http://baike.baidu.com/link?url=2S3tFqPdyGQ_loxtfIqfrhD0Yq1G8pvhTBuG9EZS_iohE_0Dpe1sFOm6W6LMqOPu#3这里不再赘述。
Nginx.Conf配置文件里,http段主要控制Nginxserver的HTTP相关配置。配置示比例如以下:
gzip on; gzip_disable "MSIE [1-6]\."; gzip_min_length 1000; gzip_buffers 4 8k; gzip_comp_level 9; gzip_types text/plain text/css application/jsonapplication/x-javascript; gzip_http_version 1.0;
对配置的各项的解释:
1. Gzip on 开启Nginx的Gzip压缩。显然,仅仅有开启了Gzip压缩,Nginxserver才会对满足条件的响应启用Gzip压缩(废话!)。
2. gzip_disable "MSIE[1-6]\." 因为IE6及下面版本号对Gzip的支持不够完好,且可能造成浏览器的假死,因而通常禁用IE6下面的Gzip压缩功能。
3. gzip_min_length 1000; 启用Gzip压缩的最小响应主体大小,单位是B, 这里是1KB. 假设你启用了Gzip却发现有的响应并没有Content-encoding: gzip首部,不要着急,非常可能是文档本身比較小,没有压缩的必要(毕竟Gzip压缩和解压缩也是须要时间的)。
4. gzip buffers 4 8k。指定缓存区的大小和数量。一个缓存区的大小通常为分页的大小。关于gzip buffers的很多其它知识,会在更深入的学习之后补充。
5. gzip_comp_level 9; 指定Gzip压缩的等级,数值1-9。数值越大,压缩率越大,对应的须要的压缩处理时间也较长。应该依据实际的情况设置适当的压缩等级,太小压缩比低,太大则处理时间较长。
6. gzip_types 指定启用Gzip压缩的MIME类型。默认情况下,text/html的响应类型一定会被压缩的。
7. gzip_http_version 1.0。仅仅有HTTP/1.0的请求,才会启用Gzip压缩,而HTTP/1.1的请求会被过滤。
So. Gzip功能是配置好了,检查一下是否生效:有两种基本方式:
1. 抓包工具,如firebug或者fiddler。发送的请求头中含有Accept-Encoding且响应中有Content-Encoding:gzip的首部。
2. Curl命令行。Curl –I –H“Accept-Encoding:gzip;” “http://xxxxx”
-I參数让curl的返回结果仅仅包括响应头部。相同,假设有Content-Encoding:gzip头部。那么你的配置就成功了。
效果如何呢?
以一个js(大小为17KB)为例,经过Gzip压缩之后的响应大小为4.4KB,也就是压缩率= 4.4/17 * 100% = 25.8%. 这已经大大降低了网络传输的流量。
參考文献:
1. http://www.open-open.com/lib/view/open1339292864521.html
2. http://www.veryhuo.com/a/view/51706.html
3. http://www.cnblogs.com/zfying/archive/2012/07/07/2580876.html
4. http://www.ithov.com/linux/109584.shtml