歡迎光臨
每天分享高質量文章

一文讀懂高性能網絡編程中的I/O模型

隨著互聯網的發展,面對海量用戶高併發業務,傳統的阻塞式的服務端架構樣式已經無能為力。為大家提供有用的高性能網絡編程的I/O模型概覽以及網絡服務行程模型的比較,以揭開設計和實現高性能網絡架構的神秘面紗。

互聯網服務端處理網絡請求的原理

首先看看一個典型互聯網服務端處理網絡請求的典型過程。由圖可以看到,主要處理步驟包括:

1)獲取請求資料,客戶端與服務器建立連接發出請求,服務器接受請求(1-3);

2)構建響應,當服務器接收完請求,併在用戶空間處理客戶端的請求,直到構建響應完成(4);

3)傳回資料,服務器將已構建好的響應再通過內核空間的網絡 I/O 發還給客戶端(5-7)。

設計服務端併發模型時,主要有如下兩個關鍵點:

1)服務器如何管理連接,獲取輸入資料;

2)服務器如何處理請求。

以上兩個關鍵點最終都與操作系統的 I/O 模型以及執行緒(行程)模型相關,下麵先詳細介紹這I/O模型。

“I/O 模型”的基本認識

介紹操作系統的 I/O 模型之前,先瞭解一下幾個概念:

1)阻塞呼叫與非阻塞呼叫;

2)阻塞呼叫是指呼叫結果傳回之前,當前執行緒會被掛起,呼叫執行緒只有在得到結果之後才會傳回;

3)非阻塞呼叫指在不能立刻得到結果之前,該呼叫不會阻塞當前執行緒。

兩者的最大區別在於被呼叫方在收到請求到傳回結果之前的這段時間內,呼叫方是否一直在等待。

阻塞是指呼叫方一直在等待而且別的事情什麼都不做;非阻塞是指呼叫方先去忙別的事情。

同步處理與異步處理:同步處理是指被呼叫方得到最終結果之後才傳回給呼叫方;異步處理是指被呼叫方先傳回應答,然後再計算呼叫結果,計算完最終結果後再通知並傳回給呼叫方。

阻塞、非阻塞和同步、異步的區別(阻塞、非阻塞和同步、異步其實針對的物件是不一樣的):

1)阻塞、非阻塞的討論物件是呼叫者;

2)同步、異步的討論物件是被呼叫者。

Recvfrom函式:Recvfrom 函式(經Socket 接收資料),這裡把它視為系統呼叫。一個輸入操作通常包括兩個不同的階段:


1)等待資料準備好;

2)從內核向行程複製資料。

對於一個套接字上的輸入操作,第一步通常涉及等待資料從網絡中到達。當所等待分組到達時,它被覆制到內核中的某個緩衝區。第二步就是把資料從內核緩衝區複製到應用行程緩衝區。

實際應用程式在系統呼叫完成上面的 2 步操作時,呼叫方式的阻塞、非阻塞,操作系統在處理應用程式請求時,處理方式的同步、異步處理的不同,可以分為 5 種 I/O 模型(參考“UNIX網絡編程捲1”)。

I/O模型1:阻塞式 I/O 模型(blocking I/O)

在阻塞式 I/O 模型中,應用程式在從呼叫 recvfrom 開始到它傳回有資料報準備好這段時間是阻塞的,recvfrom 傳回成功後,應用行程開始處理資料報。

比喻:一個人在釣魚,當沒魚上鉤時,就坐在岸邊一直等。

優點:程式簡單,在阻塞等待資料期間行程/執行緒掛起,基本不會占用 CPU 資源。

缺點:每個連接需要獨立的行程/執行緒單獨處理,當併發請求量大時為了維護程式,記憶體、執行緒切換開銷較大,這種模型在實際生產中很少使用。

I/O模型2:非阻塞式 I/O 模型(non-blocking I/O)

在非阻塞式 I/O 模型中,應用程式把一個套接口設置為非阻塞,就是告訴內核,當所請求的 I/O 操作無法完成時,不要將行程睡眠。

而是傳回一個錯誤,應用程式基於 I/O 操作函式將不斷的輪詢資料是否已經準備好,如果沒有準備好,繼續輪詢,直到資料準備好為止。

比喻:邊釣魚邊玩手機,隔會再看看有沒有魚上鉤,有的話就迅速拉桿。

