window 下的套接字以來兩種方式執行I/O操作，阻塞IO 非阻塞IO，一般預設使用的是阻塞IO 即執行緒會等待不會把控制權利立刻返回給程式，這就意為一個執行緒在某一個時候只能夠去執行一個IO操作。

如果服務端想和多個客戶端同時進行通訊的話就要使用多執行緒程式設計，但是會增加開銷，如果採用非阻塞IO程式不會等待，會立刻返回結果但是在大部分情況下返回的結果是錯誤的，並返回一個WSAEWOULDBLOCK的錯誤，所以程式設計師要不斷的檢測函式返回的程式碼以判斷一個套接字何時可供讀寫。

為了避免麻煩 winsock 提供了不同的套接字模型對IO進行管理 select （），WSAAsyncSelect（），WSAEventSelect（），Overlapped（）。

Windows作業系統提供了選擇模型、非同步選擇模型、事件選擇模型、重疊I/O模型和完成埠共五種I/O模型。每一種模型均適用於一種特定的應用場景。程式設計人員應綜合考慮到程式的擴充套件性和可移植性等因素，做出自己的選擇。

（1）選擇模式（Select）

選擇模型是Winsock中最常見的I/O模型。之所以稱其為“select模型”，是由於它的“中心思想”便是利用select函式，實現對I/O的管理！最初設計該模型時，主要面向的是某些使用Unix作業系統的計算機，它們採用的是 Berkeley套接字方案。select模型已整合到Winsock 1.1中，它使那些想避免在套接字呼叫過程中被無辜“鎖定”的應用程式，採取一種有序的方式，同時進行對多個套接字的管理。

（2 ） 非同步選擇模式（WSAAsyncSelect）

使用非同步選擇模型，應用程式可在一個套接字上，接收以Windows訊息為基礎的網路事件通知。具體的做法是在建好一個套接字後，呼叫WSAAsyncSelect函式。

（3 ）事件選擇模式（WSAEventSelect）

WSAEventSelect和WSAAsyncSelect模型類似，它也允許應用程式在一個或多個套接字上，接收以事件為基礎的網路事件通知。對於WSAAsyncSelect模型採用的網路事件來說，它們均可原封不動地移植到事件選擇模型上。在用事件選擇模型開發的應用程式中，也能接收和處理所有那些事件。該模型最主要的差別在於網路事件會投遞至一個事件物件控制代碼，而非投遞至一個視窗例程。

（4 ） 重疊I/O模式（Overlapped I/O）

在Winsock中，相比我們迄今為止解釋過的其他所有I/O模型，重疊I/O模型使應用程式能達到更佳的系統性能。重疊模型的基本設計原理便是讓應用程式使用一個重疊的資料結構，一次投遞一個或多個Winsock I/O請求。針對那些提交的請求，在它們完成之後，應用程式可為它們提供服務。該模型適用於除Windows CE之外的各種Windows平臺。模型的總體設計以Win32重疊I/O機制為基礎。那個機制可通過ReadFile和WriteFile兩個函式，針對裝置執行I/O操作。

（5 ） 完成埠模式（Completion Port)

“完成埠”模型是迄今為止最為複雜的一種I/O模型。然而，假若一個應用程式同時需要管理為數眾多的套接字，那麼採用這種模型，往往可以達到最佳的系統性能！但不幸的是，該模型只適用於Windows NT和Windows 2000作業系統。

因其設計的複雜性，只有在你的應用程式需要同時管理數百乃至上千個套接字的時候，而且希望隨著系統內安裝的CPU數量的增多，應用程式的效能也可以線性提升，才應考慮採用“完成埠”模型。要記住的一個基本準則是，假如要為Windows NT或Windows 2000開發高效能的伺服器應用，同時希望為大量套接字I/O請求提供服務（Web伺服器便是這方面的典型例子），那麼I/O完成埠模型便是最佳選擇！