window 下的套接字以來兩種方式執行i/o操作，阻塞io 非阻塞io，一般預設使用的是阻塞io 即執行緒會等待不會把控制權利立刻返回給程式，這就意為乙個執行緒在某乙個時候只能夠去執行乙個io操作。
如果服務端想和多個客戶端同時進行通訊的話就要使用多執行緒程式設計，但是會增加開銷，如果採用非阻塞io程式不會等待，會立刻返回結果但是在大部分情況下返回的結果是錯誤的，並返回乙個wsaewouldblock的錯誤，所以程式設計師要不斷的檢測函式返回的**以判斷乙個套接字何時可供讀寫。
windows作業系統提供了選擇模型、非同步選擇模型、事件選擇模型、重疊i/o模型和完成埠共五種i/o模型。每一種模型均適用於一種特定的應用場景。程式設計人員應綜合考慮到程式的擴充套件性和可移植性等因素，做出自己的選擇。
選擇模型是winsock中最常見的i/o模型。之所以稱其為「select模型」，是由於它的「中心思想」便是利用select函式，實現對i/o的管理！最初設計該模型時，主要面向的是某些使用unix作業系統的計算機，它們採用的是 berkeley套接字方案。select模型已整合到winsock 1.1中，它使那些想避免在套接字呼叫過程中被無辜「鎖定」的應用程式，採取一種有序的方式，同時進行對多個套接字的管理。
使用非同步選擇模型，應用程式可在乙個套接字上，接收以windows訊息為基礎的網路事件通知。具體的做法是在建好乙個套接字後，呼叫wsaasyncselect函式。
wsaeventselect和wsaasyncselect模型類似，它也允許應用程式在乙個或多個套接字上，接收以事件為基礎的網路事件通知。對於wsaasyncselect模型採用的網路事件來說，它們均可原封不動地移植到事件選擇模型上。在用事件選擇模型開發的應用程式中，也能接收和處理所有那些事件。該模型最主要的差別在於網路事件會投遞至乙個事件物件控制代碼，而非投遞至乙個視窗例程。
「完成埠」模型是迄今為止最為複雜的一種i/o模型。然而，假若乙個應用程式同時需要管理為數眾多的套接字，那麼採用這種模型，往往可以達到最佳的系統效能！但不幸的是，該模型只適用於windows nt和windows 2000作業系統。
因其設計的複雜性，只有在你的應用程式需要同時管理數百乃至上千個套接字的時候，而且希望隨著系統內安裝的cpu數量的增多，應用程式的效能也可以線性提公升，才應考慮採用「完成埠」模型。要記住的乙個基本準則是，假如要為windows nt或windows 2000開發高效能的伺服器應用，同時希望為大量套接字i/o請求提供服務（web伺服器便是這方面的典型例子），那麼i/o完成埠模型便是最佳選擇！
網路IO模型
為了更好地了解io模型，我們需要事先回顧下 同步 非同步 阻塞 非阻塞 1.網路傳輸中的兩個階段 分別是 waitdata 和 copydata send copydata recv waitdata copydata 記住這兩點很重要，因為這些io模型的區別就是在兩個階段上各有不同的情況。2.阻塞...
網路IO模型
io有兩種操作，同步io和非同步io。同步io指的是，必須等待io操作完成後，控制權才返回給使用者程序。非同步io指的是，無須等待io操作完成，就將控制權返回給使用者程序。網路中的io，由於不同的io裝置有著不同的特點，網路通訊中往往需要等待。常見的有以下4種情況。1 輸入操作 等待資料到達套接字接...
網路IO模型
一 阻塞io模型 阻塞io基於socket程式 原理 recv接收資料時，不是直接接收資料，而是程式將系統呼叫的命令傳送到作業系統 當作業系統收到接收資料的請求，若此時無資料，作業系統會繼續等待，處於等待資料階段 wait for data階段 這個階段相對漫長 當資料來了，作業系統會拷貝資料 co...