在之前的文章《理解同步、異步、阻塞和非阻塞》我們談了一下關於同步、異步、阻塞和非阻塞的理解。這篇文章，我打算來談談unix的io模型，其中會涉及到下面的內容：
- 阻塞 I/O（blocking IO）
- 非阻塞 I/O（nonblocking IO）
- I/O 多路複用（ IO multiplexing）
- 異步 I/O（asynchronous IO）
- 信號驅動式IO模型(signal-driven IO model)
背景知識
在開始正式的介紹unix的io模型之前，我們需要科普一些背景知識，便於大家正確的理解unix io模型。
同步、異步、阻塞和非阻塞
這些概念請查看我之前的文章《理解同步、異步、阻塞和非阻塞》
文件描述符fd
文件描述符（File descriptor）是計算機科學中的一個術語，是一個用於表述指向文件的引用的抽象化概念。
文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核爲每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫往往會圍繞着文件描述符展開。但是文件描述符這一概念往往只適用於UNIX、Linux這樣的操作系統。
用戶空間（user space）與內核空間（kernel space）
學習 Linux 時，經常可以看到兩個詞：User space（用戶空間）和 Kernel space（內核空間）。
用戶空間（user space）與內核空間（kernel space）
簡單說，Kernel space 是 Linux 內核的運行空間，User space 是用戶程序的運行空間。爲了安全，它們是隔離的，即使用戶的程序崩潰了，內核也不受影響。
Kernel space 可以執行任意命令，調用系統的一切資源；User space 只能執行簡單的運算，不能直接調用系統資源，必須通過系統接口（又稱 system call），才能向內核發出指令。
1 2 3 4 |
str = "my string" // 用戶空間 x = x + 2 // 用戶空間 file.write(str) // 切換到內核空間 y = x + 4 // 切換回用戶空間 |
上面代碼中，第一行和第二行都是簡單的賦值運算，在 User space 執行。第三行需要寫入文件，就要切換到 Kernel space，因爲用戶不能直接寫文件，必須通過內核安排。第四行又是賦值運算，就切換回 User space。
進程的阻塞
正在執行的進程，由於期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變爲阻塞狀態。可見，進程的阻塞是進程自身的一種主動行爲，也因此只有處於運行態的進程（獲得CPU），纔可能將其轉爲阻塞狀態。當進程進入阻塞狀態，是不佔用CPU資源的。
進程切換
爲了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，並恢復以前掛起的某個進程的執行。這種行爲被稱爲進程切換。因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。進程之間的切換其實是需要耗費cpu時間的。
緩存 I/O
緩存I/O又被稱作標準I/O，大多數文件系統的默認I/O操作都是緩存I/O。在Linux的緩存I/O機制中，數據先從磁盤複製到內核空間的緩衝區，然後從內核空間緩衝區複製到應用程序的地址空間。
- 讀操作：操作系統檢查內核的緩衝區有沒有需要的數據，如果已經緩存了，那麼就直接從緩存中返回；否則從磁盤中讀取，然後緩存在操作系統的緩存中。
- 寫操作：將數據從用戶空間複製到內核空間的緩存中。這時對用戶程序來說寫操作就已經完成，至於什麼時候再寫到磁盤中由操作系統決定，除非顯示地調用了sync同步命令
緩存I/O的優點：
- 在一定程度上分離了內核空間和用戶空間，保護系統本身的運行安全；
- 可以減少物理讀盤的次數，從而提高性能。
緩存I/O的缺點：
- 在緩存I/O機制中，DMA方式可以將數據直接從磁盤讀到頁緩存中，或者將數據從頁緩存直接寫回到磁盤上，而不能直接在應用程序地址空間和磁盤之間進行數據傳輸，這樣，數據在傳輸過程中需要在應用程序地址空間（用戶空間）和緩存（內核空間）之間進行多次數據拷貝操作，這些數據拷貝操作所帶來的CPU以及內存開銷是非常大的。
因爲這個原因的存在，所以又設計到zero copy技術。關於zero copy這個內容，可以參考我之前寫的文章《java中的zero copy》
unix IO模型
在linux中，對於一次IO訪問（以read舉例），數據會先被拷貝到操作系統內核的緩衝區中，然後纔會從操作系統內核的緩衝區拷貝到應用程序的地址空間。所以說，當一個read操作發生時，它會經歷兩個階段：
- 等待數據準備就緒 (Waiting for the data to be ready)
- 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
正式因爲這兩個階段，linux系統產生了下面五種網絡模式的方案：
- 阻塞式IO模型(blocking IO model)
- 非阻塞式IO模型(noblocking IO model)
- IO複用式IO模型(IO multiplexing model)
- 信號驅動式IO模型(signal-driven IO model)
- 異步IO式IO模型(asynchronous IO model)
下面我們來分別談一下這些IO模型
阻塞式IO模型(blocking IO model)
在linux中，默認情況下所有的IO操作都是blocking，一個典型的讀操作流程大概是這樣：
當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據（對於網絡IO來說，很多時候數據在一開始還沒有到達。比如，還沒有收到一個完整的UDP包。這個時候kernel就要等待足夠的數據到來），而數據被拷貝到操作系統內核的緩衝區中是需要一個過程的，這個過程需要等待。而在用戶進程這邊，整個進程會被阻塞（當然，是進程自己選擇的阻塞）。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶空間的緩衝區以後，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。
所以：blocking IO的特點就是在IO執行的下兩個階段的時候都被block了。
- 等待數據準備就緒 (Waiting for the data to be ready)
「阻塞」 - 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
「阻塞」
非阻塞 I/O（nonblocking IO）
linux下，可以通過設置socket使其變爲non-blocking。通過java可以這麼操作：
1 2 3 4 5 6 |
InetAddress host = InetAddress.getByName("localhost");
Selector selector = Selector.open();
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.configureBlocking(false);
serverSocketChannel.bind(new InetSocketAddress(hos1234));
serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);
|
比較完善的例子請看《What Is Non-blocking Socket Programming in Java?》
socket設置爲 NONBLOCK（非阻塞）就是告訴內核，當所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤碼(EWOULDBLOCK) ，這樣請求就不會阻塞。
當對一個non-blocking socket執行讀操作時，流程是這個樣子：
當用戶進程調用了recvfrom這個系統調用，如果kernel中的數據還沒有準備好，那麼它並不會block用戶進程，而是立刻返回一個EWOULDBLOCK error。從用戶進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個EWOULDBLOCK error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麼它馬上就將數據拷貝到了用戶空間緩衝區，然後返回。
可以看到，I/O 操作函數將不斷的測試數據是否已經準備好，如果沒有準備好，繼續輪詢，直到數據準備好爲止。整個 I/O 請求的過程中，雖然用戶線程每次發起 I/O 請求後可以立即返回，但是爲了等到數據，仍需要不斷地輪詢、重複請求，消耗了大量的 CPU 的資源。
所以，non blocking IO的特點是用戶進程需要不斷的主動詢問kernel數據好了沒有：
- 等待數據準備就緒 (Waiting for the data to be ready)
「非阻塞」 - 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
「阻塞」
一般很少直接使用這種模型，而是在其他 I/O 模型中使用非阻塞 I/O 這一特性。這種方式對單個 I/O 請求意義不大,但給 I/O 多路複用鋪平了道路.
I/O 多路複用（ IO multiplexing）
IO multiplexing就是我們常說的select，poll，epoll，有些地方也稱這種IO方式爲event driven IO。select/epoll的好處就在於單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select，poll，epoll這些個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。
當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。
所以，I/O 多路複用的特點是通過一種機制一個進程能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函數就可以返回。
這個圖和blocking IO的圖其實並沒有太大的不同，事實上因爲IO多路複用多了添加監視 socket，以及調用 select 函數的額外操作，效率更差。還更差一些。因爲這裏需要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。但是，但是，使用 select 以後最大的優勢是用戶可以在一個線程內同時處理多個 socket 的 I/O 請求。用戶可以註冊多個 socket，然後不斷地調用 select 讀取被激活的 socket，即可達到在同一個線程內同時處理多個 I/O 請求的目的。而在同步阻塞模型中，必須通過多線程的方式才能達到這個目的。
所以，如果處理的連接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連接能處理得更快，而是在於能處理更多的連接。）
在IO multiplexing Model中，實際中，對於每一個socket，一般都設置成爲non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。
因此對於IO多路複用模型來說：
- 等待數據準備就緒 (Waiting for the data to be ready)
「阻塞」 - 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
「阻塞」
異步 I/O（asynchronous IO）
接下來我們看看linux下的asynchronous IO的流程：
用戶進程發起aio_read調用之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它發現一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。
異步 I/O 模型使用了 Proactor 設計模式實現了這一機制。
因此對異步IO模型來說：
- 等待數據準備就緒 (Waiting for the data to be ready)
「非阻塞」 - 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
「非阻塞」
信號驅動式IO模型(signal-driven IO model)
首先我們允許 socket 進行信號驅動 I/O,並安裝一個信號處理函數，進程繼續運行並不阻塞。當數據準備好時，進程會收到一個SIGIO信號，可以在信號處理函數中調用 I/O 操作函數處理數據。
但是這種IO模確用的不多，所以我這裏也就不詳細提它了。
總結
blocking和non-blocking的區別
調用blocking IO會一直block住對應的進程直到操作完成，會block2個階段，而non-blocking IO在kernel還準備數據的情況下會立刻返回，只會block第二個階段
synchronous IO和asynchronous IO的區別
在說明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。POSIX的定義是這樣子的：
- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
- An asynchronous I/O operation does not cause the requesting process to be blocked;
兩者的區別就在於synchronous IO做”IO operation”的時候會將process阻塞。按照這個定義，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO。
有人會說，non-blocking IO並沒有被block啊。這裏有個非常“狡猾”的地方，定義中所指的”IO operation”是指真實的IO操作，就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候，如果kernel的數據沒有準備好，這時候不會block進程。但是，當kernel中數據準備好的時候，recvfrom會將數據從kernel拷貝到用戶內存中，這個時候進程是被block了，在這段時間內，進程是被block的。
而asynchronous IO則不一樣，當進程發起IO 操作之後，就直接返回再也不理睬了，直到kernel發送一個信號，告訴進程說IO完成。在這整個過程中，進程完全沒有被block。
因此我們會得出下面的分類：
- 同步IO (synchronous IO)
- blocking IO model
- non-blocking IO model
- IO multiplexing model
- 異步IO (asynchronous IO)
- asynchronous IO model
各個IO Model的比較
前四種模型的區別是階段1不相同，階段2基本相同，都是將數據從內核拷貝到調用者的緩衝區。而異步 I/O 的兩個階段都不同於前四個模型。同步 I/O 操作引起請求進程阻塞，直到 I/O 操作完成。異步 I/O 操作不引起請求進程阻塞。
同時通過上面的圖片，可以發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，並且當數據準備完成以後，也需要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人（kernel）完成，然後他人做完後發信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態，也不需要主動的去拷貝數據。