Nginx的原理是什么

這篇文章主要介紹“Nginx的原理是什么”，在日常操作中，相信很多人在Nginx的原理是什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對大家解答”Nginx的原理是什么”的疑惑有所幫助！接下來(lái)，請跟著(zhù)小編一起來(lái)學(xué)習吧！

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

Nginx 的進(jìn)程模型

Nginx ，正常運行過(guò)程中：

1. 多進(jìn)程：一個(gè) Master 進(jìn)程、多個(gè) Worker 進(jìn)程

2. Master 進(jìn)程：管理 Worker 進(jìn)程

1. 對外接口：接收外部的操作（信號）

2. 對內轉發(fā)：根據外部的操作的不同，通過(guò)信號管理 Worker

3. 監控：監控 worker 進(jìn)程的運行狀態(tài)，worker 進(jìn)程異常終止后，自動(dòng)重啟 worker 進(jìn)程

3. Worker 進(jìn)程：所有 Worker 進(jìn)程都是平等的

1. 實(shí)際處理：網(wǎng)絡(luò )請求，由 Worker 進(jìn)程處理；

2. Worker 進(jìn)程數量：在 nginx.conf 中配置，一般設置為核心數，充分利用 CPU 資源，同時(shí)，避免進(jìn)程數量過(guò)多，避免進(jìn)程競爭 CPU 資源，增加上下文切換的損耗。

思考：

1. 請求是連接到 Nginx，Master 進(jìn)程負責處理和轉發(fā)？

2. 如何選定哪個(gè) Worker 進(jìn)程處理請求？請求的處理結果，是否還要經(jīng)過(guò) Master 進(jìn)程？

HTTP 連接建立和請求處理過(guò)程：

1. Nginx 啟動(dòng)時(shí)，Master 進(jìn)程，加載配置文件

2. Master 進(jìn)程，初始化監聽(tīng)的 socket

3. Master 進(jìn)程，fork 出多個(gè) Worker 進(jìn)程

4. Worker 進(jìn)程，競爭新的連接，獲勝方通過(guò)三次握手，建立 Socket 連接，并處理請求

Nginx 高性能、高并發(fā)：

1. Nginx 采用：多進(jìn)程 + 異步非阻塞方式（IO 多路復用 epoll）

2. 請求的完整過(guò)程：

1. 建立連接

2. 讀取請求：解析請求

3. 處理請求

4. 響應請求

3. 請求的完整過(guò)程，對應到底層，就是：讀寫(xiě) socket 事件

Nginx 的事件處理模型 

request：Nginx 中 http 請求。

基本的 HTTP Web Server 工作模式：

1. 接收請求：逐行讀取請求行和請求頭，判斷段有請求體后，讀取請求體

2. 處理請求

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

Nginx 也是這個(gè)套路，整體流程一致。

模塊化體系結構

nginx的模塊根據其功能基本上可以分為以下幾種類(lèi)型：

• event module: 搭建了獨立于操作系統的事件處理機制的框架，及提供了各具體事件的處理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊，這依賴(lài)于具體的操作系統和編譯選項。

• phase handler: 此類(lèi)型的模塊也被直接稱(chēng)為handler模塊。主要負責處理客戶(hù)端請求并產(chǎn)生待響應內容，比如ngx_http_static_module模塊，負責客戶(hù)端的靜態(tài)頁(yè)面請求處理并將對應的磁盤(pán)文件準備為響應內容輸出。

• output filter: 也稱(chēng)為filter模塊，主要是負責對輸出的內容進(jìn)行處理，可以對輸出進(jìn)行修改。例如，可以實(shí)現對輸出的所有html頁(yè)面增加預定義的footbar一類(lèi)的工作，或者對輸出的圖片的URL進(jìn)行替換之類(lèi)的工作。

• upstream: upstream模塊實(shí)現反向代理的功能，將真正的請求轉發(fā)到后端服務(wù)器上，并從后端服務(wù)器上讀取響應，發(fā)回客戶(hù)端。upstream模塊是一種特殊的handler，只不過(guò)響應內容不是真正由自己產(chǎn)生的，而是從后端服務(wù)器上讀取的。

