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

gzip on;#開啟 
gzip_http_version 1.0;#默認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申請內(nèi)存的大小,其作用是按塊大小的倍數(shù)申請內(nèi)存空間設(shè)置gzip申請內(nèi)存的大小,其作用是按塊大小的倍數(shù)申請內(nèi)存空間 
 
# Disable gzip for certain browsers. 
gzip_disable “MSIE [1-6].(?!.*SV1)”;#ie6不支持gzip，需要禁用掉ie6，可惡啊!!!! 

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

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

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

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

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

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

gzip_proxied
Nginx做為反向代理的時候啟用，
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 – 無條件壓縮所有結(jié)果數(shù)據(jù)

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

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

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

第一個選擇是使用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

第二個選擇是通過LuaJIT的FFI庫來包裝ZLIB模塊，官方教程里有一些現(xiàn)成的可供參考的的例子，不過例子里介紹的是Deflate，而不是Gzip，自己用FFI封裝Gzip的話又有點小復雜，好在別人已經(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可能會令人費解，其實你可以把它們理解成輸入輸出接口，可以修改成文件，數(shù)據(jù)庫等等形式。

別高興太早，當你運行時，很可能會遇到如下錯誤：

libzlib.so: cannot open shared object file.

實際上這是因為如下zlib.lua代碼的緣故：

local C = ffi.load 'zlib'

運行時，ffi.load會自動補全文件名，如果是Windows，則加載zlib.dll文件，如果是Linux，則加載libzlib.so，但實際上在Linux下，ZLIB擴展的名字是libz.so，而非libzlib.so。

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

local C

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

有時候我們不推薦直接修改第三方庫的代碼，因為這樣的話，每次第三庫更新代碼，我們都要做對應(yīng)的修改，一旦忘記就會出錯，這時候可以考慮做一個軟連接別名。

測試

開篇說過，接口都是用PHP做的，不過請求里的Gzip數(shù)據(jù)是用LUA處理的，如何讓PHP使用LUA處理后的數(shù)據(jù)呢？不同的語言似乎是個難題，好在Nginx有Phases一說，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寫的測試腳本：

<?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);
}

?>

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

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

最新評論