Web服務(wù)器之Nginx詳解（理論部分） - Share your knowledge … - 51CTO技術(shù)博客

心靜_止水 2015-08-23

展開全文

大綱

一、前言
二、Web服務(wù)器提供服務(wù)的方式
三、多進程、多線程、異步模式的對比
四、Web 服務(wù)請求過程
五、Linux I/O 模型
六、Linux I/O 模型具體說明
七、Linux I/O模型的具體實現(xiàn)
八、Apache 的工作模式
九、支持高并發(fā)的Web服務(wù)器
十、Nginx 詳解

一、前言

注，在說Web服務(wù)器之前，先說說線程、進程、以及并發(fā)連接數(shù)。

1.進程與線程

進程是具有一定獨立功能的程序，關(guān)于某個數(shù)據(jù)集合上的一次運行活動，進程是系統(tǒng)進行資源分配和調(diào)度的一個獨立單位。從邏輯角度來看，多線程的意義在于一個應(yīng)用程序（進程）中，有多個執(zhí)行部分可以同時執(zhí)行。但操作系統(tǒng)并沒有將多個線程看做多個獨立的應(yīng)用來實現(xiàn)，而是作為進程來調(diào)度和管理以及資源分配。這就是進程和線程的重要區(qū)別，進程和線程的主要差別在于，進程有獨立的地址空間，一個進程崩潰后，在保護模式下不會對其它進程產(chǎn)生影響，而線程只是一個進程中的不同執(zhí)行路徑。線程有自己的堆棧和局部變量，但線程之間沒有單獨的地址空間，一個線程死掉就等于整個進程死掉，所以多進程的程序要比多線程的程序健壯，但在進程切換時，耗費資源較大，效率要差一些。但對于一些要求同時進行并且又要共享某些變量的并發(fā)操作，只能用線程，不能用進程。好了，我想我已經(jīng)說明白進程與線程了，下面我們來說一說并發(fā)連接數(shù)。

2.并發(fā)連接數(shù)

(1).什么是最大并發(fā)連接數(shù)呢？

所謂，最大并發(fā)連接數(shù)是服務(wù)器同一時間能處理最大會話數(shù)量。

(2).何為會話？

我們打開一個網(wǎng)站就是一個客戶端瀏覽器與服務(wù)端的一個會話，而我們?yōu)g覽網(wǎng)頁是基于http協(xié)議。

(3).HTTP協(xié)議如何工作？

HTTP支持兩種建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式為持久連接)。

(4).瀏覽器與Web服務(wù)器之間將完成下列7個步驟

建立TCP連接
Web瀏覽器向Web服務(wù)器發(fā)送請求命令
Web瀏覽器發(fā)送請求頭信息
Web服務(wù)器應(yīng)答
Web服務(wù)器發(fā)送應(yīng)答頭信息
Web服務(wù)器向瀏覽器發(fā)送數(shù)據(jù)
Web服務(wù)器關(guān)閉TCP連接

一般情況下，一旦Web服務(wù)器向瀏覽器發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，但是瀏覽器一般其頭信息加入了這行代碼 Connection:keep-alive，TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接目的，節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。

3.并發(fā)連接數(shù)的計算方法

下載：用戶下載服務(wù)器上的文件，則為一個連接，用戶文件下載完畢后這個連接就消失了。有時候用戶用迅雷的多線程方式下載的話，這一個用戶開啟了5個線程的話，就算是5個連接。
用戶打開你的頁面，就算停留在頁面沒有對服務(wù)器發(fā)出任何請求，那么在用戶打開一面以后的15分鐘內(nèi)也都要算一個在線。
上面的情況用戶繼續(xù)打開同一個網(wǎng)站的其他頁面，那么在線人數(shù)按照用戶最后一次點擊（發(fā)出請求）以后的15分鐘計算，在這個15分鐘內(nèi)不管用戶怎么點擊（包括新窗口打開）都還是一人在線。
當(dāng)用戶打開頁面然后正常關(guān)閉瀏覽器，用戶的在線人數(shù)也會馬上清除。

二、Web服務(wù)器提供服務(wù)的方式

