1. 程式人生 > >Nginx Gzip模組啟用和配置指令詳解

Nginx Gzip模組啟用和配置指令詳解

一、Nginx中的gzip的設定引數

# 開啟gzip壓縮服務
gzip on;

# gzip壓縮是要申請臨時記憶體空間的,假設前提是壓縮後大小是小於等於壓縮前的。
# 例如,如果原始檔案大小為10K,那麼它超過了8K,所以分配的記憶體是8 * 2 = 16K;再例如,
# 原始檔案大小為18K,很明顯16K也是不夠的,那麼按照 8 * 2 * 2 = 32K的大小申請記憶體。
# 如果沒有設定,預設值是申請跟原始資料相同大小的記憶體空間去儲存gzip壓縮結果。 

# 設定系統獲取幾個單位的快取用於儲存gzip的壓縮結果資料流。 
# 例如 4 4k 代表以4k為單位,按照原始資料大小以4k為單位的4倍申請記憶體。 
# 4 8k 代表以8k為單位,按照原始資料大小以8k為單位的4倍申請記憶體。 # 如果沒有設定,預設值是申請跟原始資料相同大小的記憶體空間去儲存gzip壓縮結果。 gzip_buffers 2 8k; # nginx對於靜態檔案的處理模組。 # 該模組可以讀取預先壓縮的gz檔案,這樣可以減少每次請求進行gzip壓縮的CPU資源消耗。 # 該模組啟用後,nginx首先檢查是否存在請求靜態檔案的gz結尾的檔案,如果有則直接返回該gz檔案內容。 # 為了要相容不支援gzip的瀏覽器,啟用gzip_static模組就必須同時保留原始靜態檔案和gz檔案。 # 這樣的話,在有大量靜態檔案的情況下,將會大大增加磁碟空間。我們可以利用nginx的反向代理功能實現只保留gz檔案。
gzip_static on|off # 啟用gzip壓縮的最小檔案,小於設定值的檔案將不會壓縮 gzip_min_length 1k; # gzip壓縮基於的http協議版本,預設就是HTTP 1.1 gzip_http_version 1.1; # gzip 壓縮級別,1-10,數字越大壓縮的越好,也越佔用CPU時間,後面會有詳細說明 gzip_comp_level 2; # 需要進行gzip壓縮的Content-Type的Header的型別。建議js、text、css、xml、json都要進行壓縮; # 圖片就沒必要了,gif、jpge檔案已經壓縮得很好了,就算再壓,效果也不好,而且還耗費cpu。
# 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; # 預設值:off # Nginx作為反向代理的時候啟用,開啟或者關閉後端伺服器返回的結果,匹配的前提是後端伺服器必須要返回包含"Via"的 header頭。 # 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 - 無條件啟用壓縮 gzip_proxied [off|expired|no-cache|no-store|private|no_last_modified|no_etag|auth|any] ... # 是否在http header中新增Vary: Accept-Encoding,建議開啟 # 和http頭有關係,加個vary頭,給代理伺服器用的,有的瀏覽器支援壓縮, # 有的不支援,所以避免浪費不支援的也壓縮,所以根據客戶端的HTTP頭來判斷,是否需要壓縮 gzip_vary on; # 禁用IE 6 gzip gzip_disable "MSIE [1-6]\.";

設定完成後,重啟nginx,即可生效。

二、瀏覽器和伺服器進行gzip壓縮的請求和處理返回過程

這裡寫圖片描述

  • 整個請求過程來看,開啟gzip和不開啟gip功能,其http的請求和返回過程是一致的,不同的是引數。
  • 當開啟HTTP的gzip功能時,客戶端發出http請求時,會通過headers中的Accept-Encoding屬性告訴伺服器“我支援gzip解壓,解壓格式(演算法)deflate,sdch為:”。Accept-Encoding:gzip,deflate,sdch
  • 注意,不是request說自己支援解壓,Nginx返回response資料的時候就一定會壓縮。這還要看本次Nginx返回資料的格式是什麼,如果返回資料的原始資料格式,和設定的gzip_types相符合,這時Nginx才會進行壓縮。
  • Nginx返回response headers是,如果資料被壓縮了,就會在Content-Encoding屬性中標示gzip,表示接下來返回的response
    content是經過壓縮的;並且在Content-Type屬性中表示資料的原始格式。
  • 最後返回經過壓縮的response content給客戶端,客戶端再進行解壓。這裡注意一下,在客戶端傳送的headers裡面,有一個deflate,sdch。這是兩種壓縮演算法,如果讀者感興趣,可以查查相關的資料(我建議查查,瞭解哈弗曼壓縮演算法對擴充套件自己的架構思路很有幫助)

三、關於 gzip_comp_level 的合理值,可以參考下圖。來自 serverfault

這裡寫圖片描述

從圖中可以看出 gzip_comp_level 大於2時效果並不是很明顯。所以可以將值設定為1或者2。

四、對於字型的處理

只需要為 ttf、otf 和 svg 字型啟用 gzip,對其他字型格式進行 gzip 壓縮時效果不明顯。

gzip_types  font/ttf font/otf image/svg+xml

各種字型型別壓縮效果可以參考以下測試結果:

1、eot字型壓縮效果
這裡寫圖片描述

2、otf字型壓縮效果
這裡寫圖片描述

3、svg字型壓縮效果
這裡寫圖片描述

4、ttf字型壓縮效果
這裡寫圖片描述

5、woff字型壓縮效果
這裡寫圖片描述

可以看到對 woff 和 eot 進行 gzip 壓縮效果不好。

副檔名 是否壓縮 Content-type
.eot application/vnd.ms-fontobject
.ttf font/ttf
.otf font/opentype
.woff font/x-woff
.svg image/svg+xml