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