Web服務(wù)器由于要同時為多個客戶提供服務(wù)，就必須使用某種方式來支持這種多任務(wù)的服務(wù)方式。一般情況下可以有以下三種方式來選擇，多進程方式、多線程方式及異步方式。其中，多進程方式中服務(wù)器對一個客戶要使用一個進程來提供服務(wù)，由于在操作系統(tǒng)中，生成一個進程需要進程內(nèi)存復(fù)制等額外的開銷，這樣在客戶較多時的性能就會降低。為了克服這種生成進程的額外開銷，可以使用多線程方式或異步方式。在多線程方式中，使用進程中的多個線程提供服務(wù)，由于線程的開銷較小，性能就會提高。事實上，不需要任何額外開銷的方式還是異步方式，它使用非阻塞的方式與每個客戶通信，服務(wù)器使用一個進程進行輪詢就行了。

雖然異步方式最為高效，但它也有自己的缺點。因為異步方式下，多個任務(wù)之間的調(diào)度是由服務(wù)器程序自身來完成的，而且一旦一個地方出現(xiàn)問題則整個服務(wù)器就會出現(xiàn)問題。因此，向這種服務(wù)器增加功能，一方面要遵從該服務(wù)器自身特定的任務(wù)調(diào)度方式，另一方面要確保代碼中沒有錯誤存在，這就限制了服務(wù)器的功能，使得異步方式的Web服務(wù)器的效率最高，但功能簡單，如Nginx服務(wù)器。

由于多線程方式使用線程進行任務(wù)調(diào)度，這樣服務(wù)器的開發(fā)由于遵從標準，從而變得簡單并有利于多人協(xié)作。然而多個線程位于同一個進程內(nèi)，可以訪問同樣的內(nèi)存空間，因此存在線程之間的影響，并且申請的內(nèi)存必須確保申請和釋放。對于服務(wù)器系統(tǒng)來講，由于它要數(shù)天、數(shù)月甚至數(shù)年連續(xù)不停的運轉(zhuǎn)，一點點錯誤就會逐漸積累而最終導(dǎo)致影響服務(wù)器的正常運轉(zhuǎn)，因此很難編寫一個高穩(wěn)定性的多線程服務(wù)器程序。但是，不是不能做到時。Apache的worker模塊就能很好的支持多線程的方式。

多進程方式的優(yōu)勢就在于穩(wěn)定性，因為一個進程退出的時候，操作系統(tǒng)會回收其占用的資源，從而使它不會留下任何垃圾。即便程序中出現(xiàn)錯誤，由于進程是相互隔離的，那么這個錯誤不會積累起來，而是隨著這個進程的退出而得到清除。Apache的prefork模塊就是支持多進程的模塊。

三、多進程、多線程、異步模式的對比

Web服務(wù)器總的來說提供服務(wù)的方式有三種,

多進程方式
多線程的方式
異步方式

其中效率最高的是異步的方式，最穩(wěn)定的是多進程方式，占用資源較少的是多線程的方式。

1.多進程

此種架構(gòu)方式中，web服務(wù)器生成多個進程并行處理多個用戶請求，進程可以按需或事先生成。有的web服務(wù)器應(yīng)用程序為每個用戶請求生成一個單獨的進程來進行響應(yīng)，不過，一旦并發(fā)請求數(shù)量達到成千上萬時，多個同時運行的進程將會消耗大量的系統(tǒng)資源。（即每個進程只能響應(yīng)一個請求或多個進程對應(yīng)多個請求）

優(yōu)點：

最大的優(yōu)勢就在于穩(wěn)定性，一個進程出錯不會影響其它進程。如，服務(wù)器同時連接100個請求對就的是100個進程，其中一個進程出錯，只會殺死一個進程，還有99個進程繼續(xù)響應(yīng)用戶請求。
每個進程響應(yīng)一個請求

缺點：

進程量大，進程切換次數(shù)過多，導(dǎo)致CPU資源使用效率低
每個進程的地址空間是獨立的，很多空間中重復(fù)的數(shù)據(jù)，所以內(nèi)存使用效率低
進程切換由于內(nèi)核完成，占用CPU資源

2.多線程

在多線程方式中，每個線程來響應(yīng)一下請求，由于線程之間共享進程的數(shù)據(jù)，所以線程的開銷較小，性能就會提高。

