高性能web网站优化原则4——利用gzip压缩组件

从HTTP/1.1开始，web客户端在http请求头Accept-Encoding里支持压缩技术
   Accept-Encoding:gzip, deflate, sdch  
   如果服务器看到这个请求，就可以用客户端给定列表里面的压缩方法压缩响应数据，web服务器使用响应头Content-Encoding来通知客户端Content-Encoding: gzip。Gzip是目前最流行和最有效的压缩方法，由GNU开发然后标准化为RFC 1952。其他压缩方式有deflate等，但主流浏览器大部分都支持gzip，但有的不支持deflate，所以gzip是压缩方法的首选。
   问题来了，我们改压缩哪些组件呢？
   服务器会基于文件类型来选择gzip的压缩对象，大部分的网站压缩html文档，css，js文件，或者xml、json格式的返回结果。图片和pdf格式的文件一般不会压缩，因为它们已经被压缩了。尝试压缩这些文件不仅浪费cpu资源，反而有可能会增加压缩文件的大小。
   gzip是有代价的，在服务器端进行压缩要付出额外的cpu资源，同样的在客户端解压也需要消耗cpu资源。权衡利弊要综合考虑响应的大小，带宽以及客户端和服务器之间的距离等因素。一般来说gzip可以降低响应大小的约70%左右，还是挺可观的。
  
   apache服务器端配置
   可以参考http://jingyan.baidu.com/article/359911f555f77857fe030603.html和http://www.jb51.net/article/38350.htm里面的描述，Apache 2.x 以上的服务器一般使用mod_deflate
  
   代理缓存问题
   当浏览器通过代理向服务器发送请求时，情况稍有复杂。假如第一次浏览器请求的时候不支持gzip，由于是第一次通过代理请求，cache是空的，代理转发请求到服务器，服务器做出无压缩的响应，那么这个无压缩的响应就会被代理缓存起来。那如果浏览器同样的url再次发送请求，代理会返回cache中的无压缩响应。反过来，如果第一次请求是支持压缩的，第二次请求是不支持压缩的，那么代理只返回压缩版本的响应而不管请求是压缩的还是无压缩的。
   解决方法是服务器返回的时候加一个响应头：Vary: Accept-Encoding。服务器告诉代理要基于客户端的请求来改变缓存的响应。这就会导致代理缓存多个版本的响应，像前面的例子，代理会缓存无压缩的响应和压缩的响应，随着客户端Accept-Encoding的不同而给出不同的响应。