windows網路編程第二版 第二章 Winsock的設計 讀書筆記

Windows網路編程 2nd Edition 第二章 Winsock的設計 Notes

1. System Architecture. 首先看附件1中的架構圖。在ws2_32.dll下，分成了很多層，各自管各自的事情。在Winsock中，所謂的Provider指的是針對不同的協議 實現的封裝，比如TCP有TCP的Provider，根據我們的winsock代碼在建立socket的時候指定需要的協議來選擇不同的Provider 為我們的程式提供服務。在圖中可以看到，Provider又分成base和layered兩種。我的理解是base provider就是最基本的針對協議的實現，如上面所說；layered provider根據書中的描述，是架構在ws2_32.dll之下，base provider之上的一個東西，他能攔截和操縱所有的socket操作。詳情參考第12章

2. 在Provider往下的就是kernel層的東西了，在最低層當然就是協議的具體實現了，比如TCP/IP等，但是這些協議的實現，沒有一個類似 Socket的調用介面，取而代之的是TDI介面（Transport Driver Interface），這樣做是為了更好的和上層應用解耦。既然這樣，就必然有個東西出來扮演Coordinator的角色，這就是在底層驅動實現上面一 層的Windows Socket Kernel Mode Driver（AFD.SYS），這個驅動負責connection和buffer這些東西的維護，同時提供一個socket的介面給上層應用。同時，他 也負責和TDI介面的底層實現通訊，對話。

3. 協議特性。本節其實是根據一定的標準對網路通訊的協議進行了一個分類和闡述。本節不具體介紹TCP，UDP這些東西，而是根據協議的特性對協議做了一個分類。

(1) Message-Oriented
參考 附件2 。所謂訊息類型的網路通訊最大的特點就是"preserving message boundaries"，從附件2的圖中也可以看出來。分別發送128, 64, 32的資料，在對方收到的時候也是收到這樣的三個包。UDP就是這樣類似的協議，而且前面一張還提到過AppleTalk，基於訊息的協議，而且還支援 Partial Message。

(2) Stream-Oriented
參考 附件3 。 流式和訊息類型最大的不同就是資料不會被保留邊界。也就是說，在接受的時候，我們請求了多少資料，它就返回儘可能多的資料，資料和資料之間沒有邊界和分 割，在發送方來看也是一樣。在流式協議上，有資料不是立刻就發送，而是當buffer到了一定程度之後，或是過了多長時間之後，才把資料一次性全發出去， 在接受方面，也是一樣，接受會返回儘可能多的資料。所以在附件3的圖上可以看出，發送的時候後兩次的資料合併在一起發送了，接受則是一次性把所有資料全都 接受過來了。流式協議典型的就是TCP，用來傳輸資料不錯。但是在大量傳輸小資料的場合，流式協議顯然有先天的問題，因為每次的資料都要做Error check，帶來了額外的開銷。

(3) Pseudo Stream
顧名思義就可以知道，這是基於訊息的傳輸方式，但是冠以了流的特性。將附件2圖中的左半部分和附件3中圖的右半部分合并在一起就是這種協議的特性了。發送還是獨立發送單獨的message，收的時候可以一次性全收過來。

(4) Connection-Oriented and Connectionless, Reliability and Ordering, Grace Close 這三部分的內容第一章已經講過了，不再贅述

(5) Broadcast Data.
廣播資料只適用於connectionless的協議，因為網路上的每台機器都將收到資料。廣播的效率是低的，而且每台機器都要去check資料，導致了額外的開銷。

(6) Multicast Data
多播資料在視頻會議的時候特別有用，就是一個源可以將資料同時發給多個人，但不是廣播。在基於IP的協議中，多播是對廣播的一個修改。首先在IP 位址段中就有專門用於multicast的IP地址，然後當多播發生前，每個希望發送或收到多播資料的進程/程式需要申請加入到綁定在特定多播IP地址的 一個多播group中，然後發往這個group的訊息，每個加入多播group的程式就都能收到了。其實在每台加入多播group的機器上，在加入多播 group的時候，就在網卡上設定了一個filter，從而實現了上述的功能。多播在第九章有專門的描述。

(7) Quality of Server (QoS)
這個東西也很有意思。QoS是一種應用能力，他能申請將固定的一部分網路頻寬用於特定的用途。實際的例子就是ApsaraVideo for VOD。在以往，ApsaraVideo for VOD需要先緩 沖一部分資料，當網路資料達不到要求的時候，就先播放緩衝中的資料，同時盡量的去填充緩衝。當然這是在internet上，如果在特定的一個網路內，我們 就可以使用QoS，根據ApsaraVideo for VOD需要的網路頻寬，將網路的一部分頻寬保留起來就給我們做ApsaraVideo for VOD用，那麼這樣一來，理論上來說，我們做ApsaraVideo for VOD的時候根本 就不需要什麼緩衝了。第十章有對QoS的詳細描述。

(8) Partial Messages
第一章已經講過了，使用Partial Message的好處就在於他能返回一部分資料。在不支援Partial Message的協議上，當一部分資料到達後，是不能取出來給應用程式的，只有當全部資料到達後，才能給應用程式取出，那麼，如果網路發生了一些問題或由 於某些原因，剩餘的資料一直不能到達，那麼，對於不支援Partial Message的協議來說，就會在timeout的時候將已經收到的部分資料丟棄，應用程式從而收不到任何的資料。

(9) Routing Considerations
NetBEUI是WINSOCK目前唯一支援的不使用路由的協議。

4. Winsock Catalog。本節介紹了WSAEnumProtocols函數，用這個函數可以列出winsock支援的所有協議和該協議的具體資訊（比如支不支援 data ordering，最大的transmission size等）。在這個基礎上，對建立socket的函數做了一個深入，我們在使用winsock 1.1的socket的函數的時候，必須指定協議特性和協議：

SOCKETs;
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

比如我們指定流式，使用TCP協議。

但是如果有一些provider共用相同的協議特性和協議的話，也就是說有多個provider都實現了同一個協議，那麼socket函數就無法 實現這樣的功能。比如RSVP provider，他能在TCP和UDP上提供QOS。這樣的provider我們就無法用socket函數構建出來。（其實更多時候我們建立的 socket就是一個provider，這是winsock根據我們建立socket的時候給定的參數給我們選定的provider）。此時 WSASocket函數就派上用處了。

詳細資料看本節原文吧，老實說，本節沒怎麼看明白，以後看到具體章節的時候再回頭來看，可能會有收穫。