快捷導(dǎo)航

Nginx Gzip模塊啟用和配置指令詳解

更新時(shí)間：2014年04月14日 11:51:47 作者：

這篇文章主要介紹了Nginx Gzip模塊啟用和配置指令詳解的,需要的朋友可以參考下

Nginx的gzip模塊是內(nèi)置的，在http中添加如下配置：

gzip on;
gzip_min_length  5k;
gzip_buffers     4 16k;
gzip_http_version 1.0;
gzip_comp_level 3;
gzip_types       text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
gzip_vary on;

配置指令詳細(xì)注釋：

gzip on|off
# 默認(rèn)值: gzip off
# 開(kāi)啟或者關(guān)閉gzip模塊

gzip_static on|off

# nginx對(duì)于靜態(tài)文件的處理模塊
# 該模塊可以讀取預(yù)先壓縮的gz文件，這樣可以減少每次請(qǐng)求進(jìn)行g(shù)zip壓縮的CPU資源消耗。該模塊啟用后，nginx首先檢查是否存在請(qǐng)求靜態(tài)文件的gz結(jié)尾的文件，如果有則直接返回該gz文件內(nèi)容。為了要兼容不支持gzip的瀏覽器，啟用gzip_static模塊就必須同時(shí)保留原始靜態(tài)文件和gz文件。這樣的話，在有大量靜態(tài)文件的情況下，將會(huì)大大增加磁盤空間。我們可以利用nginx的反向代理功能實(shí)現(xiàn)只保留gz文件。
# 可以google"nginx gzip_static"了解更多

gzip_comp_level 4

# 默認(rèn)值：1(建議選擇為4)
# gzip壓縮比/壓縮級(jí)別，壓縮級(jí)別 1-9，級(jí)別越高壓縮率越大，當(dāng)然壓縮時(shí)間也就越長(zhǎng)（傳輸快但比較消耗cpu）。

gzip_buffers 4 16k

# 默認(rèn)值: gzip_buffers 4 4k/8k
# 設(shè)置系統(tǒng)獲取幾個(gè)單位的緩存用于存儲(chǔ)gzip的壓縮結(jié)果數(shù)據(jù)流。例如 4 4k 代表以4k為單位，按照原始數(shù)據(jù)大小以4k為單位的4倍申請(qǐng)內(nèi)存。 4 8k 代表以8k為單位，按照原始數(shù)據(jù)大小以8k為單位的4倍申請(qǐng)內(nèi)存。
# 如果沒(méi)有設(shè)置，默認(rèn)值是申請(qǐng)跟原始數(shù)據(jù)相同大小的內(nèi)存空間去存儲(chǔ)gzip壓縮結(jié)果。

gzip_types mime-type [mime-type ...]

# 默認(rèn)值: gzip_types text/html (默認(rèn)不對(duì)js/css文件進(jìn)行壓縮)
# 壓縮類型，匹配MIME類型進(jìn)行壓縮
# 不能用通配符 text/*
# (無(wú)論是否指定)text/html默認(rèn)已經(jīng)壓縮
# 設(shè)置哪壓縮種文本文件可參考 conf/mime.types

gzip_min_length 1k

# 默認(rèn)值: 0 ，不管頁(yè)面多大都?jí)嚎s
# 設(shè)置允許壓縮的頁(yè)面最小字節(jié)數(shù)，頁(yè)面字節(jié)數(shù)從header頭中的Content-Length中進(jìn)行獲取。
# 建議設(shè)置成大于1k的字節(jié)數(shù)，小于1k可能會(huì)越壓越大。即: gzip_min_length 1024

gzip_http_version 1.0|1.1

# 默認(rèn)值: gzip_http_version 1.1(就是說(shuō)對(duì)HTTP/1.1協(xié)議的請(qǐng)求才會(huì)進(jìn)行g(shù)zip壓縮)
# 識(shí)別http的協(xié)議版本。由于早期的一些瀏覽器或者h(yuǎn)ttp客戶端，可能不支持gzip自解壓，用戶就會(huì)看到亂碼，所以做一些判斷還是有必要的。
# 注：99.99%的瀏覽器基本上都支持gzip解壓了，所以可以不用設(shè)這個(gè)值,保持系統(tǒng)默認(rèn)即可。
# 假設(shè)我們使用的是默認(rèn)值1.1，如果我們使用了proxy_pass進(jìn)行反向代理，那么nginx和后端的upstream server之間是用HTTP/1.0協(xié)議通信的，如果我們使用nginx通過(guò)反向代理做Cache Server，而且前端的nginx沒(méi)有開(kāi)啟gzip，同時(shí)，我們后端的nginx上沒(méi)有設(shè)置gzip_http_version為1.0，那么Cache的url將不會(huì)進(jìn)行g(shù)zip壓縮

gzip_proxied [off|expired|no-cache|no-store|private|no_last_modified|no_etag|auth|any] ...

# 默認(rèn)值：off
# Nginx作為反向代理的時(shí)候啟用，開(kāi)啟或者關(guān)閉后端服務(wù)器返回的結(jié)果，匹配的前提是后端服務(wù)器必須要返回包含"Via"的 header頭。
off - 關(guān)閉所有的代理結(jié)果數(shù)據(jù)的壓縮
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 - 無(wú)條件啟用壓縮

gzip_vary on

# 和http頭有關(guān)系，加個(gè)vary頭，給代理服務(wù)器用的，有的瀏覽器支持壓縮，有的不支持，所以避免浪費(fèi)不支持的也壓縮，所以根據(jù)客戶端的HTTP頭來(lái)判斷，是否需要壓縮

gzip_disable "MSIE [1-6]."

# 禁用IE6的gzip壓縮，又是因?yàn)楸叩腎E6。當(dāng)然，IE6目前依然廣泛的存在，所以這里你也可以設(shè)置為“MSIE [1-5].”
# IE6的某些版本對(duì)gzip的壓縮支持很不好，會(huì)造成頁(yè)面的假死，今天產(chǎn)品的同學(xué)就測(cè)試出了這個(gè)問(wèn)題
后來(lái)調(diào)試后，發(fā)現(xiàn)是對(duì)img進(jìn)行g(shù)zip后造成IE6的假死，把對(duì)img的gzip壓縮去掉后就正常了
為了確保其它的IE6版本不出問(wèn)題，所以建議加上gzip_disable的設(shè)置

關(guān)于 SEO：
有人說(shuō)百度對(duì)Gzip的支持不夠好，擔(dān)心影響收錄和SEO，經(jīng)百度查閱相關(guān)資料后發(fā)現(xiàn)百度專門針對(duì)這個(gè)問(wèn)題作過(guò)報(bào)告，聲明百度是支持Gzip的。
服務(wù)器開(kāi)啟gzip壓縮是否會(huì)影響蜘蛛抓取和收錄量?
服務(wù)器開(kāi)啟gzip壓縮，不會(huì)對(duì)spider抓取產(chǎn)生影響，我們會(huì)以壓縮的方式來(lái)抓取。并且也能夠節(jié)省站點(diǎn)的網(wǎng)絡(luò)流量。

您可能感興趣的文章: