Summary of the Windows Network Architecture (from the perspective of snow, Author: jbwang)

Question: [original] Windows Network Architecture Summary
Author: jbwang
Time: 2009-11-23,11: 22: 25
Chain: http://bbs.pediy.com/showthread.php? T = 101794

I have read some books and summarized them recently. I 'd like to share with you that the experts can fly over. If you have any questions, please let me know. Thank you!

Before introducing the windows network architecture, I will first introduce two important programming specifications in Windows-TDI and NDIS. Then I will introduce the network architecture.
TDI, transport driver interface, and transmission driver interface. \ Windows \ system32 \ drivers \ TDI. sys
When implementing the Network API driver, because many different protocols are involved, interfaces provided by different protocol drivers are used to complicate development. Therefore, Microsoft adds a layer of TDI between the Network API driver and the protocol driver. The TDI interface is just a way to standardize "format network requests into IRPs, and apply for network addresses and data communications. The TDI interface is exported to their customers (such as socket emulator and NetBIOS emulator) according to the TDI standard transmission protocol, which facilitates communication between the upper and lower layers:
On the one hand, Network API drivers on the TDI layer do not need to use the interfaces provided by all protocol drivers, and directly use the unified interfaces provided by TDI.
On the other hand, the underlying protocol driver (also known as the TDI transport provider TRANSMITTER) is called directly by the TDI interface to send a request.
 

After Windows Vista, TDI is no longer used and replaced by Windows filter platform and Winsock kernel.

NDIS, Network Driver Interface Specification, Network Driver Interface Specification, location in the operating system
\ Windows \ system32 \ drivers \ NDIS. sys
When a protocol driver wants to parse the data read and written on the internet according to the protocol format, the data must be obtained through the network adapter, it is expected that the protocol driver can understand the nuances of each network adapter on the market. Therefore, in 1989, the NDIS jointly developed by Microsoft and 3Com enables the protocol driver to communicate with the Network Adapter driver in a device-independent manner. The Network Adapter driver that complies with NDIS is known as NDIS minport driver.

 
The NDIS specification implements functions similar to the TDI standard. It standardizes and standardizes complex lower-layer calls, greatly improving the scalability and compatibility of Windows operating systems. It is also manifested in two aspects:
For lower layers, it is easy for network adapter manufacturers to develop their own device drivers, that is, NDIS miniport driver. These miniport drivers directly use the interfaces provided by NDIS to send commands. NDIS parses these formatted commands for further processing. (These processes are now Hal)
For upper-layer communication between multiple Protocol drivers and lower-layer minport drivers, data is also sent and received through the unified NDIS interface, nidsallocatepacket, ndissend, and other functions.

The two interface specifications TDI and NDIS greatly improve the support of the Windows operating system for different device manufacturers and reduce the difficulty of the device manufacturers in developing device drivers; it also adds support for different network protocols and provides users with more powerful network functions. We can also see this design in Windows storage management, from which we seem to be able to understand some of the reasons for the Windows operating system's commercial success. In Linux, there is no such driver hierarchy.

The NDIS miniport driver developed by the device manufacturer directly calls the interface functions in the NDIS library. Therefore, the re-entry issue does not need to be considered. That is, when a request is not completed, a new request comes in again. The NDIS library serializes requests, but this serialization also hinders the scalability of multi-processor. Therefore, ndis5 provides non-serialized operation items. Next, let me introduce the differences between deserialized and serialized minport DRIVER:
The deserialized NDIS miniport driver serializes the operations on the minportxxx function by itself. All tasks for queuing and managing multiple concurrent requests are completed by the driver itself. The serialized NDIS miniport driver and above depend on the NDIS library. From the performance perspective, the performance of deserialized NDIS miniport driver is more than twice that of serialized NDIS miniport driver. Therefore, all miniport drivers after ndis6.0 are deserialize.

 
The above is the Windows Network Architecture diagram drawn by referring to msdn and some of my own understandings. Next I will briefly introduce each layer from top to bottom.