優(yōu)點：

線程間共享進程數(shù)據(jù)
每個線程響應(yīng)一個請求
線程切換不可避免（切換量級比較輕量）
同一進程的線程可以共享進程的諸多資源，比如打開的文件
對內(nèi)存的需求較之進程有很大下降
讀可以共享，寫不可以共享

缺點：

線程快速切換時會帶來線程抖動
多線程會導(dǎo)致服務(wù)器不穩(wěn)定

3.異步方式

一個進程或線程響應(yīng)多個請求，不需要任何額外開銷的，性能最高，占用資源最少。但也有問題一但進程或線程出錯就會導(dǎo)致整個服務(wù)器的宕機。

四、Web 服務(wù)請求過程

在上面的講解中我們說明，Web服務(wù)器的如何提供服務(wù)的，有多進程的方式、多線程的方式還有異步方式我們先簡單這么理解，大家肯定還有很多疑問，我們先存疑，后面我們慢慢說，現(xiàn)在我們不管Web服務(wù)器是如何提供服務(wù)的，多進程也好、多線程好，異步也罷。下面我們來說一下，一個客戶端的具體請求Web服務(wù)的具體過程，從上圖中我們可以看到有11步，下面我們來具體說一下，

首先我們客戶端發(fā)送一個請求到Web服務(wù)器，請求首先是到網(wǎng)卡。
網(wǎng)卡將請求交由內(nèi)核空間的內(nèi)核處理，其實就是拆包了，發(fā)現(xiàn)請求的是80端口。
內(nèi)核便將請求發(fā)給了在用戶空間的Web服務(wù)器，Web服務(wù)器接受到請求發(fā)現(xiàn)客戶端請求的index.html頁面、
Web服務(wù)器便進行系統(tǒng)調(diào)用將請求發(fā)給內(nèi)核
內(nèi)核發(fā)現(xiàn)在請求的是一頁面，便調(diào)用磁盤的驅(qū)動程序，連接磁盤
內(nèi)核通過驅(qū)動調(diào)用磁盤取得的頁面文件
內(nèi)核將取得的頁面文件保存在自己的緩存區(qū)域中便通知Web進程或線程來取相應(yīng)的頁面文件
Web服務(wù)器通過系統(tǒng)調(diào)用將內(nèi)核緩存中的頁面文件復(fù)制到進程緩存區(qū)域中
Web服務(wù)器取得頁面文件來響應(yīng)用戶，再次通過系統(tǒng)調(diào)用將頁面文件發(fā)給內(nèi)核
內(nèi)核進程頁面文件的封裝并通過網(wǎng)卡發(fā)送出去
當(dāng)報文到達網(wǎng)卡時通過網(wǎng)絡(luò)響應(yīng)給客戶端

簡單來說就是：用戶請求-->送達到用戶空間-->系統(tǒng)調(diào)用-->內(nèi)核空間-->內(nèi)核到磁盤上讀取網(wǎng)頁資源->返回到用戶空間->響應(yīng)給用戶。上述簡單的說明了一下，客戶端向Web服務(wù)請求過程，在這個過程中，有兩個I/O過程，一個就是客戶端請求的網(wǎng)絡(luò)I/O，另一個就是Web服務(wù)器請求頁面的磁盤I/O。下面我們就來說說Linux的I/O模型。

五、Linux I/O 模型

1.I/O模型分類

說明：我們都知道web服務(wù)器的進程響應(yīng)用戶請求，但無法直接操作I/O設(shè)備，其必須通過系統(tǒng)調(diào)用，請求kernel來協(xié)助完成I/O動作
內(nèi)核會為每個I/O設(shè)備維護一個buffer，如下圖：

對于數(shù)據(jù)輸入而言，即等待(wait)數(shù)據(jù)輸入至buffer需要時間，而從buffer復(fù)制(copy)數(shù)據(jù)至進程也需要時間
根據(jù)等待模式不同，I/O動作可分為五種模式。

阻塞I/O
非阻塞I/O
I/O復(fù)用（select和poll）
信號（事件）驅(qū)動I/O（SIGIO）
異步I/O（Posix.1的aio_系列函數(shù)）