• load-balancer: 模塊，實(shí)現特定的算法，在眾多的后端服務(wù)器中，選擇一個(gè)服務(wù)器出來(lái)作為某個(gè)請求的轉發(fā)服務(wù)器。

常見(jiàn)問(wèn)題剖析

Nginx vs. Apache

nginx vs. apache：

• http://www.oschina.net/translate/nginx-vs-apache

網(wǎng)絡(luò ) IO 模型：

1. nginx：IO 多路復用，epoll(freebsd 上是 kqueue )

1. 高性能

2. 高并發(fā)

3. 占用系統資源少

2. apache：阻塞 + 多進(jìn)程/多線(xiàn)程

1. 更穩定，bug 少

2. 模塊更豐富

參考：https://www.zhihu.com/question/19571087

場(chǎng)景：

處理多個(gè)請求時(shí)，可以采用：IO 多路復用 或者 阻塞 IO +多線(xiàn)程

1. IO 多路服用：一個(gè) 線(xiàn)程，跟蹤多個(gè) socket 狀態(tài)，哪個(gè)就緒，就讀寫(xiě)哪個(gè)；

2. 阻塞 IO + 多線(xiàn)程：每一個(gè)請求，新建一個(gè)服務(wù)線(xiàn)程 

思考：IO 多路復用 和 多線(xiàn)程 的適用場(chǎng)景？

• IO 多路復用：?jiǎn)蝹€(gè)連接的請求處理速度沒(méi)有優(yōu)勢，適合 IO 密集型 場(chǎng)景，事件驅動(dòng)

• 大并發(fā)量：只使用一個(gè)線(xiàn)程，處理大量的并發(fā)請求，降低上下文環(huán)境切換損耗，也不需要考慮并發(fā)問(wèn)題，相對可以處理更多的請求；

• 消耗更少的系統資源（不需要線(xiàn)程調度開(kāi)銷(xiāo)）

• 適用于長(cháng)連接的情況（多線(xiàn)程模式長(cháng)連接容易造成線(xiàn)程過(guò)多，造成頻繁調度）

• 阻塞IO + 多線(xiàn)程：實(shí)現簡(jiǎn)單，可以不依賴(lài)系統調用，適合 CPU 密集型 場(chǎng)景

• 每個(gè)線(xiàn)程，都需要時(shí)間和空間；

• 線(xiàn)程數量增長(cháng)時(shí)，線(xiàn)程調度開(kāi)銷(xiāo)指數增長(cháng)

Nginx 最大連接數

基礎背景：

1. Nginx 是多進(jìn)程模型，Worker 進(jìn)程用于處理請求；

2. 單個(gè)進(jìn)程的連接數（文件描述符 fd），有上限（nofile）：ulimit -n

3. Nginx 上配置單個(gè) worker 進(jìn)程的最大連接數：worker_connections 上限為 nofile

4. Nginx 上配置 worker 進(jìn)程的數量：worker_processes

因此，Nginx 的最大連接數：

1. Nginx 的最大連接數：Worker 進(jìn)程數量 x 單個(gè) Worker 進(jìn)程的最大連接數

2. 上面是 Nginx 作為通用服務(wù)器時(shí)，最大的連接數

3. Nginx 作為反向代理服務(wù)器時(shí)，能夠服務(wù)的最大連接數：（Worker 進(jìn)程數量 x 單個(gè) Worker 進(jìn)程的最大連接數）/ 2。

4. Nginx 反向代理時(shí)，會(huì )建立 Client 的連接和后端 Web Server 的連接，占用 2 個(gè)連接

思考：

1. 每打開(kāi)一個(gè) socket 占用一個(gè) fd

2. 為什么，一個(gè)進(jìn)程能夠打開(kāi)的 fd 數量有限制？

附錄

HTTP 請求和響應

• HTTP 請求：

1. 請求行：method、uri、http version

2. 請求頭

3. 請求體

• HTTP 響應：

1. 響應行：http version、status code

2. 響應頭

3. 響應體

IO 模型

場(chǎng)景：

