在介紹windows網路體系架構之前，我首先介紹一下windows中的兩個重要程式設計規範——tdi，ndis.，然後再介紹網路體系的架構。tdi，transport driver inte***ce，傳輸驅動程式介面。/windows/system32/drivers/tdi.sys。在實現網路api驅動程式時，由於牽涉到很多不同協議，會用到不同協議驅動提供的介面，使得開發的工作複雜化。所以microsoft在網路api驅動程式和協議驅動之間又增加了一層tdi。tdi介面只是一種「將網路請求格式化成irp，以及申請網路位址和資料通訊」的做法規範化。遵從tdi標準的傳輸協議向他們的客戶（如socket emulator，netbios emulator等）匯出了tdi介面，有利於上下層之間的通訊：
一方面，對於tdi上層的網路api驅動程式就不需要使用所有協議驅動程式所提供的介面，直接使用tdi提供的統一介面。
另一方面，對於下層協議驅動程式（也稱為tdi transport provider傳輸器）直接由tdi介面來呼叫，發出請求。
在windows vista版本之後，tdi就不再使用了，取而代之的是windows filter platform和winsock kernel。
tdindis，network driver inte***ce specification，網路驅動程式介面規範，在作業系統中的位置/windows/system32/drivers/ndis.sys。當乙個協議驅動程式想要按照其協議的格式解析網上讀寫的資料時，而這些資料必須通過網路介面卡才能取得，期望協議驅動程式能夠理解市場上的每一款網路介面卡的細微區別是不可能的。所以在2023年，由microsoft和3com聯合開發的了ndis，使得協議驅動程式可以以一種與裝置無關的方式來跟網路介面卡驅動程式進行通訊。遵從ndis的網路介面卡驅動程式稱為ndis minport driver。
ndis規範實現了與tdi標準類似的功能，都是將複雜的下層呼叫規範化、標準化，大大提高了windows作業系統的可擴充套件性和相容性。也表現在兩個方面：
對於下層，讓網路介面卡製造商很easy的開發自己的裝置驅動程式，也就是ndis miniport driver。這些 miniport driver直接利用ndis提供的介面傳送指令，ndis對這些格式化的指令進行解析，做進一步處理。（這些處理就到了hal了）
對於上層，多個協議驅動程式與下層minport driver之間的通訊，也都是通過統一的ndis介面，nidsallocatepacket，ndissend等函式來收發資料。
裝置製造商開發的ndis miniport driver直接呼叫ndis庫中的介面函式，因此不需要考慮重入的問題，就是乙個請求尚未結束的時候，新的請求又進來了。ndis庫對請求進行了序列化，但是這種序列化也妨礙了多處理器的擴充套件性。所以ndis5中提供了非序列化的操作項。下面，我來介紹一下，deserialized和 serialized minport driver的區別：
deserialized ndis miniport driver自己序列化對minport***函式的操作，排隊和管理多個併發請求的任務都由驅動程式自己來完成。而serialized ndis miniport driver以上的工作都是依賴於ndis庫來完成的。從效能角度看，deserialized ndis miniport driver的效能是serialized ndis miniport driver效能的2倍多，所以到ndis6.0之後的所有miniport driver都是deserialize的。
以上是我參考msdn以及自己的一些理解畫出來的windows網路架構圖，下面我就從上到下來簡單介紹一下其中的各個層。
windows網路元件結構圖
3. tdi transport providers、tdi傳輸器、ndis協議驅動程式、協議驅動程式，所有這些其實就是指的同乙個東西，我在後面就稱其為協議驅動程式。這個部分就是我們對某個協議的具體實現部分。做過網路協議開發的朋友一定知道，協議其實就是雙發協商好的一套通訊的規則。以ip 協議為例，實際上就是對網路資料的一種處理方式，根據網路資料報的解析結構，做出相應的處理。windows的tcpip.sys就實現了多個協議，ip、tcp、udp、arp、icmp、igmp，它為上層的tdi clients提供了5個裝置物件，用於訪問使用這些協議，tdi clients開啟這些裝置物件，向其傳送irp請求來實現自己的操作。通過ddk的devicetree我們可以得到這些裝置物件：
a) /device/rawip
b) /device/tcp
c) /device/udp
d) /device/ipmulticast
e) /device/ip
協議驅動程式處理的資料是通過ndis庫中提供的介面來獲取的，不需要傳送irp來取得。在ddk xp中提供了乙個協議驅動程式了源程式 ndisuio，ddk xp後的版本提供的是ndisport。在driverentry中我們可以看到，驅動程式一開始就註冊了乙個 ndis_protocol_characteristics，這個結構體中是一堆ndis***x函式。ndis規範在這裡就開始發揮它的作用了。
協議驅動程式的另乙個作用就是監聽網路資料，自己開發乙個網路協議通過ndis api獲得所有的網路資料，但是不能夠攔截網路資料，因為其他協議驅動也可以通過nids api獲取資料。乙個典型的應用就是winpcap了，使用npf.sys來捕獲網路資料，並且做好充分緩衝處理，防止大資料量到來時出現資料報丟失的情況。詳情情節winpcap的開源**。
具體的協議驅動開發過程，我就不細述了，大家可以參看ndisuio和ddk doc，我推薦boywhp的一篇文件《ndis協議驅動開發》給大家。
4. ndis，network driver inte***ce specification，網路協議介面標準。從圖中我們可以看到包裹在其中的兩個驅動程式，乙個是ndis intermediate driver，ndis中間層驅動程式，另乙個是ndis minport driver，小埠驅動程式。下面簡單介紹一下這兩個驅動程式：
a) ndis intermediate driver：ndis中間層驅動程式。對於上層的protocol driver它充當 minport driver的作用，對於下層的minport driver它充當乙個protocol driver的作用，所以在驅動程式 driverentry中就註冊ndis_protocol_characteristics和 ndis_miniport_characteristics，使用protocol characteristics中ndis api從 miniport driver那裡取得資料報，再用miniport characteristics的ndis api向上層的 protocol driver傳送資料報。nids intermediate driver最大的優勢就是所有miniport driver的資料報都要通過它這裡倒手給protocol driver，所以網路防火牆就看上了這塊風水寶地。現在很多網路防火牆都使用 ndis intermediate driver做資料報的過濾和攔截工作，過濾的規則設定到 mpsendpackets，ptreceive，ptreceiveracket這三個函式。具體開發過程請大家參考ddk提供的passthru源**，www.ndis.com， 網上有很多相關的資料。
ndis 6.0之後，filter driver就取代了ndis intermediate driver，wdk中提供原始碼。
b) ndis miniport driver:小埠驅動，其實是真正的網絡卡驅動。一般是由裝置廠商提供的，在ddk中也提供了miniport driver的乙個例子 e100bex，支援intel etherexpresstm pro/100+ ethernet pci adapter 和 intel etherexpresstm pro/100b pci adapter兩款網路介面卡。在安全軟體領域，小埠驅動的技術主要用於虛擬網路。
網路 系統測試方案
系統測試方案 文件控制 文件審核記錄 文件名稱 編寫者 簽名 日期 審核者 說明 文件版本控制 日期 版本 作者 備註 目錄1 概述.4 2 測試資源和測試環境.5 2.1 硬體的配置.5 2.2 軟體配置.5 2.3 測試資料.5 3 測試策略.6 3.1 測試型別.6 3.1.1 功能測試.6 ...
網際網路系統架構演變簡史
隨著網際網路的發展，應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。網際網路系統架構也因此也不斷的演進 公升級 迭代。從單一應用，到垂直拆分，到分布式服務，到soa，以及現在火熱的微服務架構等，還有在google帶領下來勢洶湧的service mesh。作為一名合格的架構師，有必要對架構的前世...
C S和B S架構的網路系統各有哪些優勢？
c s架構 互動性強 程式模式安全 cs模式採用適用於區域網，安全性較好的網路協議，是配對的典對典的結構模式，能夠提供更安全的訪問模式。網路通訊量低，處理速度快 cs模式的網路採用兩層結構，只包括客戶端與伺服器之間的通訊量，這樣能夠降低網路通訊量，提高處理大量資訊的速度和能力。b s架構 客戶端簡單...