Nginx Gzip 压缩使用和详解
网站的性能部分取决于用户浏览器下载的所有文件的大小。减小这些传输文件的大小可以使网站更快。对于那些在按流量计费的连接上支付带宽使用费的人来说,它还可以使网站成本更低。
gzip 是一种流行的数据压缩程序。可以配置 Nginx 用于动态压缩它提供的文件。然后,这些文件在使用时由支持它的浏览器解压缩,没有任何损失,但可以在Web服务器和浏览器之间传输更少的数据量。好消息是,所有主流浏览器都支持
由于压缩的一般工作方式,某些文件压缩得比其他文件更好。例如,文本文件压缩得很好,通常最终会缩小两倍以上。另一方面,JPEG或PNG文件等图像已经按其性质进行了压缩,并且使用二次压缩很少或根本没有结果。另外压缩文件会耗费服务器资源,所以只压缩可以压缩的文件
Nginx实现资源压缩的原理是通过 ngx_http_gzip_module 模块拦截请求,并对需要做 gzip 的类型做 gzip,ngx_http_gzip_module 是Nginx默认集成的,不需要重新编译,直接开启
Gzip 参数
gzip on
这个没的说,打开或关闭gzip
Syntax: gzip on | off;
Default:
gzip off;
Context: http, server, location, if in locationgzip_buffers
设置用于处理请求压缩的缓冲区数量和大小。比如32 4K表示按照内存页(one memory page)大小以4K为单位(即一个系统中内存页为4K),申请32倍的内存空间。建议此项不设置,使用默认值。
Syntax: gzip_buffers number size;
Default:
gzip_buffers 32 4k|16 8k;
Context: http, server, locationgzip_comp_level
设置gzip压缩级别,级别越底压缩速度越快文件压缩比越小,反之速度越慢文件压缩比越大
Syntax: gzip_comp_level level;
Default:
gzip_comp_level 1;
Context: http, server, location我们以一个大小为92.6K的脚本文件为例,如下所示。其中最后三个数值分别表示压缩比、包大小、平均处理时间(使用ab压测,100用户并发下 )以及CPU消耗。
$ ab -n 10000 -c 100 -H 'Accept-Encoding: gzip' https://example.com/assets/js/web/app.js从这我们可以得出结论:
- 随着压缩级别的升高,压缩比有所提高,但到了级别6后,很难再提高;
- 随着压缩级别的升高,处理时间明显变慢;
- gzip很消耗cpu的性能,高并发情况下cpu达到100%;
因此,建议:
- 不是压缩级别越高越好,其实gzip_comp_level 1的压缩能力已经够用了,后面级别越高,压缩的比例其实增长不大,反而很吃处理性能。
- 压缩一定要和静态资源缓存相结合,缓存压缩后的版本,否则每次都压缩高负载下服务器肯定吃不住。
gzip_disable
通过表达式,表明哪些UA头不使用gzip压缩
Syntax: gzip_disable regex ...;
Default: —
Context: http, server, location
This directive appeared in version 0.6.23.gzip_min_length
当返回内容大于此值时才会使用gzip进行压缩,以K为单位,当值为0时,所有页面都进行压缩。
Syntax: gzip_min_length length;
Default:
gzip_min_length 20;
Context: http, server, locationgzip_http_version
用于识别 http 协议的版本,早期的浏览器不支持 gzip 压缩,用户会看到乱码,所以为了支持前期版本加了此选项。默认在 http/1.0 的协议下不开启 gzip 压缩。
Syntax: gzip_http_version 1.0 | 1.1;
Default:
gzip_http_version 1.1;
Context: http, server, location因为浏览器基本上都支持HTTP/1.1。然而这里面却存在着一个很容易掉入的坑,也是笔者从生产环境中一个诡异问题中发现的:
明明开启gzip功能,但是未生效。
原因定位:
为什么这样呢?在应用服务器前,公司还有一层Nginx的集群作为七层负载均衡,在这一层上,是没有开启gzip的。
如果我们使用了proxy_pass进行反向代理,那么 nginx 和后端的 upstream server 之间默认是用HTTP/1.0协议通信的。如果我们的 Cache Server 也是 nginx ,而前端的 nginx 没有开启gzip。
同时,我们后端的 nginx 上没有设置 gzip_http_version 为1.0,那么 Cache 的 url 将不会进行 gzip 压缩。我相信,以后还有人会入坑,比如你用 Apache ab 做压测,如果不是设置 gzip_http_version为 1.0,你也压不出gzip的效果(同样的道理)。希望写在这里对大家有帮助

