網路程式著名的 C10K 問題

阻塞 I/O (bloking I/O)

程序對 I/O 提出請求時，如果 I/O 不能立即完成操作，程序與執行緒進入等待狀態，直到 I/O 操作完成。在這個模型中執行緒實際等待的時間包含兩部分，一個是等待資料就緒，另一個是等待資料複製完成，對於網路 I/O 來說，等待資料就緒的時間顯然要長一點。在這個模型當中如果平行連線數過多，通常會搭配多執行緒使用。這是最簡單也最直覺的模型，也由於簡單，所以被廣泛的使用。

非阻塞 I/O (non-bloking I/O)

程序對 I/O 提出請求時，如果 I/O 不能立即完成操作，執行緒會立即返回狀態碼，此時程序可以先處理別的請求後再向 I/O 詢問資料準備好了沒，反覆此過程，直到資料準備就緒，這個過程被稱為輪詢 (Polling)。在這個模型當中，在資料準備階段程序與執行緒皆不阻塞，最大的好處是在同一個執行緒可同時處理多個 I/O 操作，但需要消耗大量 CPU 時間來做輪詢的動作，要注意的是，資料複製階段程序依然處於阻塞。

多路複用 I/O (multiplexing I/O)

在非阻塞 I/O 模型中，當伺服器收到多個連線時，就必須輪流對每個執行緒詢問資料是否準備就緒，不管這些執行緒是否有接收到資料，都必須詢問一遍，這顯然不是好的策略。多路複用 I/O 的出現就是為了改善這個問題，在多路複用 I/O 模型中，程序提出請求時，執行緒透過某種方式來監視資源是否準備就緒，並可快速得到就緒的資源符號，然後只針對就緒的資源做處理，與非阻塞 I/O 不同的是，多路複用 I/O 可同時等待多個資源，待一部分資源到來，便可先行處理，而無需等到所有的資源到達。由於平台歷史的原因，多路複用 I/O 有很多不同的實作，其效能也有些微的差異，常見的有 select、poll、SIGIO、epoll 及 kqueue。

select 與 poll 本質上沒有什麼不同，當程序呼叫 select 時，實際上是讓 select 監視所需的資料，此時無論有多少連線處於活躍狀態或有多少檔案準備就緒，select 都會對其做一次線性掃描，當資料準備就緒之後 select 會通知程序，此時如果程序沒有對其進行 I/O 操作，下次呼叫 select 的時候，將再次報告這些檔案已準備就緒，因此一般不會有遺失的問題，該方式被稱為水平觸發 (Level Triggered)。select 的一個缺點在於單一執行緒能監視的檔案描述符號是有上限的，通常為 1024，而 poll 則沒有這個限制。兩者共同存在的缺點是，當大量的檔案描述符號被整體複製於程序與核心的位址空間，系統資源的消耗會隨著檔案描述符號的數量增加而增加。我們常用的 Apache 即是使用 select 模型，因此才會有 C10K 的問題。

SIGIO 被稱為訊息驅動 (signal-driven I/O)，它透過即時訊號來實作 select/poll 的通知方法，不同的是 select/poll 在資料準備就緒時會一直通知程序，直到程序讀寫資源為止；而 SIGIO 只會通知一次，如果程序不做任何讀寫的話，他也不會再次通知，該方式稱為邊緣觸發 (Edge Triggered)。其缺點是代表事件的訊號是由核心事件佇列來維護，訊號按照順序進行通知，這可能導致訊號到達時，該事件已經過期了，有造成遺失的問題，另外事件佇列也是有長度限制的。

epoll 實作於 Linux 2.6；kqueue 實作於 FreeBSD，兩者一樣都可以設定水平觸發或邊緣觸發，預設情況下 epoll 使用水平觸發，同時使用記憶體映射技術來解決 select/poll 中大量描述符號被整體複製時資源消耗過大的問題，且 epoll 直接由核心支援，被公認為 Linux 2.6 下效能最好的多路複用 I/O。Nginx 即是使用 epoll 模型且使用邊緣觸發模式。

非同步 I/O (asynchronous I/O)

程序對 I/O 提出請求時，無論資料是否準備好，都直接返回，然後程序就可以去做別的事情了，待資料準備就緒，內核直接複製數據，然後通知程序，該模型在資料準備與資料複製都是非阻塞的。

了解上面的 I/O 模型的差異之後，如果大家想要進一步瞭解這些模型效能上的差異，我會建議大家看一下巨型網站大師親自指導：建立極速 Web 站台的祕密這本書，這本書在 3.7 章伺服器平行策略有針對不同模型的實驗紀錄及數據。您或許會好奇為什麼 Apache 不使用 epoll 模式，那是因為 Apache 很多模組都是針對 select 模型而設計的，要全面改成 epoll 模型，想必是一件大工程吧。