網頁壓縮傳輸

   

 

    在Nginx中與網頁壓縮的模組有兩個一個是HttpGzipModule，而另一個是HttpGzipStaticModule。前者用於啟用在檔案傳輸過程中使用gzip壓縮，而後者的作用是在將一個檔案以壓縮的方式傳遞到一個支援壓縮功能的客戶端之前，首先檢查是否已經存在相應檔案的以“.gz”結尾的的檔名格式，這樣可以避免重複壓縮浪費資源。

 

因此，對於Nginx的網頁壓縮傳輸在Nginx的配置是將分為分兩種模式：一種是動態的，實時壓縮輸出(邊壓縮，邊輸出)，而另一種則是靜態的，找到同名檔案的.gz格式檔案就輸出。

 

    我們先來看第一個模組HttpGzipModul。

 

HttpGzipModule

 

    該模組啟用在檔案傳輸過程中使用gzip壓縮，壓縮率通過變數$gzip_ratio來設定。

 

配置示例

   

gzip             on;   gzip_min_length  1000;   gzip_proxied     expired no-cache no-store private auth;   gzip_types       text/plain application/xml;   gzip_disable     "MSIE [1-6]\.";

 

指    令

 

    ....//無法上傳，故略

 

 

使用例項

 

新增配置

 

    在原有的配置區段中新增以下配置：

 

gzip             on;   gzip_types       text/plain application/xml;

   

訪問測試

 

    看一下我們要訪問的網頁(注意它的大小)：

 

[root@mfsmaster html]# ll -rw-r--r--  1 root root 12376  8月 19 08:22 index.html

   

在新增以上配置後，先不要重新啟動或者重新載入配置檔案，然後訪問該網頁，用協議分析軟體分析響應包：

 

   

 

    注意，在這裡沒有使用“Accept-encoding: gzip”，而是返回“Accept-Ranges: bytes”表示支援斷點續傳，同時注意它的Content-Length為12376，看下面的截圖：

 

   

 

    在這個截圖中，我們計算一下傳輸的位元組：1260*9+1036=12376。

 

然後重新載入Nginx的配置，再次進行訪問，注意要訪問同一頁面(記得清除快取)，同樣分析響應包：

 

   

 

    注意圖中圈起的部分，這是伺服器的返回資訊，說明我們這次使用的是壓縮傳輸，即“Content-Encoding: gzip”；另外，要注意這裡的“二進位制資料 1019位元組”這已經是我們傳輸的資料了。

 

   

 

    在這個截圖中傳輸的位元組數為：1260*2+785+1019=4324。比‘.gz’格式多292個位元組，後面會講到‘.gz’格式的傳輸。