Nginx系統學習篇（2）--基礎概念IO

轉自：http://freeloda.blog.51cto.com/2033581/1285332

大綱

一、前言

二、Web服務器提供服務的方式

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

四、Web 服務請求過程

五、Linux I/O 模型

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

七、Linux I/O模型的具體實現

八、Apache 的工作模式

九、支持高併發的Web服務器

十、Nginx 詳解

一、前言

注，在說Web服務器之前，先說說線程、進程、以及併發連接數。

1.進程與線程

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

2.併發連接數

(1).什麼是最大併發連接數呢？

所謂，最大併發連接數是服務器同一時間能處理最大會話數量。

(2).何爲會話？

我們打開一個網站就是一個客戶端瀏覽器與服務端的一個會話，而我們瀏覽網頁是基於http協議。

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

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

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

• 建立TCP連接

• Web瀏覽器向Web服務器發送請求命令

• Web瀏覽器發送請求頭信息

• Web服務器應答

• Web服務器發送應答頭信息

• Web服務器向瀏覽器發送數據

• Web服務器關閉TCP連接

       一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，但是瀏覽器一般其頭信息加入了這行代碼 Connection:keep-alive，TCP連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接目的，節省了爲每 個請求建立新連接所需的時間，還節約了網絡帶寬。

3.併發連接數的計算方法

• 下載：用戶下載服務器上的文件，則爲一個連接，用戶文件下載完畢後這個連接就消失了。有時候用戶用迅雷的多線程方式下載的話，這一個用戶開啓了5個線程的話，就算是5個連接。

• 用戶打開你的頁面，就算停留在頁面沒有對服務器發出任何請求，那麼在用戶打開一面以後的15分鐘內也都要算一個在線。

• 上面的情況用戶繼續打開同一個網站的其他頁面，那麼在線人數按照用戶最後一次點擊（發出請求）以後的15分鐘計算，在這個15分鐘內不管用戶怎麼點擊（包括新窗口打開）都還是一人在線。

• 當用戶打開頁面然後正常關閉瀏覽器，用戶的在線人數也會馬上清除。

二、Web服務器提供服務的方式

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

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

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

       多進程方式的優勢就在於穩定性，因爲一個進程退出的時候，操作系統會回收其佔用的資源，從而使它不會留下任何垃圾。即便程序中出現錯誤，由於進程是相互隔離的，那麼這個錯誤不會積累起來，而是隨着這個進程的退出而得到清除。Apache的prefork模塊就是支持多進程的模塊。

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

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

• 多進程方式

• 多線程的方式

• 異步方式

其中效率最高的是異步的方式，最穩定的是多進程方式，佔用資源較少的是多線程的方式。

1.多進程

       此種架構方式中，web服務器生成多個進程並行處理多個用戶請求，進程可以按需或事先生成。有的web服務器應用程序爲每個用戶請求生成一個單獨的進程來進行響應，不過，一旦併發請求數量達到成千上萬時，多個同時運行的進程將會消耗大量的系統資源。（即每個進程只能響應一個請求或多個進程對應多個請求）

優點：

• 最大的優勢就在於穩定性，一個進程出錯不會影響其它進程。如，服務器同時連接100個請求對就的是100個進程，其中一個進程出錯，只會殺死一個進程，還有99個進程繼續響應用戶請求。

• 每個進程響應一個請求

缺點：

• 進程量大，進程切換次數過多，導致CPU資源使用效率低

• 每個進程的地址空間是獨立的，很多空間中重複的數據，所以內存使用效率低

• 進程切換由於內核完成，佔用CPU資源

2.多線程

       在多線程方式中，每個線程來響應一下請求，由於線程之間共享進程的數據，所以線程的開銷較小，性能就會提高。

優點：

• 線程間共享進程數據

• 每個線程響應一個請求

• 線程切換不可避免（切換量級比較輕量）

• 同一進程的線程可以共享進程的諸多資源，比如打開的文件

• 對內存的需求較之進程有很大下降

• 讀可以共享，寫不可以共享

缺點：

• 線程快速切換時會帶來線程抖動

• 多線程會導致服務器不穩定

3.異步方式

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

四、Web 服務請求過程

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

• 首先我們客戶端發送一個請求到Web服務器，請求首先是到網卡。

• 網卡將請求交由內核空間的內核處理，其實就是拆包了，發現請求的是80端口。

• 內核便將請求發給了在用戶空間的Web服務器，Web服務器接受到請求發現客戶端請求的index.html頁面、

• Web服務器便進行系統調用將請求發給內核

• 內核發現在請求的是一頁面，便調用磁盤的驅動程序，連接磁盤

• 內核通過驅動調用磁盤取得的頁面文件

• 內核將取得的頁面文件保存在自己的緩存區域中便通知Web進程或線程來取相應的頁面文件

• Web服務器通過系統調用將內核緩存中的頁面文件複製到進程緩存區域中

• Web服務器取得頁面文件來響應用戶，再次通過系統調用將頁面文件發給內核

• 內核進程頁面文件的封裝並通過網卡發送出去

• 當報文到達網卡時通過網絡響應給客戶端

