一、程序、執行緒？

程序是具有一定獨立功能的，在計算機中已經執行的程式的實體。在早期系統中（如linux 2.4以前），程序是基本運作單位，在支援執行緒的系統中（如windows，linux2.6）中，執行緒才是基本的運作單位，而程序只是執行緒的容器。程式 本身只是指令、資料及其組織形式的描述，程序才是程式（那些指令和資料）的真正執行例項。若干程序有可能與同一個程式相關係，且每個程序皆可以同步（循 序）或非同步（平行）的方式獨立執行。現代計算機系統可在同一段時間內以程序的形式將多個程式載入到儲存器中，並藉由時間共享（或稱時分複用），以在一個處 理器上表現出同時（平行性）執行的感覺。同樣的，使用多執行緒技術（多執行緒即每一個執行緒都代表一個程序內的一個獨立執行上下文）的作業系統或計算機架構，同 樣程式的平行執行緒，可在多 CPU 主機或網路上真正同時執行（在不同的CPU上）。

二、常見Web服務方式

2.1 三種工作模型比較：

Web伺服器要為使用者提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理使用者請求是，一般有如下三種方式可選擇：多程序方式、多執行緒方式、非同步方式。

• 多程序方式：為每個請求啟動一個程序來處理。由於在作業系統中，生成程序、銷燬程序、程序間切換都很消耗CPU和記憶體，當負載高是，效能會明顯降低。

優點： 穩定性！由於採用獨立程序處理獨立請求，而程序之間是獨立的，單個程序問題不會影響其他程序，因此穩定性最好。

缺點： 資源佔用！當請求過大時，需要大量的程序處理請求，程序生成、切換開銷很大，而且程序間資源是獨立的，造成記憶體重複利用。

• 多執行緒方式：一個程序中用多個執行緒處理使用者請求。由於執行緒開銷明顯小於程序，而且部分資源還可以共享，因此效率較高。

優點：開銷較小！執行緒間部分資料是共享的，且執行緒生成與執行緒間的切換所需資源開銷比程序間切換小得多。

缺點：穩定性！執行緒切換過快可能造成執行緒抖動，且執行緒過多會造成伺服器不穩定。

• 非同步方式：使用非阻塞方式處理請求，是三種方式中開銷最小的。但非同步方式雖然效率高，但要求也高，因為多工之間的排程如果出現問題，就可能出現整體故障，因此使用非同步工作的，一般是一些功能相對簡單，但卻符合伺服器任務排程、且程式碼中沒有影響排程的錯誤程式碼存在的程式。

優點：效能最好！一個程序或執行緒處理多個請求，不需要額外開銷，效能最好，資源佔用最低。

缺點：穩定性！某個程序或執行緒出錯，可能導致大量請求無法處理，甚至導致整個服務宕機。

2.2 一個Web請求的處理過程：

1. 客戶發起情況到伺服器網絡卡；
2. 伺服器網絡卡接受到請求後轉交給核心處理；
3. 核心根據請求對應的套接字，將請求交給工作在使用者空間的Web伺服器程序
4. Web伺服器程序根據使用者請求，向核心進行系統呼叫，申請獲取相應資源（如index.html）
5. 核心發現web伺服器程序請求的是一個存放在硬碟上的資源，因此通過驅動程式連線磁碟
6. 核心排程磁碟，獲取需要的資源
7. 核心將資源存放在自己的緩衝區中，並通知Web伺服器程序
8. Web伺服器程序通過系統呼叫取得資源，並將其複製到程序自己的緩衝區中
9. Web伺服器程序形成響應，通過系統呼叫再次發給核心以響應使用者請求
10. 核心將響應傳送至網絡卡
11. 網絡卡傳送響應給使用者

通過這樣的一個複雜過程，一次請求就完成了。

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

三、各種I/O模型詳解

通過上面的對連線的處理分析，我們知道工作在使用者空間的web伺服器程序是無法直接操作IO的，需要通過系統呼叫進行，其關係如下：

