說一段廢話

壓縮響應數據有什么作用呢？問的好：從用戶體驗和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)那么在其中一層沒有配置或者配置錯誤那么整體的返回數據就是沒有被壓縮的， 這種情況出現還是比較多的。