2.I/O模型的相關(guān)術(shù)語

這里有必要先解釋一下阻塞、非阻塞，同步、異步、I/O的概念。

(1).阻塞和非阻塞:

阻塞和非阻塞指的是執(zhí)行一個操作是等操作結(jié)束再返回，還是馬上返回。比如你去車站接朋友，這是一個操作?？梢杂袃煞N執(zhí)行方式。第一種，你這人特實誠，老早就到了車站一直等到車來了接到朋友為止。第二種，你到了車站，問值班的那趟車來了沒有，“還沒有”，你出去逛一圈，可能過會回來再問。第一種就是阻塞方式，第二種則是非阻塞的。我認為阻塞和非阻塞講得是做事方法，是針對做事的人而言的。

(2).同步和異步:

同步和異步又是另外一個概念，它是事件本身的一個屬性。比如老板讓你去搬一堆石頭，而且只讓你一個人干，你只好自己上陣，最后的結(jié)果是搬完了，還是你砸到腳了，只有搬完了你才知道。這就是同步的事件。如果老板還給你個小弟，你就可以讓小弟去搬，搬完了告你一聲。這就變成異步的了。其實異步還可以分為兩種：帶通知的和不帶通知的。前面說的那種屬于帶通知的。有些小弟干活可能主動性不是很夠，不會主動通知你，你就需要時不時的去關(guān)注一下狀態(tài)。這種就是不帶通知的異步。

對于同步的事件，你只能以阻塞的方式去做。而對于異步的事件，阻塞和非阻塞都是可以的。非阻塞又有兩種方式：主動查詢和被動接收消息。被動不意味著一定不好，在這里它恰恰是效率更高的，因為在主動查詢里絕大部分的查詢是在做無用功。對于帶通知的異步事件，兩者皆可。而對于不帶通知的，則只能用主動查詢。

(3).I/O

回到I/O，不管是I還是O，對外設(shè)(磁盤)的訪問都可以分成請求和執(zhí)行兩個階段。請求就是看外設(shè)的狀態(tài)信息（比如是否準備好了），執(zhí)行才是真正的I/O操作。在Linux 2.6之前，只有“請求”是異步事件，2.6之后才引入AIO把“執(zhí)行”異步化。別看Linux/Unix是用來做服務(wù)器的，這點上比Windows落后了好多，IOCP（Windows上的AIO）在Win2000上就有了,呵呵。

(4).總結(jié)

Linux上的前四種I/O模型的“執(zhí)行”階段都是同步的，只有最后一種才做到了真正的全異步。第一種阻塞式是最原始的方法，也是最累的辦法。當(dāng)然累與不累要看針對誰。應(yīng)用程序是和內(nèi)核打交道的。對應(yīng)用程序來說，這種方式是最累的，但對內(nèi)核來說這種方式恰恰是最省事的。還拿接人這事為例，你就是應(yīng)用程序，值班員就是內(nèi)核，如果你去了一直等著，值班員就省事了。當(dāng)然現(xiàn)在計算機的設(shè)計，包括操作系統(tǒng)，越來越為終端用戶考慮了，為了讓用戶滿意，內(nèi)核慢慢的承擔(dān)起越來越多的工作，IO模型的演化也是如此。

非阻塞I/O ，I/O復(fù)用，信號驅(qū)動式I/O其實都是非阻塞的，當(dāng)然是針對“請求”這個階段。非阻塞式是主動查詢外設(shè)狀態(tài)。I/O復(fù)用里的select，poll也是主動查詢，不同的是select和poll可以同時查詢多個fd（文件句柄）的狀態(tài)，另外select有fd個數(shù)的限制。epoll是基于回調(diào)函數(shù)的。信號驅(qū)動式I/O則是基于信號消息的。這兩個應(yīng)該可以歸到“被動接收消息”那一類中。最后就是偉大的AIO的出現(xiàn)，內(nèi)核把什么事都干了，對上層應(yīng)用實現(xiàn)了全異步，性能最好，當(dāng)然復(fù)雜度也最高。好了，下面我們就來詳細說一說，這幾種模式。

六、Linux I/O 模型具體說明

首先我們先來看一下，基本 Linux I/O 模型的簡單矩陣，