即程序向核心進行系統呼叫申請IO，核心將資源從IO排程到核心的buffer中（wait階段），核心還需將資料從核心buffer中複製（copy階段）到web伺服器程序所在的使用者空間，才算完成一次IO排程。這幾個階段都是需要時間的。根據wait和copy階段的處理等待的機制不同，可將I/O動作分為如下五種模式：

• 阻塞I/O
• 非阻塞I/O
• I/O複用（select和poll）
• 訊號（事件）驅動I/O（SIGIO）
• 非同步I/O（aio）
  

  3.1 I/O模型簡介

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

3.1.1 阻塞和非阻塞:

阻塞和非阻塞指的是執行一個操作是等操作結束再返回，還是馬上返回。

比如餐館的服務員為使用者點菜，當有使用者點完菜後，服務員將選單給後臺廚師，此時有兩種方式：

• 第一種：就在出菜視窗等待，直到廚師炒完菜後將菜送到視窗，然後服務員再將菜送到使用者手中；
• 第二種：等一會再到視窗來問廚師，某個菜好了沒？如果沒有先處理其他事情，等會再去問一次；

第一種就是阻塞方式，第二種則是非阻塞的。

3.1.2 同步和非同步:

同步和非同步又是另外一個概念，它是事件本身的一個屬性。還拿前面點菜為例，服務員直接跟廚師打交道，菜出來沒出來，服務員直接指導，但只有當廚師將 菜送到服務員手上，這個過程才算正常完成，這就是同步的事件。同樣是點菜，有些餐館有專門的傳菜人員，當廚師炒好菜後，傳菜員將菜送到傳菜視窗，並通知服 務員，這就變成非同步的了。其實非同步還可以分為兩種：帶通知的和不帶通知的。前面說的那種屬於帶通知的。有些傳菜員幹活可能主動性不是很夠，不會主動通知 你，你就需要時不時的去關注一下狀態。這種就是不帶通知的非同步。

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

3.1.3 全非同步I/O

回到I/O，不管是I還是O，對外設(磁碟)的訪問都可以分成請求和執行兩個階段。請求就是看外設的狀態資訊（比如是否準備好了），執行才是真正的 I/O操作。在Linux 2.6之前，只有“請求”是非同步事件，2.6之後才引入AIO（asynchronous I/O ）把“執行”非同步化。別看Linux/Unix是用來做伺服器的，這點上比Windows落後了好多，IOCP（Windows上的AIO，效率極高）在Win2000上就有了。所以學linux的別老覺得Windows這裡不好那裡不好（Windows的多執行緒機制也由於linux）。

3.1.4 I/O的五種模型

根據以上分析，I/O可分為五種模型：

• 阻塞I/O：所有過程全阻塞
• 非阻塞I/O：如果沒有資料buffer，則立即返回EWOULDBLOCK
• I/O複用（select和poll）：在wait和copy階段分別阻塞
• 訊號驅動I/O（SIGIO）：在wait階段不阻塞，但copy階段阻塞（訊號驅動I/O，即通知）
• 非同步I/O（aio）：完全五阻塞方式，當I/O完成是提供訊號

Linux上的前四種I/O模型的“執行”階段都是同步的，只有最後一種才做到了真正的全非同步。第一種阻塞式是最原始的方法，也是最累的辦法。當然 累與不累要看針對誰。應用程式是和核心打交道的。對應用程式來說，這種方式是最累的，但對核心來說這種方式恰恰是最省事的。還拿點菜這事為例，你就是應用 程式，廚師就是核心，如果你去了一直等著，廚師就省事了（不用同時處理其他服務員的菜）。當然現在計算機的設計，包括作業系統，越來越為終端使用者考慮了， 為了讓使用者滿意，核心慢慢的承擔起越來越多的工作，IO模型的演化也是如此。

非阻塞I/O ，I/O複用，訊號驅動式I/O其實都是非阻塞的，當然是針對“請求”這個階段。非阻塞式是主動查詢外設狀態。I/O複用裡的select，poll也是 主動查詢，不同的是select和poll可以同時查詢多個fd（檔案控制代碼）的狀態，另外select有fd個數的限制。epoll是基於回撥函式的。信 號驅動式I/O則是基於訊號訊息的。這兩個應該可以歸到“被動接收訊息”那一類中。最後就是偉大的AIO的出現，核心把什麼事都幹了，對上層應用實現了全 非同步，效能最好，當然複雜度也最高。

