IO模式和IO多路複用

原文連接:http://www.javashuo.com/article/p-pnwzixrq-n.html

http://www.javashuo.com/article/p-xaxjhpru-z.html

　　網絡編程裏常聽到阻塞IO、非阻塞IO、同步IO、異步IO等概念，總聽別人裝13不如本身下來鑽研一下。不過，搞清楚這些概念以前，還得先回顧一些基礎的概念。

回到頂部

1 基礎知識回顧

注意：我們下面說的都是Linux環境下，跟Windows不同哈~~~

1.1 用戶空間和內核空間

　　如今操做系統都採用虛擬尋址，處理器先產生一個虛擬地址，經過地址翻譯成物理地址（內存的地址），再經過總線的傳遞，最後處理器拿到某個物理地址返回的字節。

　　對32位操做系統而言，它的尋址空間（虛擬存儲空間）爲4G（2的32次方）。操做系統的核心是內核，獨立於普通的應用程序，能夠訪問受保護的內存空間，也有訪問底層硬件設備的全部權限。爲了保證用戶進程不能直接操做內核（kernel），保證內核的安全，操心繫統將虛擬空間劃分爲兩部分，一部分爲內核空間，一部分爲用戶空間。針對linux操做系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱爲內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱爲用戶空間。

補充：地址空間就是一個非負整數地址的有序集合。如{0,1,2...}。

1.2 進程上下文切換（進程切換）

　　爲了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，並恢復之前掛起的某個進程的執行。這種行爲被稱爲進程切換（也叫調度）。所以能夠說，任何進程都是在操做系統內核的支持下運行的，是與內核緊密相關的。

　　從一個進程的運行轉到另外一個進程上運行，這個過程當中通過下面這些變化：
　　1. 保存當前進程A的上下文。

　　上下文就是內核再次喚醒當前進程時所須要的狀態，由一些對象（程序計數器、狀態寄存器、用戶棧等各類內核數據結構）的值組成。

　　這些值包括描繪地址空間的頁表、包含進程相關信息的進程表、文件表等。
　　2. 切換頁全局目錄以安裝一個新的地址空間。

　　　　...
　　3. 恢復進程B的上下文。

　　能夠理解成一個比較耗資源的過程。

1.3 進程的阻塞

　　正在執行的進程，因爲期待的某些事件未發生，如請求系統資源失敗、等待某種操做的完成、新數據還沒有到達或無新工做作等，則由系統自動執行阻塞原語(Block)，使本身由運行狀態變爲阻塞狀態。可見，進程的阻塞是進程自身的一種主動行爲，也所以只有處於運行態的進程（得到CPU），纔可能將其轉爲阻塞狀態。當進程進入阻塞狀態，是不佔用CPU資源的。

1.4 文件描述符

　　文件描述符（File descriptor）是計算機科學中的一個術語，是一個用於表述指向文件的引用的抽象化概念。

　　文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核爲每個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者建立一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫每每會圍繞着文件描述符展開。可是文件描述符這一律念每每只適用於UNIX、Linux這樣的操做系統。

1.5 直接I/O和緩存I/O

　　緩存 I/O 又被稱做標準 I/O，大多數文件系統的默認 I/O 操做都是緩存 I/O。在 Linux 的緩存 I/O 機制中，以write爲例，數據會先被拷貝進程緩衝區，在拷貝到操做系統內核的緩衝區中，而後纔會寫到存儲設備中。

緩存I/O的write：

直接I/O的write：（少了拷貝到進程緩衝區這一步）

 

write過程當中會有不少次拷貝，知道數據所有寫到磁盤。好了，準備知識概略複習了一下，開始探討IO模式。

 

回到頂部

2 I/O模式

　　對於一次IO訪問（這回以read舉例），數據會先被拷貝到操做系統內核的緩衝區中，而後纔會從操做系統內核的緩衝區拷貝到應用程序的緩衝區，最後交給進程。因此說，當一個read操做發生時，它會經歷兩個階段：
　　1. 等待數據準備 (Waiting for the data to be ready)
　　2. 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)