從圖中我們可以看到的模型有，同步阻塞I/O（阻塞I/O）、同步非阻塞I/O（非阻塞I/O ）、異步阻塞I/O（I/O復(fù)用），異步非阻塞I/O（有兩種，信號驅(qū)動I/O和異步I/O）。好了現(xiàn)在就來具體說一說吧。

1.阻塞I/O

說明：應(yīng)用程序調(diào)用一個IO函數(shù)，導(dǎo)致應(yīng)用程序阻塞，等待數(shù)據(jù)準備好。如果數(shù)據(jù)沒有準備好，一直等待數(shù)據(jù)準備好了，從內(nèi)核拷貝到用戶空間,IO函數(shù)返回成功指示。這個不用多解釋吧，阻塞套接字。下圖是它調(diào)用過程的圖示：（注，一般網(wǎng)絡(luò)I/O都是阻塞I/O，客戶端發(fā)出請求，Web服務(wù)器進程響應(yīng)，在進程沒有返回頁面之前，這個請求會處于一直等待狀態(tài)）

2.非阻塞I/O

我們把一個套接口設(shè)置為非阻塞就是告訴內(nèi)核，當(dāng)所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤。這樣我們的I/O操作函數(shù)將不斷的測試數(shù)據(jù)是否已經(jīng)準備好，如果沒有準備好，繼續(xù)測試，直到數(shù)據(jù)準備好為止。在這個不斷測試的過程中，會大量的占用CPU的時間，所有一般Web服務(wù)器都不使用這種I/O模型。具體過程如下圖:

3.I/O復(fù)用（select和poll）

I/O復(fù)用模型會用到select或poll函數(shù)或epoll函數(shù)(Linux2.6以后的內(nèi)核開始支持)，這兩個函數(shù)也會使進程阻塞，但是和阻塞I/O所不同的的，這兩個函數(shù)可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數(shù)進行檢測，直到有數(shù)據(jù)可讀或可寫時，才真正調(diào)用I/O操作函數(shù)。具體過程如下圖:

4.信號驅(qū)動I/O（SIGIO）

首先，我們允許套接口進行信號驅(qū)動I/O，并安裝一個信號處理函數(shù)，進程繼續(xù)運行并不阻塞。當(dāng)數(shù)據(jù)準備好時，進程會收到一個SIGIO信號，可以在信號處理函數(shù)中調(diào)用I/O操作函數(shù)處理數(shù)據(jù)。具體過程如下圖:

5.異步I/O（Posix.1的aio_系列函數(shù)）

當(dāng)一個異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果。實際處理這個調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者的輸入輸出操作。具體過程如下圖:

6.I/O 模型總結(jié)（如下圖）
0987654

從上圖中我們可以看出，可以看出，越往后，阻塞越少，理論上效率也是最優(yōu)。其五種I/O模型中，前三種屬于同步I/O，后兩者屬于異步I/O。

同步I/O:

阻塞I/O
非阻塞I/O
I/O復(fù)用（select和poll）

異步I/O:

信號驅(qū)動I/O（SIGIO）（半異步）
異步I/O（Posix.1的aio_系列函數(shù)）（真正的異步）

異步 I/O 和信號驅(qū)動I/O的區(qū)別:

信號驅(qū)動 I/O 模式下，內(nèi)核可以復(fù)制的時候通知給我們的應(yīng)用程序發(fā)送SIGIO 消息。
異步 I/O 模式下，內(nèi)核在所有的操作都已經(jīng)被內(nèi)核操作結(jié)束之后才會通知我們的應(yīng)用程序。

好了，5種模型的比較比較清晰了，下面我們來說一下五種模型的具體實現(xiàn)。

七、Linux I/O模型的具體實現(xiàn)

1.主要實現(xiàn)方式有以下幾種：

select
poll
epoll
kqueue
/dev/poll
iocp

注，其中iocp是Windows實現(xiàn)的，select、poll、epoll是Linux實現(xiàn)的，kqueue是FreeBSD實現(xiàn)的，/dev/poll是SUN的Solaris實現(xiàn)的。select、poll對應(yīng)第3種（I/O復(fù)用）模型，iocp對應(yīng)第5種（異步I/O）模型，那么epoll、kqueue、/dev/poll呢？其實也同select屬于同一種模型，只是更高級一些，可以看作有了第4種（信號驅(qū)動I/O）模型的某些特性，如callback機制。

