剛剛給博客加了一個500px相冊插件，lightbox引入了很多js文件和css文件，頁面一下子看起來非常臃腫，所以還是把Gzip打開了。

環(huán)境：Debian 6

1、Vim打開Nginx配置文件

vim /usr/local/nginx/conf/nginx.conf

2、找到如下一段，進行修改

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
#gzip_http_version 1.0;
gzip_comp_level 2;
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 off;
gzip_disable "MSIE [1-6]\.";

3、解釋一下

第1行：開啟Gzip

第2行：不壓縮臨界值，大于1K的才壓縮，一般不用改

第3行：buffer，就是，嗯，算了不解釋了，不用改

第4行：用了反向代理的話，末端通信是HTTP/1.0，有需求的應該也不用看我這科普文了；有這句的話注釋了就行了，默認是HTTP/1.1

第5行：壓縮級別，1-10，數(shù)字越大壓縮的越好，時間也越長，看心情隨便改吧

第6行：進行壓縮的文件類型，缺啥補啥就行了，JavaScript有兩種寫法，最好都寫上吧，總有人抱怨js文件沒有壓縮，其實多寫一種格式就行了

第7行：跟Squid等緩存服務有關，on的話會在Header里增加"Vary: Accept-Encoding"，我不需要這玩意，自己對照情況看著辦吧

第8行：IE6對Gzip不怎么友好，不給它Gzip了

4、:wq保存退出，重新加載Nginx

/usr/local/nginx/sbin/nginx -s reload

5、用curl測試Gzip是否成功開啟

curl -I -H "Accept-Encoding: gzip, deflate" "http://www.slyar.com/blog/"

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sun, 26 Aug 2012 18:13:09 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.2.17p1
X-Pingback: http://www.slyar.com/blog/xmlrpc.php
Content-Encoding: gzip

頁面成功壓縮

curl -I -H "Accept-Encoding: gzip, deflate" "http://www.slyar.com/blog/wp-content/plugins/photonic/include/css/photonic.css"

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sun, 26 Aug 2012 18:21:25 GMT
Content-Type: text/css
Last-Modified: Sun, 26 Aug 2012 15:17:07 GMT
Connection: keep-alive
Expires: Mon, 27 Aug 2012 06:21:25 GMT
Cache-Control: max-age=43200
Content-Encoding: gzip

css文件成功壓縮

curl -I -H "Accept-Encoding: gzip, deflate" "http://www.slyar.com/blog/wp-includes/js/jquery/jquery.js"

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sun, 26 Aug 2012 18:21:38 GMT
Content-Type: application/x-javascript
Last-Modified: Thu, 12 Jul 2012 17:42:45 GMT
Connection: keep-alive
Expires: Mon, 27 Aug 2012 06:21:38 GMT
Cache-Control: max-age=43200
Content-Encoding: gzip

js文件成功壓縮

curl -I -H "Accept-Encoding: gzip, deflate" "http://www.slyar.com/blog/wp-content/uploads/2012/08/2012-08-23_203542.png"

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sun, 26 Aug 2012 18:22:45 GMT
Content-Type: image/png
Last-Modified: Thu, 23 Aug 2012 13:50:53 GMT
Connection: keep-alive
Expires: Tue, 25 Sep 2012 18:22:45 GMT
Cache-Control: max-age=2592000
Content-Encoding: gzip

圖片成功壓縮

curl -I -H "Accept-Encoding: gzip, deflate" "http://www.slyar.com/blog/wp-content/plugins/wp-multicollinks/wp-multicollinks.css"

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sun, 26 Aug 2012 18:23:27 GMT
Content-Type: text/css
Content-Length: 180
Last-Modified: Sat, 02 May 2009 08:46:15 GMT
Connection: keep-alive
Expires: Mon, 27 Aug 2012 06:23:27 GMT
Cache-Control: max-age=43200
Accept-Ranges: bytes

最后來個不到1K的文件，由于我的閾值是1K，所以沒壓縮

gzip參數(shù)解釋

gzip on|off

默認值: gzip off

開啟或者關閉gzip模塊

gzip_static on|off

nginx對于靜態(tài)文件的處理模塊

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

可以google”nginx gzip_static”了解更多

gzip_comp_level 4

默認值：1(建議選擇為4)

gzip壓縮比/壓縮級別，壓縮級別 1-9，級別越高壓縮率越大，當然壓縮時間也就越長（傳輸快但比較消耗cpu）。

gzip_buffers 4 16k

默認值: gzip_buffers 4 4k/8k

設置系統(tǒng)獲取幾個單位的緩存用于存儲gzip的壓縮結果數(shù)據流。 例如 4 4k 代表以4k為單位，按照原始數(shù)據大小以4k為單位的4倍申請內存。 4 8k 代表以8k為單位，按照原始數(shù)據大小以8k為單位的4倍申請內存。
如果沒有設置，默認值是申請跟原始數(shù)據相同大小的內存空間去存儲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 ，不管頁面多大都壓縮

設置允許壓縮的頁面最小字節(jié)數(shù)，頁面字節(jié)數(shù)從header頭中的Content-Length中進行獲取。

建議設置成大于1k的字節(jié)數(shù)，小于1k可能會越壓越大。 即: gzip_min_length 1024

gzip_http_version 1.0|1.1

默認值: gzip_http_version 1.1(就是說對HTTP/1.1協(xié)議的請求才會進行gzip壓縮)

識別http的協(xié)議版本。由于早期的一些瀏覽器或者http客戶端，可能不支持gzip自解壓，用戶就會看到亂碼，所以做一些判斷還是有必要的。

注：99.99%的瀏覽器基本上都支持gzip解壓了，所以可以不用設這個值,保持系統(tǒng)默認即可。

假設我們使用的是默認值1.1，如果我們使用了proxy_pass進行反向代理，那么nginx和后端的upstream server之間是用HTTP/1.0協(xié)議通信的，如果我們使用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 - 關閉所有的代理結果數(shù)據的壓縮
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的壓縮支持很不好，會造成頁面的假死，今天產品的同學就測試出了這個問題

后來調試后，發(fā)現(xiàn)是對img進行gzip后造成IE6的假死，把對img的gzip壓縮去掉后就正常了

為了確保其它的IE6版本不出問題，所以建議加上gzip_disable的設置

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。