優點:不會阻塞在內核的等待資料過程,每次發起的 I/O 請求可以立即傳回,不用阻塞等待,實時性較好。

缺點:輪詢將會不斷地詢問內核,這將占用大量的 CPU 時間,系統資源利用率較低,所以一般 Web 服務器不使用這種 I/O 模型。

I/O模型3:I/O 復用模型(I/O multiplexing)

在 I/O 復用模型中,會用到 Select 或 Poll 函式或 Epoll 函式(Linux 2.6 以後的內核開始支持),這兩個函式也會使行程阻塞,但是和阻塞 I/O 有所不同。

這兩個函式可以同時阻塞多個 I/O 操作,而且可以同時對多個讀操作,多個寫操作的 I/O 函式進行檢測,直到有資料可讀或可寫時,才真正呼叫 I/O 操作函式。

比喻:放了一堆魚竿,在岸邊一直守著這堆魚竿,沒魚上鉤就玩手機。

優點:可以基於一個阻塞物件,同時在多個描述符上等待就緒,而不是使用多個執行緒(每個檔案描述符一個執行緒),這樣可以大大節省系統資源。

缺點:當連接數較少時效率相比多執行緒+阻塞 I/O 模型效率較低,可能延遲更大,因為單個連接處理需要 2 次系統呼叫,占用時間會有增加。

眾所周之,Nginx這樣的高性能互聯網反向代理服務器大獲成功的關鍵就是得益於Epoll。

I/O模型4:信號驅動式 I/O 模型(signal-driven I/O)

在信號驅動式 I/O 模型中,應用程式使用套接口進行信號驅動 I/O,並安裝一個信號處理函式,行程繼續運行並不阻塞。

當資料準備好時,行程會收到一個 SIGIO 信號,可以在信號處理函式中呼叫 I/O 操作函式處理資料。

比喻:魚竿上系了個鈴鐺,當鈴鐺響,就知道魚上鉤,然後可以專心玩手機。

優點:執行緒並沒有在等待資料時被阻塞,可以提高資源的利用率。

缺點:信號 I/O 在大量 IO 操作時可能會因為信號佇列上限溢位導致沒法通知。

信號驅動 I/O 儘管對於處理 UDP 套接字來說有用,即這種信號通知意味著到達一個資料報,或者傳回一個異步錯誤。

但是,對於 TCP 而言,信號驅動的 I/O 方式近乎無用,因為導致這種通知的條件為數眾多,每一個來進行判別會消耗很大資源,與前幾種方式相比優勢盡失。

I/O模型5:異步 I/O 模型(即AIO,全稱asynchronous I/O)


由 POSIX 規範定義,應用程式告知內核啟動某個操作,並讓內核在整個操作(包括將資料從內核拷貝到應用程式的緩衝區)完成後通知應用程式。

這種模型與信號驅動模型的主要區別在於:信號驅動 I/O 是由內核通知應用程式何時啟動一個 I/O 操作,而異步 I/O 模型是由內核通知應用程式 I/O 操作何時完成。

優點:異步 I/O 能夠充分利用 DMA 特性,讓 I/O 操作與計算重疊。

缺點:要實現真正的異步 I/O,操作系統需要做大量的工作。目前 Windows 下通過 IOCP 實現了真正的異步 I/O。

而在 Linux 系統下,Linux 2.6才引入,目前 AIO 並不完善,因此在 Linux 下實現高併發網絡編程時都是以 IO 復用模型樣式為主。

關於AOI的介紹,請見“Java新一代網絡編程模型AIO原理及Linux系統AIO介紹”。

I/O 模型總結

從上圖中我們可以看出,越往後,阻塞越少,理論上效率也是最優。

這五種 I/O 模型中,前四種屬於同步 I/O,因為其中真正的 I/O 操作(recvfrom)將阻塞行程/執行緒,只有異步 I/O 模型才與 POSIX 定義的異步 I/O 相匹配。

作者:陳彩華(caison),主要從事服務端開發、需求分析、系統設計、優化重構工作,主要開發語言是 Java,現任廣州貝聊服務端研發工程師。


推薦閱讀:

溫馨提示:

請搜索“ICT_Architect”“掃一掃”二維碼關註公眾號,點擊原文鏈接獲取更多電子書詳情

求知若渴, 虛心若愚

赞(0)

分享創造快樂