gzip壓縮
使用 gzip 壓縮可以降低網(wǎng)站帶寬消耗，同時(shí)提升訪問速度。
主要在nginx服務(wù)端將頁(yè)面進(jìn)行壓縮，然后在瀏覽器端進(jìn)行解壓和解析，
目前大多數(shù)流行的瀏覽器都遲滯gzip格式的壓縮，所以不用擔(dān)心。
默認(rèn)情況下，Nginx的gzip壓縮是關(guān)閉的，同時(shí)，Nginx默認(rèn)只對(duì)text/html進(jìn)行壓縮
主要配置如下：

gzip on;#開啟 
gzip_http_version 1.0;#默認(rèn)1.1 
gzip_vary on; 
gzip_comp_level 6; 
gzip_proxied any; 
gzip_types text/plain text/html text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;#壓縮的文件類型 
 
gzip_buffers 16 8k;#設(shè)置gzip申請(qǐng)內(nèi)存的大小,其作用是按塊大小的倍數(shù)申請(qǐng)內(nèi)存空間設(shè)置gzip申請(qǐng)內(nèi)存的大小,其作用是按塊大小的倍數(shù)申請(qǐng)內(nèi)存空間 
 
# Disable gzip for certain browsers. 
gzip_disable “MSIE [1-6].(?!.*SV1)”;#ie6不支持gzip，需要禁用掉ie6，可惡啊!!!! 

注意： 其中的gzip_http_version的設(shè)置，它的默認(rèn)值是1.1，就是說(shuō)對(duì)HTTP/1.1協(xié)議的請(qǐng)求才會(huì)進(jìn)行g(shù)zip壓縮
如果我們使用了proxy_pass進(jìn)行反向代理，那么nginx和后端的upstream server之間是用HTTP/1.0協(xié)議通信的。

gzip參數(shù)說(shuō)明：
決定是否開啟gzip模塊
param:on|off
example:gzip on;

gzip_buffers
設(shè)置gzip申請(qǐng)內(nèi)存的大小,其作用是按塊大小的倍數(shù)申請(qǐng)內(nèi)存空間
param1:int 增加的倍數(shù)
param2:int(k) 后面單位是k
example: gzip_buffers 4 8k;

gzip_comp_level
設(shè)置gzip壓縮等級(jí)，等級(jí)越底壓縮速度越快文件壓縮比越小，反之速度越慢文件壓縮比越大
param:1-9
example:gzip_com_level 1;

gzip_min_length
當(dāng)返回內(nèi)容大于此值時(shí)才會(huì)使用gzip進(jìn)行壓縮,以K為單位,當(dāng)值為0時(shí)，所有頁(yè)面都進(jìn)行壓縮
param:int
example:gzip_min_length 1000;

gzip_http_version
用于識(shí)別http協(xié)議的版本，早期的瀏覽器不支持gzip壓縮，用戶會(huì)看到亂碼，所以為了支持前期版本加了此選項(xiàng),目前此項(xiàng)基本可以忽略
param: 1.0|1.1
example:gzip_http_version 1.0

gzip_proxied
Nginx做為反向代理的時(shí)候啟用，
param:off|expired|no-cache|no-sotre|private|no_last_modified|no_etag|auth|any]
expample:gzip_proxied no-cache;
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ú)條件壓縮所有結(jié)果數(shù)據(jù)

gzip_types
設(shè)置需要壓縮的MIME類型,非設(shè)置值不進(jìn)行壓縮
param:text/html|application/x-javascript|text/css|application/xml
example:gzip_types text/html;

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

Nginx與Gzip請(qǐng)求
一般線程的Nginx的Gzip模塊都是和Response相關(guān)的Gzip，但如果需要的是和Request相關(guān)的Gzip呢？來(lái)看下面：
方案

第一個(gè)選擇是使用lua-zlib：

local zlib = require "zlib"

local encoding = ngx.req.get_headers()["Content-Encoding"]

if encoding == "gzip" then
  local body = ngx.req.get_body_data()

  if body then
    local stream = zlib.inflate()
    ngx.req.set_body_data(stream(body))
  end
end

