標題索引
追溯IO原因
網絡數據流
網絡IO模型
IO模型舉例
追溯IO原因
從事項目多年來，有個問題一直困擾着我，但因種種原因一直沒有翻閱資料去釋懷，隨着項目經歷的增加、年齡的增長和責任的使命促使我去詮釋這個困擾我多年的問題，這個問題就是"網絡IO模型"，希望這個問題能夠給知識庫項目的建設添磚加瓦，希望這個問題能夠給後續兄弟們帶來啓發和避免行走不必要的彎路，希望這個問題促進我對“有物爲證”的理解更上一層。
網絡數據流
客戶端發起一個http請求，服務器端處理響應http請求，這一過程在服務器端以網絡IO的角度，經歷了哪些階段，具體可參考下圖：
圖1-1網絡進程IO流程圖
如上圖當服務器接受到一個http請求時，具體操作流程如下：
1.用戶空間進程通過reveform函數接收等待接收數據包，並將接收到的數據包在內核通過四表五鏈檢查網絡狀態，若通過網絡檢查，則提交給用戶空間http進程；
2.http進程解析請求，併發起系統調用read函數，到達內核空間；
3.內核空間執行read函數讀取磁盤內容，並將此內容加載至內存；
4.內核空間提交給用戶空間http進程，告知數據已經read完畢；
5.用戶空間http進程根據請求報文進行構建響應報文；
6.構建完http響應報文後，通知內核空間構建網絡封裝；
7.內核空間再次通過四表五鏈網絡狀態，通過網卡發送構建好的http的響應報文。
此爲服務器構建網絡數據包觸發IO的過程，根據此過程進行分析IO模型，若在高併發的情況下，在哪一步可以實現多IO並存，哪一步可以實現IO的優化。
單純根據流程可得信息如下，
1.單進程接收響應數據報文調用receform函數時，與此同時不執行其他函數調用，此時嚴重影響效率；
2.當內核空間執行read函數後提交給用戶空間進行http封裝，最後調用內核空間進行網絡封裝構建併發送報文；
網絡IO模型
根據上述的流程可以將一次IO邏輯意義上處於兩種形態，在這兩種形態上進行優化IO纔可進行優化整體的性能，此兩種形態在Linux網絡編程中定義如下：
第一種：Waiting for the data to be ready
等待數據準備，邏輯意義上是內核網絡驅動等待接收網絡數據包，即上述案例中第1步，表現在內核形態，同時也是數據流可得信息的第1步，在用戶空間封裝完畢後如何通知內核層再次進行網絡報文的構建，在此狀態下誕生兩種狀態同步(synchronous)和異步(asynchronous)，同步爲進程自已主動等待函數執行成功並返回消息後才能繼續執行其他函數，異步爲函數執行完成後主動通知進程進行執行其他還是，最後進行內核空間對網絡IO進行解封裝。
第二種：Copying the data from the kernel to the process
將數據從內核拷貝到進程中，邏輯意義上是內核空間調用並執行系統調用函數後將執行的結果反饋給用戶空間，讓用戶空間進行構建響應報文，即上述案例中第4步，同時也是數據流可得信息的第2步，用戶空間的進程能否執行其他函數，從而提升整體性能。在此狀態下誕生兩種狀態，阻塞(blocking)和非阻塞(nonblocking)，阻塞狀態爲指IO操作需要徹底完成後才返回到用戶空間，調用結果返回之前，調用者被掛起，即進程調用函數後被掛起，直到函數返回結果後才能執行其他操作，非阻塞狀態指IO操作被調用後立即返回給用戶一個狀態值，無需等到IO操作徹底完成，最終的調用結果返回之前，調用者不會被掛起，即進程在執行函數後，無需等待執行結果，仍可繼續執行其他函數。
因此通過組合形成如下模型：
1、阻塞IO模型
同步阻塞IO模型具體如下圖
圖2-1 阻塞IO模型圖
在同步阻塞IO模型中，
2.非阻塞IO模型
同步阻塞IO模型具體如下圖
圖2-2 非阻塞IO模型圖
3.IO多路複用模型
IO多路複用模型如下圖
圖2-3 IO多路複用模型圖
4.