Nginx 以其高性能，穩定性，豐富的功能，簡單的配置和低資源消耗而聞名。本文從底層原理分析 Nginx 爲何這麼快！html
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 爲何擁有高性能而且可以支撐高併發？apache
- Nginx 採用多進程+異步非阻塞方式（IO 多路複用 Epoll）。
- 請求的完整過程：創建鏈接→讀取請求→解析請求→處理請求→響應請求。
- 請求的完整過程對應到底層就是：讀寫 Socket 事件。
Request：Nginx 中 HTTP 請求。segmentfault
基本的 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 少
- 模塊更豐富
參考文章：
http://www.oschina.net/transl... https://www.zhihu.com/question/19571087
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 請求和響應
HTTP 請求：
- 請求行：method、uri、http version
- 請求頭
- 請求體
HTTP 響應：
- 響應行：http version、status code
- 響應頭
- 響應體
IO 模型
處理多個請求時，能夠採用：IO 多路複用或者阻塞 IO+多線程：
- IO 多路複用： 一個線程，跟蹤多個 Socket 狀態，哪一個就緒，就讀寫哪一個。
- 阻塞 IO+多線程： 每個請求，新建一個服務線程。
IO 多路複用和多線程的適用場景？
- IO 多路複用：單個鏈接的請求處理速度沒有優點。
- 大併發量：只使用一個線程，處理大量的併發請求，下降上下文環境切換損耗，也不須要考慮併發問題，相對能夠處理更多的請求。
- 消耗更少的系統資源（不須要線程調度開銷）。
- 適用於長鏈接的狀況（多線程模式長鏈接容易形成線程過多，形成頻繁調度）。
- 阻塞 IO +多線程：實現簡單，能夠不依賴系統調用。
- 每一個線程，都須要時間和空間。
- 線程數量增加時，線程調度開銷指數增加。
select/poll 和 epoll 比較以下：
詳細內容，參考：
https://www.cnblogs.com/wiess...
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)；
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 核心數不一樣，會有進一步優化空間）