【Web优化】Yslow优化法则（四）启用Gzip压缩

Yslow的第4个经验法则指出：启用gzip压缩功能，可以减少HTTP传输的数据和时间，从而减少客户端请求的响应时间。

本篇是Yslow法则的第四个，主要包括三个方面的内容：

1.      什么是gzip

2.      gzip与HTTP

3.      nginx启用gzip

Gzip最早出现在Unix系统中，是GNU的文件压缩工具。我们今天所说的Gzip，并不是特指Linux/Unix中的压缩工具，而是指HTTP中普遍使用的内容编码格式（内容编码，这里指的是内容的压缩）。由于Gzip具有较好的压缩性能, 且几乎所有的主流浏览器都支持Gzip的压缩方式，使得Gzip几乎成为现代web服务器的标配。通过对HTTP响应实体的压缩，Gzip可以：

1.      减少网络传输的时间和数据量，从而降低服务器的流量。

2.      由于降低了传输时间，使得web页面可以更快的渲染。

3.      以上两者，不仅减少了服务器端的压力和成本，而且改善了用户体验。

以本博客http://blog.csdn.net/ohmygirl为例，firebug抓取请求可以看出，csdn站点启用了Gzip的压缩方式：

由于Gzip是需要客户端和服务器共同遵守的编码规则，这意味着，如果客户端不支持Gzip或者服务器端不支持Gzip的压缩方式，一定是不能启用Gzip压缩的，否则便会出现客户端接收到压缩后的内容主体却无法解码的情况。为了避免这种不必要的情况，通常需要编码协商。

1.       Accept-Encoding请求首部。

为了避免服务器使用客户端不支持的编码压缩方式对响应主体进行编码，客户端在发送请求的时候，需要把自己能够支持的内容编码方式列表放在请求的Accept-Encoding首部中发送出去，服务器便可以从中选择一种合适的编码压缩方式。如果HTTP请求中没有包含Accept-Encoding首部，服务器可以假定客户端可以接受任何的编码压缩方式（类似于Accept-Encoding:*）。标准的内容编码压缩方式包括Gzip、compress、deflate、identity等，其中Gzip, compress , deflate都是无损压缩算法，而Gzip通常是压缩效率最高的，也是最普遍支持的压缩算法。同样以本博客为例，下图展示了客户端在请求时发送的Accept-Encoding内容编码协商首部：

图中的请求首部表明，客户端支持的内容编码方式是deflate和Gzip。

2.       Content-Encoding响应首部

与Accept-Encoding请求首部相对应，Content-Encoding响应首部用于表明服务器实际选择的内容编码方式。在上面的例子中，CSDN站点便是使用Gzip的压缩方式。

另外，如果响应首部中同时出现了Content-length头部，这时的Content-length指的是内容编码之后的长度。

3.        内容编码过程。

由以上两点可以看出，启用了Gzip内容编码压缩的过程如下：

a.      客户端请求，其中包含Accept-Encoding首部表明客户端支持的编码方式。

b.      Web服务器生成原始的响应报文，其中包含未编码的Content-Type和Content-length首部。

c.      Gzip编码服务器（通常就是web服务器）创建Gzip压缩后的报文。压缩后的报文有同样的Content-type首部，但是Content-Length首部不同。

d.      客户端接收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段主要控制Nginx服务器的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压缩，Nginx服务器才会对满足条件的响应启用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