說一段廢話

壓縮響應(yīng)數(shù)據(jù)有什么作用呢？問的好：從用戶體驗和IT成本兩方面回答這個問題：

用戶體驗上

網(wǎng)速一定的情況下，傳輸5MB數(shù)據(jù)比傳輸10MB數(shù)據(jù)的時間快了一半。所以傳輸數(shù)據(jù)越小用戶加載頁面就越快，當(dāng)然相比較之下體驗會更好。

IT成本上

對這個場景來說的成本主要是帶寬成本, 數(shù)據(jù)不壓縮那么傳輸這些數(shù)據(jù)相應(yīng)的帶寬肯定更大，對比之下壓縮耗費的CPU資源在帶寬費用上不值一提。

所以你有什么理由不用壓縮呢？

背景

當(dāng)然Nginx也提供了gzip的壓縮方式可以使用，但是在日常的工作中我發(fā)現(xiàn)或多或少在使用上有些問題，有點像：用了但又好像沒用的感覺。 這篇就記錄一下gzip的使用方式和易錯點。

指令介紹

gzip

gzip指令來自 ngx_http_gzip_module 模塊，提供的核心能力就是壓縮響應(yīng)數(shù)據(jù)。

該模塊下提供的指令如下：

gzip                on;     # 開啟gzip
gzip_comp_level     6;      # 壓縮等級：1-9 1:壓縮最快/CPU消耗最少/壓縮率最低 以次類推
gzip_min_length     1000;   # 小于此大小的數(shù)據(jù)不壓縮(單位字節(jié)/byte)；數(shù)據(jù)來源"Content-Length"頭
gzip_buffers        32 4k;  # 壓縮響應(yīng)的緩沖區(qū)數(shù)量和大小(4K 內(nèi)存頁大小取決于平臺)
gzip_proxied        any;    # 對代理的請求是否開啟壓縮
gzip_types text/plain application/xml application/javascript application/x-javascript text/css application/json;    # 哪些類型的數(shù)據(jù)需要被壓縮
gzip_disable     "MSIE [1-5].";    # User-Agent 被正則匹配到的不開啟壓縮
gzip_vary on;               # 當(dāng)gzip對請求生效時會被添加一個響應(yīng)頭 "Vary: Accept-Encoding"

tips:

gzip 是動態(tài)壓縮： 每個請求在被響應(yīng)時都會在gzip邏輯內(nèi)走一遍

壓縮等級不是越高越好： 壓縮到一定程度后就會吃力不討好， 從js的測試來看性價比最高的級別是 5或6

buffer大小設(shè)置最好是和平臺的內(nèi)存頁保持一致： getconf PAGE_SIZE

gzip_types不要瞎寫： 寫壓縮率大的(css/js/xml/json/ttf)， image圖片就不要寫了，壓縮空間太小，又耗CPU

gzip_static

gzip_stati指令來自 ngx_http_gzip_static_module模塊，提供的核心能力是靜態(tài)/預(yù)壓縮

該模塊提供的指令如下:

gzip_static on|off|always;  # always: 不管客戶端是否支持壓縮我他媽全部給你壓縮之后給你

tips:

可以復(fù)用gzip_module中以下的指令:

gzip_http_version, gzip_proxied, gzip_disable, gzip_vary

gzip_static是靜態(tài)壓縮：意思是你的服務(wù)端需要同時存在源文件和使用gzip壓縮后的源文件，這時請求的時候會優(yōu)先吧壓縮文件返回，這樣就不用再耗費CPU去動態(tài)壓縮了。(視情況來用，我們沒用)

可以和gzip一同開啟，沒啥影響，它的優(yōu)先級高于gzip

易錯點提示

在實際的生產(chǎn)環(huán)境中架構(gòu)都比較負(fù)載，不像一個單純的Nginx一樣，我配置好了就萬事大吉了。

時常會遇到有些網(wǎng)站明明配置了gzip但是展示上看并沒有生效，為什么？

此時需要梳理這個請求流程，看看這個請求都經(jīng)過了哪些地方，比如 你的請求通過三次代理(CDN-->Nginx-->Nginx)那么在其中一層沒有配置或者配置錯誤那么整體的返回數(shù)據(jù)就是沒有被壓縮的， 這種情況出現(xiàn)還是比較多的。