nginx的配置系統(tǒng)由一個主配置文件和其他一些輔助的配置文件構(gòu)成。這些配置文件均是純文本文件，全部位于nginx安裝目錄下的conf目錄下。
配置文件中以#開始的行，或者是前面有若干空格或者TAB，然后再跟#的行，都被認(rèn)為是注釋，也就是只對編輯查看文件的用戶有意義，程序在讀取這些注釋行的時候，其實際的內(nèi)容是被忽略的。
由于除主配置文件nginx.conf以外的文件都是在某些情況下才使用的，而只有主配置文件是在任何情況下都被使用的。所以在這里我們就以主配置文件為例，來解釋nginx的配置系統(tǒng)。
在nginx.conf中，包含若干配置項。每個配置項由配置指令和指令參數(shù)2個部分構(gòu)成。指令參數(shù)也就是配置指令對應(yīng)的配置值。
指令的參數(shù)使用一個或者多個空格或者TAB字符與指令分開。指令的參數(shù)有一個或者多個TOKEN串組成。TOKEN串之間由空格或者TAB鍵分隔。
TOKEN串分為簡單字符串或者是復(fù)合配置塊。復(fù)合配置塊即是由大括號括起來的一堆內(nèi)容。一個復(fù)合配置塊中可能包含若干其他的配置指令。
如果一個配置指令的參數(shù)全部由簡單字符串構(gòu)成，也就是不包含復(fù)合配置塊，那么我們就說這個配置指令是一個簡單配置項，否則稱之為復(fù)雜配置項。例如下面這個是一個簡單配置項：
對于簡單配置，配置項的結(jié)尾使用分號結(jié)束。對于復(fù)雜配置項，包含多個TOKEN串的，一般都是簡單TOKEN串放在前面，復(fù)合配置塊一般位于最后，而且其結(jié)尾，并不需要再添加分號。例如下面這個復(fù)雜配置項：
nginx.conf中的配置信息，根據(jù)其邏輯上的意義，對它們進行了分類，也就是分成了多個作用域，或者稱之為配置指令上下文。不同的作用域含有一個或者多個配置項。
當(dāng)前nginx支持的幾個指令上下文：
| main: | nginx在運行時與具體業(yè)務(wù)功能（比如http服務(wù)或者email服務(wù)代理）無關(guān)的一些參數(shù)，比如工作進程數(shù)，運行的身份等。 |
|---|---|
| http: | 與提供http服務(wù)相關(guān)的一些配置參數(shù)。例如：是否使用keepalive啊，是否使用gzip進行壓縮等。 |
| server: | http服務(wù)上支持若干虛擬主機。每個虛擬主機一個對應(yīng)的server配置項，配置項里面包含該虛擬主機相關(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)聽地址上）。 |
指令上下文，可能有包含的情況出現(xiàn)。例如：通常http上下文和mail上下文一定是出現(xiàn)在main上下文里的。在一個上下文里，可能包含另外一種類型的上下文多次。例如：如果http服務(wù)，支持了多個虛擬主機，那么在http上下文里，就會出現(xiàn)多個server上下文。
我們來看一個示例配置：
在這個配置中，上面提到個五種配置指令上下文都存在。
存在于main上下文中的配置指令如下:
存在于http上下文中的指令如下:
存在于mail上下文中的指令如下：
存在于server上下文中的配置指令如下：
存在于location上下文中的指令如下：
當(dāng)然，這里只是一些示例。具體有哪些配置指令，以及這些配置指令可以出現(xiàn)在什么樣的上下文中，需要參考nginx的使用文檔。
nginx的內(nèi)部結(jié)構(gòu)是由核心部分和一系列的功能模塊所組成。這樣劃分是為了使得每個模塊的功能相對簡單，便于開發(fā)，同時也便于對系統(tǒng)進行功能擴展。為了便于描述，下文中我們將使用nginx core來稱呼nginx的核心功能部分。
nginx提供了web服務(wù)器的基礎(chǔ)功能，同時提供了web服務(wù)反向代理，email服務(wù)反向代理功能。nginx core實現(xiàn)了底層的通訊協(xié)議，為其他模塊和nginx進程構(gòu)建了基本的運行時環(huán)境，并且構(gòu)建了其他各模塊的協(xié)作基礎(chǔ)。除此之外，或者說大部分與協(xié)議相關(guān)的，或者應(yīng)用相關(guān)的功能都是在這些模塊中所實現(xiàn)的。
nginx將各功能模塊組織成一條鏈，當(dāng)有請求到達的時候，請求依次經(jīng)過這條鏈上的部分或者全部模塊，進行處理。每個模塊實現(xiàn)特定的功能。例如，實現(xiàn)對請求解壓縮的模塊，實現(xiàn)SSI的模塊，實現(xiàn)與上游服務(wù)器進行通訊的模塊，實現(xiàn)與FastCGI服務(wù)進行通訊的模塊。
有兩個模塊比較特殊，他們居于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模塊中的，但是有可能將來被剝離到一個單獨的模塊中，以擴展nginx支持SPDY協(xié)議。
nginx的模塊根據(jù)其功能基本上可以分為以下幾種類型：
| event module: | 搭建了獨立于操作系統(tǒng)的事件處理機制的框架，及提供了各具體事件的處理。包括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)容進行處理，可以對輸出進行修改。例如，可以實現(xiàn)對輸出的所有html頁面增加預(yù)定義的footbar一類的工作，或者對輸出的圖片的URL進行替換之類的工作。 |
| 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使用一個多進程模型來對外提供服務(wù)，其中一個master進程，多個worker進程。master進程負(fù)責(zé)管理nginx本身和其他worker進程。
所有實際上的業(yè)務(wù)處理邏輯都在worker進程。worker進程中有一個函數(shù)，執(zhí)行無限循環(huán)，不斷處理收到的來自客戶端的請求，并進行處理，直到整個nginx服務(wù)被停止。
worker進程中，ngx_worker_process_cycle()函數(shù)就是這個無限循環(huán)的處理函數(shù)。在這個函數(shù)中，一個請求的簡單處理流程如下：
為了讓大家更好的了解nginx中請求處理過程，我們以HTTP Request為例，來做一下詳細(xì)地說明。
從nginx的內(nèi)部來看，一個HTTP Request的處理過程涉及到以下幾個階段。
在這里，我們需要了解一下phase handler這個概念。phase字面的意思，就是階段。所以phase handlers也就好理解了，就是包含若干個處理階段的一些handler。
在每一個階段，包含有若干個handler，再處理到某個階段的時候，依次調(diào)用該階段的handler對HTTP Request進行處理。
通常情況下，一個phase handler對這個request進行處理，并產(chǎn)生一些輸出。通常phase handler是與定義在配置文件中的某個location相關(guān)聯(lián)的。
一個phase handler通常執(zhí)行以下幾項任務(wù)：
當(dāng)nginx讀取到一個HTTP Request的header的時候，nginx首先查找與這個請求關(guān)聯(lián)的虛擬主機的配置。如果找到了這個虛擬主機的配置，那么通常情況下，這個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依次嘗試:
內(nèi)容產(chǎn)生階段完成以后，生成的輸出會被傳遞到filter模塊去進行處理。filter模塊也是與location相關(guān)的。所有的fiter模塊都被組織成一條鏈。輸出會依次穿越所有的filter，直到有一個filter模塊的返回值表明已經(jīng)處理完成。
這里列舉幾個常見的filter模塊，例如：
在所有的filter中，有幾個filter模塊需要關(guān)注一下。按照調(diào)用的順序依次說明如下：
| write: | 寫輸出到客戶端，實際上是寫到連接對應(yīng)的socket上。 |
|---|---|
| postpone: | 這個filter是負(fù)責(zé)subrequest的，也就是子請求的。 |
| copy: | 將一些需要復(fù)制的buf(文件或者內(nèi)存)重新復(fù)制一份然后交給剩余的body filter處理。 |
