Nginx 為什麼這麼快？

來源：rrd.me/ggFBd

Nginx 是一個免費的，開源的，高效能的 HTTP 伺服器和反向代理，以及 IMAP / POP3 代理伺服器。Nginx 以其高效能，穩定性，豐富的功能，簡單的配置和低資源消耗而聞名。本文從底層原理分析 Nginx 為什麼這麼快！

Nginx 伺服器，正常執行過程中：

• 多程式：一個 Master 程式、多個 Worker 程式。

• Master 程式：管理 Worker 程式。對外介面：接收外部的操作（訊號）；對內轉發：根據外部的操作的不同，透過訊號管理 Worker；監控：監控 Worker 程式的執行狀態，Worker 程式異常終止後，自動重啟 Worker 程式。

• Worker 程式：所有 Worker 程式都是平等的。實際處理：網路請求，由 Worker 程式處理。Worker 程式數量：在 nginx.conf 中配置，一般設定為核心數，充分利用 CPU 資源，同時，避免程式數量過多，避免程式競爭 CPU 資源，增加上下文切換的損耗。

• 請求是連線到 Nginx，Master 程式負責處理和轉發？

• 如何選定哪個 Worker 程式處理請求？請求的處理結果，是否還要經過 Master 程式？

HTTP 連線建立和請求處理過程如下：

• Nginx 啟動時，Master 程式，載入配置檔案。

• Master 程式，初始化監聽的 Socket。

• Master 程式，Fork 出多個 Worker 程式。

• Worker 程式，競爭新的連線，獲勝方透過三次握手，建立 Socket 連線，並處理請求。

• Nginx 採用多程式+非同步非阻塞方式（IO 多路複用 Epoll）。

• 請求的完整過程：建立連線→讀取請求→解析請求→處理請求→響應請求。

• 請求的完整過程對應到底層就是：讀寫 Socket 事件。

• 接收請求：逐行讀取請求行和請求頭，判斷段有請求體後，讀取請求體。

• 處理請求。

• 返回響應：根據處理結果，生成相應的 HTTP 請求（響應行、響應頭、響應體）。

Nginx 也是這個套路，整體流程一致：

模組化體系結構

①event module：搭建了獨立於作業系統的事件處理機制的框架，及提供了各具體事件的處理。包括 ngx_events_module，ngx_event_core_module 和 ngx_epoll_module 等。

Nginx 具體使用何種事件處理模組，這依賴於具體的作業系統和編譯選項。

②phase handler：此型別的模組也被直接稱為 handler 模組。主要負責處理客戶端請求併產生待響應內容，比如 ngx_http_static_module 模組，負責客戶端的靜態頁面請求處理並將對應的磁碟檔案準備為響應內容輸出。

③output filter：也稱為 filter 模組，主要是負責對輸出的內容進行處理，可以對輸出進行修改。

例如，可以實現對輸出的所有 html 頁面增加預定義的 footbar 一類的工作，或者對輸出的圖片的 URL 進行替換之類的工作。

④upstream：upstream 模組實現反向代理的功能，將真正的請求轉發到後端伺服器上，並從後端伺服器上讀取響應，發回客戶端。

upstream 模組是一種特殊的 handler，只不過響應內容不是真正由自己產生的，而是從後端伺服器上讀取的。

⑤load-balancer：負載均衡模組，實現特定的演算法，在眾多的後端伺服器中，選擇一個伺服器出來作為某個請求的轉發伺服器。

• IO 多路複用，Epoll（freebsd 上是 kqueue）

• 高效能

• 高併發

• 佔用系統資源少

• 阻塞+多程式/多執行緒

• 更穩定，Bug 少

• 模組更豐富

參考文章：

http://

https://

• Nginx 是多程式模型，Worker 程式用於處理請求。

• 單個程式的連線數（檔案描述符 fd），有上限（nofile）：ulimit -n。

• Nginx 上配置單個 Worker 程式的最大連線數：worker_connections 上限為 nofile。

• Nginx 上配置 Worker 程式的數量：worker_processes。

• Nginx 的最大連線數：Worker 程式數量 x 單個 Worker 程式的最大連線數。

• 上面是 Nginx 作為通用伺服器時，最大的連線數。

• Nginx 作為反向代理伺服器時，能夠服務的最大連線數：（Worker 程式數量 x 單個 Worker 程式的最大連線數）/ 2。

• Nginx 反向代理時，會建立 Client 的連線和後端 Web Server 的連線，佔用 2 個連線。

• 每開啟一個 Socket 佔用一個 fd？

• 為什麼，一個程式能夠開啟的 fd 數量有限制？

HTTP 請求：

• 請求行：method、uri、http version

• 請求頭

• 請求體

HTTP 響應：

• 響應行：http version、status code

• 響應頭

• 響應體

• IO 多路複用：一個執行緒，跟蹤多個 Socket 狀態，哪個就緒，就讀寫哪個。

• 阻塞 IO+多執行緒：每一個請求，新建一個服務執行緒。

• IO 多路複用：單個連線的請求處理速度沒有優勢。

• 大併發量：只使用一個執行緒，處理大量的併發請求，降低上下文環境切換損耗，也不需要考慮併發問題，相對可以處理更多的請求。

• 消耗更少的系統資源（不需要執行緒排程開銷）。

• 適用於長連線的情況（多執行緒模式長連線容易造成執行緒過多，造成頻繁排程）。

• 阻塞 IO +多執行緒：實現簡單，可以不依賴系統呼叫。

• 每個執行緒，都需要時間和空間。

• 執行緒數量增長時，執行緒排程開銷指數增長。

select/poll 和 epoll 比較如下：

詳細內容，參考：

https://www.cnblogs.com/wiessharling/p/4106295.html

select/poll 系統呼叫：

// select 系統呼叫
int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout); 
// poll 系統呼叫
int poll(struct pollfd fds[], nfds_t nfds, int timeout)；

• 查詢 fd_set 中，是否有就緒的 fd，可以設定一個超時時間，當有 fd (File descripter) 就緒或超時返回。

• fd_set 是一個位集合，大小是在編譯核心時的常量，預設大小為 1024。

• 特點：連線數限制，fd_set 可表示的 fd 數量太小了；線性掃描：判斷 fd 是否就緒，需要遍歷一邊 fd_set；資料複製：使用者空間和核心空間，複製連線就緒狀態資訊。

• 解決了連線數限制：poll 中將 select 中的 fd_set 替換成了一個 pollfd 陣列，解決 fd 數量過小的問題。

• 資料複製：使用者空間和核心空間，複製連線就緒狀態資訊。

• 事件機制：避免線性掃描，為每個 fd，註冊一個監聽事件，fd 變更為就緒時，將 fd 新增到就緒連結串列。

• fd 數量：無限制（OS 級別的限制，單個程式能開啟多少個 fd）。

• I/O 多路複用的機制。

• I/O 多路複用就透過一種機制，可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程式進行相應的讀寫操作；監視多個檔案描述符。

• 但 select，poll，epoll 本質上都是同步 I/O：使用者程式負責讀寫（從核心空間複製到使用者空間），讀寫過程中，使用者程式是阻塞的；非同步 IO，無需使用者程式負責讀寫，非同步 IO，會負責從核心空間複製到使用者空間。