闲聊gzip压缩

序言

人总是把一些话挂嘴上，例如时间挤挤总是会有的，如果挤不出来，那说明那件事的优先级不高，也没有那么重要，如果重要，挤挤总是有的。

原来总说时间碎片，现在有了各种APP，时间碎片没有了，想忙里偷闲，找个无聊的感觉，好像也挺难的，手机依赖症。

gzip压缩

1 为什么需要压缩

当好看的视频，网页在浏览器中穿梭的时候，如果内容都很大，那么将是一件耗费时间的事情，看各种高清视频，高清图片，都需要成本，节省成本是需要压缩的首要原因，曾几何时，因为在nginx中未开启压缩功能，导致流量费成本的增加。

当一个大文件在网络上传输的时候，带宽总是有限的，别听吹牛逼什么5G网络，总是有上限的，毕竟大部分的网络都是共享的，共享的就会导致带宽超限，超限的结果就是随机丢包，从而导致访问速度或者传输速度大大降低，而压缩后的文件，如果压缩比很高，既节省了带宽，也让传输的时间减少。

当你关注成本的时候，如果从开启过度到未开启，那么成本的变化你会关注到；当你关注一个请求的rt的时候，那么如果未开启压缩，你会发现rt的增高。

2 gzip产生的问题

gzip有各种各样的配置选项，在官网上的配置如下：

Q1：经常碰到的第一个问题是有人反馈，我这个请求怎么没压缩呢，怎么没有gzip的header头呀？

A1：首先检查文件的大小，在gzip的配置中，有个gzip_min_lenth的配置，表示压缩的最小大小，如果少于，那么就不会压缩；然后检查文件的类型，有个gzip_type的配置，如果不在这个类型里面，也不会进行压缩。

Q2：有人会问，我使用curl命令进行模拟请求一个接口的时候，为什么没有压缩呢？

A2：当使用curl命令进行请求的时候，必须在curl命令里面使用accept-encoding的header头，默认情况下curl是不会进行压缩的。

查看一个请求的时候，一般就看几个header就好了：

3 在哪里压缩

在进行压缩的时候，其实很多的地方可以进行压缩。

可以在业务服务的地方，直接压缩，顺便节省小内网的带宽，损耗的也是服务器端的cpu。

在服务端压缩有一个坏处，就是如果代码写的不好，就很麻烦，特别是在链路很长的时候。在原来有个场景中，都说开始要使用br的压缩算法了，毕竟压缩比更高，从而兴冲冲的服务端上线了这个功能，但是在进行请求的时候，有的时候压缩了，有的时候没压缩，这个时候的排查简直是痛苦，在每一个环节中，都需要用curl命令进行验证，并且将对应的文件保存下来，然后使用file命令，查看这个文件是gzip压缩，还是br压缩，首先看服务端，发现请求十几次都是br压缩，然后在前端nginx进行curl，发现有概率出现不是br压缩，从而是nginx的配置文件，最后发现主要的问题是nginx没有添加br模块导致。但是，最后解决问题的方式是下线br算法，因为业务主要关注性能，此时把nginx的h2协议开启，发现已经满足了需求。

可以在nginx的地方进行统一压缩，配置一下gzip压缩指令，需要注意的是，有可能会重复压缩，特别是当后端进行压缩了之后，然后nginx又配置了gzip_proxied any，那么就是指无论情况下都会进行压缩。

那么你会说，既然这个会导致重复压缩，那么就不配置这个指令呗，但是还有一种场景，当使用公有云的lb的时候，可能后端会挂nginx，那么特别是使用gcp的lb的时候，他们会加上一个特殊的头部Via：1.1 google，而这个头部将会导致nginx的gzip模块失效，而且加上这个头部还无法去掉，从而必须开启gzip_proxied配置，但是，其实也有另外的解法，那就是当nginx收到这个请求的时候，直接将这个头部去掉。

在cdn可以压缩，在公有云lb也可以压缩，在nginx各种中间件也可以压缩，在服务端也可以压缩，随便你选，反正你考虑的要么是性能，要么是成本。。当然，玩也可以。在使用不同的压缩算法的时候，注意关注客户端支持哪些压缩算法，不能一概而论；在使用压缩的时候，其实是要增加rt的时候，增加cpu消耗的，增加内存使用的，所以一旦开启，都是需要关注这些的。

风言风语

很多东西可能不是规矩，而是陋习，不可为之。

在很多极端的场景中，其实大部分的理论都不合适，虽然现在的AI已经成了得力助手，但是如果极端，如果这个东西的资料很少，AI就开始胡扯了，有的时候也要有分辨的能力，有的甚至要自己动手去测试一下。AI越来越强了，都能分析数据包了，取代人类，指日可待。

压缩不压缩，是要和客户端协商的，如果客户端不接受，那么压缩了也没用。。。