簡單來說就是：用戶請求-->送達到用戶空間-->系統調用-->內核空間-->內核到磁盤上讀取網頁資源->返回到用戶空間->響應給用戶。上述簡單的說明了一下，客戶端向Web服務請求過程，在這個過程中，有兩個I/O過程，一個就是客戶端請求的網絡I/O，另一個就是Web服務器請求頁面的磁盤I/O。 下面我們就來說說Linux的I/O模型。

五、Linux I/O 模型

1.I/O模型分類

說明：我們都知道web服務器的進程響應用戶請求，但無法直接操作I/O設備，其必須通過系統調用，請求kernel來協助完成I/O動作        
內核會爲每個I/O設備維護一個buffer，如下圖：

對於數據輸入而言，即等待(wait)數據輸入至buffer需要時間，而從buffer複製(copy)數據至進程也需要時間    
根據等待模式不同，I/O動作可分爲五種模式。

• 阻塞I/O

• 非阻塞I/O

• I/O複用（select和poll）

• 信號（事件）驅動I/O（SIGIO）

• 異步I/O（Posix.1的aio_系列函數）

2.I/O模型的相關術語

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

(1).阻塞和非阻塞:

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

(2).同步和異步:

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

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

(3).I/O

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

(4).總結

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

       非阻塞I/O ，I/O複用，信號驅動式I/O其實都是非阻塞的，當然是針對“請求”這個階段。非阻塞式是主動查詢外設狀態。I/O複用裏的select，poll也是主動查詢，不同的是select和poll可以同時查詢多個fd（文件句柄）的狀態，另外select有fd個數的限制。epoll是基於回調函數的。信號驅動式I/O則是基於信號消息的。這兩個應該可以歸到“被動接收消息”那一類中。最後就是偉大的AIO的出現，內核把什麼事都幹了，對上層應用實現了全異步，性能最好，當然複雜度也最高。好了，下面我們就來詳細說一說，這幾種模式。

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

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

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

1.阻塞I/O

說明：應用程序調用一個IO函數，導致應用程序阻塞，等待數據準備好。 如果數據沒有準備好，一直等待數據準備好了，從內核拷貝到用戶空間,IO函數返回成功指示。這個不用多解釋吧，阻塞套接字。下圖是它調用過程的圖示：（注，一般網絡I/O都是阻塞I/O，客戶端發出請求，Web服務器進程響應，在進程沒有返回頁面之前，這個請求會處於一直等待狀態）

2.非阻塞I/O

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

3.I/O複用（select和poll）

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

4.信號驅動I/O（SIGIO）

首先，我們允許套接口進行信號驅動I/O，並安裝一個信號處理函數，進程繼續運行並不阻塞。當數據準備好時，進程會收到一個SIGIO信號，可以在信號處理函數中調用I/O操作函數處理數據。具體過程如下圖:

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

當一個異步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀態、通知和回調來通知調用者的輸入輸出操作。具體過程如下圖:

6.I/O 模型總結（如下圖）    
0987654

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

同步I/O:

• 阻塞I/O

• 非阻塞I/O

• I/O複用（select和poll）      

異步I/O:

• 信號驅動I/O（SIGIO） （半異步）

• 異步I/O（Posix.1的aio_系列函數） （真正的異步）

異步 I/O 和 信號驅動I/O的區別:

• 信號驅動 I/O 模式下，內核可以複製的時候通知給我們的應用程序發送SIGIO 消息。

• 異步 I/O 模式下，內核在所有的操作都已經被內核操作結束之後纔會通知我們的應用程序。

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

七、Linux I/O模型的具體實現

1.主要實現方式有以下幾種：

• select

• poll

• epoll

• kqueue

• /dev/poll

• iocp

注，其中iocp是Windows實現的，select、poll、epoll是Linux實現的，kqueue是FreeBSD實現的，/dev/poll是SUN的Solaris實現的。select、poll對應第3種（I/O複用）模型，iocp對應第5種（異步I/O）模型，那麼epoll、kqueue、/dev/poll呢？其實也同select屬於同一種模型，只是更高級一些，可以看作有了第4種（信號驅動I/O）模型的某些特性，如callback機制。

2.爲什麼epoll、kqueue、/dev/poll比select高級？

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

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

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

4.總結一些重點

• 只有IOCP(windows實現)是asynchronous I/O，其他機制或多或少都會有一點阻塞。

• select（Linux實現）低效是因爲每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善

• epoll(Linux實現)、kqueue（FreeBSD實現）、/dev/poll（Solaris實現）是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：多進程，每個請求用一個進程響應，這個過程會用到select機制來通知。

• worker：多線程，一個進程可以生成多個線程，每個線程響應一個請求，但通知機制還是select不過可以接受更多的請求。

• event：基於異步I/O模型，一個進程或線程，每個進程或線程響應多個用戶請求，它是基於事件驅動（也就是epoll機制）實現的。

2.prefork的工作原理

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

3.worker的工作原理

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

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

       一個進程響應多個用戶請求，利用callback機制，讓套接字複用，請求過來後進程並不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，進程本身一直處於空閒狀態，可以一直接收用戶請求。可以實現一個進程程響應多個用戶請求。支持持海量併發連接數，消耗更少的資源。

