Nginx调优：gzip的相关设置

问题：

公司项目在开发一项3D全景功能时，需要用到threejs这个框架进行3D渲染，一般3D文件的大小都在40M以上，这次我们渲染的文件在44M左右，下载所花费的时间是80s。

以前的解决办法：

耐心劝说产品经理，这是正常现象，这么大文件肯定要这么多秒，别急啊，又不是加载不出来，你看，这不是加载出来了吗？

现在的解决办法：

文件这么大，是否可以压缩后再传输？这里就引出nginx gzip的概念，gzip分为两种压缩模式：
1、实时压缩，通过消耗cpu来实时压缩文件并返回给浏览器，该方式下响应头中Etag属性会有’W\’的字样，开启方式在nginx.conf中添加gzip on等属性即可。
2、静态文件压缩，这种方式需要提前将文件压缩成.gz文件，nginx在加载文件时会优先使用.gz文件，而不是实时压缩中的自行压缩方式，开启方式在nginx.conf中添加gzip_static on等属性，这里nginx中不自带gzip_static模块，需要编译并添加，此外需要在vue项目打包过程中配置gzip ->bingo成功

具体的详细参数设置详见 vue 项目开启gzip压缩和部署 vue项目开启Gzip压缩和性能优化 - guopengju - 博客园

效果：44Msize的ifc文件被压缩成8M，加载时间从80秒，降为12秒

此外，js、css、json等静态资源文件都得到了加载提升

Respect！

将来的解决办法：

请大家把更好的方法留在评论区！！！

---

衍生proxy_cache缓存

出发点：在做完上面gzip压缩后，大文件的传输问题基本得以解决，于是想进一步提高加载速度，静态资源在首次加载后，会产生memory cache和disk cache两种缓存，但是这类缓存都属于客户端缓存，换句话说，当另外一个用户访问网站时，他也是需要重新再加载一遍，针对此类问题，思考是否可以有服务端缓存，于是有了proxy_cache的想法：
用法很简单，各类博客都有说到：https://blog.csdn.net/qq_3172...
自己觉得重要的点：
1、proxy_cache的设置需要在proxy_pass的前提下，要不然无效
2、add_header Nginx-Cache $upstream_cache_status; 原来响应头中缓存是否中的属性是可以自定义。
3、这种缓存我分为两种情况：
（1）对后端响应的数据做缓存，可以将请求到的结果缓存下来，效果显著，但是弊端是针对实时性要求高的接口做缓存，在现实中不可取，还是得因地制宜吧。
（2）静态资源做缓存（不能直接添加proxy_cache,需要做一层代理转发）：教程 https://www.jb51.net/article/...
效果不明显，但是通过分析别人的CDN资源，都有做缓存，是否真的有用后续再观察。