Web服務器之Nginx詳解（理論部分）

時間 2019-11-16

標籤 web 服務器 nginx 詳解理論部分欄目 HTML 简体版

原文原文鏈接

大綱html

1、前言nginx

2、Web服務器提供服務的方式web

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

4、Web 服務請求過程windows

5、Linux I/O 模型後端

6、Linux I/O 模型具體說明瀏覽器

7、Linux I/O模型的具體實現緩存

8、Apache 的工做模式服務器

9、支持高併發的Web服務器網絡

10、Nginx 詳解

1、前言

注，在說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分鐘內無論用戶怎麼點擊（包括新窗口打開）都仍是一人在線。
當用戶打開頁面而後正常關閉瀏覽器，用戶的在線人數也會立刻清除。

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

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

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

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

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

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

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

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

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

1.多進程

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

優勢：

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

缺點：

進程量大，進程切換次數過多，致使CPU資源使用效率低
每一個進程的地址空間是獨立的，不少空間中重複的數據，因此內存使用效率低
進程切換因爲內核完成，佔用CPU資源

2.多線程

在多線程方式中，每一個線程來響應一下請求，因爲線程之間共享進程的數據，因此線程的開銷較小，性能就會提升。

優勢：

線程間共享進程數據
每一個線程響應一個請求
線程切換不可避免（切換量級比較輕量）
同一進程的線程能夠共享進程的諸多資源，好比打開的文件
對內存的需求較之進程有很大降低
讀能夠共享，寫不能夠共享

缺點：

線程快速切換時會帶來線程抖動
多線程會致使服務器不穩定

3.異步方式

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

4、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模型。

5、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的出現，內核把什麼事都幹了，對上層應用實現了全異步，性能最好，固然複雜度也最高。好了，下面咱們就來詳細說一說，這幾種模式。

6、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種模型的比較比較清晰了，下面咱們來講一下五種模型的具體實現。

7、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模型

8、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機制來通知請求是否完成；在這個過程當中，進程自己一直處於空閒狀態，能夠一直接收用戶請求。能夠實現一個進程程響應多個用戶請求。支持持海量併發鏈接數，消耗更少的資源。

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

有幾個基本條件：

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

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

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

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

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

10、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問題