3、Nginx原理解析

Nginx原理解析

1、反向代理

工做流程

1. 用戶經過域名發出訪問Web服務器的請求，該域名被DNS服務器解析爲反向代理服務器的IP地址；
2. 反向代理服務器接受用戶的請求；
3. 反向代理服務器在本地緩存中查找請求的內容，找到後直接把內容發送給用戶；
4. 若是本地緩存裏沒有用戶所請求的信息內容，反向代理服務器會代替用戶向源服務器請求一樣的信息內容，並把信息內容發給用戶，若是信息內容是緩存的還會把它保存到緩存中。

優勢

1. 保護了真實的web服務器，保證了web服務器的資源安全

一般的代理服務器，只用於代理內部網絡對Internet外部網絡的鏈接請求，客戶機必須指定代理服務器，並將原本要直接發送到Web服務器上的http請求發送到代理服務器中。不支持外部網絡對內部網絡的鏈接請求，由於內部網絡對外部網絡是不可見的。當一個代理服務器可以代理外部網絡上的主機，訪問內部網絡時，這種代理服務的方式稱爲反向代理服務。此時代理服務器對外就表現爲一個Web服務器，外部網絡就能夠簡單把它看成一個標準的Web服務器而不須要特定的配置。不一樣之處在於，這個服務器沒有保存任何網頁的真實數據，全部的靜態網頁或者CGI程序，都保存在內部的Web服務器上。所以對反向代理服務器的攻擊並不會使得網頁信息遭到破壞，這樣就加強了Web服務器的安全性。

1. 節約了有限的IP地址資源

企業內全部的網站共享一個在internet中註冊的IP地址，這些服務器分配私有地址，採用虛擬主機的方式對外提供服務。

1. 減小WEB服務器壓力，提升響應速度

反向代理就是一般所說的web服務器加速，它是一種經過在繁忙的web服務器和外部網絡之間增長一個高速的web緩衝服務器來下降實際的web服務器的負載的一種技術。反向代理是針對web服務器提升加速功能，做爲代理緩存，它並非針對瀏覽器用戶，而針對一臺或多臺特定的web服務器，它能夠代理外部網絡對內部網絡的訪問請求。

反向代理服務器會強制將外部網絡對要代理的服務器的訪問通過它，這樣反向代理服務器負責接收客戶端的請求，而後到源服務器上獲取內容，把內容返回給用戶，並把內容保存到本地，以便往後再收到一樣的信息請求時，它會把本地緩存裏的內容直接發給用戶，以減小後端web服務器的壓力，提升響應速度。所以Nginx還具備緩存功能。

2、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等進行交互，實現服務代理和負載均衡等功能。

3、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。由於做爲反向代理服務器，每一個併發會創建與客戶端的鏈接和與後端服務的鏈接，會佔用兩個鏈接。