常見的web服務方式
Web服務器要爲用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web服務器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、異步方式。
多進程方式：爲每個請求啓動一個進程來處理。由於在操作系統中，生成進程、銷燬進程、進程間切換都很消耗CPU和內存，當負載高是，性能會明顯降低。
優點： 穩定性！由於採用獨立進程處理獨立請求，而進程之間是獨立的，單個進程問題不會影響其他進程，因此穩定性最好。
缺點： 資源佔用！當請求過大時，需要大量的進程處理請求，進程生成、切換開銷很大，而且進程間資源是獨立的，造成內存重複利用。
多線程方式：一個進程中用多個線程處理用戶請求。由於線程開銷明顯小於進程，而且部分資源還可以共享，因此效率較高。
優點：開銷較小！線程間部分數據是共享的，且線程生成與線程間的切換所需資源開銷比進程間切換小得多。
缺點：穩定性！線程切換過快可能造成線程抖動，且線程過多會造成服務器不穩定。
異步方式：使用非阻塞方式處理請求，是三種方式中開銷最小的。但異步方式雖然效率高，但要求也高，因爲多任務之間的調度如果出現問題，就可能出現整體故障，因此使用異步工作的，一般是一些功能相對簡單，但卻符合服務器任務調度、且代碼中沒有影響調度的錯誤代碼存在的程序。
優點：性能最好！一個進程或線程處理多個請求，不需要額外開銷，性能最好，資源佔用最低。
缺點：穩定性！某個進程或線程出錯，可能導致大量請求無法處理，甚至導致整個服務宕機。
一個web請求的處理過程
客戶發起情況到服務器網卡；
服務器網卡接受到請求後轉交給內核處理；
內核根據請求對應的套接字，將請求交給工作在用戶空間的Web服務器進程
Web服務器進程根據用戶請求，向內核進行系統調用，申請獲取相應資源（如index.html）
內核發現web服務器進程請求的是一個存放在硬盤上的資源，因此通過驅動程序連接磁盤
內核調度磁盤，獲取需要的資源
內核將資源存放在自己的緩衝區中，並通知Web服務器進程
Web服務器進程通過系統調用取得資源，並將其複製到進程自己的緩衝區中
Web服務器進程形成響應，通過系統調用再次發給內核以響應用戶請求
內核將響應發送至網卡
網卡發送響應給用戶
通過這樣的一個複雜過程，一次請求就完成了。
簡單來說就是：用戶請求-->送達到用戶空間-->系統調用-->內核空間-->內核到磁盤上讀取網頁資源->返回到用戶空間->響應給用戶。
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 工作原理
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倍。
爲什麼選擇Nginx
在高連接併發的情況下，Nginx是Apache服務器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟件平臺之一. 能夠支持高達 50,000 個併發連接數的響應, 感謝Nginx爲我們選擇了 epoll and kqueue 作爲開發模型。
Nginx作爲負載均衡服務器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作爲 HTTP代理 服務器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。
作爲郵件代理服務器: Nginx 同時也是一個非常優秀的郵件代理服務器（最早開發這個產品的目的之一也是作爲郵件代理服務器）, Last.fm 描述了成功並且美妙的使用經驗.
Nginx 安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）,Bugs 非常少的服務器: Nginx 啓動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啓動. 你還能夠 不間斷服務的情況下進行軟件版本的升級 。
Nginx 的誕生主要解決C10K問題