nginx中如何設置gzip（總結）

nginx中如何設置gzip（總結）

1、總結

一句話總結：

真正用的時候，花一小點時間把gzip的各個字段的意思都看一下，會節約大量時間

直接gzip on：在nginx的配置中就能夠開啓gzip壓縮

server{
    gzip on;
    gzip_buffers 32 4K;
    gzip_comp_level 6;
    gzip_min_length 100;
    gzip_types application/javascript text/css text/xml;
    gzip_disable "MSIE [1-6]\."; #配置禁用gzip條件，支持正則。此處表示ie6及如下不啓用gzip（由於ie低版本不支持）
    gzip_vary on;
}

 

 

一、nginx中開啓gzip實例？

|||-begin

server{
    gzip on;
    gzip_buffers 32 4K;
    gzip_comp_level 6;
    gzip_min_length 100;
    gzip_types application/javascript text/css text/xml;
    gzip_disable "MSIE [1-6]\."; #配置禁用gzip條件，支持正則。此處表示ie6及如下不啓用gzip（由於ie低版本不支持）
    gzip_vary on;
}

|||-end

直接gzip on：在nginx的配置中就能夠開啓gzip壓縮

 

 

二、什麼樣的資源不適合開啓gzip壓縮？

二進制資源：例如圖片/mp3這樣的二進制文件,沒必要壓縮；由於壓縮率比較小, 好比100->80字節,並且壓縮也是耗費CPU資源的.

 

三、nginx中gzip模塊須要額外安裝麼（看清楚模塊名）？

不須要：ngx_http_gzip_module是Nginx默認集成的，不須要從新編譯，直接開啓便可

 

四、如何解決：公司的靜態資源服務器所有使用的Nginx，且都開啓了gzip壓縮。內部測試是徹底正常的，然而一到外網，竟然沒有作gzip！ ？

緣由：作負載均衡的機器上面沒開gzip：在應用服務器前，公司還有一層Nginx的集羣做爲七層負責均衡，在這一層上，是沒有開啓gzip的。

還須要設置gzip_http_version爲1.0：nginx和後端的upstream server之間默認是用HTTP/1.0協議通訊的

在應用服務器前，公司還有一層Nginx的集羣做爲七層負責均衡，在這一層上，是沒有開啓gzip的。
若是咱們使用了proxy_pass進行反向代理，那麼nginx和後端的upstream server之間默認是用HTTP/1.0協議通訊的。
若是咱們的Cache Server也是nginx，而前端的nginx沒有開啓gzip。
同時，咱們後端的nginx上沒有設置gzip_http_version爲1.0，那麼Cache的url將不會進行gzip壓縮。

 

 

 

2、Nginx優化之gzip壓縮提高網站速度

轉自或參考：Nginx優化之gzip壓縮提高網站速度
https://blog.csdn.net/php12345679/article/details/80843939

gzip配置的經常使用參數

gzip on|off; #是否開啓gzip

gzip_buffers 32 4K| 16 8K #緩衝(壓縮在內存中緩衝幾塊? 每塊多大?)

gzip_comp_level [1-9] #推薦6 壓縮級別(級別越高,壓的越小,越浪費CPU計算資源)

gzip_disable #正則匹配UA 什麼樣的Uri不進行gzip

gzip_min_length 200 # 開始壓縮的最小長度(再小就不要壓縮了,意義不在)

gzip_http_version 1.0|1.1 # 開始壓縮的http協議版本(能夠不設置,目前幾乎全是1.1協議)

gzip_proxied # 設置請求者代理服務器,該如何緩存內容

gzip_types text/plain application/xml # 對哪些類型的文件用壓縮 如txt,xml,html ,css

gzip_vary on|off # 是否傳輸gzip壓縮標誌

注意：

圖片/mp3這樣的二進制文件,沒必要壓縮

由於壓縮率比較小, 好比100->80字節,並且壓縮也是耗費CPU資源的.

比較小的文件沒必要壓縮,

如下是配置：

在nginx.conf中加入

gzip on;
	gzip_buffers 32 4K;
	gzip_comp_level 6;
        gzip_min_length 100;
	gzip_types application/javascript text/css text/xml;
        gzip_disable "MSIE [1-6]\."; #配置禁用gzip條件，支持正則。此處表示ie6及如下不啓用gzip（由於ie低版本不支持）
        gzip_vary on;

保存並重啓nginx，刷新頁面（爲了不緩存，請強制刷新）就能看到效果了。以谷歌瀏覽器爲例，經過F12看請求的響應頭部，以下圖：

Content-Encoding:gzip 說明開啓了gzip壓縮

Transfet-Encoding:chunked 說明壓縮後分塊傳輸

 

