Linux 的 Socket IO 模型

時間 2019-11-30

標籤 linux socket 模型欄目 Linux 简体版

原文原文鏈接

前言

以前有看到用很幽默的方式講解Windows的socket IO模型，借用這個故事，講解下linux的socket IO模型；html

老陳有一個在外地工做的女兒，不能常常回來，老陳和她經過信件聯繫。linux

他們的信會被郵遞員投遞到他們小區門口的收發室裏。這和Socket模型很是相似。安全

下面就以老陳接收信件爲例講解linux的 Socket I/O模型。服務器

1、同步阻塞模型

老陳的女兒第一次去外地工做，送走她以後，老陳很是的掛心她安全到達沒有；因而老陳什麼也不幹，一直在小區門口收發室裏等着她女兒的報平安的信到；這就是linux的同步阻塞模式；微信

在這個模式中，用戶空間的應用程序執行一個系統調用，並阻塞，直到系統調用完成爲止(數據傳輸完成或發生錯誤)。網絡

Socket設置爲阻塞模式，當socket不能當即完成I/O操做時，進程或線程進入等待狀態，直到操做完成。app

如圖1所示：異步

顯然，代碼中的connect, send, recv都是同步阻塞工做模式，在結果沒有返回時，程序什麼也不作。socket

這種模型很是經典，也被普遍使用。async

優點在於很是簡單，等待的過程當中佔用的系統資源微乎其微，程序調用返回時，一定能夠拿到數據；但簡單也帶來一些缺點，程序在數據到來並準備好之前，不能進行其餘操做，須要有一個線程專門用於等待，這種代價對於須要處理大量鏈接的服務器而言，是很難接受的。

2、同步非阻塞模型

收到平安信後，老陳稍稍放心了，就再也不一直在收發室前等信；而是每隔一段時間就去收發室檢查信箱；這樣，老陳也能在間隔時間內休息一會，或喝杯荼，看會電視，作點別的事情；

這就是同步非阻塞模型；

同步阻塞 I/O 的一種效率稍低的變種是同步非阻塞 I/O。

在這種模型中，系統調用是以非阻塞的形式打開的。

這意味着 I/O 操做不會當即完成，操做可能會返回一個錯誤代碼，說明這個命令不能當即知足（EAGAIN 或 EWOULDBLOCK），非阻塞的實現是 I/O 命令可能並不會當即知足，須要應用程序調用許屢次來等待操做完成。

這可能效率不高，由於在不少狀況下，當內核執行這個命令時，應用程序必需要進行忙碌等待，直到數據可用爲止，或者試圖執行其餘工做。

由於數據在內核中變爲可用到用戶調用 read 返回數據之間存在必定的間隔，這會致使總體數據吞吐量的下降。

如圖2所示：

這種模式在沒有數據能夠接收時，能夠進行其餘的一些操做，好比有多個socket時，能夠去查看其餘socket有沒有能夠接收的數據；實際應用中，這種I/O模型的直接使用並不常見，由於它須要不停的查詢，而這些查詢大部分會是無必要的調用，白白浪費了系統資源；

非阻塞I/O應該算是一個鋪墊，爲I/O複用和信號驅動奠基了非阻塞使用的基礎。咱們可使用 fcntl(fd, F_SETFL, flag | O_NONBLOCK);

將套接字標誌變成非阻塞，調用recv，若是設備暫時沒有數據可讀就返回-1，同時置errno爲EWOULDBLOCK（或者EAGAIN，這兩個宏定義的值相同），表示原本應該阻塞在這裏（would block，虛擬語氣），事實上並無阻塞而是直接返回錯誤，調用者應該試着再讀一次（again）。

這種行爲方式稱爲輪詢（Poll），調用者只是查詢一下，而不是阻塞在這裏死等，這樣能夠同時監視多個設備：

while(1)
{
非阻塞read(設備1);
if(設備1有數據到達)
處理數據;

非阻塞read(設備2);
if(設備2有數據到達)
處理數據;

…………………………
}

若是read(設備1)是阻塞的，那麼只要設備1沒有數據到達就會一直阻塞在設備1的read調用上，即便設備2有數據到達也不能處理，使用非阻塞I/O就能夠避免設備2得不到及時處理。