正式由於這兩個階段，linux系統產生了下面五種網絡模式的方案：
　　-- 阻塞 I/O（blocking IO）
　　-- 非阻塞 I/O（nonblocking IO）
　　-- I/O 多路複用（ IO multiplexing）
　　-- 信號驅動 I/O（ signal driven IO）
　　-- 異步 I/O（asynchronous IO）

　　注：因爲signal driven IO在實際中並不經常使用，因此我這隻說起剩下的四種IO 模型。

2.1 block I/O模型（阻塞I/O）

阻塞I/O模型示意圖：

read爲例：

（1）進程發起read，進行recvfrom系統調用；

（2）內核開始第一階段，準備數據（從磁盤拷貝到緩衝區），進程請求的數據並非一下就能準備好；準備數據是要消耗時間的；

（3）與此同時，進程阻塞（進程是本身選擇阻塞與否），等待數據ing；

（4）直到數據從內核拷貝到了用戶空間，內核返回結果，進程解除阻塞。

也就是說，內核準備數據和數據從內核拷貝到進程內存地址這兩個過程都是阻塞的。

 

2.2 non-block（非阻塞I/O模型）

能夠經過設置socket使其變爲non-blocking。當對一個non-blocking socket執行讀操做時，流程是這個樣子：

 

　　（1）當用戶進程發出read操做時，若是kernel中的數據尚未準備好；

　　（2）那麼它並不會block用戶進程，而是馬上返回一個error，從用戶進程角度講 ，它發起一個read操做後，並不須要等待，而是立刻就獲得了一個結果；

　　（3）用戶進程判斷結果是一個error時，它就知道數據尚未準備好，因而它能夠再次發送read操做。一旦kernel中的數據準備好了，而且又再次收到了用戶進程的system call；

　　（4）那麼它立刻就將數據拷貝到了用戶內存，而後返回。

　　因此，nonblocking IO的特色是用戶進程在內核準備數據的階段須要不斷的主動詢問數據好了沒有。

 

2.3 I/O多路複用（JAVA NIO就是採用此模式）

　　　　I/O多路複用實際上就是用select, poll, epoll監聽多個io對象，當io對象有變化（有數據）的時候就通知用戶進程。好處就是單個進程能夠處理多個socket。固然具體區別咱們後面再討論，如今先來看下I/O多路複用的流程：

　　（1）當用戶進程調用了select，那麼整個進程會被block；

      （2）而同時，kernel會「監視」全部select負責的socket；

　　（3）當任何一個socket中的數據準備好了，select就會返回；

　　（4）這個時候用戶進程再調用read操做，將數據從kernel拷貝到用戶進程。

　　因此，I/O 多路複用的特色是經過一種機制一個進程能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函數就能夠返回。

　　這個圖和blocking IO的圖其實並無太大的不一樣，事實上，還更差一些。由於這裏須要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。可是，用select的優點在於它能夠同時處理多個connection。

　　因此，若是處理的鏈接數不是很高的話，使用select/epoll的web server不必定比使用多線程 + 阻塞 IO的web server性能更好，可能延遲還更大。

　　select/epoll的優點並非對於單個鏈接能處理得更快，而是在於能處理更多的鏈接。）

　　在IO multiplexing Model中，實際中，對於每個socket，通常都設置成爲non-blocking，可是，如上圖所示，整個用戶的process實際上是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。

 

 2.4 asynchronous I/O（異步 I/O）

　　真正的異步I/O很牛逼，流程大概以下：

（1）用戶進程發起read操做以後，馬上就能夠開始去作其它的事。

（2）而另外一方面，從kernel的角度，當它受到一個asynchronous read以後，首先它會馬上返回，因此不會對用戶進程產生任何block。

（3）而後，kernel會等待數據準備完成，而後將數據拷貝到用戶內存，當這一切都完成以後，kernel會給用戶進程發送一個signal，告訴它read操做完成了。

 

2.5 小結

（1）blocking和non-blocking的區別

　　調用blocking IO會一直block住對應的進程直到操做完成，而non-blocking IO在kernel還準備數據的狀況下會馬上返回。