第二個(gè)選擇是通過LuaJIT的FFI庫(kù)來(lái)包裝ZLIB模塊，官方教程里有一些現(xiàn)成的可供參考的的例子，不過例子里介紹的是Deflate，而不是Gzip，自己用FFI封裝Gzip的話又有點(diǎn)小復(fù)雜，好在別人已經(jīng)做了相關(guān)的工作，那就是lua-files：

local ffi = require "ffi"
local zlib = require "zlib"

local function reader(s)
  local done
  return function()
    if done then return end
    done = true
    return s
  end
end

local function writer()
  local t = {}
  return function(data, sz)
    if not data then return table.concat(t) end
    t[#t + 1] = ffi.string(data, sz)
  end
end

local encoding = ngx.req.get_headers()["Content-Encoding"]

if encoding == "gzip" then
  local body = ngx.req.get_body_data()

  if body then
    local write = writer()
    zlib.inflate(reader(body), write, nil, "gzip")
    ngx.req.set_body_data(write())
  end
end

如上例子代碼源自zlib_test.lua，乍看上去，代碼里的reader和writer可能會(huì)令人費(fèi)解，其實(shí)你可以把它們理解成輸入輸出接口，可以修改成文件，數(shù)據(jù)庫(kù)等等形式。

別高興太早，當(dāng)你運(yùn)行時(shí)，很可能會(huì)遇到如下錯(cuò)誤：

libzlib.so: cannot open shared object file.

實(shí)際上這是因?yàn)槿缦聑lib.lua代碼的緣故：

local C = ffi.load 'zlib'

運(yùn)行時(shí)，ffi.load會(huì)自動(dòng)補(bǔ)全文件名，如果是Windows，則加載zlib.dll文件，如果是Linux，則加載libzlib.so，但實(shí)際上在Linux下，ZLIB擴(kuò)展的名字是libz.so，而非libzlib.so。

知道的問題的原委，我們自然就知道如何修改代碼了：

local C

if ffi.os == "Windows" then
  C = ffi.load "zlib"
else
  C = ffi.load "z"
end

有時(shí)候我們不推薦直接修改第三方庫(kù)的代碼，因?yàn)檫@樣的話，每次第三庫(kù)更新代碼，我們都要做對(duì)應(yīng)的修改，一旦忘記就會(huì)出錯(cuò)，這時(shí)候可以考慮做一個(gè)軟連接別名。

測(cè)試

開篇說(shuō)過，接口都是用PHP做的，不過請(qǐng)求里的Gzip數(shù)據(jù)是用LUA處理的，如何讓PHP使用LUA處理后的數(shù)據(jù)呢？不同的語(yǔ)言似乎是個(gè)難題，好在Nginx有Phases一說(shuō)，PHP作為FastCGI模塊工作在content階段，LUA可以工作在access階段，這樣它們就和諧了：

location ~ \.php$ {
  access_by_lua_file /path/to/lua/file;

  include fastcgi.conf;
  fastcgi_pass 127.0.0.1:9000;
}

那么lua-zlib和lua-files兩種方案效率如何？下面是我用PHP寫的測(cè)試腳本：

<?php

$url = 'http://url';

$header = implode("\r\n", array(
  'Content-Type: application/x-www-form-urlencoded',
  'Content-Encoding: gzip',
  'Connection: close',
));

$content = gzencode(http_build_query(array(
  'foo' => str_repeat('x', 100),
  'bar' => str_repeat('y', 100),
)));

$options = array(
  'http' => array(
    'protocol_version' => '1.1',
    'method' => 'POST',
    'header' => $header,
    'content' => $content,
  ),
);

$context = stream_context_create($options);

for ($i = 0; $i < 1000; $i++) {
  file_get_contents($url, false, $context);
}

?>

很多人寫測(cè)試腳本的時(shí)候，喜歡在開始結(jié)束部分加上時(shí)間，這樣相減就得到了代碼實(shí)際運(yùn)行的時(shí)間，其實(shí)這是不必要的，利用Linux自帶的time就可以獲取運(yùn)行時(shí)間：

shell> time php /path/to/php/file

最新評(píng)論