本文簡單介紹了當前Windows支持的各種Socket I/O模型，如果你發現其中存在什麼錯誤請務必賜教。
一：select模型
二：WSAAsyncSelect模型
三：WSAEventSelect模型
四：Overlapped I/O 事件通知模型
五：Overlapped I/O 完成例程模型
六：IOCP模型
老陳有一個在外地工作的女兒，不能經常回來，老陳和她通過信件聯繫。他們的信會被郵遞員投遞到他們的信箱裏。
這和Socket模型非常類似。下面我就以老陳接收信件爲例講解Socket I/O模型~~~
一：select模型
老陳非常想看到女兒的信。以至於他每隔10分鐘就下樓檢查信箱，看是否有女兒的信~~~~~
在這種情況下，"下樓檢查信箱"然後回到樓上耽誤了老陳太多的時間，以至於老陳無法做其他工作。
select模型和老陳的這種情況非常相似：周而復始地去檢查......如果有數據......接收/發送.......
使用線程來select應該是通用的做法：
二：WSAAsyncSelect模型
後來，老陳使用了微軟公司的新式信箱。這種信箱非常先進，一旦信箱裏有新的信件，蓋茨就會給老陳打電話：喂，大爺，你有新的信件了！從此，老陳再也不必頻繁上下樓檢查信箱了，牙也不疼了，你瞅準了，藍天......不是，微軟~~~~~~~~
微軟提供的WSAAsyncSelect模型就是這個意思。
WSAAsyncSelect模型是Windows下最簡單易用的一種Socket I/O模型。使用這種模型時，Windows會把網絡事件以消息的形勢通知應用程序。
首先定義一個消息標示常量：
const WM_SOCKET = WM_USER + 55;
再在主Form的private域添加一個處理此消息的函數聲明：
private
procedure WMSocket(var Msg: TMessage); message WM_SOCKET;
然後就可以使用WSAAsyncSelect了：
三：WSAEventSelect模型
後來，微軟的信箱非常暢銷，購買微軟信箱的人以百萬計數......以至於蓋茨每天24小時給客戶打電話，累得腰痠背痛，喝蟻力神都不好使~~~~~~
微軟改進了他們的信箱：在客戶的家中添加一個附加裝置，這個裝置會監視客戶的信箱，每當新的信件來臨，此裝置會發出"新信件到達"聲，提醒老陳去收信。蓋茨終於可以睡覺了。
四：Overlapped I/O 事件通知模型
後 來，微軟通過調查發現，老陳不喜歡上下樓收發信件，因爲上下樓其實很浪費時間。於是微軟再次改進他們的信箱。新式的信箱採用了更爲先進的技術，只要用戶告 訴微軟自己的家在幾樓幾號，新式信箱會把信件直接傳送到用戶的家中，然後告訴用戶，你的信件已經放到你的家中了！老陳很高興，因爲他不必再親自收發信件 了！
Overlapped I/O 事件通知模型和WSAEventSelect模型在實現上非常相似，主要區別在"Overlapped"，Overlapped模型是讓應用程序使用重疊 數據結構(WSAOVERLAPPED)，一次投遞一個或多個Winsock I/O請求。這些提交的請求完成後，應用程序會收到通知。什麼意思呢？就是說，如果你想從socket上接收數據，只需要告訴系統，由系統爲你接收數據， 而你需要做的只是爲系統提供一個緩衝區~~~~~
Listen線程和WSAEventSelect模型一模一樣，Recv/Send線程則完全不同：
五：Overlapped I/O 完成例程模型
老陳接收到新的信件後，一般的程序是：打開信封----掏出信紙----閱讀信件----回覆信件......爲了進一步減輕用戶負擔，微軟又開發了一種 新的技術：用戶只要告訴微軟對信件的操作步驟，微軟信箱將按照這些步驟去處理信件，不再需要用戶親自拆信/閱讀/回覆了！老陳終於過上了小資生活！
Overlapped I/O 完成例程要求用戶提供一個回調函數，發生新的網絡事件的時候系統將執行這個函數：
procedure WorkerRoutine( const dwError, cbTransferred : DWORD; const
lpOverlapped : LPWSAOVERLAPPED; const dwFlags : DWORD ); stdcall;
然後告訴系統用WorkerRoutine函數處理接收到的數據：
WSARecv( m_socket, @FBuf, 1, dwTemp, dwFlag, @m_overlap, WorkerRoutine );
然後......沒有什麼然後了，系統什麼都給你做了！微軟真實體貼！
六：IOCP模型
微軟信箱似乎很完美，老陳也很滿意。但是在一些大公司情況卻完全不同！這些大公司有數以萬計的信箱，每秒鐘都有數以百計的信件需要處理，以至於微軟信箱經常因超負荷運轉而崩潰！需要重新啓動！微軟不得不使出殺手鐗......
微軟給每個大公司派了一名名叫"Completion Port"的超級機器人，讓這個機器人去處理那些信件！
"Windows NT小組注意到這些應用程序的性能沒有預料的那麼高。特別的，處理很多同時的客戶請求意味着很多線程併發地運行在系統中。因爲所有這些線程都是可運行的 [沒有被掛起和等待發生什麼事]，Microsoft意識到NT內核花費了太多的時間來轉換運行線程的上下文[Context]，線程就沒有得到很多 CPU時間來做它們的工作。大家可能也都感覺到並行模型的瓶頸在於它爲每一個客戶請求都創建了一個新線程。創建線程比起創建進程開銷要小，但也遠不是沒有 開銷的。我們不妨設想一下：如果事先開好N個線程，讓它們在那hold[堵塞]，然後可以將所有用戶的請求都投遞到一個消息隊列中去。然後那N個線程逐一 從消息隊列中去取出消息並加以處理。就可以避免針對每一個用戶請求都開線程。不僅減少了線程的資源，也提高了線程的利用率。理論上很不錯，你想我等泛泛之 輩都能想出來的問題，Microsoft又怎會沒有考慮到呢?"-----摘自nonocast的《理解I/O Completion Port》