（2）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。

（3）non-blocking IO和asynchronous IO的區別

　　能夠發現non-blocking IO和asynchronous IO的區別仍是很明顯的。

　　--在non-blocking IO中，雖然進程大部分時間都不會被block，可是它仍然要求進程去主動的check，而且當數據準備完成之後，也須要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。

　　--而asynchronous IO則徹底不一樣。它就像是用戶進程將整個IO操做交給了他人（kernel）完成，而後他人作完後發信號通知。在此期間，用戶進程不須要去檢查IO操做的狀態，也不須要主動的去拷貝數據。

sellect、poll、epoll三者的區別  

select 
select最先於1983年出如今4.2BSD中，它經過一個select()系統調用來監視多個文件描述符的數組，當select()返回後，該數組中就緒的文件描述符便會被內核修改標誌位，使得進程能夠得到這些文件描述符從而進行後續的讀寫操做。

select目前幾乎在全部的平臺上支持，其良好跨平臺支持也是它的一個優勢，事實上從如今看來，這也是它所剩很少的優勢之一。

select的一個缺點在於單個進程可以監視的文件描述符的數量存在最大限制，在Linux上通常爲1024，不過能夠經過修改宏定義甚至從新編譯內核的方式提高這一限制。

另外，select()所維護的存儲大量文件描述符的數據結構，隨着文件描述符數量的增大，其複製的開銷也線性增加。同時，因爲網絡響應時間的延遲使得大量TCP鏈接處於非活躍狀態，但調用select()會對全部socket進行一次線性掃描，因此這也浪費了必定的開銷。

poll 
poll在1986年誕生於System V Release 3，它和select在本質上沒有多大差異，可是poll沒有最大文件描述符數量的限制。

poll和select一樣存在一個缺點就是，包含大量文件描述符的數組被總體複製於用戶態和內核的地址空間之間，而不論這些文件描述符是否就緒，它的開銷隨着文件描述符數量的增長而線性增大。另外，select()和poll()將就緒的文件描述符告訴進程後，若是進程沒有對其進行IO操做，那麼下次調用select()和poll()的時候將再次報告這些文件描述符，因此它們通常不會丟失就緒的消息，這種方式稱爲水平觸發（Level Triggered）。

epoll 
直到Linux2.6纔出現了由內核直接支持的實現方法，那就是epoll，它幾乎具有了以前所說的一切優勢，被公認爲Linux2.6下性能最好的多路I/O就緒通知方法。

epoll能夠同時支持水平觸發和邊緣觸發（Edge Triggered，只告訴進程哪些文件描述符剛剛變爲就緒狀態，它只說一遍，若是咱們沒有采起行動，那麼它將不會再次告知，這種方式稱爲邊緣觸發），理論上邊緣觸發的性能要更高一些，可是代碼實現至關複雜。

epoll一樣只告知那些就緒的文件描述符，並且當咱們調用epoll_wait()得到就緒文件描述符時，返回的不是實際的描述符，而是一個表明就緒描述符數量的值，你只須要去epoll指定的一個數組中依次取得相應數量的文件描述符便可，這裏也使用了內存映射（mmap）技術，這樣便完全省掉了這些文件描述符在系統調用時複製的開銷。

另外一個本質的改進在於epoll採用基於事件的就緒通知方式。在select/poll中，進程只有在調用必定的方法後，內核纔對全部監視的文件描述符進行掃描，而epoll事先經過epoll_ctl()來註冊一個文件描述符，一旦基於某個文件描述符就緒時，內核會採用相似callback的回調機制，迅速激活這個文件描述符，當進程調用epoll_wait()時便獲得通知。

epoll是Linux內核爲處理大批量文件描述符而做了改進的poll，是Linux下多路複用IO接口select/poll的加強版本，它能顯著提升程序在大量併發鏈接中只有少許活躍的狀況下的系統CPU利用率。緣由就是獲取事件的時候，它無須遍歷整個被偵聽的描述符集，只要遍歷那些被內核IO事件異步喚醒而加入Ready隊列的描述符集合就好了。