3.2 各I/O模型詳細介紹【本部分摘自獨孤成部落格】：

3.2.1 阻塞I/O

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

3.2.2 非阻塞I/O

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

3.2.3 I/O複用（select和poll）

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

3.2.4 訊號驅動I/O（SIGIO）

首先，我們允許套介面進行訊號驅動I/O，並安裝一個訊號處理函式，程序繼續執行並不阻塞。當資料準備好時，程序會收到一個SIGIO訊號，可以在訊號處理函式中呼叫I/O操作函式處理資料。具體過程如下圖:

3.2.5 非同步I/O（aio）

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

3.2.6 I/O 模型總結（如下圖）

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

同步I/O:

阻塞I/O
非阻塞I/O
I/O複用（select和poll）

非同步I/O:

訊號驅動I/O（SIGIO） （半非同步）
非同步I/O（aio） （真正的非同步）

非同步 I/O 和 訊號驅動I/O的區別:

訊號驅動 I/O 模式下，核心可以複製的時候通知給我們的應用程式傳送SIGIO 訊息。
非同步 I/O 模式下，核心在所有的操作都已經被核心操作結束之後才會通知我們的應用程式。

3.3 Linux I/O模型的具體實現[轉自孤城部落格]

3.3.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機制。

3.3.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.3.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 已經做得很優秀了。

3.3.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 Httpd的工作模式

4.1 apache三種工作模式

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

• prefork：多程序，每個請求用一個程序響應，這個過程會用到select機制來通知。
• worker：多執行緒，一個程序可以生成多個執行緒，每個執行緒響應一個請求，但通知機制還是select不過可以接受更多的請求。
• event：基於非同步I/O模型，一個程序或執行緒，每個程序或執行緒響應多個使用者請求，它是基於事件驅動（也就是epoll機制）實現的。

4.2 prefork的工作原理

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

4.3 worker的工作原理

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

4.4 event 基於事件機制的特性

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

五、如何提高Web伺服器的併發連線處理能力

有幾個基本條件：

• 基於執行緒，即一個程序生成多個執行緒，每個執行緒響應使用者的每個請求。
• 基於事件的模型，一個程序處理多個請求，並且通過epoll機制來通知使用者請求完成。
• 基於磁碟的AIO（非同步I/O）
• 支援mmap記憶體對映，mmap傳統的web伺服器，進行頁面輸入時，都是將磁碟的頁面先輸入到核心快取中，再由核心快取中複製一份到web服務 器上，mmap機制就是讓核心快取與磁碟進行對映，web伺服器，直接複製頁面內容即可。不需要先把磁碟的上的頁面先輸入到核心快取去。

剛好，Nginx 支援以上所有特性。所以Nginx官網上說，Nginx支援50000併發，是有依據的。

六、Nginx優異之處

6.1 簡介

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

6.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倍。

6.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建立會話等。

6.4 Nginx 基礎功能

• 處理靜態檔案，索引檔案以及自動索引；
• 反向代理加速(無快取)，簡單的負載均衡和容錯；
• FastCGI，簡單的負載均衡和容錯；
• 模組化的結構。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求併發處理；
• SSL 和 TLS SNI 支援；

6.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.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 系列作業系統;

6.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 記憶體。
• 最小化的資料拷貝操作；

6.8 Nginx 其他HTTP功能

• 基於IP 和名稱的虛擬主機服務；
• Memcached 的 GET 介面；
• 支援 keep-alive 和管道連線；
• 靈活簡單的配置；
• 重新配置和線上升級而無須中斷客戶的工作程序；
• 可定製的訪問日誌，日誌寫入快取，以及快捷的日誌回捲；
• 4xx-5xx 錯誤程式碼重定向；
• 基於 PCRE 的 rewrite 重寫模組；
• 基於客戶端 IP 地址和 HTTP 基本認證的訪問控制；
• PUT, DELETE, 和 MKCOL 方法；
• 支援 FLV （Flash 視訊）；
• 頻寬限制；

6.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問題