Nginx的gzip指令大有用处
说一段废话
压缩响应数据有什么作用呢？问的好：从用户体验和IT成本两方面回答这个问题：
- 用户体验上
网速一定的情况下，传输5MB数据比传输10MB数据的时间快了一半。所以传输数据越小用户加载页面就越快，当然相比较之下体验会更好。
- IT成本上
对这个场景来说的成本主要是带宽成本, 数据不压缩那么传输这些数据相应的带宽肯定更大，对比之下压缩耗费的CPU资源在带宽费用上不值一提。
所以你有什么理由不用压缩呢？
背景
当然Nginx也提供了gzip的压缩方式可以使用，但是在日常的工作中我发现或多或少在使用上有些问题，有点像：用了但又好像没用的感觉。 这篇就记录一下gzip的使用方式和易错点。
指令介绍
gzip
gzip指令来自 ngx_http_gzip_module 模块，提供的核心能力就是压缩响应数据。
该模块下提供的指令如下：
gzip on; # 开启gzip
gzip_comp_level 6; # 压缩等级：1-9 1:压缩最快/CPU消耗最少/压缩率最低 以次类推
gzip_min_length 1000; # 小于此大小的数据不压缩(单位字节/byte)；数据来源"Content-Length"头
gzip_buffers 32 4k; # 压缩响应的缓冲区数量和大小(4K 内存页大小取决于平台)
gzip_proxied any; # 对代理的请求是否开启压缩
gzip_types text/plain application/xml application/javascript application/x-javascript text/css application/json; # 哪些类型的数据需要被压缩
gzip_disable "MSIE [1-5]\."; # User-Agent 被正则匹配到的不开启压缩
gzip_vary on; # 当gzip对请求生效时会被添加一个响应头 "Vary: Accept-Encoding"
tips:
- gzip 是动态压缩： 每个请求在被响应时都会在gzip逻辑内走一遍
- 压缩等级不是越高越好： 压缩到一定程度后就会吃力不讨好， 从js的测试来看性价比最高的级别是 5或6
- buffer大小设置最好是和平台的内存页保持一致： getconf PAGE_SIZE
- gzip_types不要瞎写： 写压缩率大的(css/js/xml/json/ttf)， image图片就不要写了，压缩空间太小，又耗CPU
gzip_static
gzip_stati指令来自 ngx_http_gzip_static_module模块，提供的核心能力是静态/预压缩
该模块提供的指令如下:
gzip_static on|off|always; # always: 不管客户端是否支持压缩我他妈全部给你压缩之后给你
tips:
- 可以复用gzip_module中以下的指令:
- gzip_http_version, gzip_proxied, gzip_disable, gzip_vary
- gzip_static是静态压缩：意思是你的服务端需要同时存在源文件和使用gzip压缩后的源文件，这时请求的时候会优先吧压缩文件返回，这样就不用再耗费CPU去动态压缩了。(视情况来用，我们没用)
- 可以和gzip一同开启，没啥影响，它的优先级高于gzip
易错点提示
在实际的生产环境中架构都比较负载，不像一个单纯的Nginx一样，我配置好了就万事大吉了。
时常会遇到有些网站明明配置了gzip但是展示上看并没有生效，为什么？
此时需要梳理这个请求流程，看看这个请求都经过了哪些地方，比如 你的请求通过三次代理(CDN-->Nginx-->Nginx)那么在其中一层没有配置或者配置错误那么整体的返回数据就是没有被压缩的， 这种情况出现还是比较多的。
