nginx 开启--with-http_gunzip_module 模块是否有坑

[firebroo]

目前需求需要优化前后端 nginx 之间传输的流量，压缩数据节约小水管带宽，所以准备开启全流量压缩，大概流程就是前端 nginx 会 set 一个 header 到后端 nginx，proxy_set_header Accept-Encoding "gzip"; 让后端 nginx 开启压缩，前端 nginx 再使用这个模块解压数据返回给不支持解压 gzip 的客户端

网上搜了下，这个模块没有看到被大量投入使用的场景，所以上到线上环境，有点担心 gunzip 解压带给前端 nginx 的内存和 CPU 压力会有多高，内心慌的一匹。。有把这个模块线上实战的老铁吗？

[gstqc]

大规模用过，没问题

[AnnanDou]

应该就是吃内存和 cpu 的问题吧

[lhx2008]

gzip 很常见吧，阿里云腾讯云的 cdn 的 nginx 都有开 gzip，而且大部分网站也有开 gzip，比起后端的资源占用，nginx 这里真的不值得一提
另外，现在开始流行 br 算法了

[firebroo]

@gstqc 好的，老哥

[isCyan]

@lhx2008 他说的是服务端解压 gzip 不是压缩

[firebroo]

@lhx2008 br 我知道，但是没找到 nginx 的解压模块。

[jimrok]

还可以研究一下 http_gzip_static_module 模块

[liuxu]

baidu:
Content-Encoding: gzip

google:
content-encoding: br

[305835227fadf]

前后端 nginx 之间的链路真的这么紧张吗？这种做法有点骚啊。前端 nginx 还要判断用户端是否支持 gzip，鸡肋。

[gstqc]

@305835227fadf 回源强制 gzip
发现客户端不支持 gzip 并且源站返回 gzip 内容就解压

本来前端 nginx 就必须判断客户端是否支持 gzip

[305835227fadf]

CDN 回源强制 gzip?这个苛刻点了吧，一般场景没这样干的吧？如果用户浏览器访问不支持压缩，那 CDN 的缓存就没意义了，或者 CDN 有 2 种缓存，压缩和非压缩的。

[gstqc]

@305835227fadf 可以只缓存一份压缩的，客户端不支持压缩再解压

[305835227fadf]

这就需要在 CDN 的缓存服务器写逻辑配置了吧？还有贵司也太精打细算了吧。。我是觉得是否有必要这么做，虽然技术上可行。

[firebroo]

@liuxu 我上面说了 nginx 没找到 br 算法解压模块，大佬你给写 nginx 的 br 解压模块吗

[firebroo]

@305835227fadf 做法是有点极端，但是我的现实环境就是这样。。CND 不清楚，但是我测试 nginx 本身就实现了你说的逻辑，发现客户端不支持解压才会去解压。

[liuxu]

@firebroo

google 出的，你为什么不找 google

https://github.com/google/ngx_brotli

[mytry]

用 nginx lua 写个监控 CPU 和内存的程序吧，根据当前负载动态调整要不要压缩，以及压缩比都可以调整~

[firebroo]

@liuxu 我擦，你是一直看东西只看一半吗。。

[ryd994]

解压的开销一般小于压缩的开销

[ladypxy]

没必要用这个模块啊，你的需求其实在前端开始 nginx cache 就可以减少很多前后端的压力了。还有这楼里很多人分不清 gzip 和 gunzip 模块的区别……