Nginx 以其高性能，穩定性，豐富的功能，簡單的配置和低資源消耗而聞名。本文從底層原理分析 Nginx 為什麼這麼快！

Nginx 服務器，正常運行過程中：

• 多進程：一個 Master 進程、多個 Worker 進程。
• Master 進程：管理 Worker 進程。對外接口：接收外部的操作（信号）；對内轉發：根據外部的操作的不同，通過信号管理 Worker；監控：監控 Worker 進程的運行狀态，Worker 進程異常終止後，自動重啟 Worker 進程。
• Worker 進程：所有 Worker 進程都是平等的。實際處理：網絡請求，由 Worker 進程處理。Worker 進程數量：在 nginx.conf 中配置，一般設置為核心數，充分利用 CPU 資源，同時，避免進程數量過多，避免進程競争 CPU 資源，增加上下文切換的損耗。

思考：

• 請求是連接到 Nginx，Master 進程負責處理和轉發？
• 如何選定哪個 Worker 進程處理請求？請求的處理結果，是否還要經過 Master 進程？

• Nginx 啟動時，Master 進程，加載配置文件。
• Master 進程，初始化監聽的 Socket。
• Master 進程，Fork 出多個 Worker 進程。
• Worker 進程，競争新的連接，獲勝方通過三次握手，建立 Socket 連接，并處理請求。

Nginx 為什麼擁有高性能并且能夠支撐高并發？

• Nginx 采用多進程 異步非阻塞方式（IO 多路複用 Epoll）。
• 請求的完整過程：建立連接→讀取請求→解析請求→處理請求→響應請求。
• 請求的完整過程對應到底層就是：讀寫 Socket 事件。

Request：Nginx 中 HTTP 請求。

基本的 HTTP Web Server 工作模式：

• 接收請求：逐行讀取請求行和請求頭，判斷段有請求體後，讀取請求體。
• 處理請求。
• 返回響應：根據處理結果，生成相應的 HTTP 請求（響應行、響應頭、響應體）。

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

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：負載均衡模塊，實現特定的算法，在衆多的後端服務器中，選擇一個服務器出來作為某個請求的轉發服務器。

Nginx vs Apache

Nginx：

• IO 多路複用，Epoll（freebsd 上是 kqueue）
• 高性能
• 高并發
• 占用系統資源少

Apache：

• 阻塞 多進程/多線程
• 更穩定，Bug 少
• 模塊更豐富

Nginx 最大連接數

基礎背景：

• Nginx 是多進程模型，Worker 進程用于處理請求。
• 單個進程的連接數（文件描述符 fd），有上限（nofile）：ulimit -n。
• Nginx 上配置單個 Worker 進程的最大連接數：worker_connections 上限為 nofile。
• Nginx 上配置 Worker 進程的數量：worker_processes。

因此，Nginx 的最大連接數：

• Nginx 的最大連接數：Worker 進程數量 x 單個 Worker 進程的最大連接數。
• 上面是 Nginx 作為通用服務器時，最大的連接數。
• Nginx 作為反向代理服務器時，能夠服務的最大連接數：（Worker 進程數量 x 單個 Worker 進程的最大連接數）/ 2。
• Nginx 反向代理時，會建立 Client 的連接和後端 Web Server 的連接，占用 2 個連接。

思考：

• 每打開一個 Socket 占用一個 fd？
• 為什麼，一個進程能夠打開的 fd 數量有限制？

HTTP 請求和響應

• 請求行：method、uri、http version
• 請求頭
• 請求體

• 響應行：http version、status code
• 響應頭
• 響應體

IO 模型

處理多個請求時，可以采用：IO 多路複用或者阻塞 IO 多線程：

• IO 多路複用：一個線程，跟蹤多個 Socket 狀态，哪個就緒，就讀寫哪個。
• 阻塞 IO 多線程：每一個請求，新建一個服務線程。

IO 多路複用和多線程的适用場景？

• IO 多路複用：單個連接的請求處理速度沒有優勢。
• 大并發量：隻使用一個線程，處理大量的并發請求，降低上下文環境切換損耗，也不需要考慮并發問題，相對可以處理更多的請求。
• 消耗更少的系統資源（不需要線程調度開銷）。
• 适用于長連接的情況（多線程模式長連接容易造成線程過多，造成頻繁調度）。
• 阻塞 IO 多線程：實現簡單，可以不依賴系統調用。
• 每個線程，都需要時間和空間。
• 線程數量增長時，線程調度開銷指數增長。

select/poll 系統調用：

//select系統調用 intselect(intmaxfdp,fd_set*readfds,fd_set*writefds,fd_set*errorfds,structtimeval*timeout); //poll系統調用 intpoll(structpollfdfds[],nfds_tnfds,inttimeout)；

select：

• 查詢 fd_set 中，是否有就緒的 fd，可以設定一個超時時間，當有 fd (File descripter) 就緒或超時返回。
• fd_set 是一個位集合，大小是在編譯内核時的常量，默認大小為 1024。
• 特點：連接數限制，fd_set 可表示的 fd 數量太小了；線性掃描：判斷 fd 是否就緒，需要遍曆一邊 fd_set；數據複制：用戶空間和内核空間，複制連接就緒狀态信息。

poll：

• 解決了連接數限制：poll 中将 select 中的 fd_set 替換成了一個 pollfd 數組，解決 fd 數量過小的問題。
• 數據複制：用戶空間和内核空間，複制連接就緒狀态信息。

epoll，event 事件驅動：

• 事件機制：避免線性掃描，為每個 fd，注冊一個監聽事件，fd 變更為就緒時，将 fd 添加到就緒鍊表。
• fd 數量：無限制（OS 級别的限制，單個進程能打開多少個 fd）。

select，poll，epoll：

• I/O 多路複用的機制。
• I/O 多路複用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程序進行相應的讀寫操作；監視多個文件描述符。
• 但 select，poll，epoll 本質上都是同步 I/O：用戶進程負責讀寫（從内核空間拷貝到用戶空間），讀寫過程中，用戶進程是阻塞的；異步 IO，無需用戶進程負責讀寫，異步 IO，會負責從内核空間拷貝到用戶空間。

關于 Nginx 的并發處理能力：并發連接數，一般優化後，峰值能保持在 1~3w 左右。（内存和 CPU 核心數不同，會有進一步優化空間）。