本文目录：
- 1、Nginx开启和配置Gzip压缩
- 2、Nginx服务器中的Gzip配置参数详解
- 3、前端性能优化之Gzip
- 4、前端打包gzip + nginx开启静态gzip
- 5、vue 开启gzip ,nginx 配置gzip
- 6、nginx前端常用配置
Nginx开启和配置Gzip压缩
nginx 是一个高性能的 Web 服务器，合理配置nginx可以有效提高网站的响应速度。
本文介绍 nginx 的 gzip 和缓存开启配置。
gzip的压缩页面需要浏览器和服务器双方都支持，实际上就是服务器端压缩，传到浏览器后浏览器解压并解析。
Nginx的压缩输出有一组gzip压缩指令来实现。
相关指令位于 http{…} 两个大括号之间。
pre Liberation Mono", "Courier New", monospace; font-size: 14px; margin-top: 0px; margin-bottom: 1rem; overflow: auto; display: block; color: rgb(33, 37, 41); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"# 开启gzip
gzip on;
gzip_min_length 1k;
gzip_comp_level 6;
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
gzip_vary on;
gzip_disable "MSIE [1-6].";/pre
关于具体的参数说明可以参考 nginx 的文档 。
pre Liberation Mono", "Courier New", monospace; font-size: 14px; margin-top: 0px; margin-bottom: 1rem; overflow: auto; display: block; color: rgb(33, 37, 41); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"location ~* ^.+.(ico|gif|jpg|jpeg|png)$ {
access_log off;
expires 30d;
}
location ~* ^.+.(css|js|txt|xml|swf|wav)$ {
access_log off;
expires 24h;
}
location ~* ^.+.(html|htm)$ {
expires 1h;
}/pre
其中的缓存时间可以自己根据需要修改。
Nginx服务器中的Gzip配置参数详解
gzip on; 开启gzip off关闭
gzip_min_length 1k; 设置允许压缩的页面最小字节(从header头的Content-Length中获取) 建议大于1k
gzip_buffers 4 16k; 以16k为单位,按照原始数据大小以16k为单位的4倍申请内存
gzip_http_version 1.1; 识别http协议的版本,早起浏览器可能不支持gzip自解压,用户会看到乱码
gzip_comp_level 2; 等级1-9 最小的压缩最快 但是消耗cpu
gzip_types text/plain application/x-javascript text/css application/xml; 匹配压缩类型
gzip_vary on; 启用应答头"Vary: Accept-Encoding"
gzip_proxied off;
nginx做为反向代理时启用,off(关闭所有代理结果的数据的压缩),expired(启用压缩,如果header头中包括"Expires"头信息),no-cache(启用压缩,header头中包含"Cache-Control:no-cache"),no-store(启用压缩,header头中包含"Cache-Control:no-store"),private(启用压缩,header头中包含"Cache-Control:private"),no_last_modefied(启用压缩,header头中不包含"Last-Modified"),no_etag(启用压缩,如果header头中不包含"Etag"头信息),auth(启用压缩,如果header头中包含"Authorization"头信息)
gzip_disable msie6;
(IE5.5和IE6 SP1使用msie6参数来禁止gzip压缩 )指定哪些不需要gzip压缩的浏览器(将和User-Agents进行匹配),依赖于PCRE库
gzip 决定是否开启gzip模块
gzip_buffers 设置gzip申请内存的大小,其作用是按块大小的倍数申请内存空间,param2:int(k) 后面单位是k
gzip_comp_level 设置gzip压缩等级，等级越底压缩速度越快文件压缩比越小，反之速度越慢文件压缩比越大
gzip_min_length 当返回内容大于此值时才会使用gzip进行压缩,以K为单位,当值为0时，所有页面都进行压缩
gzip_types 设置需要压缩的MIME类型,非设置值不进行压缩
param:text/html|application/x-javascript|text/css|application/xml
对于多数以文本为主的站点来说，文本自身内容占流量的绝大部分。虽然单个文本体积并不算大，但是如果数量众多的话，流量还是相当可观。启用GZIP以后，可以大幅度减少所需的流量。
前端性能优化之Gzip
由于我们团队的前端项目越来越庞大，加之Vue的SPA首屏加载特性，导致系统第一次加载速度越来越缓慢，可能达到几十秒的程度，所以为了优化用户性能体验，我们选择了开启Gzip进行文件压缩，确实达到了显著的效果。
Gzip原本用户UNIX系统的文件压缩，后来逐渐成为Internet最主流的数据压缩格式。
当用户访问我们的web站点时，服务器就将我们的网页文件进行压缩，将压缩后的文件传输到客户端，对于纯文本文件我们可以至少压缩到原大小的40%，这样大大提高了传输效率，页面便可更快的加载出来。
由于目前我们项目是使用ngxin来部署前端的，nginx自带 HttpGzip模块 ， 所以我们直接对 nginx.conf 文件的http配置项进行配置即可。但相对的由于nginx自身处理请求然后压缩返回，会消耗对应的服务器内存。
测试效果
我们应尽可能减少对服务端内存的使用，毕竟服务端的资源是十分宝贵的，这里我们仍然使用nginx进行前端部署，我们在客户端替nginx处理压缩文件这一步操作，nginx便可直接使用我们压缩好的文件，下面是一个基于vue-cli配置的前端项目。
这里最好安装低版本，防止报错。
这里可以根据大家不同的配置，总之就是将webpack插件进行注册。
成功运行后，便可以在打包文件中看到.gz结尾的文件了，将打包后的文件上传到指定的nginx文件夹下。
这里需要nginx对应的插件 http_gzip_static_module ，之前我是通过yum安装的nginx，这里似乎不可以，需要手动安装。这里目录可以根据大家个人情况而定。
安装nginx
修改nginx.conf
启动nginx服务
这里我们虽然服务端js文件夹里只有.gz格式的文件（其他的文件已删除），但客户端却成功读取了。
无论是服务端与客户端进行gzip的压缩，我们都大大缩小了文件体积，给用户带来了更好的体验。
服务端处理gzip优点是只需配置一下即可，无需复杂操作，但缺点是会消耗服务器内存。
客户端处理gzip优点是无需服务器进行文件压缩，减少服务器内存消耗，但配置起来相比服务端gzip会稍加繁琐。
Nginx中文文档
什么是GZIP,有什么优势,如何开启GZIP?
vue-cli4 开发项目中开启gzip压缩，优化打包体积，提升加载速度
Nginx gzip static静态压缩
配置nginx直接使用webpack生成的gz压缩文件，而不用nginx自己压缩
前端打包gzip + nginx开启静态gzip
服务端动态gzip是常见的方案，即服务端判断浏览器http请求头中的Accept-Encodin是否有gzip，有的话就说明浏览器支持gzip服务器就实时压缩生成gzip返回给浏览器，否则就返回原文件。但是这种模式是比较消耗服务器CPU的，如果前端打包的时候就压缩好，把原文件和gzip文件全丢到服务器上，服务器不干压缩的活，只区分浏览器是不是支持gzip，支持就返gzip文件，不支持就返原文件，那就能省去服务器动态压缩的环节。
PS：因为Linux系统下nginx不能向磁盘写文件，所以服务端只能实时生成。
PS：服务器数量少的条件，就不要用nginx动态压缩了。
不同的前端框架配置gzip的方式不一样，这里不多说，网上方法非常多。这里我用的VUE，可以参考下：
1、前端文件部署到服务器后，在nginx.config的目标应用location下配置 gzip_static;
gzip_static on;
gzip_http_version 1.1;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\.";
gzip_vary on ;`
说明nginx的编译参数缺失，需要添加--with-http_gzip_static_module参数，然后重新编译：
3、验证静态gzip是否生效：
vue 开启gzip ,nginx 配置gzip
1 在vue.config.js 里面引入'compression-webpack-plugin'
3、打包npm run build 后目标文件里出现 gz 压缩文件即成功
访问 网站，出现一下标志，证明nginx 配置成功
nginx前端常用配置
nginx现在几乎是众多大型网站的必用技术，大多数情况下，我们不需要亲自去配置它，但是了解它在应用程序中所担任的角色，以及如何解决这些问题是非常必要的。
下面我将从nginx在企业中的真实应用来解释nginx在应用程序中起到的作用。
为了便于理解，首先先来了解一下一些基础知识， nginx是一个高性能的反向代理服务器 那么什么是反向代理呢？
代理 是在服务器和客户端之间假设的一层服务器， 代理 将接收客户端的请求并将它转发给服务器，然后将服务端的响应转发给客户端。
不管是正向代理还是反向代理，实现的都是上面的功能。
正向代理 是为我们服务的，即为客户端服务的，客户端可以根据正向代理访问到它本身无法访问到的服务器资源。
正向代理 对我们是透明的，对服务端是非透明的，即服务端并不知道自己收到的是来自代理的访问还是来自真实客户端的访问。
反向代理 是为服务端服务的，反向代理可以帮助服务器接收来自客户端的请求，帮助服务器做请求转发，负载均衡等。
反向代理 对服务端是透明的，对我们是非透明的，即我们并不知道自己访问的是代理服务器，而服务器知道反向代理在为他服务。
下面是一个nginx配置文件的基本结构：
下面是 nginx 一些配置中常用的内置全局变量，你可以在配置的任何位置使用它们。
| 变量名 | 功能 | | ------ | ------ | | $host | 请求信息中的 Host ，如果请求中没有 Host 行，则等于设置的服务器名 | | $request_method | 客户端请求类型，如 GET 、 POST | $remote_addr | 客户端的 IP 地址 | | $args | 请求中的参数 | | $content_length | 请求头中的 Content-length 字段 | | $http_user_agent | 客户端agent信息 | | $http_cookie | 客户端cookie信息 | | $remote_addr | 客户端的IP地址 | | $remote_port | 客户端的端口 | | $server_protocol | 请求使用的协议，如 HTTP/1.0 、·HTTP/1.1 | | server_name | 服务器名称| | $server_port`|服务器的端口号|
先追本溯源以下，跨域究竟是怎么回事。
同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。通常不允许不同源间的读操作。
如果两个页面的协议，端口（如果有指定）和域名都相同，则两个页面具有相同的源。
例如：
现在我在 fe.server.com 对 dev.server.com 发起请求一定会出现跨域。
现在我们只需要启动一个nginx服务器，将 server_name 设置为 fe.server.com ,然后设置相应的location以拦截前端需要跨域的请求，最后将请求代理回 dev.server.com 。如下面的配置：
这样可以完美绕过浏览器的同源策略： fe.server.com 访问 nginx 的 fe.server.com 属于同源访问，而 nginx 对服务端转发的请求不会触发浏览器的同源策略。
根据状态码过滤
根据URL名称过滤，精准匹配URL，不匹配的URL全部重定向到主页。
根据请求类型过滤。
GZIP 是规定的三种标准HTTP压缩格式之一。目前绝大多数的网站都在使用 GZIP 传输 HTML 、 CSS 、 JavaScript 等资源文件。
对于文本文件， GZip 的效果非常明显，开启后传输所需流量大约会降至 1/4 ~ 1/3 。
并不是每个浏览器都支持 gzip 的，如何知道客户端是否支持 gzip 呢，请求头中的 Accept-Encoding 来标识对压缩的支持。
启用 gzip 同时需要客户端和服务端的支持，如果客户端支持 gzip 的解析，那么只要服务端能够返回 gzip 的文件就可以启用 gzip 了,我们可以通过 nginx 的配置来让服务端支持 gzip 。下面的 respone 中 content-encoding:gzip ，指服务端开启了 gzip 的压缩方式。
这里为什么默认版本不是 1.0 呢？
HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性。
启用持久连接情况下，服务器发出响应后让 TCP 连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。
为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。
HTTP/1.1 默认支持 TCP 持久连接， HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置，而在 HTTP/1.0 中，这种机制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。
nginx 同样有着配置 chunked的 属性 chunked_transfer_encoding ，这个属性是默认开启的。
Nginx 在启用了 GZip 的情况下，不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显著提高 TTFB ( Time To First Byte ，首字节时间，WEB 性能优化重要指标)。这样唯一的问题是， Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。
所以，在 HTTP1.0 中如果利用 Nginx 启用了 GZip ，是无法获得 Content-Length 的，这导致HTTP1.0中开启持久链接和使用 GZip 只能二选一，所以在这里 gzip_http_version 默认设置为 1.1 。
如上面的图，前面是众多的服务窗口，下面有很多用户需要服务，我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口，来达到资源的充分利用以及更少的排队时间。
把前面的服务窗口想像成我们的后端服务器，而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器，以达到服务端资源的充分利用和更少的请求时间。
Upstream指定后端服务器地址列表
在server中拦截响应请求，并将请求转发到Upstream中配置的服务器列表。
上面的配置只是指定了nginx需要转发的服务端列表，并没有指定分配策略。
轮询策略
默认情况下采用的策略，将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。
最小连接数策略
将请求优先分配给压力较小的服务器，它可以平衡每个队列的长度，并避免向压力大的服务器添加更多的请求。
最快响应时间策略
依赖于NGINX Plus，优先分配给响应时间最短的服务器。
客户端ip绑定
来自同一个ip的请求永远只分配一台服务器，有效解决了动态网页存在的session共享问题。
匹配以 png|gif|jpg|jpeg 为结尾的请求，并将请求转发到本地路径， root 中指定的路径即nginx本地路径。同时也可以进行一些缓存的设置。
nginx的功能非常强大，还有很多需要探索，上面的一些配置都是公司配置的真实应用（精简过了），如果您有什么意见或者建议，欢迎在下方留言...
【nginx配置gzip】的内容来源于互联网，如引用不当，请联系我们修改。
网友留言：