gzip_proxied
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_modified
启用压缩,如果header中包含”Last_Modified”头信息,启用压缩
no_etag
启用压缩,如果header中包含“ETag”头信息,启用压缩
auth
启用压缩,如果header中包含“Authorization”头信息,启用压缩
any
无条件压缩所有结果数据
Syntax: gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ...;
Default:
gzip_proxied off;
Context: http, server, locationgzip_vary
增加响应头”Vary: Accept-Encoding”
Syntax: gzip_vary on | off;
Default:
gzip_vary off;
Context: http, server, locationgzip_types
设置需要压缩的MIME类型,如果不在设置类型范围内的请求不进行压缩
Syntax: gzip_types mime-type ...;
Default:
gzip_types text/html;
Context: http, server, location所以MIME-TYPE中应该新增字体类型:
| 字体类型扩展名 | Content-type |
| .eot | application/vnd.ms-fontobject |
| .ttf | font/ttf |
| .otf | font/opentype |
| .woff | font/x-woff |
| .svg | image/svg+xml |
配置
测试是否参与压缩
支持 gzip header 的测试
$ curl -H "Accept-Encoding: gzip" -I https://wulicode.com/demo/html/link/favicon.html
HTTP/1.1 200 OK
Server: nginx/1.22.0
Date: Tue, 30 Aug 2022 02:22:45 GMT
Content-Type: text/html
Connection: keep-alive
Last-Modified: Wed, 23 Mar 2022 16:24:34 GMT
ETag: W/"623b49c2-18b"
Content-Encoding: gzip这样可以看到内容已经被 gzip 过了对于图片类型的是无法进行压缩的
$ curl -H "Accept-Encoding: gzip" -I https://wulicode.com/demo/html/link/assets/icon/favicon.png转发服务器验证源服务器的设置
如果我们在转发服务器上验证源服务器上的配置, 需要 curl 额外的参数来进行验证
指定域名解析的访问, 这里使用 --resolve
$ curl -v --resolve example.com:443:121.4.4.4 -I https://example.com/jquery.js
* Added example.com:443:121.4.4.4 to DNS cache
* About to connect() to example.com port 443 (#0)
* Trying 121.4.4.4...
* Connected to example.com (121.4.4.4) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=example.com
* start date: 2月 07 00:00:00 2022 GMT
* expire date: 2月 08 23:59:59 2023 GMT
* common name: kejinshou.com
* issuer: CN=Encryption Everywhere DV TLS CA - G1,OU=www.digicert.com,O=DigiCert Inc,C=US
> HEAD /jquery.js HTTP/1.1
> User-Agent: curl/7.29.0
> Host: kejinshou.com
> Accept: */*这里将IP 临时加入域名的 dns 缓存, 从而在对下一步访问进行解析
指定主机头+ IP 的访问
$ curl -H 'Accept-encoding:gzip' \
-H 'Host:example.com' \
-I http://121.4.4.4/jquery.jsNginx 配置
对于 gzip 我们可以在服务器进行如下配置, 最简约的配置
http {
# ...
gzip on;
gzip_types
application/atom+xml
application/geo+json
application/javascript
application/x-javascript
application/json
application/ld+json
application/manifest+json
application/rdf+xml
application/rss+xml
application/xhtml+xml
application/xml
font/eot
font/otf
font/ttf
image/svg+xml
text/css
text/javascript
text/plain
text/xml;
# ...
}