gzip, deflate, br
gzip, deflate, br
的客户端使用,否则需再次回源gzip, br
,虽然这个 header 声明支持 br,但与缓存的gzip, deflate, br
并不相同,仍会回源proxy_set_header Accept-Encoding "";
覆盖客户端 accept encoding,使回源时后端返回未压缩文件;配置 proxy_ignore_headers Vary;
忽略 vary headerbrotli on; gzip on; gzip_vary on;
启用 nginx 端压缩(缺点是不支持 br,因为 nginx 目前没有类似 gunzip 的解压 br 的模块?)
proxy_set_header Accept-Encoding "gzip";
覆盖客户端 accept encoding,使回源时后端返回 gzip 压缩文件;配置 proxy_ignore_headers Vary;
忽略 vary headergzip off; brotli off; gzip_vary off;
, 配置 gunzip on;
按需解压。写的不是很清晰,因为是刚刚搞出来的,但是应该可以解决一些朋友的疑问,如果有问题还可以继续发在下面。
1
isCyan OP 以上仅仅是这台 nginx 服务器作为最边缘的直接接触客户的情况。
如果前面还有各种 cdn 或者其他反代的话,也要考虑 cdn 的行为。 |
2
isCyan OP 各大 cdn 厂商应该都是沿用 nginx 默认配置因为
不论是动态资源还是静态资源都能通用, 也不会带来灾难性的后果 无非是缓存命中率低一些而已 目前想到的一个较好的解决办法是 为 cdn 回源单独设置一个域名 为这个域名的访问关闭所有压缩 来提高缓存命中率 |
3
dandycheung 2019-02-22 13:45:12 +08:00 via Android
很有意义的测试和总结。
|
4
Lax 2019-02-22 14:07:32 +08:00
方案 1 是个正常的方案,在这种有命中率的情况下,回源流量多一些仅仅是个很次要的问题。
|