2.為什么epoll、kqueue、/dev/poll比select高級？

答案是，他們無輪詢。因為他們用callback取代了。想想看，當(dāng)套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調(diào)度，不管哪個Socket是活躍的，都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調(diào)函數(shù)，當(dāng)他們活躍時，自動完成相關(guān)操作，那就避免了輪詢，這正是epoll、kqueue、/dev/poll做的。這樣子說可能不好理解，那么我說一個現(xiàn)實中的例子，假設(shè)你在大學(xué)讀書，住的宿舍樓有很多間房間，你的朋友要來找你。select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。而epoll版宿管大媽會先記下每位同學(xué)的房間號，你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。如果來了10000個人，都要找自己住這棟樓的同學(xué)時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高并發(fā)服務(wù)器中，輪詢I/O是最耗時間的操作之一，select、epoll、/dev/poll的性能誰的性能更高，同樣十分明了。

3.Windows or *nix （IOCP or kqueue、epoll、/dev/poll）？

誠然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系統(tǒng)，但是由于其系統(tǒng)本身的局限性，大型服務(wù)器還是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 與 IOCP相比，就是多了一層從內(nèi)核copy數(shù)據(jù)到應(yīng)用層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue、epoll、/dev/poll 已經(jīng)做得很優(yōu)秀了。

4.總結(jié)一些重點

只有IOCP(windows實現(xiàn))是asynchronous I/O，其他機制或多或少都會有一點阻塞。
select（Linux實現(xiàn)）低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設(shè)計改善
epoll(Linux實現(xiàn))、kqueue（FreeBSD實現(xiàn)）、/dev/poll（Solaris實現(xiàn)）是Reacor模式，IOCP是Proactor模式。
Apache 2.2.9之前只支持select模型，2.2.9之后支持epoll模型
Nginx 支持epoll模型
Java nio包是select模型

八、Apache 的工作模式

1.apache三種工作模式

我們都知道Apache有三種工作模塊，分別為prefork、worker、event。

prefork：多進程，每個請求用一個進程響應(yīng)，這個過程會用到select機制來通知。
worker：多線程，一個進程可以生成多個線程，每個線程響應(yīng)一個請求，但通知機制還是select不過可以接受更多的請求。
event：基于異步I/O模型，一個進程或線程，每個進程或線程響應(yīng)多個用戶請求，它是基于事件驅(qū)動（也就是epoll機制）實現(xiàn)的。

2.prefork的工作原理

如果不用“--with-mpm”顯式指定某種MPM,prefork就是Unix平臺上缺省的MPM.它所采用的預(yù)派生子進程方式也是 Apache1.3中采用的模式.prefork本身并沒有使用到線程,2.0版使用它是為了與1.3版保持兼容性;另一方面,prefork用單獨的子進程來處理不同的請求,進程之間是彼此獨立的,這也使其成為最穩(wěn)定的MPM之一。

3.worker的工作原理

相對于prefork,worker是2.0版中全新的支持多線程和多進程混合模型的MPM.由于使用線程來處理,所以可以處理相對海量的請求,而系統(tǒng)資源的開銷要小于基于進程的服務(wù)器.但是,worker也使用了多進程,每個進程又生成多個線程,以獲得基于進程服務(wù)器的穩(wěn)定性.這種MPM的工作方式將是Apache2.0的發(fā)展趨勢。

4.event 基于事件機制的特性

一個進程響應(yīng)多個用戶請求，利用callback機制，讓套接字復(fù)用，請求過來后進程并不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，進程本身一直處于空閑狀態(tài)，可以一直接收用戶請求。可以實現(xiàn)一個進程程響應(yīng)多個用戶請求。支持持海量并發(fā)連接數(shù)，消耗更少的資源。

九、支持高并發(fā)的Web服務(wù)器

有幾個基本條件：

1.基于線程，即一個進程生成多個線程，每個線程響應(yīng)用戶的每個請求。

2.基于事件的模型，一個進程處理多個請求，并且通過epoll機制來通知用戶請求完成。

