首先得弄清楚同步、異步、阻塞、非阻塞的概念。
同步和異步是針對通訊的工作模式，阻塞和非阻塞是指socket的I/O操作。
實際上對于socket，只存在阻塞和非阻塞，同步與異步是在程序?qū)崿F(xiàn)上有所不同。
以阻塞的方式執(zhí)行recv函數(shù)，在沒有收到數(shù)據(jù)前，此函數(shù)是不會返回的，所以這很容易執(zhí)行函數(shù)的線程處于等待I/O上的數(shù)據(jù)狀態(tài)，然后被掛起。非阻塞就不一樣，執(zhí)行recv時候不管有沒有數(shù)據(jù)都立即返回，有數(shù)據(jù)時返回數(shù)據(jù)，沒數(shù)據(jù)時返回錯誤。非阻塞可以帶來程序的高效，也帶來了寫程序中必須注意的地方，非阻塞情況下，發(fā)送與接收數(shù)據(jù)時候，要用戶自己管理自己的緩沖區(qū)，并且要記錄發(fā)送與接受的位置，因為很可能發(fā)送與接受數(shù)據(jù)的任務(wù)不能一次完成，需要多次調(diào)用send和recv才可以完成。
本來同步異步是用來表示通訊模式的，通信的同步，主要是指客戶端在發(fā)送請求后，必須得在服務(wù)端有回應(yīng)后才發(fā)送下一個請求。所以這個時候的所有請求將會在服務(wù)端得到同步。通信的異步，指客戶端在發(fā)送請求后，不必等待服務(wù)端的回應(yīng)就可以發(fā)送下一個請求，這樣對于所有的請求動作來說將會在服務(wù)端得到異步，這條請求的鏈路就象是一個請求隊列，所有的動作在這里不會得到同步的。但是個人感覺，在說到socket的同步異步時候，同步跟阻塞概念差不多，都是有了結(jié)果才返回，異步則是告訴系統(tǒng)我要recv數(shù)據(jù)，然后馬上返回，等待數(shù)據(jù)來了后，系統(tǒng)跟程序說數(shù)據(jù)到了，然后程序再recv數(shù)據(jù)。引用在網(wǎng)上看到的比較好的描述“阻塞 block 是指，你撥通某人的電話，但是此人不在，于是你拿著電話等他回來，其間不能再用電話。同步大概和阻塞差不多。非阻塞 nonblock 是指，你撥通某人的電話，但是此人不在，于是你掛斷電話，待會兒再打。至于到時候他回來沒有，只有打了電話才知道。即所謂的“輪詢 / poll”。異步是指，你撥通某人的電話，但是此人不在，于是你叫接電話的人告訴那人(leave a message)，回來后給你打電話（call back）。”

顯然，異步要高效一些。在Winsock中實現(xiàn)異步的方法有很多，Winsock工作模型有下面六種
    一：select模型
    二：WSAAsyncSelect模型
    三：WSAEventSelect模型
    四：Overlapped I/O 事件通知模型
    五：Overlapped I/O 完成例程模型
    六：IOCP模型
從一到六越來越高級，越來越高效，實現(xiàn)越來越復(fù)雜。曾在網(wǎng)上看到一些比喻用來很好的說明這些模型，在這里引用一下。

    老陳有一個在外地工作的女兒，不能經(jīng)常回來，老陳和她通過信件聯(lián)系。他們的信會被郵遞員投遞到他們的信箱里。
一：select模型

老陳非常想看到女兒的信。以至于他每隔10分鐘就下樓檢查信箱，看是否有女兒的信~~~~~
在這種情況下，“下樓檢查信箱”然后回到樓上耽誤了老陳太多的時間，以至于老陳無法做其他工作。

二：WSAAsyncSelect模型

后來，老陳使用了微軟公司的新式信箱。這種信箱非常先進，一旦信箱里有新的信件，蓋茨就會給老陳打電話：喂，大爺，你有新的信件了！從此，老陳再也不必頻繁上下樓檢查信箱了，牙也不疼了，你瞅準了，藍天......不是，微軟~~~~~~~~

三：WSAEventSelect模型

后來，微軟的信箱非常暢銷，購買微軟信箱的人以百萬計數(shù)......以至于蓋茨每天24小時給客戶打電話，累得腰酸背痛，喝蟻力神都不好使~~~~~~
微軟改進了他們的信箱：在客戶的家中添加一個附加裝置，這個裝置會監(jiān)視客戶的信箱，每當新的信件來臨，此裝置會發(fā)出“新信件到達”聲，提醒老陳去收信。蓋茨終于可以睡覺了。

四：Overlapped I/O 事件通知模型

后來，微軟通過調(diào)查發(fā)現(xiàn)，老陳不喜歡上下樓收發(fā)信件，因為上下樓其實很浪費時間。于是微軟再次改進他們的信箱。新式的信箱采用了更為先進的技術(shù)，只要用戶告訴微軟自己的家在幾樓幾號，新式信箱會把信件直接傳送到用戶的家中，然后告訴用戶，你的信件已經(jīng)放到你的家中了！老陳很高興，因為他不必再親自收發(fā)信件了！

五：Overlapped I/O 完成例程模型

老陳接收到新的信件后，一般的程序是：打開信封----掏出信紙----閱讀信件----回復(fù)信件......為了進一步減輕用戶負擔，微軟又開發(fā)了一種新的技術(shù)：用戶只要告訴微軟對信件的操作步驟，微軟信箱將按照這些步驟去處理信件，不再需要用戶親自拆信/閱讀/回復(fù)了！老陳終于過上了小資生活！

六：IOCP模型

微軟信箱似乎很完美，老陳也很滿意。但是在一些大公司情況卻完全不同！這些大公司有數(shù)以萬計的信箱，每秒鐘都有數(shù)以百計的信件需要處理，以至于微軟信箱經(jīng)常因超負荷運轉(zhuǎn)而崩潰！需要重新啟動！微軟不得不使出殺手锏......
微軟給每個大公司派了一名名叫“Completion Port”的超級機器人，讓這個機器人去處理那些信件！

其實，上面每種模型都有優(yōu)點，要根據(jù)程序需求而適當選擇合適的模型，前面三種模型效率已經(jīng)比較高，實現(xiàn)起來難道不大，很多一般的網(wǎng)絡(luò)程序都采用前三種模型，只有對網(wǎng)絡(luò)要求特別高的一些服務(wù)器才會考慮用后面的那些模型。MFC中的CAsyncSocket類就是用的WSAAsyncSelect模型，電驢中也是用的這種，不過在尋找對應(yīng)socket的時候進行了優(yōu)化，查找更快，在GridCast中采用的是WSAEventSelect模型，等待。

BTW：上面所說均在Windows平臺下，只用WinSock才有這么多模型，在linux下，好像就只有第一種select模式，我對linux下的socket不是很了解，應(yīng)該也有很多提高效率的地方。