今天准备写汤圆网的app后台接口时，观摩了一下api.huaban.com的返回。发现人家的http响应头中有个值：
Content-Encoding:”gzip”
看起来略屌对不对，我才知道原来http响应可以在先服务器端进行gzip压缩，然后传输，最后由浏览器自动解压！这样既能加速传输效率、又降低带宽占用。对于我这种带宽渣渣的小个体户，简直就是天降福音。
（sorry，以上都是废话）
nginx关于gzip压缩模块的官方配置文档：http://nginx.org/en/docs/http/ngx_http_gzip_module.html
1. 打开nginx的配置文件 nginx.conf
2. 在http花括号里可以看到gzip功能被注释掉了：
#gzip on;
3. 取消注释，开启gzip压缩，并添加如下配置：
gzip on; gzip_comp_level 3; gzip_min_length 1024; gzip_types text/plain text/css text/xml text/javascript application/javascript application/x-javascript application/json; gzip_disable "MSIE [4-6]\."; gzip_vary on;
gzip_comp_level:
gzip压缩等级，从1～9可选，数值越大压缩比率越高，也越耗cpu。（3我是随便选的。我也没做过比较）
gzip_min_length:
一个阈值，字节为单位，Content-Length小于该值的http响应就不压缩。（比如说有一个css文件大小只有989B，那么就会直接传输，而不进行压缩）
由于该阈值是对比Content-Length字段，而只有对于静态文件（比如css、js），nginx才能知道Content-Length，才有的比较。动态生成的页面是无法预知Content-Length的，所以照样会被压缩。
gzip_type:
需要进行gzip压缩的MIME类型，text/html类型是默认都要压缩的所以没必要再写。需要压缩的主要是纯文本，如css、js、json。图像则不需要进行压缩，因为jpg、gif、png这些图像格式本身就是压缩格式的。再用gzip压缩一来压缩不了多少质量，二是反而拖慢速度。当然，我没做过试验哈哈，我就是看其他网站也都没有对图像进行gzip压缩的。
gzip_disable:
正则表达式，匹配请求头的User-Agent字段，匹配到的则不进行gzip。主要用来排除那些不支持gzip解压的古董浏览器。
gzip_vary:
on的话，则会在响应头中加上一项 Vary: Accept-Encoding。该字段的作用是明确告知缓存服务器（如果有的话）按照客户端Accept-Encoding字段的内容（即客户端是否支持gzip解压），分别给其传输对应的压缩或未压缩的内容。
另外还有其他几个配置，使用nginx默认的就好了。
?