非阻塞I/O有一個缺點，若是全部設備都一直沒有數據到達，調用者須要反覆查詢作無用功，若是阻塞在那裏，操做系統能夠調度別的進程執行，就不會作無用功了，在實際應用中非阻塞I/O模型比較少用

3、I/O 複用(異步阻塞)模式

頻繁地去收發室對老陳來講太累了，在間隔的時間內能作的事也不多，並且取到信的效率也很低.因而，老陳向小區物業提了建議；小區物業改進了他們的信箱系統：住戶先向小區物業註冊，以後小區物業會在已註冊的住戶的家中添加一個提醒裝置，每當有註冊住房的新的信件來臨，此裝置會發出「新信件到達」聲，提醒老陳去看是否是本身的信到了。

這就是異步阻塞模型；

在這種模型中，配置的是非阻塞 I/O，而後使用阻塞 select 系統調用來肯定一個 I/O 描述符什麼時候有操做。

使 select 調用很是有趣的是它能夠用來爲多個描述符提供通知，而不只僅爲一個描述符提供通知。

對於每一個提示符來講，咱們能夠請求這個描述符能夠寫數據、有讀數據可用以及是否發生錯誤的通知

I/O複用模型能讓一個或多個socket可讀或可寫準備好時，應用能被通知到；

I/O複用模型早期用select實現，它的工做流程以下圖：

用select來管理多個I/O，當沒有數據時select阻塞，若是在超時時間內數據到來則select返回，再調用recv進行數據的複製，recv返回後處理數據。

下面的C語言實現的例子，它從網絡上接受數據寫入一個文件中:

perl實現:

4、信號驅動 I/O 模型

老陳接收到新的信件後，通常的程序是：打開信封—-掏出信紙 —-閱讀信件—-回覆信件 ……爲了進一步減輕用戶負擔，小區物業又開發了一種新的技術：住戶只要告訴小區物業對信件的操做步驟，小區物業信箱將按照這些步驟去處理信件，再也不須要用戶親自拆信 /閱讀/回覆了！

這就是信號驅動I/O模型

咱們也能夠用信號，讓內核在描述字就緒時發送SIGIO信號通知咱們。

首先開啓套接口的信號驅動 I/O功能，並經過sigaction系統調用安裝一個信號處理函數。

該系統調用將當即返回，咱們的進程繼續工做，也就是說沒被阻塞。

當數據報準備好讀取時，內核就爲該進程產生一個SIGIO信號，咱們隨後既能夠在信號處理函數中調用recvfrom讀取數據報，並通知主循環數據已準備好待處理，也能夠當即通知主循環，讓它讀取數據報。

不管如何處理SIGIO信號，這種模型的優點在於等待數據報到達期間，進程不被阻塞，主循環能夠繼續執行，只要不時地等待來自信號處理函數的通知：既能夠是數據已準備好被處理，也能夠是數據報已準備好被讀取。

5、異步非阻塞模式

linux下的asynchronous IO其實用得不多。

與前面的信號驅動模型的主要區別在於：信號驅動 I/O是由內核通知咱們什麼時候能夠啓動一個 I/O操做，而異步 I/O模型是由內核通知咱們 I/O操做什麼時候完成。

先看一下它的流程：

這就是異步非阻塞模式

以read系統調用爲例

steps：

a. 調用read;
b. read請求會當即返回，說明請求已經成功發起了。
c. 在後臺完成讀操做這段時間內，應用程序能夠執行其餘處理操做。
d. 當 read 的響應到達時，就會產生一個信號或執行一個基於線程的回調函數來完成此次 I/O 處理過程。

server端程序:

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

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

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

6、總結

到目前爲止，已經將四個IO Model都介紹完了。

如今回過頭來回答兩個問題：

blocking和non-blocking的區別在哪?
synchronous IO和asynchronous 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 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 Model的比較如圖所示：

通過上面的介紹，會發現non-blocking IO和asynchronous IO的區別仍是很明顯的:

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

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

最後，再舉幾個不是很恰當的例子來講明這五個IO Model:

有A，B，C，D，E五我的釣魚：