剛剛給博客加了一個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等緩存服務有關(guān)，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
開啟或者關(guān)閉gzip模塊
gzip_static on|off
nginx對于靜態(tài)文件的處理模塊
該模塊可以讀取預先壓縮的gz文件，這樣可以減少每次請求進行g(shù)zip壓縮的CPU資源消耗。該模塊啟用后，nginx首先檢查是否存在請求靜態(tài)文件的gz結(jié)尾的文件，如果有則直接返回該gz文件內(nèi)容。為了要兼容不支持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的壓縮結(jié)果數(shù)據(jù)流。 例如 4 4k 代表以4k為單位，按照原始數(shù)據(jù)大小以4k為單位的4倍申請內(nèi)存。 4 8k 代表以8k為單位，按照原始數(shù)據(jù)大小以8k為單位的4倍申請內(nèi)存。
如果沒有設置，默認值是申請跟原始數(shù)據(jù)相同大小的內(nèi)存空間去存儲gzip壓縮結(jié)果。
gzip_types mime-type [mime-type …]
默認值: gzip_types text/html (默認不對js/css文件進行壓縮)
壓縮類型，匹配MIME類型進行壓縮
不能用通配符 text/* (無論是否指定)text/html默認已經(jīng)壓縮
設置哪壓縮種文本文件可參考 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é)議的請求才會進行g(shù)zip壓縮)
識別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將不會進行g(shù)zip壓縮
gzip_proxied [off|expired|no-cache|no-store|private|no_last_modified|no_etag|auth|any] …
默認值：off
Nginx作為反向代理的時候啟用，開啟或者關(guān)閉后端服務器返回的結(jié)果，匹配的前提是后端服務器必須要返回包含”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 - 無條件啟用壓縮
gzip_vary on
和http頭有關(guān)系，加個vary頭，給代理服務器用的，有的瀏覽器支持壓縮，有的不支持，所以避免浪費不支持的也壓縮，所以根據(jù)客戶端的HTTP頭來判斷，是否需要壓縮
gzip_disable “MSIE [1-6].”
禁用IE6的gzip壓縮，又是因為杯具的IE6。當然，IE6目前依然廣泛的存在，所以這里你也可以設置為“MSIE [1-5].”
IE6的某些版本對gzip的壓縮支持很不好，會造成頁面的假死，今天產(chǎn)品的同學就測試出了這個問題
后來調(diào)試后，發(fā)現(xiàn)是對img進行g(shù)zip后造成IE6的假死，把對img的gzip壓縮去掉后就正常了
為了確保其它的IE6版本不出問題，所以建議加上gzip_disable的設置
以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。
