Nginx以其高性能，穩定性，豐富的功能，簡單的配置和低資源消耗而聞名。本文了解一下?Nginx為什么這么快！

?為了防止不提供原網址的轉載，特加原文鏈接：ningg.top/nginx-series-principle/

Nginx 的進程模型

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

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

• Master 進程：管理 Worker 進程。對外接口：接收外部的操作(信號)；對內轉發：根據外部的操作的不同，通過信號管理 Worker；監控：監控 Worker 進程的運行狀態，Worker 進程異常終止后，自動重啟 Worker 進程。

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

HTTP 連接建立和請求處理過程

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

• Nginx 啟動時，Master 進程，加載配置文件。

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

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

• Worker 進程，競爭新的連接，獲勝方通過三次握手，建立 Socket 連接，并處理請求。

Nginx 高性能、高并發

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

• Nginx 采用多進程+異步非阻塞方式(IO 多路復用 Epoll)。

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

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

Nginx 的事件處理模型

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 少

• 模塊更豐富

場 景：

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

1、IO 多路復用：一個?線程，跟蹤多個 socket 狀態，哪個就緒，就讀寫哪個；

2、阻塞 IO?+?多線程：每一個請求，新建一個服務線程

思考：IO 多路復用?和?多線程?的適用場景？

IO 多路復用：單個連接的請求處理速度沒有優勢，適合?IO 密集型?場景，事件驅動

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

• 消耗更少的系統資源(不需要線程調度開銷)

• 適用于長連接的情況(多線程模式長連接容易造成線程過多，造成頻繁調度)

阻塞IO?+?多線程：實現簡單，可以不依賴系統調用，適合?CPU 密集型場景

• 每個線程，都需要時間和空間；

• 線程數量增長時，線程調度開銷指數增長

參考：

http://www.oschina.net/translate/nginx-vs-apache
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 個連接。

Nginx 的并發處理能力

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

-?end?-

每天進步一點點

慢一點才能更快

總結

以上是生活随笔為你收集整理的nginx 转发慢_为啥 Nginx 能轻松淦到几万并发？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。