處理多個(gè)請求時(shí)，可以采用：IO 多路復用 或者 阻塞 IO +多線(xiàn)程

1. IO 多路服用：一個(gè) 線(xiàn)程，跟蹤多個(gè) socket 狀態(tài)，哪個(gè)就緒，就讀寫(xiě)哪個(gè)；

2. 阻塞 IO + 多線(xiàn)程：每一個(gè)請求，新建一個(gè)服務(wù)線(xiàn)程

思考：IO 多路復用 和 多線(xiàn)程 的適用場(chǎng)景？

• IO 多路復用：?jiǎn)蝹€(gè)連接的請求處理速度沒(méi)有優(yōu)勢

• 大并發(fā)量：只使用一個(gè)線(xiàn)程，處理大量的并發(fā)請求，降低上下文環(huán)境切換損耗，也不需要考慮并發(fā)問(wèn)題，相對可以處理更多的請求；

• 消耗更少的系統資源（不需要線(xiàn)程調度開(kāi)銷(xiāo)）

• 適用于長(cháng)連接的情況（多線(xiàn)程模式長(cháng)連接容易造成線(xiàn)程過(guò)多，造成頻繁調度）

• 阻塞IO + 多線(xiàn)程：實(shí)現簡(jiǎn)單，可以不依賴(lài)系統調用。

• 每個(gè)線(xiàn)程，都需要時(shí)間和空間；

• 線(xiàn)程數量增長(cháng)時(shí)，線(xiàn)程調度開(kāi)銷(xiāo)指數增長(cháng)

select/poll 和 epoll 比較

詳細內容，參考：

• select poll epoll三者之間的比較

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：

• 查詢(xún) fd_set 中，是否有就緒的 fd，可以設定一個(gè)超時(shí)時(shí)間，當有 fd (File descripter) 就緒或超時(shí)返回；

• fd_set 是一個(gè)位集合，大小是在編譯內核時(shí)的常量，默認大小為 1024

• 特點(diǎn)：

• 連接數限制，fd_set 可表示的 fd 數量太小了；

• 線(xiàn)性?huà)呙?/strong>：判斷 fd 是否就緒，需要遍歷一邊 fd_set；

• 數據復制：用戶(hù)空間和內核空間，復制連接就緒狀態(tài)信息

poll：

• 解決了連接數限制：

• poll 中將 select 中的 fd_set 替換成了一個(gè) pollfd 數組

• 解決 fd 數量過(guò)小的問(wèn)題

• 數據復制：用戶(hù)空間和內核空間，復制連接就緒狀態(tài)信息

epoll： event 事件驅動(dòng)

• 事件機制：避免線(xiàn)性?huà)呙?/strong>

• 為每個(gè) fd，注冊一個(gè)監聽(tīng)事件

• fd 變更為就緒時(shí)，將 fd 添加到就緒鏈表

• fd 數量：無(wú)限制（OS 級別的限制，單個(gè)進(jìn)程能打開(kāi)多少個(gè) fd）

select，poll，epoll：

1. I/O多路復用的機制；

2. I/O多路復用就通過(guò)一種機制，可以監視多個(gè)描述符，一旦某個(gè)描述符就緒（一般是讀就緒或者寫(xiě)就緒），能夠通知程序進(jìn)行相應的讀寫(xiě)操作。

1. 監視多個(gè)文件描述符

3. 但select，poll，epoll本質(zhì)上都是同步I/O：

1. 用戶(hù)進(jìn)程負責讀寫(xiě)（從內核空間拷貝到用戶(hù)空間），讀寫(xiě)過(guò)程中，用戶(hù)進(jìn)程是阻塞的；

2. 異步 IO，無(wú)需用戶(hù)進(jìn)程負責讀寫(xiě)，異步IO，會(huì )負責從內核空間拷貝到用戶(hù)空間；

Nginx 的并發(fā)處理能力

關(guān)于 Nginx 的并發(fā)處理能力：并發(fā)連接數，一般優(yōu)化后，峰值能保持在 1~3w 左右。（內存和 CPU 核心數不同，會(huì )有進(jìn)一步優(yōu)化空間）