參考：點擊打開鏈接
對於一個network IO (這裏我們以read舉例)，它會涉及到兩個系統對象，一個是調用這個IO的process (or thread)，另一個就是系統內核(kernel)。當一個read操作發生時，該操作會經歷兩個階段：
1）等待數據準備 (Waiting for the data to be ready)
2）將數據從內核拷貝到進程中(Copying the data from the kernel to the process)記住這兩點很重要，因爲這些IO模型的區別就是在兩個階段上各有不同的情況。
阻塞IO(blocking IO)
當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。
而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。
所以，blocking IO的特點就是在IO執行的兩個階段（等待數據和拷貝數據兩個階段）都被block了。
例子，通常的默認情況下所有的socket都是blocking
import socket
sk=socket.socket()
sk.bind(('10.11.185.130',8080))
sk.listen(5)
while True:
print('begin to connect...')
conn,addr=sk.accept()#沒有連接時發生阻塞
print('connect successfully...')
data=conn.recv(1024)# 沒有data時發生阻塞
print(data)
#######################################客戶端
import socket
sk=socket.socket()
sk.connect(('10.11.185.130',8080))
while True:
sk.send(b'hello')非阻塞IO(non-blocking IO)
從圖中可以看出，當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那麼它並不會block用戶進程，而是立刻返回一個error。從用戶進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，於是用戶就可以在本次到下次再發起read詢問的時間間隔內做其他事情，或者直接再次發送read操作。一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麼它馬上就將數據拷貝到了用戶內存（這一階段仍然是阻塞的），然後返回。
也就是說非阻塞的recvform系統調用調用之後，進程並沒有被阻塞，內核馬上返回給進程，如果數據還沒準備好，此時會返回一個error。進程在返回之後，可以乾點別的事情，然後再發起recvform系統調用。重複上面的過程，循環往復的進行recvform系統調用。這個過程通常被稱之爲輪詢。輪詢檢查內核數據，直到數據準備好，再拷貝數據到進程，進行數據處理。需要注意，拷貝數據整個過程，進程仍然是屬於阻塞的狀態。
所以，在非阻塞式IO中，用戶進程其實是需要不斷的主動詢問kernel數據準備好了沒有。
例子：
########################################服務端
import socket,time
sk=socket.socket()
sk.bind(('10.11.185.130',8080))
sk.listen(5)
sk.setblocking(False)#設置爲非阻塞
l=[]
while True:
try:
print('begin to connect...')
conn,addr=sk.accept()#沒有連接時不會發生阻塞
print('connect successfully...')
l.append(conn)
except Exception as e:
print(e)
time.sleep(5)
try:
for conn in l:
data=conn.recv(1024)# 沒有data時不會發生阻塞
print(data)
conn.send(data.upper())
except Exception as e:
print(e)
time.sleep(5)
########################################客戶端
from socket import *
client=socket(AF_INET,SOCK_STREAM)
client.connect(('10.11.185.130',8080))
while True:
msg=input('>>: ').strip()
if not msg:continue
client.send(msg.encode('utf-8'))
data=client.recv(1024)
print(data.decode('utf-8'))
client.close()多路複用IO(IO multiplexing)![]()
這個圖和blocking IO的圖其實並沒有太大的不同，事實上還更差一些。因爲這裏需要使用兩個系統調用(select和recvfrom)，而blocking IO只調用了一個系統調用(recvfrom)。但是，用select的優勢在於它可以同時處理多個connection。
強調：
1. 如果處理的連接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連接能處理得更快，而是在於能處理更多的連接。
2. 在多路複用模型中，對於每一個socket，一般都設置成爲non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。
結論: select的優勢在於可以處理多個連接，不適用於單個連接
異步IO(Asynchronous I/O)
用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。
IO模型比較分析
先回答最簡單的這個：blocking vs non-blocking。前面的介紹中其實已經很明確的說明了這兩者的區別。調用blocking IO會一直block住對應的進程直到操作完成，而non-blocking IO在kernel還準備數據的情況下會立刻返回。
再說明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。Stevens給出的定義（其實是POSIX的定義）是這樣子的：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operationcompletes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
兩者的區別就在於synchronous IO做”IO operation”的時候會將process阻塞。按照這個定義，四個IO模型可以分爲兩大類，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO這一類，而 asynchronous I/O後一類 。
有人可能會說，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。