九、支持高併發的Web服務器

有幾個基本條件：

1.基於線程，即一個進程生成多個線程，每個線程響應用戶的每個請求。

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

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

4.支持mmap內存映射，mmap傳統的web服務器，進行頁面輸入時，都是將磁盤的頁面先輸入到內核緩存中，再由內核緩存中複製一份到web服務器上，mmap機制就是讓內核緩存與磁盤進行映射，web服務器，直接複製頁面內容即可。不需要先把磁盤的上的頁面先輸入到內核緩存去。

剛好，Nginx 支持以上所有特性。所以Nginx官網上說，Nginx支持50000併發，是有依據的。好了，基礎知識就說到這邊下面我們來談談我們今天講解的重點Nginx。

十、Nginx 詳解

1.簡介

       傳統上基於進程或線程模型架構的web服務通過每進程或每線程處理併發連接請求，這勢必會在網絡和I/O操作時產生阻塞，其另一個必然結果則是對內存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境，這包括爲其分配堆內存和棧內存，以及爲其創建新的執行上下文等。這些操作都需要佔用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統性能也會由此進一步下降。另一種高性能web服務器/web服務器反向代理：Nginx（Engine X），nginx的主要着眼點就是其高性能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啓發於多種操作系統設計中基於“事件”的高級處理機制，nginx採用了模塊化、事件驅動、異步、單線程及非阻塞的架構，並大量採用了多路複用及事件通知機制。在nginx中，連接請求由爲數不多的幾個僅包含一個線程的進程worker以高效的迴環(run-loop)機制進行處理，而每個worker可以並行處理數千個的併發連接及請求。

2.Nginx 工作原理

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

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

• 讀取並驗正配置信息；

• 創建、綁定及關閉套接字；

• 啓動、終止及維護worker進程的個數；

• 無須中止服務而重新配置工作特性；

• 控制非中斷式程序升級，啓用新的二進制程序並在需要時回滾至老版本；

• 重新打開日誌文件；

• 編譯嵌入式perl腳本；

worker進程主要完成的任務包括：

• 接收、傳入並處理來自客戶端的連接；

• 提供反向代理及過濾功能；

• nginx任何能完成的其它任務；

注，如果負載以CPU密集型應用爲主，如SSL或壓縮應用，則worker數應與CPU數相同；如果負載以IO密集型爲主，如響應大量內容給客戶端，則worker數應該爲CPU個數的1.5或2倍。

3.Nginx 架構

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

4.Nginx 基礎功能

• 處理靜態文件，索引文件以及自動索引；

• 反向代理加速(無緩存)，簡單的負載均衡和容錯；

• FastCGI，簡單的負載均衡和容錯；

• 模塊化的結構。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求併發處理；

• SSL 和 TLS SNI 支持；

5.Nginx IMAP/POP3 代理服務功能

• 使用外部 HTTP 認證服務器重定向用戶到 IMAP/POP3 後端；

• 使用外部 HTTP 認證服務器認證用戶後連接重定向到內部的 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 支持的操作系統

• 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 系列操作系統;

7.Nginx 結構與擴展

• 一個主進程和多個工作進程，工作進程運行於非特權用戶；

• 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, 有效數據的數目，錯誤代碼；

• 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 內存。

• 最小化的數據拷貝操作；

8.Nginx 其他HTTP功能

• 基於IP 和名稱的虛擬主機服務；

• Memcached 的 GET 接口；

• 支持 keep-alive 和管道連接；

• 靈活簡單的配置；

• 重新配置和在線升級而無須中斷客戶的工作進程；

• 可定製的訪問日誌，日誌寫入緩存，以及快捷的日誌回捲；

• 4xx-5xx 錯誤代碼重定向；

• 基於 PCRE 的 rewrite 重寫模塊；

• 基於客戶端 IP 地址和 HTTP 基本認證的訪問控制；

• PUT, DELETE, 和 MKCOL 方法；

• 支持 FLV （Flash 視頻）；

• 帶寬限制；

9.爲什麼選擇Nginx

• 在高連接併發的情況下，Nginx是Apache服務器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟件平臺之一. 能夠支持高達 50,000 個併發連接數的響應, 感謝Nginx爲我們選擇了 epoll and kqueue 作爲開發模型。

• Nginx作爲負載均衡服務器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作爲 HTTP代理 服務器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。

• 作爲郵件代理服務器: Nginx 同時也是一個非常優秀的郵件代理服務器（最早開發這個產品的目的之一也是作爲郵件代理服務器）, Last.fm 描述了成功並且美妙的使用經驗.

• Nginx 是一個 [#installation 安裝] 非常的簡單 , 配置文件 非常簡潔（還能夠支持perl語法）,Bugs 非常少的服務器: Nginx 啓動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啓動. 你還能夠 不間斷服務的情況下進行軟件版本的升級 。

• Nginx 的誕生主要解決C10K問題

好了，到這裏Nginx的理論部分就說到這了，下一篇博文中我們將詳細說明，Nginx的安裝與應用。希望大家有所收穫……