Linux下的I/O模型以及各自的優缺點

2020-06-16 17:08:44

其實關於這方面的知識，我閱讀的是《UNIX網路程式設計:卷一》，書裡是以UNIX為中心展開描述的，根據這部分知識，在網上參考了部分資料。以Linux為中心整理了這篇部落格。

UNIX 網路程式設計（第2版）第1卷：套介面API和X／Open 傳輸介面API PDF http://www.linuxidc.com/Linux/2014-04/100155.htm

UNIX網路程式設計捲1:通訊端聯網API(第3版) 中文高清帶完整書籤 PDF http://www.linuxidc.com/Linux/2014-04/100222.htm

Linux的I/O模型

和Unix的I/O模型基本一致，Linux下一共有5種I/O模型_[1]

阻塞式I/O模型；
非阻塞式I/O模型；
I/O複用式模型；
信號驅動動式I/O模型
非同步I/O模型

上面這個列表，算是絕大部分關於Linux I/O模型部落格中都會貼出來的。

在上述５種I/O模型中，前4種，其實都可以劃分為同步I/O方式，只有最有一種非同步I/O模型才使用非同步I/O方式。
為什麼這麼劃分呢，就得仔細看看這5種I/O模型到底是什麼。

行文須知

下文中對各個模型的描述，都是使用資料包(UDP)通訊端作為例子進行說明的。
因為UDP相對與TCP來說比較簡單——要麼整個資料包已經收到，要麼還沒有——而對於TCP來說，通訊端低水位標記等額外變數開始起作用,導致整個概念變得複雜。（加粗字型的內容在寫這篇部落格時，並沒有搞清楚是什麼，可能後續會陸續搞懂）

一、阻塞式I/O

通常我們使用的I/O都是阻塞式I/O，在程式設計時使用的大多數也是阻塞式I/O。在預設情況下，所有的通訊端(socket)都是阻塞的。下圖解釋了阻塞式I/O模型的流程

上圖中，我們說從呼叫recvfrom開始到它返回的整段時間內是被阻塞的，recvfrom成功返回後，參照程式才開始處理資料包。

阻塞式I/O的優缺點

優點：
阻塞式I/O很容易上手，一般程式按照read-process的順序進行處理就好。通常來說我們編寫的第一個TCP的C/S程式就是阻塞式I/O模型的。並且該模型定位錯誤，在阻塞時整個進程將被掛起，基本不會佔用CPU資源。
缺點:
該模型的缺點也十分明顯。作為伺服器，需要處理同時多個的通訊端，使用該模型對具有多個的用戶端並行的場景時就顯得力不從心。
當然也有補救方法，我們使用多執行緒技術來彌補這個缺陷。但是多執行緒在具有大量連線時，多執行緒技術帶來的資源消耗也不容小看：

如果我們現在有1000個連線時，就需要開啟1000個執行緒來處理這些連線，於是就會出現下面的情況

執行緒有記憶體開銷，假設每個執行緒需要512K的存放棧，那麼1000個連線就需要月512M的記憶體。當並行量高的時候，這樣的記憶體開銷是無法接受的。

執行緒切換有CPU開銷，這個CPU開銷體現在上下文切換上，如果執行緒數越多，那麼大多數CPU時間都用於上下文切換，這樣每個執行緒的時間槽會非常短，CPU真正處理資料的時間就會少了非常多。

二、非阻塞式I/O

有阻塞I/O，那麼也會有非阻塞I/O，在上文說過預設情況下，所有的通訊端都是阻塞的，那麼通過設定通訊端的NONBLOCK(一般在open(),socket()等呼叫中設定)標誌或者設定recv、send等輸入輸出函數的MSG_DONTWAIT標誌就可以實現非阻塞操作。
那我們來看看非阻塞I/O模型的執行流程吧

可以看到，前三次recvfrom時沒有資料可以返回，此時核心不阻塞進程，轉而立即返回一個EWOULDBLOCK錯誤。第四次呼叫recvfrom時已經有一個資料包準備好了，此時它將被複製到應用進程的緩衝區，於是recvfrom呼叫成功返回。
當一個應用進程像這樣對一個非阻塞描述符迴圈呼叫recvfrom時，我們稱之為輪詢(polling)

非阻塞式I/O的優缺點

優點：
這種I/O方式也有明顯的優勢，即不會阻塞在核心的等待資料過程，每次發起的I/O請求可以立即返回，不用阻塞等待。在資料量收發不均，等待時間隨機性極強的情況下比較常用。
缺點
輪詢這一個特徵就已近暴露了這個I/O模型的缺點。輪詢將會不斷地詢問核心，這將占用大量的CPU時間，系統資源利用率較低。同時，該模型也不便於使用，需要編寫複雜的程式碼。