1. network applications, network applicantion, and user-Mode Applications call network APIs provided by the Windows operating system. Network APIs include:
A) Windows Socket (Winsock)
B) Remote Procedure Call RPC
C) Web access API
D) named pipe and mail slot
E) other network APIs
These APIs can be implemented in both user and kernel modes. Essentially, these APIs are another layer of encapsulation provided by the lower layer.
2. TDI clients, a Transport Driver Interface customer, is a device driver in kernel mode, used to implement the kernel part of the Network API. The Network API request is converted to IRP, formatted using the TDI standard, and sent to the underlying protocol driver (that is, the tdi transmitter ). From the architecture diagram of sockets emulator, we can see that the implementation of TDI clients includes user-mode and kernel-mode. The AFD auxiliary function driver sends the tdi irp to the protocol driver to perform network socket operations, such as sending and receiving messages. AFD does not determine which protocol driver to use, but notifies the upper layer of the protocol name to use, and then AFD opens the device object of the corresponding protocol.

 
3. TDI transport providers, TDI transmitter, NDIS protocol driver, and protocol driver. All these actually refer to the same thing. I will call them protocol drivers later. This part is the specific implementation part of a specific protocol. Those who have worked on network protocol development know that the Protocol is actually a set of communication rules negotiated by the dual-producer. Taking the IP protocol as an example, it is actually a processing method for network data, and processing is made based on the parsing structure of network data packets. Windows tcpip. sys implements multiple protocols, including IP, TCP, UDP, ARP, ICMP, and IGMP. It provides five Device objects for the TDI clients on the upper layer to access and use these protocols, TDI clients open these device objects and send IRP requests to them for their own operations. Through devicetree of DDK, we can get these device objects.
A) \ device \ rawip
B) \ device \ Tcp
C) \ device \ UDP
D) \ device \ ipmulticast
E) \ device \ IP
The data processed by the protocol driver is obtained through the interface provided in the NDIS library and does not need to be obtained by sending IRPs. In ddk xp, a protocol driver is provided for the source program ndisuio. In the later versions of ddk xp, ndisport is provided. In DriverEntry, we can see that the driver registered an ndis_protocol_characteristics from the very beginning. This struct contains a bunch of ndisxxxx functions. The NDIS specification starts to play its role here.
The protocol driver monitors network data. It develops a network protocol to obtain all network data through the ndis api, but cannot intercept network data, because other protocol drivers can also obtain data through the NIDs API. A typical application is Winpcap, which uses NPF. sys to capture network data and buffer the data to prevent packet loss when large data volumes arrive. The source code of Winpcap.
I will not elaborate on the specific Protocol-driven development process. For more information, see ndisuio and DDK Doc. I recommend boywhp's document "NDIS protocol-driven development.
4. NDIS, Network Driver Interface Specification, network protocol interface standard. We can see two drivers included in the package: NDIS intermediate driver, NDIS middle layer driver, and NDIS minport driver, small port driver. The following describes the two drivers:
A) NDIS intermediate driver, which is a middle-layer driver. It acts as a minport driver for the protocol driver on the upper layer and acts as a protocol driver on the lower layer, therefore, register ndis_protocol_characteristics and drivers in the driver DriverEntry, use the ndis api in protocol characteristics to retrieve data packets from The miniport driver, and then use the ndis api of miniport characteristics to send data packets to the proto. The biggest advantage of NIDs intermediate driver is that all the data packets of miniport driver must be handed over to protocol driver. Therefore, the network firewall is regarded as a perfect place. Nowadays, many network firewalls use the NDIS intermediate driver to filter and intercept data packets. The filtering rules are set to the mpsendpackets, ptreceive, and ptreceiveracket functions. For details about the development process, refer to the source code of passthru provided by DDK, www.ndis.com. There are a lot of related information on the Internet.
After NDIS 6.0, the filter driver replaces the NDIS intermediate driver. The source code is provided in wdk.
B) NDIS miniport driver is generally provided by the device manufacturer. In DDK, an example of miniport driver is provided: e100bex, supports two network adapters: Intel etherexpresstm Pro/100 + Ethernet PCI adapter and Intel etherexpresstm Pro/100b PCI adapter.
5. finally, we will introduce several types of Bus: USB bus, ISA bus, PCI bus, and virtual bus. Generally, PCI bus is used as the root bus, in Windows, other bus can be understood as a device on the PCI bus. As the root bus, the PCI bus delivers a high transmission speed of 133 Mb/s. Many graphics cards and NICs use PCI slots.
PCI-ISA bridge equipment, also known as the South Bridge, implements the ISA bus and PCI Bus Bridge, south bridge also includes Terminal, IDE, USB, DMA controller equipment. The USB-HOST device realizes the bridge between the USB bus and the PCI bus. The host/PCI bridge is called the North Bridge. It is the master processor center to the basic PCI local bus. The South Bridge and the North Bridge form the Motherboard chipset, And the chip extension enables the bridge between multiple bus and the basic PCI local bus.
The bus driver and the PnP Manager implement the plug-and-play function. The physical device object PDO is generated by the bus driver.