上一篇文章我寫(xiě)了 Nginx 的 11 個(gè)階段，很多人都說(shuō)太長(zhǎng)了。這是出于文章完整性的考慮的，11 個(gè)階段嘛，一次性說(shuō)完就完事了。今天這篇文章比較短，看完沒(méi)問(wèn)題。
過(guò)濾模塊的位置
之前我們介紹了 Nginx 的 11 個(gè)階段，在 content 階段時(shí)，Nginx 會(huì)生成返回給用戶的響應(yīng)內(nèi)容，對(duì)用戶的響應(yīng)內(nèi)容，實(shí)際上還需要做再加工處理，Nginx 的過(guò)濾模塊就是對(duì)響應(yīng)內(nèi)容進(jìn)行再加工處理的。所以實(shí)際上過(guò)濾模塊位于 content 階段之后，log 階段之前。
我們先來(lái)看一段配置指令：
limit_req zone=req_one
burst=120;
limit_conn c_zone 1;
satisfy any;
allow 192.168.1.0/32;
auth_basic_user_file access.pass;
gzip on;
image_filter resize 80 80;
那么在這一段配置指令之下，會(huì)遵循怎樣的請(qǐng)求流程呢？請(qǐng)看一下下面這張圖：
上面這張圖的流程大致說(shuō)一下，如果對(duì)于 Nginx 的 11 個(gè)階段不了解的去翻一下之前的文章。
我這里再簡(jiǎn)單說(shuō)一下。首先由 Nginx 框架接收 HTTP 請(qǐng)求，經(jīng)過(guò) preaccess、access、content 階段的處理，當(dāng)經(jīng)過(guò) static 模塊之后生成響應(yīng)的時(shí)候，很多時(shí)候需要對(duì)響應(yīng)進(jìn)行處理，然后才會(huì)返回給客戶端。
這里我們假如響應(yīng)是一張圖片的話，那么需要做縮略圖的時(shí)候，首先就要經(jīng)過(guò) image_filter 模塊的處理。這里面還有一個(gè) gzip 模塊，這兩個(gè)模塊也是需要遵循嚴(yán)格的順序的。因?yàn)槿绻茸?gzip 壓縮的話，縮略圖后面就沒(méi)辦法做了。
第二個(gè)需要關(guān)注的地方是，首先對(duì) header 進(jìn)行過(guò)濾，再對(duì) body 進(jìn)行過(guò)濾。因?yàn)槲覀冊(cè)趯?duì)用戶發(fā)送響應(yīng)的時(shí)候，一定是先發(fā)送 header，然后再發(fā)送 body，所以所有的過(guò)濾模塊都會(huì)提供對(duì) header 或 body 的過(guò)濾，當(dāng)然 image_filter 和 gzip 模塊對(duì)這兩者都可以過(guò)濾。
返回響應(yīng)
前面我們說(shuō)過(guò)，Nginx 的 11 個(gè)階段是有嚴(yán)格的順序的，而這個(gè)順序是在 Nginx 的代碼中以一個(gè)數(shù)組的形式存在的，這個(gè)數(shù)組的順序是從后往前。在給用戶返回響應(yīng)的時(shí)候，過(guò)濾模塊也是有嚴(yán)格順序的，這個(gè)順序同樣是從后往前。來(lái)看一下在代碼中的定義，標(biāo)紅的是我下面會(huì)提到的幾個(gè)過(guò)濾模塊。
我們需要重點(diǎn)關(guān)注四個(gè)過(guò)濾模塊，它們分別的作用是啥呢？
- copy_filter：復(fù)制包體內(nèi)容 當(dāng)我們使用 sendfile 指令的時(shí)候，也就是零拷貝技術(shù)，不經(jīng)過(guò)用戶態(tài)內(nèi)存，這里就是不經(jīng)過(guò) Nginx 直接發(fā)給用戶，同時(shí)也用了 gzip 模塊的時(shí)候，gzip 是必須在 copy_filter 模塊之后的，因?yàn)?gzip 必須對(duì)內(nèi)存中的數(shù)據(jù)做壓縮，這時(shí) copy_filter 就會(huì)讓 sendfile 指令失效。有些模塊不需要對(duì)內(nèi)存中的數(shù)據(jù)進(jìn)行處理，就需要在 copy_filter 模塊之前進(jìn)行處理。
- postpone_filter：處理子請(qǐng)求 用來(lái)處理子請(qǐng)求，有些過(guò)濾模塊需要關(guān)心子請(qǐng)求的處理結(jié)果，需要放在該模塊之后。
- header_filter：構(gòu)造響應(yīng)頭部 用來(lái)構(gòu)造最終發(fā)送給用戶的響應(yīng)頭部，可能會(huì)添加一些 Server，Nginx 版本號(hào)等內(nèi)容。
- write_filter：發(fā)送響應(yīng) 用來(lái)實(shí)際調(diào)用操作系統(tǒng)的 write 或 send 等系統(tǒng)調(diào)用，來(lái)把響應(yīng)實(shí)際發(fā)送出去。
介紹完了過(guò)濾模塊的功能以及所處的階段，下面來(lái)具體看兩個(gè)模塊。
sub 模塊
介紹一個(gè)可以替換響應(yīng)中字符串內(nèi)容的模塊：sub 模塊。
- 功能：將響應(yīng)中指定的字符串，替換成新的字符串
- 模塊：ngx_http_sub_filter_module 模塊，默認(rèn)未編譯進(jìn) Nginx，通過(guò) --with-http_sub_module 啟用
指令
Syntax: sub_filter string replacement;
Default: —
Context: http, server, location
Syntax: sub_filter_last_modified on | off;
Default: sub_filter_last_modified off;
Context: http, server, location
Syntax: sub_filter_once on | off;
Default: sub_filter_once on;
Context: http, server, location
Syntax: sub_filter_types mime-type ...;
Default: sub_filter_types text/html;
Context: http, server, location
來(lái)解釋一下這四個(gè)指令都是啥意思。
- sub_filter string replacement sub_filter 指令會(huì)把匹配到的 string 字符串替換成 replacement 表示的字符串。
- sub_filter_last_modified on | off sub_filter_last_modified 指令的意思是，是否要返回原來(lái)的 last_modified HTTP 頭部，因?yàn)槲覀円呀?jīng)修改了文件內(nèi)容，如果是 on 的話，就會(huì)繼續(xù)返回原來(lái)的頭部。
- sub_filter_once on | off sub_filter_once 的意思是，是否只替換一次，默認(rèn)打開(kāi)，如果設(shè)置為 off 的話，那就會(huì)將響應(yīng)中的內(nèi)容全部掃描一遍并替換。
- sub_filter_types mime-type 這個(gè)指令是說(shuō)針對(duì)那些文件類(lèi)型進(jìn)行替換，這里可以設(shè)置成 *，但是效率就會(huì)比較低了，需要根據(jù)實(shí)際情況考慮。
實(shí)戰(zhàn)
配置文件如下：
server {
server_name sub.ziyang.com;
error_log logs/myerror.log info;
location / {
sub_filter 'Nginx.oRg' '$host/nginx';
sub_filter 'nginX.cOm' '$host/nginx';
#sub_filter_once on;
sub_filter_once off;
#sub_filter_last_modified off;
sub_filter_last_modified on;
}
}
這里需要重新編譯 Nginx，我這里把下一節(jié)需要的模塊也一起編譯進(jìn)去了：
./configure --prefix=/Users/mtdp/myproject/nginx/test_nginx --with-http_sub_module --with-http_addition_module --with-http_realip_module
make
cp nginx ../../test_nginx/sbin/ # 復(fù)制編譯好的 nginx 到之前的目錄
執(zhí)行熱部署：
熱部署的流程詳見(jiàn) Nginx 入門(mén)及命令行操作
kill -USR2 87693 # 使用新的 Nginx 二進(jìn)制文件提供服務(wù)
kill -WINCH 87693 # 退出老的 Nginx 的 worker 進(jìn)程
kill -quit 87693 # 優(yōu)雅的退出老的 master 進(jìn)程
在瀏覽器中打開(kāi) sub.ziyang.com：
這里面會(huì)發(fā)現(xiàn)，nginx.org 已經(jīng)替換成了 sub.ziyang.com/nginx，nginx.com 也替換成了 sub.ziyang.com/nginx。
addition 模塊
下面再來(lái)看一個(gè)過(guò)濾模塊，addition 模塊，它可以在響應(yīng)的前后添加內(nèi)容。
- 功能：在相應(yīng)前或者響應(yīng)后增加內(nèi)容，增加內(nèi)容的方式，是通過(guò)新增子請(qǐng)求，根據(jù)子請(qǐng)求的響應(yīng)來(lái)完成。
- 模塊：ngx_http_addition_filter_module 默認(rèn)未編譯進(jìn) Nginx，通過(guò) --with-http_addition_module 啟用
指令
Syntax: add_before_body uri;
Default: —
Context: http, server, location
Syntax: add_after_body uri;
Default: —
Context: http, server, location
Syntax: addition_types mime-type ...;
Default: addition_types text/html;
Context: http, server, location
這里的三個(gè)指令都比較簡(jiǎn)單，說(shuō)一下 add_before_body 和 add_after_body 后面的 uri，這個(gè)的意思是說(shuō)，向指定 uri 發(fā)起子請(qǐng)求，根據(jù)子請(qǐng)求的響應(yīng)來(lái)添加內(nèi)容。
addition_types 指令是指定要添加的文件類(lèi)型。
實(shí)戰(zhàn)
配置文件如下：
server {
server_name addition.ziyang.com;
error_log logs/myerror.log info;
location / {
#add_before_body /before_action;
#add_after_body /after_action;
#addition_types *;
}
location /before_action {
return 200 'new content beforen';
}
location /after_action {
return 200 'new content aftern';
}
location /testhost {
uninitialized_variable_warn on;
set $foo 'testhost';
return 200 '$gzip_ration';
}
}
先看在注釋掉 addition 模塊的指令的情況下，會(huì)是什么效果：
? ~ curl addition.ziyang.com/a.txt
a
然后打開(kāi)注釋?zhuān)?/p>
? ~ curl addition.ziyang.com/a.txt
new content before
a
new content after
在原響應(yīng)前后都增加了內(nèi)容。
這里面需要注意一點(diǎn)，在實(shí)際情況下，add_before_body 和 add_after_body 后面是其他的 uri，我這里為了簡(jiǎn)化，直接轉(zhuǎn)發(fā)到對(duì)應(yīng)的 location。
本文涉及到的所有配置文件我已經(jīng)放在了 Nginx 配置文件，大家可以自取。
本文首發(fā)于我的個(gè)人博客：iziyang.github.io
