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