說一段廢話
壓縮響應資料有什麼作用呢？問的好：從使用者體驗和IT成本兩方面回答這個問題：
-
使用者體驗上
網速一定的情況下，傳輸5MB資料比傳輸10MB資料的時間快了一半。所以傳輸資料越小使用者載入頁面就越快，當然相比較之下體驗會更好。
-
IT成本上
對這個場景來說的成本主要是頻寬成本, 資料不壓縮那麼傳輸這些資料相應的頻寬肯定更大，對比之下壓縮耗費的CPU資源在頻寬費用上不值一提。
所以你有什麼理由不用壓縮呢？
背景
當然Nginx也提供了gzip的壓縮方式可以使用，但是在日常的工作中我發現或多或少在使用上有些問題，有點像：用了但又好像沒用的感覺。 這篇就記錄一下gzip的使用方式和易錯點。
指令介紹
gzip
gzip指令來自 ngx_http_gzip_module 模組，提供的核心能力就是壓縮響應資料。
該模組下提供的指令如下：
gzip on;
# 開啟gzip
gzip_comp_level 6;
# 壓縮等級：1-9 1:壓縮最快/CPU消耗最少/壓縮率最低 以次類推
gzip_min_length 1000;
# 小於此大小的資料不壓縮(單位位元組/byte)；資料來源"Content-Length"頭
gzip_buffers 32 4k;
# 壓縮響應的緩衝區數量和大小(4K 記憶體頁大小取決於平臺)
gzip_proxied any;
# 對代理的請求是否開啟壓縮
gzip_types text/plain application/xml application/javascript application/x-javascript text/css application/json;
# 哪些型別的資料需要被壓縮
gzip_disable
"MSIE [1-5]\."
;
# User-Agent 被正則匹配到的不開啟壓縮
gzip_vary on;
# 當gzip對請求生效時會被新增一個響應頭 "Vary: Accept-Encoding"
tips:
-
gzip 是動態壓縮： 每個請求在被響應時都會在gzip邏輯內走一遍
-
壓縮等級不是越高越好： 壓縮到一定程度後就會吃力不討好， 從js的測試來看價效比最高的級別是 5或6
-
buffer大小設定最好是和平臺的記憶體頁保持一致： getconf PAGE_SIZE
-
gzip_types不要瞎寫： 寫壓縮率大的(css/js/xml/json/ttf)， image圖片就不要寫了，壓縮空間太小，又耗CPU
gzip_static
gzip_stati指令來自 ngx_http_gzip_static_module模組，提供的核心能力是靜態/預壓縮
該模組提供的指令如下:
gzip_static
on
|
off
|always;
# always: 不管客戶端是否支援壓縮我他媽全部給你壓縮之後給你
tips:
-
可以複用gzip_module中以下的指令:
-
gzip_http_version, gzip_proxied, gzip_disable, gzip_vary
-
gzip_static是靜態壓縮：意思是你的服務端需要同時存在原始檔和使用gzip壓縮後的原始檔，這時請求的時候會優先吧壓縮檔案返回，這樣就不用再耗費CPU去動態壓縮了。(視情況來用，我們沒用)
-
可以和gzip一同開啟，沒啥影響，它的優先順序高於gzip
易錯點提示
在實際的生產環境中架構都比較負載，不像一個單純的Nginx一樣，我配置好了就萬事大吉了。
時常會遇到有些網站明明配置了gzip但是展示上看並沒有生效，為什麼？
此時需要梳理這個請求流程，看看這個請求都經過了哪些地方，比如 你的請求透過三次代理(CDN–>Nginx–>Nginx)那麼在其中一層沒有配置或者配置錯誤那麼整體的返回資料就是沒有被壓縮的， 這種情況出現還是比較多的。
連結：https://www.cnblogs.com/chaizhenhua/p/16245875.html
（版權歸原作者所有，侵刪）
