# 配置nginx gzip壓縮功能 #
提供了對檔案內容壓縮的功能，允許將輸出內容在傳送到客戶端之前根據具體的策略壓縮節約貸頻寬。功能同apache的mod_deflate壓縮功能。依賴ngx_http_gzip_module模組。預設已安裝
網頁壓縮是一項由 web 伺服器和瀏覽器之間共同遵守的協議，也就是說 web 伺服器和瀏覽器都必須支援該技術，所幸的是現在流行的瀏覽器都是支援的，包括 ie、firefox、opera 等；伺服器有 apache 和 iis 等。雙方的協商過程如下：
首先瀏覽器請求某個 url 位址，並在請求的頭 (head) 中設定屬性 accept-encoding 值為 gzip, deflate，表明瀏覽器支援 gzip 和 deflate 這兩種壓縮方式（事實上 deflate 也是使用 gzip 壓縮協議，下面我們會介紹二者之間的區別）；
web 伺服器接收到請求後判斷瀏覽器是否支援壓縮，如果支援就傳送壓縮後的響應內容，否則傳送不經過壓縮的內容；
瀏覽器獲取響應內容後，判斷內容是否被壓縮，如果是則解壓縮，然後顯示響應頁面的內容。
在實際的應用中我們發現壓縮的比率往往在 3 到 10 倍，也就是本來 50k 大小的頁面，採用壓縮後實際傳輸的內容大小只有 5 至 15k 大小，這可以大大節省伺服器的網路頻寬，同時如果應用程式的響應足夠快時，**的速度瓶頸就轉到了網路的傳輸速度上，因此內容壓縮後就可以大大的提公升頁面的瀏覽速度。
配置啟用gzip
配置指令詳細注釋：
- gzip on|off
- # 預設值: gzip off
- # 開啟或者關閉gzip模組
- - gzip_static on|off
- - gzip_comp_level 4
- - # 預設值：1(建議選擇為4)
- # gzip壓縮比/壓縮級別，壓縮級別 1-9，級別越高壓縮率越大，當然壓縮時間也就越長（傳輸快但比較消耗cpu）。
- - gzip_buffers 4 16k
- - # 預設值: gzip_buffers 4 4k/8k
- # 設定系統獲取幾個單位的快取用於儲存gzip的壓縮結果資料流。 例如 4 4k 代表以4k為單位，按照原始資料大小以4k為單位的4倍申請記憶體。 4 8k 代表以8k為單位，按照原始資料大小以8k為單位的4倍申請記憶體。
- # 如果沒有設定，預設值是申請跟原始資料相同大小的記憶體空間去儲存gzip壓縮結果。
- - gzip_types mime-type [mime-type ...]
- - # 預設值: gzip_types text/html (預設不對js/css檔案進行壓縮)
- # 壓縮型別，匹配mime型別進行壓縮
- # 不能用萬用字元 text/*
- # (無論是否指定)text/html預設已經壓縮
- # 設定哪壓縮種文字檔案可參考 conf/mime.types
- - gzip_min_length 1k
- - # 預設值: 0 ，不管頁面多大都壓縮
- # 設定允許壓縮的頁面最小位元組數，頁面位元組數從header頭中的content-length中進行獲取。
- # 建議設定成大於1k的位元組數，小於1k可能會越壓越大。 即: gzip_min_length 1024
- - # 預設值: gzip_http_version 1.1(就是說對http/1.1協議的請求才會進行gzip壓縮)
- # 識別http的協議版本。由於早期的一些瀏覽器或者http客戶端，可能不支援gzip自解壓，使用者就會看到亂碼，所以做一些判斷還是有必要的。
- # 注：99.99%的瀏覽器基本上都支援gzip解壓了，所以可以不用設這個值,保持系統預設即可。
- # 假設我們使用的是預設值1.1，如果我們使用了proxy_pass進行反向**，那麼nginx和後端的upstream server之間是用http/1.0協議通訊的，如果我們使用nginx通過反向**做cache server，而且前端的nginx沒有開啟gzip，同時，我們後端的nginx上沒有設定gzip_http_version為1.0，那麼cache的url將不會進行gzip壓縮
- - gzip_proxied [off|expired|no-cache|no-store|private|no_last_modified|no_etag|auth|any] ...
- - # 預設值：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_vary on
- - # 和http頭有關係，加個vary頭，給**伺服器用的，有的瀏覽器支援壓縮，有的不支援，所以避免浪費不支援的也壓縮，所以根據客戶端的http頭來判斷，是否需要壓縮
- - gzip_disable "msie [1-6]."
- - # 禁用ie6的gzip壓縮，又是因為杯具的ie6。當然，ie6目前依然廣泛的存在，所以這裡你也可以設定為「msie [1-5].」
- # ie6的某些版本對gzip的壓縮支援很不好，會造成頁面的假死，今天產品的同學就測試出了這個問題
- 後來除錯後，發現是對img進行gzip後造成ie6的假死，把對img的gzip壓縮去掉後就正常了
- 為了確保其它的ie6版本不出問題，所以建議加上gzip_disable的設定
- 3. 使用curl測試
複製**
頁面成功壓縮
Apache配置HTTP壓縮功能
對於apache而言，有兩種情況 1.針對apache2.0之前的版本，原本是不支援壓縮傳輸的，不過可以通過新增第三方的mod gzip模組來實現。2.針對apache2.0及之後的版本，apache提供壓縮傳輸支援，使用mod deflate模組即可。下面是對apache2.0及之後的版本進行配置...
nginx gzip壓縮 相關配置，
網頁內容的壓縮編碼與傳輸速度優化 我們觀察news.163.com的頭資訊 請求 accept encoding gzip,deflate,sdch 響應 content encoding gzip content length 36093 再把頁面另存下來,觀察,約10w位元組,實際傳輸的3609...
Nginx壓縮模組的壓縮功能
nginx gzip模組類似於apach的mod deflate壓縮功能，依賴ngx http gzip module模組。壓縮配置 gzip on 開啟起壓縮功能 gzip min length 1k 設定允許亞索頁面的最小位元組數，頁面位元組數從header頭的content length中獲取...