3.基于磁盤的AIO（異步I/O）

4.支持mmap內(nèi)存映射，mmap傳統(tǒng)的web服務(wù)器，進行頁面輸入時，都是將磁盤的頁面先輸入到內(nèi)核緩存中，再由內(nèi)核緩存中復(fù)制一份到web服務(wù)器上，mmap機制就是讓內(nèi)核緩存與磁盤進行映射，web服務(wù)器，直接復(fù)制頁面內(nèi)容即可。不需要先把磁盤的上的頁面先輸入到內(nèi)核緩存去。

剛好，Nginx 支持以上所有特性。所以Nginx官網(wǎng)上說，Nginx支持50000并發(fā)，是有依據(jù)的。好了，基礎(chǔ)知識就說到這邊下面我們來談?wù)勎覀兘裉熘v解的重點Nginx。

十、Nginx 詳解

1.簡介

傳統(tǒng)上基于進程或線程模型架構(gòu)的web服務(wù)通過每進程或每線程處理并發(fā)連接請求，這勢必會在網(wǎng)絡(luò)和I/O操作時產(chǎn)生阻塞，其另一個必然結(jié)果則是對內(nèi)存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環(huán)境，這包括為其分配堆內(nèi)存和棧內(nèi)存，以及為其創(chuàng)建新的執(zhí)行上下文等。這些操作都需要占用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統(tǒng)性能也會由此進一步下降。另一種高性能web服務(wù)器/web服務(wù)器反向代理：Nginx（Engine X），nginx的主要著眼點就是其高性能以及對物理計算資源的高密度利用，因此其采用了不同的架構(gòu)模型。受啟發(fā)于多種操作系統(tǒng)設(shè)計中基于“事件”的高級處理機制，nginx采用了模塊化、事件驅(qū)動、異步、單線程及非阻塞的架構(gòu)，并大量采用了多路復(fù)用及事件通知機制。在nginx中，連接請求由為數(shù)不多的幾個僅包含一個線程的進程worker以高效的回環(huán)(run-loop)機制進行處理，而每個worker可以并行處理數(shù)千個的并發(fā)連接及請求。

2.Nginx 工作原理

Nginx會按需同時運行多個進程：一個主進程(master)和幾個工作進程(worker)，配置了緩存時還會有緩存加載器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程，并主要通過“共享內(nèi)存”的機制實現(xiàn)進程間通信。主進程以root用戶身份運行，而worker、cache loader和cache manager均應(yīng)以非特權(quán)用戶身份運行。

主進程主要完成如下工作：

讀取并驗正配置信息；
創(chuàng)建、綁定及關(guān)閉套接字；
啟動、終止及維護worker進程的個數(shù)；
無須中止服務(wù)而重新配置工作特性；
控制非中斷式程序升級，啟用新的二進制程序并在需要時回滾至老版本；
重新打開日志文件；
編譯嵌入式perl腳本；

worker進程主要完成的任務(wù)包括：

接收、傳入并處理來自客戶端的連接；
提供反向代理及過濾功能；
nginx任何能完成的其它任務(wù)；

注，如果負載以CPU密集型應(yīng)用為主，如SSL或壓縮應(yīng)用，則worker數(shù)應(yīng)與CPU數(shù)相同；如果負載以IO密集型為主，如響應(yīng)大量內(nèi)容給客戶端，則worker數(shù)應(yīng)該為CPU個數(shù)的1.5或2倍。

3.Nginx 架構(gòu)

Nginx的代碼是由一個核心和一系列的模塊組成, 核心主要用于提供Web Server的基本功能，以及Web和Mail反向代理的功能；還用于啟用網(wǎng)絡(luò)協(xié)議，創(chuàng)建必要的運行時環(huán)境以及確保不同的模塊之間平滑地進行交互。不過，大多跟協(xié)議相關(guān)的功能和某應(yīng)用特有的功能都是由nginx的模塊實現(xiàn)的。這些功能模塊大致可以分為事件模塊、階段性處理器、輸出過濾器、變量處理器、協(xié)議、upstream和負載均衡幾個類別，這些共同組成了nginx的http功能。事件模塊主要用于提供OS獨立的(不同操作系統(tǒng)的事件機制有所不同)事件通知機制如kqueue或epoll等。協(xié)議模塊則負責(zé)實現(xiàn)nginx通過http、tls/ssl、smtp、pop3以及imap與對應(yīng)的客戶端建立會話。在Nginx內(nèi)部，進程間的通信是通過模塊的pipeline或chain實現(xiàn)的；換句話說，每一個功能或操作都由一個模塊來實現(xiàn)。例如，壓縮、通過FastCGI或uwsgi協(xié)議與upstream服務(wù)器通信，以及與memcached建立會話等。

