指令上下文
nginx.conf中的配置信息，根據(jù)其邏輯上的意義，對它們進(jìn)行了分類，也就是分成了多個作用域，或者稱之為配置指令上下文。不同的作用域含有一個或者多個配置項。
當(dāng)前nginx支持的幾個指令上下文：
main: nginx在運(yùn)行時與具體業(yè)務(wù)功能（比如http服務(wù)或者email服務(wù)代理）無關(guān)的一些參數(shù)，比如工作進(jìn)程數(shù)，運(yùn)行的身份等。
http: 與提供http服務(wù)相關(guān)的一些配置參數(shù)。例如：是否使用keepalive啊，是否使用gzip進(jìn)行壓縮等。
server: http服務(wù)上支持若干虛擬主機(jī)。每個虛擬主機(jī)一個對應(yīng)的server配置項，配置項里面包含該虛擬主機(jī)相關(guān)的配置。在提供mail服務(wù)的代理時，也可以建立若干server. 每個server通過監(jiān)聽的地址來區(qū)分。
location: http服務(wù)中，某些特定的URL對應(yīng)的一系列配置項。
mail: 實現(xiàn)email相關(guān)的SMTP/IMAP/POP3代理時，共享的一些配置項（因為可能實現(xiàn)多個代理，工作在多個監(jiān)聽地址上）。
示例配置：
user nobody;
worker_processes 1;
error_log logs/error.log info;
events {
worker_connections 1024;
}
http {
server {
listen 80;
server_name www.linuxidc.com;
access_log logs/linuxidc.access.log main;
location / {
index index.html;
root /var/www/linuxidc.com/htdocs;
}
}
server {
listen 80;
server_name www.Androidj.com;
access_log logs/androidj.access.log main;
location / {
index index.html;
root /var/www/androidj.com/htdocs;
}
}
}
mail {
auth_http 127.0.0.1:80/auth.php;
pop3_capabilities "TOP" "USER";
imap_capabilities "IMAP4rev1" "UIDPLUS";
server {
listen 110;
protocol pop3;
proxy on;
}
server {
listen 25;
protocol smtp;
proxy on;
smtp_auth login plain;
xclient off;
}
}
存在于main上下文中的配置指令如下:
· user
· worker_processes
· error_log
· events
· http
· mail
存在于http上下文中的指令如下:
· server
存在于mail上下文中的指令如下：
· server
· auth_http
· imap_capabilities
存在于server上下文中的配置指令如下：
· listen
· server_name
· access_log
· location
· protocol
· proxy
· smtp_auth
· xclient
存在于location上下文中的指令如下：
· index
· root
nginx的模塊化體系結(jié)構(gòu)
nginx提供了web服務(wù)器的基礎(chǔ)功能，同時提供了web服務(wù)反向代理，email服務(wù)反向代理功能。nginx core實現(xiàn)了底層的通訊協(xié)議，為其他模塊和nginx進(jìn)程構(gòu)建了基本的運(yùn)行時環(huán)境，并且構(gòu)建了其他各模塊的協(xié)作基礎(chǔ)。除此之外，或者說大部分與協(xié)議相關(guān)的，或者應(yīng)用相關(guān)的功能都是在這些模塊中所實現(xiàn)的。
模塊
nginx將各功能模塊組織成一條鏈，當(dāng)有請求到達(dá)的時候，請求依次經(jīng)過這條鏈上的部分或者全部模塊，進(jìn)行處理。每個模塊實現(xiàn)特定的功能。例如，實現(xiàn)對請求解壓縮的模塊，實現(xiàn)SSI的模塊，實現(xiàn)與上游服務(wù)器進(jìn)行通訊的模塊，實現(xiàn)與FastCGI服務(wù)進(jìn)行通訊的模塊。
有兩個模塊比較特殊，他們居于nginx core和各功能模塊的中間。這兩個模塊就是http模塊和mail模塊。這2個模塊在nginx core之上實現(xiàn)了另外一層抽象，處理與HTTP協(xié)議和email相關(guān)協(xié)議（SMTP/POP3/IMAP）有關(guān)的事件，并且確保這些事件能被以正確的順序調(diào)用其他的一些功能模塊。
目前HTTP協(xié)議是被實現(xiàn)在http模塊中的，但是有可能將來被剝離到一個單獨的模塊中，以擴(kuò)展nginx支持SPDY協(xié)議。
模塊的分類
nginx的模塊根據(jù)其功能基本上可以分為以下幾種類型：
event module
搭建了獨立于操作系統(tǒng)的事件處理機(jī)制的框架，及提供了各具體事件的處理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊，這依賴于具體的操作系統(tǒng)和編譯選項。
phase handler
此類型的模塊也被直接稱為handler模塊。主要負(fù)責(zé)處理客戶端請求并產(chǎn)生待響應(yīng)內(nèi)容，比如ngx_http_static_module模塊，負(fù)責(zé)客戶端的靜態(tài)頁面請求處理并將對應(yīng)的磁盤文件準(zhǔn)備為響應(yīng)內(nèi)容輸出。
output filter
也稱為filter模塊，主要是負(fù)責(zé)對輸出的內(nèi)容進(jìn)行處理，可以對輸出進(jìn)行修改。例如，可以實現(xiàn)對輸出的所有html頁面增加預(yù)定義的footbar一類的工作，或者對輸出的圖片的URL進(jìn)行替換之類的工作。
upstream
upstream模塊實現(xiàn)反向代理的功能，將真正的請求轉(zhuǎn)發(fā)到后端服務(wù)器上，并從后端服務(wù)器上讀取響應(yīng)，發(fā)回客戶端。upstream模塊是一種特殊的handler，只不過響應(yīng)內(nèi)容不是真正由自己產(chǎn)生的，而是從后端服務(wù)器上讀取的。
load-balancer
負(fù)載均衡模塊，實現(xiàn)特定的算法，在眾多的后端服務(wù)器中，選擇一個服務(wù)器出來作為某個請求的轉(zhuǎn)發(fā)服務(wù)器。
nginx的請求處理
nginx使用一個多進(jìn)程模型來對外提供服務(wù)，其中一個master進(jìn)程，多個worker進(jìn)程。master進(jìn)程負(fù)責(zé)管理nginx本身和其他worker進(jìn)程。
所有實際上的業(yè)務(wù)處理邏輯都在worker進(jìn)程。worker進(jìn)程中有一個函數(shù)，執(zhí)行無限循環(huán)，不斷處理收到的來自客戶端的請求，并進(jìn)行處理，直到整個nginx服務(wù)被停止。
worker進(jìn)程中，ngx_worker_process_cycle()函數(shù)就是這個無限循環(huán)的處理函數(shù)。在這個函數(shù)中，一個請求的簡單處理流程如下：
1. 操作系統(tǒng)提供的機(jī)制（例如epoll, kqueue等）產(chǎn)生相關(guān)的事件。
2. 接收和處理這些事件，如是接受到數(shù)據(jù)，則產(chǎn)生更高層的request對象。
3. 處理request的header和body。
4. 產(chǎn)生響應(yīng)，并發(fā)送回客戶端。
5. 完成request的處理。
6. 重新初始化定時器及其他事件。
請求的處理流程
以HTTP Request為例，詳細(xì)地說明nginx中請求處理過程。
從nginx的內(nèi)部來看，一個HTTP Request的處理過程涉及到以下幾個階段：
1. 初始化HTTP Request（讀取來自客戶端的數(shù)據(jù)，生成HTTP Request對象，該對象含有該請求所有的信息）。
2. 處理請求頭。
3. 處理請求體。
4. 如果有的話，調(diào)用與此請求（URL或者Location）關(guān)聯(lián)的handler。
5. 依次調(diào)用各phase handler進(jìn)行處理。
phase字面的意思，就是階段。phase handlers是包含若干個處理階段的一些handler。
在每一個階段，包含有若干個handler，再處理到某個階段的時候，依次調(diào)用該階段的handler對HTTP Request進(jìn)行處理。
通常情況下，一個phase handler對這個request進(jìn)行處理，并產(chǎn)生一些輸出。通常phase handler是與定義在配置文件中的某個location相關(guān)聯(lián)的。一個phase handler通常執(zhí)行以下幾項任務(wù)：
1. 獲取location配置。
2. 產(chǎn)生適當(dāng)?shù)捻憫?yīng)。
3. 發(fā)送response header。
4. 發(fā)送response body。
當(dāng)nginx讀取到一個HTTP Request的header的時候，nginx首先查找與這個請求關(guān)聯(lián)的虛擬主機(jī)的配置。如果找到了這個虛擬主機(jī)的配置，那么通常情況下，這個HTTP Request將會經(jīng)過以下幾個階段的處理（phase handlers）：
NGX_HTTP_POST_READ_PHASE:
讀取請求內(nèi)容階段
NGX_HTTP_SERVER_REWRITE_PHASE:
Server請求地址重寫階段
NGX_HTTP_FIND_CONFIG_PHASE:
配置查找階段:
NGX_HTTP_REWRITE_PHASE:
Location請求地址重寫階段
NGX_HTTP_POST_REWRITE_PHASE:
請求地址重寫提交階段
NGX_HTTP_PREACCESS_PHASE:
訪問權(quán)限檢查準(zhǔn)備階段
NGX_HTTP_ACCESS_PHASE:
訪問權(quán)限檢查階段
NGX_HTTP_POST_ACCESS_PHASE:
訪問權(quán)限檢查提交階段
NGX_HTTP_TRY_FILES_PHASE:
配置項try_files處理階段
NGX_HTTP_CONTENT_PHASE:
內(nèi)容產(chǎn)生階段
NGX_HTTP_LOG_PHASE:
日志模塊處理階段
在內(nèi)容產(chǎn)生階段，為了給一個request產(chǎn)生正確的響應(yīng)，nginx必須把這個request交給一個合適的content handler去處理。如果這個request對應(yīng)的location在配置文件中被明確指定了一個content handler，那么nginx就可以通過對location的匹配，直接找到這個對應(yīng)的handler，并把這個request交給這個content handler去處理。這樣的配置指令包括像，perl，flv，proxy_pass，mp4等。
如果一個request對應(yīng)的location并沒有直接有配置的content handler，那么nginx依次嘗試:
1. 如果一個location里面有配置 random_index on，那么隨機(jī)選擇一個文件，發(fā)送給客戶端。
2. 如果一個location里面有配置 index指令，那么發(fā)送index指令指明的文件，給客戶端。
3. 如果一個location里面有配置 autoindex on，那么就發(fā)送請求地址對應(yīng)的服務(wù)端路徑下的文件列表給客戶端。
4. 如果這個request對應(yīng)的location上有設(shè)置gzip_static on，那么就查找是否有對應(yīng)的.gz文件存在，
有的話，就發(fā)送這個給客戶端（客戶端支持gzip的情況下）。
5. 請求的URI如果對應(yīng)一個靜態(tài)文件，static module就發(fā)送靜態(tài)文件的內(nèi)容到客戶端。
內(nèi)容產(chǎn)生階段完成以后，生成的輸出會被傳遞到filter模塊去進(jìn)行處理。filter模塊也是與location相關(guān)的。所有的fiter模塊都被組織成一條鏈。輸出會依次穿越所有的filter，直到有一個filter模塊的返回值表明已經(jīng)處理完成。
這里列舉幾個常見的filter模塊，例如：
1. server-side includes。
2. XSLT filtering。
3. 圖像縮放之類的。
4. gzip壓縮。
在所有的filter中，有幾個filter模塊需要關(guān)注一下。按照調(diào)用的順序依次說明如下：
write: 寫輸出到客戶端，實際上是寫到連接對應(yīng)的socket上。
postpone: 這個filter是負(fù)責(zé)subrequest的，也就是子請求的。
copy: 將一些需要復(fù)制的buf(文件或者內(nèi)存)重新復(fù)制一份然后交給剩余的body filter處理。
