Nginx原理解析 一、反向代理 工作流程 1. 用戶通過功能變數名稱發出訪問Web伺服器的請求，該功能變數名稱被DNS伺服器解析為反向代理伺服器的IP地址； 2. 反向代理伺服器接受用戶的請求； 3. 反向代理伺服器在本地緩存中查找請求的內容，找到後直接把內容發送給用戶； 4. 如果本地緩存里沒有用戶所請求的信息 ...
Nginx原理解析
一、反向代理
工作流程
- 用戶通過功能變數名稱發出訪問Web伺服器的請求，該功能變數名稱被DNS伺服器解析為反向代理伺服器的IP地址；
- 反向代理伺服器接受用戶的請求；
- 反向代理伺服器在本地緩存中查找請求的內容，找到後直接把內容發送給用戶；
- 如果本地緩存里沒有用戶所請求的信息內容，反向代理伺服器會代替用戶向源伺服器請求同樣的信息內容，並把信息內容發給用戶，如果信息內容是緩存的還會把它保存到緩存中。
優點
- 保護了真實的web伺服器，保證了web伺服器的資源安全
通常的代理伺服器，只用於代理內部網路對Internet外部網路的連接請求，客戶機必須指定代理伺服器，並將本來要直接發送到Web伺服器上的http請求發送到代理伺服器中。不支持外部網路對內部網路的連接請求，因為內部網路對外部網路是不可見的。當一個代理伺服器能夠代理外部網路上的主機，訪問內部網路時，這種代理服務的方式稱為反向代理服務。此時代理伺服器對外就表現為一個Web伺服器，外部網路就可以簡單把它當作一個標準的Web伺服器而不需要特定的配置。不同之處在於，這個伺服器沒有保存任何網頁的真實數據，所有的靜態網頁或者CGI程式，都保存在內部的Web伺服器上。因此對反向代理伺服器的攻擊並不會使得網頁信息遭到破壞，這樣就增強了Web伺服器的安全性。
- 節約了有限的IP地址資源
企業內所有的網站共用一個在internet中註冊的IP地址，這些伺服器分配私有地址，採用虛擬主機的方式對外提供服務。
- 減少WEB伺服器壓力，提高響應速度
反向代理就是通常所說的web伺服器加速，它是一種通過在繁忙的web伺服器和外部網路之間增加一個高速的web緩衝伺服器來降低實際的web伺服器的負載的一種技術。反向代理是針對web伺服器提高加速功能，作為代理緩存，它並不是針對瀏覽器用戶，而針對一臺或多台特定的web伺服器，它可以代理外部網路對內部網路的訪問請求。
反向代理伺服器會強制將外部網路對要代理的伺服器的訪問經過它，這樣反向代理伺服器負責接收客戶端的請求，然後到源伺服器上獲取內容，把內容返回給用戶，並把內容保存到本地，以便日後再收到同樣的信息請求時，它會把本地緩存里的內容直接發給用戶，以減少後端web伺服器的壓力，提高響應速度。因此Nginx還具有緩存功能。
二、Nginx工作原理
Nginx由內核和模塊組成。
Nginx本身做的工作實際很少，當它接到一個HTTP請求時，它僅僅是通過查找配置文件將此次請求映射到一個location block，而此location中所配置的各個指令則會啟動不同的模塊去完成工作，因此模塊可以看做Nginx真正的勞動工作者。通常一個location中的指令會涉及一個handler模塊和多個filter模塊（當然，多個location可以復用同一個模塊）。handler模塊負責處理請求，完成響應內容的生成，而filter模塊對響應內容進行處理。
用戶根據自己的需要開發的模塊都屬於第三方模塊。正是有了這麼多模塊的支撐，Nginx的功能才會如此強大。
Nginx的模塊從結構上分為核心模塊、基礎模塊和第三方模塊：
- 核心模塊：HTTP模塊、EVENT模塊和MAIL模塊
- 基礎模塊：HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊，
- 第三方模塊：HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。
Nginx的模塊從功能上分為如下三類：
- Handlers（處理器模塊）。此類模塊直接處理請求，併進行輸出內容和修改headers信息等操作。Handlers處理器模塊一般只能有一個。
- Filters （過濾器模塊）。此類模塊主要對其他處理器模塊輸出的內容進行修改操作，最後由Nginx輸出。
- Proxies （代理類模塊）。此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與後端一些服務比如FastCGI等進行交互，實現服務代理和負載均衡等功能。
三、Nginx進程模型
Nginx預設採用多進程工作方式，Nginx啟動後，會運行一個master進程和多個worker進程。其中master充當整個進程組與用戶的交互介面，同時對進程進行監護，管理worker進程來實現重啟服務、平滑升級、更換日誌文件、配置文件實時生效等功能。worker用來處理基本的網路事件，worker之間是平等的，他們共同競爭來處理來自客戶端的請求。
nginx的進程模型如圖所示：
在創建master進程時，先建立需要監聽的socket（listenfd），然後從master進程中fork()出多個worker進程，如此一來每個worker進程多可以監聽用戶請求的socket。一般來說，當一個連接進來後，所有在Worker都會收到通知，但是只有一個進程可以接受這個連接請求，其它的都失敗，這是所謂的驚群現象。nginx提供了一個accept_mutex（互斥鎖），有了這把鎖之後，同一時刻，就只會有一個進程在accpet連接，這樣就不會有驚群問題了。
先打開accept_mutex選項，只有獲得了accept_mutex的進程才會去添加accept事件。nginx使用一個叫ngx_accept_disabled的變數來控制是否去競爭accept_mutex鎖。ngx_accept_disabled = nginx單進程的所有連接總數 / 8 -空閑連接數量，當ngx_accept_disabled大於0時，不會去嘗試獲取accept_mutex鎖，ngx_accept_disable越大，於是讓出的機會就越多，這樣其它進程獲取鎖的機會也就越大。不去accept，每個worker進程的連接數就控制下來了，其它進程的連接池就會得到利用，這樣，nginx就控制了多進程間連接的平衡。
每個worker進程都有一個獨立的連接池，連接池的大小是worker_connections。這裡的連接池裡面保存的其實不是真實的連接，它只是一個worker_connections大小的一個ngx_connection_t結構的數組。並且，nginx會通過一個鏈表free_connections來保存所有的空閑ngx_connection_t，每次獲取一個連接時，就從空閑連接鏈表中獲取一個，用完後，再放回空閑連接鏈表裡面。一個nginx能建立的最大連接數，應該是worker_connections * worker_processes。當然，這裡說的是最大連接數，對於HTTP請求本地資源來說，能夠支持的最大併發數量是worker_connections * worker_processes，而如果是HTTP作為反向代理來說，最大併發數量應該是worker_connections * worker_processes/2。因為作為反向代理伺服器，每個併發會建立與客戶端的連接和與後端服務的連接，會占用兩個連接。
