Nginx gzip參數詳解及常見問題(已解決)

一、Nginx gzip功能

Nginx實現資源壓縮的原理是經過ngx_http_gzip_module模塊攔截請求,並對須要作gzip的類型作gzip,ngx_http_gzip_module是Nginx默認集成的,不須要從新編譯,直接開啓便可html

 

二、參數詳解

gzip on

這個沒的說,打開或關閉gzip前端

Syntax: gzip on | off;
Default:    
gzip off;
Context:    http, server, location, if in location

 

 

gzip_buffers

設置用於處理請求壓縮的緩衝區數量和大小。好比32 4K表示按照內存頁(one memory page)大小以4K爲單位(即一個系統中內存頁爲4K),申請32倍的內存空間。建議此項不設置,使用默認值。jquery

Syntax: gzip_buffers number size;
Default:    
gzip_buffers 32 4k|16 8k;
Context:    http, server, location

gzip_comp_level

設置gzip壓縮級別,級別越底壓縮速度越快文件壓縮比越小,反之速度越慢文件壓縮比越大nginx

Syntax: gzip_comp_level level;
Default:    
gzip_comp_level 1;
Context:    http, server, location

咱們以一個大小爲92.6K的腳本文件爲例,以下所示。其中最後三個數值分別表示壓縮比、包大小、平均處理時間(使用ab壓測,100用戶併發下, ./ab -n 10000 -c 100 -H 'Accept-Encoding: gzip' http://10.27.180.75/jquery.js )以及CPU消耗。後端

從這咱們能夠得出結論:瀏覽器

  • 隨着壓縮級別的升高,壓縮比有所提升,但到了級別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, location

gzip_http_version

用於識別http協議的版本,早期的瀏覽器不支持gzip壓縮,用戶會看到亂碼,因此爲了支持前期版本加了此選項。默認在http/1.0的協議下不開啓gzip壓縮。app

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, location

gzip_vary

增長響應頭」Vary: Accept-Encoding」

Syntax: gzip_vary on | off;
Default:    
gzip_vary off;
Context:    http, server, location

gzip_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
相關文章
相關標籤/搜索