4.Nginx 基礎(chǔ)功能

處理靜態(tài)文件，索引文件以及自動索引；
反向代理加速(無緩存)，簡單的負載均衡和容錯；
FastCGI，簡單的負載均衡和容錯；
模塊化的結(jié)構(gòu)。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求并發(fā)處理；
SSL 和 TLS SNI 支持；

5.Nginx IMAP/POP3 代理服務(wù)功能

使用外部 HTTP 認證服務(wù)器重定向用戶到 IMAP/POP3 后端；
使用外部 HTTP 認證服務(wù)器認證用戶后連接重定向到內(nèi)部的 SMTP 后端；
認證方法：
POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;
IMAP: IMAP LOGIN;
SMTP: AUTH LOGIN PLAIN CRAM-MD5;
SSL 支持；
在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

6.Nginx 支持的操作系統(tǒng)

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;
Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;
Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;
MacOS X (10.4) PPC;
Windows 編譯版本支持 windows 系列操作系統(tǒng);

7.Nginx 結(jié)構(gòu)與擴展

一個主進程和多個工作進程，工作進程運行于非特權(quán)用戶；
kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；
kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （臨時禁止事件）， NOTE_LOWAT, EV_EOF, 有效數(shù)據(jù)的數(shù)目，錯誤代碼；
sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；
輸入過濾 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；
10,000 非活動的 HTTP keep-alive 連接僅需要 2.5M 內(nèi)存。
最小化的數(shù)據(jù)拷貝操作；

8.Nginx 其他HTTP功能

基于IP 和名稱的虛擬主機服務(wù)；
Memcached 的 GET 接口；
支持 keep-alive 和管道連接；
靈活簡單的配置；
重新配置和在線升級而無須中斷客戶的工作進程；
可定制的訪問日志，日志寫入緩存，以及快捷的日志回卷；
4xx-5xx 錯誤代碼重定向；
基于 PCRE 的 rewrite 重寫模塊；
基于客戶端 IP 地址和 HTTP 基本認證的訪問控制；
PUT, DELETE, 和 MKCOL 方法；
支持 FLV （Flash 視頻）；
帶寬限制；

9.為什么選擇Nginx

在高連接并發(fā)的情況下，Nginx是Apache服務(wù)器不錯的替代品: Nginx在美國是做虛擬主機生意的老板們經(jīng)常選擇的軟件平臺之一. 能夠支持高達 50,000 個并發(fā)連接數(shù)的響應(yīng), 感謝Nginx為我們選擇了 epoll and kqueue 作為開發(fā)模型。
Nginx作為負載均衡服務(wù)器: Nginx 既可以在內(nèi)部直接支持 Rails 和 PHP 程序?qū)ν膺M行服務(wù), 也可以支持作為 HTTP代理服務(wù)器對外進行服務(wù). Nginx采用C進行編寫, 不論是系統(tǒng)資源開銷還是CPU使用效率都比 Perlbal 要好很多。
作為郵件代理服務(wù)器: Nginx 同時也是一個非常優(yōu)秀的郵件代理服務(wù)器（最早開發(fā)這個產(chǎn)品的目的之一也是作為郵件代理服務(wù)器）, Last.fm 描述了成功并且美妙的使用經(jīng)驗.
Nginx 是一個 [#installation 安裝] 非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）, Bugs 非常少的服務(wù)器: Nginx 啟動特別容易, 并且?guī)缀蹩梢宰龅?*24不間斷運行，即使運行數(shù)個月也不需要重新啟動. 你還能夠不間斷服務(wù)的情況下進行軟件版本的升級。
Nginx 的誕生主要解決C10K問題