• IO模型介紹
• 阻塞IO
• 非阻塞
• 多路複用
• 非同步
• IO模型比較分析
• selectors

阻塞IO:之前寫的所有的socket,recv,accput都是

阻塞原理:

其實多數時間多用到了等待資料那裡.

非阻塞IO:當你需要資料時,你給系統要系統知道沒有資料,但他會反饋給你,沒有資料,程式碼繼續向下走

多路複用: 有好幾種機制: select,poll(比select稍微好點,也是輪詢,底層資料做了優化),epoll(最好的在windows上沒有存在於linx上有,不使用輪詢,採用的是回撥函式機制.)

簡單來說:多個conn複用著同一個執行緒操作

是作業系統提供給你的,對於你來說,是一個代理,幫助你監聽所有的通訊物件,是否有資料來到作業系統中,一旦有,就通知你,你再來根據通知來接收相應的資料,而你就不需要,一直迴圈著問每一個物件是否有資訊來,而是阻塞等待,任意一個來,我就就接收.

select監聽資料的過程:

使用者程序建立socket物件，拷貝監聽的fd到核心空間，每一個fd會對應一張系統檔案表，核心空間的fd響應到資料後，就會發送訊號給使用者程序資料已到；
使用者程序再發送系統呼叫，比如（accept）將核心空間的資料copy到使用者空間，同時作為接受資料端核心空間的資料清除，這樣重新監聽時fd再有新的資料又可以響應到了（
傳送端因為基於TCP協議所以需要收到應答後才會清除）。

優點:

相比其他模型，使用select() 的事件驅動模型只用單執行緒（程序）執行，佔用資源少，不消耗太多 CPU，同時能夠為多客戶端提供服務。

如果試圖建立一個簡單的事件驅動的伺服器程式，這個模型有一定的參考價值

缺點:

首先select()介面並不是實現“事件驅動”的最好選擇。因為當需要探測的控制代碼值較大時，select()介面本身需要消耗大量時間去輪詢各個控制代碼。
#很多作業系統提供了更為高效的介面，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。
#如果需要實現更高效的伺服器程式，類似epoll這樣的介面更被推薦。遺憾的是不同的作業系統特供的epoll介面有很大差異，
 

#所以使用類似於epoll的介面實現具有較好跨平臺能力的伺服器會比較困難。
#其次，該模型將事件探測和事件響應夾雜在一起，一旦事件響應的執行體龐大，則對整個模型是災難性的原理圖:

非同步IO:(最好的機制)