三、I/O複用模型

上文中說到，在出現大量的連結時，使用多執行緒+阻塞I/O的程式設計模型會佔用大量的記憶體。那麼I/O復用技術在記憶體占用方面，就有著很好的控制。
當前的高效能反向代理伺服器Nginx使用的就是I/O複用模型(epoll),它以高效能和低資源消耗著稱，在大規模並行上也有著很好的表現。
那麼，我們就來看一看I/O複用模型的面目吧

那到底什麼是I/O複用(I/O multiplexing)。根據我的理解，復用指的是複用執行緒，從阻塞式I/O來看，基本一個通訊端就霸佔了整個執行緒。例如當對一個通訊端呼叫recvfrom呼叫時，整個執行緒將被阻塞掛起，直到資料包準備完畢。
多路複用就是複用一個執行緒的I/O模型，Linux中擁有幾個呼叫來實現I/O複用的系統呼叫——select,poll,epoll（Linux 2.6+）

執行緒將阻塞在上面的三個系統呼叫中的某一個之上，而不是阻塞在真正的I/O系統呼叫上。I/O複用允許對多個通訊端進行監聽，當有某個通訊端準備就緒(可讀/可寫/異常)時，系統呼叫將會返回。
然後我們可能將重新啟用一個執行緒並呼叫recvfrom來將特定通訊端中的資料包從核心緩衝區複製到進程緩衝區。

I/O複用模型的優缺點

優點
I/O復用技術的優勢在於，只需要使用一個執行緒就可以管理多個socket，系統不需要建立新的進程或者執行緒，也不必維護這些執行緒和進程，所以它也是很大程度上減少了資源佔用。
另外I/O復用技術還可以同時監聽不同協定的通訊端
缺點
在只處理連線數較小的場合，使用select的伺服器不一定比多執行緒+阻塞I/O模型效率高，可能延遲更大，因為單個連線處理需要2次系統呼叫，佔用時間會有增加。

四、信號驅動式I/O模型

當然你可能會想到使用信號這一機制來避免I/O時執行緒陷入阻塞狀態。那麼核心開發者怎麼可能會想不到。那麼我們來看看信號驅動式I/O模型的具體流程

從上圖可以看到，我們首先開啟通訊端的信號驅動式I/O功能，並通過sigaction系統呼叫來安裝一個信號處理常式，我們進程不會被阻塞。
當資料包準備好讀取時，核心就為該進程產生一個SIGIO信號，此時我們可以在信號處理常式中呼叫recvfrom讀取資料包，並通知資料已經準備好，正在等待處理。

信號驅動式I/O模型的優缺點

優點
很明顯，我們的執行緒並沒有在等待資料時被阻塞，可以提高資源的利用率
缺點
其實在Unix中，信號是一個被過度設計的機制(這句話來自知乎大神,有待考究)
信號I/O在大量IO操作時可能會因為信號佇列溢位導致沒法通知——這個是一個非常嚴重的問題。

稍微歇息一下，還記得我們前面說過這4種I/O模型都可以劃分為同步I/O方式，那我們來看看為什麼。
了解了４種I/O模型的呼叫過程後，我們可以注意到，在資料從核心緩衝區複製到使用者緩衝區時，都需要進程顯示呼叫recvfrom，並且這個複製過程是阻塞的。
也就是說真正I/O過程(這裡的I/O有點狹義，指的是核心緩衝區到使用者緩衝區)是同步阻塞的，不同的是各個I/O模型在資料包準備好之前的動作不一樣。

下面所說的非同步I/O模型將會有所不同

五、非同步I/O模型

非同步I/O，是由POSIX規範定義的。這個規範定義了一些函數，這些函數的工作機制是：告知核心啟動某個操作，並讓核心在整個操作完成後再通知我們。(包括將資料從核心複製到我們進程的緩衝區)
照樣，先看模型的流程

全程沒有阻塞，真正做到了非同步
非同步的優點還用說明嗎？

but

非同步I/O在Linux2.6才引入，而且到現在仍然未成熟。
雖然有知名的非同步I/O庫 glibc，但是聽說glibc採用多執行緒模擬，但存在一些bug和設計上的不合理。wtf？多執行緒模擬，那還有殺卵用。

引入非同步I/O可能會程式碼難以理解的問題，這個站在軟體工程的角度也是需要細細衡量的。

總結

關於對Linux 的I/O模型的學習就寫到這裡，每個模型都有自己使用的範圍

Talk is cheap, show me the code
實踐出真知。
關於I/O模型的實驗程式碼會在2017年10月前放到我的github倉庫中。

參考文獻

《Unix網路程式設計捲1：通訊端聯網API》（第3版）人民郵電出版社