完成連接埠->Windows NT和Windows 2000的通訊端架構(收集)

Windows NT和Windows 2000的通訊端架構

對於開發大響應規模的Winsock應用程式而言，對Windows NT和Windows 2000的通訊端架構有基本的瞭解是很有協助的。

與其它類型作業系統不同，Windows NT和Windows 2000的傳輸協議沒有一種風格像通訊端那樣的、可以和應用程式直接交談的介面，而是採用了一種更為底層的API，叫做傳輸驅動程式介面(Transport Driver Interface,TDI)。Winsock的核心模式驅動程式負責串連和緩衝區管理，以便嚮應用程式提供通訊端模擬(在AFD.SYS檔案中實現)，同時負責與底層傳輸驅動程式對話。

誰來負責管理緩衝區？

正如上面所說的，應用程式通過Winsock來和傳輸協議驅動程式交談，而AFD.SYS負責為應用程式進行緩衝區管理。也就是說，當應用程式調用send()或WSASend()函數來發送資料時，AFD.SYS將把資料拷貝進它自己的內部緩衝區(取決於SO_SNDBUF設定值)，然後send()或WSASend()函數立即返回。也可以這麼說，AFD.SYS在後台負責把資料發送出去。不過，如果應用程式要求發出的資料超過了SO_SNDBUF設定的緩衝區大小，那麼WSASend()函數會阻塞，直至所有資料發送完畢。

從遠程用戶端接收資料的情況也類似。只要不用從應用程式那裡接收大量的資料，而且沒有超出SO_RCVBUF設定的值，AFD.SYS將把資料先拷貝到其內部緩衝區中。當應用程式調用recv()或WSARecv()函數時，資料將從內部緩衝拷貝到應用程式提供的緩衝區。

多數情況下，這樣的架構運行良好，特別在是應用程式採用傳統的通訊端下非重疊的send()和receive()模式編寫的時候。不過程式員要小心的是，儘管可以通過setsockopt()這個API來把SO_SNDBUF和SO_RCVBUF選項值設成0(關閉內部緩衝區)，但是程式員必須十分清楚把AFD.SYS的內部緩衝區關掉會造成什麼後果，避免收發資料時有關的緩衝區拷貝可能引起的系統崩潰。

舉例來說，一個應用程式通過設定SO_SNDBUF為0把緩衝區關閉，然後發出一個阻塞send()調用。在這樣的情況下，系統核心會把應用程式的緩衝區鎖定，直到接收方確認收到了整個緩衝區後send()調用才返回。似乎這是一種判定你的資料是否已經為對方全部收到的簡潔的方法，實際上卻並非如此。想想看，即使遠端TCP通知數據已經收到，其實也根本不代表資料已經成功送給用戶端應用程式，比如對方可能發生資源不足的情況，導致AFD.SYS不能把資料拷貝給應用程式。另一個更要緊的問題是，在每個線程中每次只能進行一次發送調用，效率極其低下。

把SO_RCVBUF設為0，關閉AFD.SYS的接收緩衝區也不能讓效能得到提升，這隻會迫使接收到的資料在比Winsock更低的層次進行緩衝，當你發出receive調用時，同樣要進行緩衝區拷貝，因此你本來想避免緩衝區拷貝的陰謀不會得逞。

現在我們應該清楚了，關閉緩衝區對於多數應用程式而言並不是什麼好主意。只要要應用程式注意隨時在某個串連上保持幾個WSARecvs重疊調用，那麼通常沒有必要關閉接收緩衝區。如果AFD.SYS總是有由應用程式提供的緩衝區可用，那麼它將沒有必要使用內部緩衝區。

高效能的伺服器應用程式可以關閉發送緩衝區，同時不會損失效能。不過，這樣的應用程式必須十分小心，保證它總是發出多個重疊發送調用，而不是等待某個重疊發送結束了才發出下一個。如果應用程式是按一個發完再發下一個的順序來操作，那浪費掉兩次發送中間的空檔時間，總之是要保證傳輸驅動程式在發送完一個緩衝區後，立刻可以轉向另一個緩衝區。