在此咱們看出這個js的傳輸大小68.3k，而這個js實際大小爲282k 因此壓縮生效成功

 

 

 

 

3、Nginx開啓Gzip詳解

轉自或參考：Nginx開啓Gzip詳解
https://www.cnblogs.com/caicaizi/p/9488837.html

最近生產上發生了一些問題，原先全部的靜態資源文件都是通過gzip壓縮的，然而這幾天忽然都沒有壓縮了，通過一頓排查，發現是Nginx的配置有問題，藉此機會詳細瞭解了Nginx的Gzip配置。

1. Nginx開啓Gzip

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

1.1 配置說明

Nginx開啓Gzip的配置以下：

# $gzip_ratio計算請求的壓縮率，$body_bytes_sent請求體大小 log_format main '$remote_addr - $remote_user [$time_local] "$host" - "$request" ' '$gzip_ratio - $body_bytes_sent - $request_time'; access_log logs/access.log main; # 開啓gzip gzip off; # 啓用gzip壓縮的最小文件，小於設置值的文件將不會壓縮 gzip_min_length 1k; # gzip 壓縮級別，1-9，數字越大壓縮的越好，也越佔用CPU時間，後面會有詳細說明 gzip_comp_level 1; # 進行壓縮的文件類型。javascript有多種形式。其中的值能夠在 mime.types 文件中找到。 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 application/vnd.ms-fontobject font/ttf font/opentype font/x-woff image/svg+xml; # 是否在http header中添加Vary: Accept-Encoding，建議開啓 gzip_vary on; # 禁用IE 6 gzip gzip_disable "MSIE [1-6]\."; # 設置壓縮所須要的緩衝區大小 gzip_buffers 32 4k; # 設置gzip壓縮針對的HTTP協議版本 gzip_http_version 1.0;

 

下面將逐條介紹下gzip的指令和參數配置。

1.2 參數詳解

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倍的內存空間。建議此項不設置，使用默認值。

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

 

gzip_comp_level

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

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消耗。

從這咱們能夠得出結論：

1. 隨着壓縮級別的升高，壓縮比有所提升，但到了級別6後，很難再提升；
2. 隨着壓縮級別的升高，處理時間明顯變慢；
3. gzip很消耗cpu的性能，高併發狀況下cpu達到100%

所以，建議：
一方面，不是壓縮級別越高越好，其實gzip_comp_level 1的壓縮能力已經夠用了，後面級別越高，壓縮的比例其實增加不大，反而很吃處理性能。
另外一方面，壓縮必定要和靜態資源緩存相結合，緩存壓縮後的版本，不然每次都壓縮高負載下服務器確定吃不住。

http://10.27.180.75/jquery.js gzip_comp_level 0: 0，94840, 63 [ms], 29% gzip_comp_level 1: 2.43，39005, 248 [ms], 100% gzip_comp_level 2: 2.51，37743, 273 [ms], 100% gzip_comp_level 3; 2.57，36849, 327 [ms], 100% gzip_comp_level 4; 2.73，34807, 370 [ms], 100% gzip_comp_level 5; 2.80，33898, 491 [ms], 100% gzip_comp_level 6; 2.82，33686, 604 [ms], 100% gzip_comp_level 7; 2.82，33626, 659 [ms], 100% gzip_comp_level 8; 2.82，33626, 698 [ms], 100% gzip_comp_level 9; 2.82，33626, 698 [ms], 100%

 

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壓縮。

Syntax: gzip_http_version 1.0 | 1.1; Default: gzip_http_version 1.1; Context: http, server, location

 

我看網上的不少文章中，對這一點都以爲過期了，由於瀏覽器基本上都支持HTTP/1.1。然而這裏面卻存在着一個很容易掉入的坑，也是筆者從生產環境中一個詭異問題中發現的：
問題背景：
筆者所在公司的靜態資源服務器所有使用的Nginx，且都開啓了gzip壓縮。內部測試是徹底正常的，然而一到外網，竟然沒有作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_types

設置須要壓縮的MIME類型,若是不在設置類型範圍內的請求不進行壓縮

Syntax: gzip_types mime-type ...; Default: gzip_types text/html; Context: http, server, location

 

這裏須要說明一些特殊的類型，好比筆者公司會使用」字體類型」的資源，而這些資源類型每每會被忽略，且這些資源又比較大，沒有被壓縮很不合算。（能夠參考：http://www.darrenfang.com/2015/01/setting-up-http-cache-and-gzip-with-nginx/）：

因此MIME-TYPE中應該新增字體類型：

字體類型擴展名	Content-type
.eot	application/vnd.ms-fontobject
.ttf	font/ttf
.otf	font/opentype
.woff	font/x-woff
.svg	image/svg+xml

gzip_vary

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

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