Windows 实现TCP/IP 协议也是建立在上一篇博客的OSI 基础之上的。
用户态是由ws2_32.dll 和一些其他服务提供者的 dll 共同实现，当中ws2_32.dll 是一个框架。能够容纳非常多的服务提供者，这些服务提供者事实上就是各种协议的实现者，如比較常见的有 TCP/IP 协议，IPX 协议。而 TCP/IP 协议的服务实现是由 msafd.dll 和 mswsock.dll 来完毕。
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWinSock2，该注冊表下记录了协议（服务）及其一些其他的信息。
就 TCP/IP 而言。我们普遍会使用 posix标准的 socket 接口来完毕我们应用程序的功能，这样要想完毕跨平台的代码就会比較方便。
在上一篇文章中，我们知道，tcp/ip 协议的用户态部分由msafd.dll 完毕，它与内核部分的 afd.sys 交互来实现 socket 接口的系统调用。然后 afd.sys 完毕 socket 的一些机制。而且和 tcpip.sys 驱动程序交互，总结一下例如以下。
1. Msafd.dll : socket 接口的用户态部分。与afd.sys 通信。
2. Afd.sys : socket 接口的内核态部分。满足 msafd.dll的调用，向下与 tcpip.sys 通信。
3. Tcpip.sys : tcp/ip 协议的主要实现部分，满足afd.sys 的调用，向下与小port网卡驱动通过 IRP通信。
4. socket 的概念是在 msafd.dll和 afd.sys 中才有的，它们两个实现了 socket 的用户态和内核态部分。它们的下层是传输层（TDI）层，TDI 层完毕了 TCP, UDP, RawIp的机制。在 TDI 层中。仅仅有地址对象，连接对象，控制通道的概念。TDI 的下层是网络层（IP 层），在 IP 层中，仅仅有 Packet 的概念，收到数据时，通过 IP 包中的标识。知道要提交给 TCP 或 UDP 等处理。
TDI 层和 IP 层都由 tcpip.sys 来实现。
知道上面的概念后。就有了比較清晰的结构，当然驱动和设备的管理由 IO 管理器来管理，但tcpip 协议族却没实用常规设备栈的方式来处理数据包，afd.sys 与 tcpip.sys 以及 tcpip.sys 与 miniport 驱动之间都是由发送 IRP 来实现。这也使中间过滤层驱动的实现稍微复杂，这里且不谈。
那么我们把上面零散的概念串起来，看看从普通的 socket 接口到数据终于由网卡发出的整个过程。
Socket ：
Ws2_32.dll 载入时会依据注冊表初始化服务提供者，服务者会告知自己支持的地址族，socket 类型，和协议类型。当我们调用socket(AF_INET, SOCK_DGRAM, IPPROT_UDP) 来创建一个 UDP 类型的套接字的时候，依据传入的參数，会定位到 msafd.dll 这个服务提供者，并会调用对应的 socket 创建接口，它会打开设备 DeviceAfdEndPoint ，因为 afd.sys 创建了一个 DeviceAfd 设备，所以一个 IRP_MJ_CREATE 的 IRP 便会发送到 afd.sys 驱动的创建函数，它会创建一个FAD_FCB 结构体来表示这个套接字，而且记录下 FileObject，并返回。
Bind :
要想接收数据包。我们会把 socket 绑定到本地的一个IP-Port 对，就是调用 Bind 接口，msafd.dll 会通过一个控制消息。次功能号为 IOCTL_AFD_BIND。此时afd.sys 会接着依据上面 FCB 记录的设备名打开对应的 DeviceUDP 设备，并把输入參数标识为是一个传输层的地址，那么 tcpip.sys 会创建接口就会创建一个地址对象来表示这次绑定。当然还会分配对应的port信息。
Connect:
假设是 TCP，还须要连接到对方的socket。与 Bind 类似。它也会依据 FCB 记录的设备名打开对应的设备，并把输入參数标识为是一个连接对象，tcpip.sys 会创建一个连接对象来表示这次连接。
事实上在 TDI 层，另一种叫做控制通道。当其他驱动想得到 TDI 层的一些信息，如当前的 TCP或 UDP 连接有哪些，那么它会直接打开 DeviceTCP 等设备，因为没有传入參数，那么 tcpip.sys 则会创建一个控制通道。TDI 层这些对象的标识都会保存在与之相应的 FileObject->FsContext2 里，以便后来区分。
当前面准备工作做好后。我们就来看数据的接收和发送。
SendTo:
由 msafd.dll 发送一个 IOCTL_AFD_SEND_DATAGRAM到 afd.sys 。afd.sys 创建一个主功能号为 IRP_MJ_INTERNAL_DEVICE_CONTROL ，次功能号为 TDI_SEND_DATAGRAM的 IRP 到 tcpip.sys，tcpip.sys 调用相就的 UDPSendDatagram。组装一个 UDP 包，最后通过 IpSendDatagram 到协议层，然后由对应的小port驱动发送出去。
RecvFrom:
接收数据略微复杂一点，接收数据都是由afd.sys 驱动发送一个次功能号为 TDI_RECEIVE_DATAGRAM （afd.sys 与 tcpip.sys 的传输层都是以 IRP_MJ_INTERNAL_DEVICE_CONTROL 为主功能号）的 IRP 到 TDI 层。而 TDI 层都是以接收请求的形式来挂在地址对象的接收请求（DATAGRAM_RECEIVE_REQUEST）队列中，在地址对象创建的时候会创建这个队列。那么什么时候这个请求会被满足呢，这要从网卡接到数据说起。当网卡接收到数据时。协议驱动也会收到这个数据，普通情况下仅仅有能处理这个协议的驱动才会去处理这个包。此时就会进行到 tcpip.sys 的协议部分，即 IP 协议，tcpip.sys 依据对应的标识，确定是 IP 包，由于 tcpip.sys 还完毕了 ARP 包的处理，最后会上交到 Ipv4 的处理流程。它会调用ProcessFragment ->IpDispatchProtocol ，IpDispatchProtocl 会区分出是什么包，假设是 UDP 包，由会调用UDPReceive ，并进一步依据地址对象链表来找到匹配的地址对象。DGDeliverData 来交付数据。它会查看对址对象的接收请求队列中是否有请求。假设没有，则查看是否注冊了接收数据的处理过程，假设也没有注冊。那么就会丢掉这个包。这就是 UDP 不可靠的一个原因。
那么有人就会有疑问，我们假设调用完 Bind 之后，还没来得及调用 RecvFrom ，那么。接收到的包不就丢了么。事实上，在调用 Bind 之后。就会立即发送一个接收请求到队列中。也就避免了这样的情况的发生。
这仅仅是整个过程的导火索。在 Bind 里面它是通过调用TdiReceiveDatagram 来投递一个接收请求的，它会创建一个TDI_RECEIVE_DATAGRAM 的 IRP。并为这个 IRP 设置一个完毕例程PacketSocketRecvComplete， tcpip.sys 会响应这个 IRP，并在对应的地址对象的接收请求队列中插入一个请求，并设置这个请求的完毕函数为DGReceiveComplete。用户完毕函数为DispDataRequestComplete。 当通过 DGDeliverData 交付数据时，假设队列中有请求，那么就去满足这个请求，拷贝数据到与这个请求对应的缓冲中，当调用请求的完毕函数 DGReceiveComplete，它会调用用户完毕函数 DispDataRequestComplete，DiapDataRequestComplete会完毕这个 IRP，那么 IRP 的完毕例程PacketSocketRecvComplete 就会得到调用了。 在 PacketSocketRecvComplete中（该函数在 afd.sys 中）要做的工作先暂停一下。回到 RecvFrom 的调用。在 RecvFrom 向下直到 afd.sys 层，它并不会直接发送 IRP 到 tcpip.sys 中去请求接收数据，假设 FCB->DatagramList 中没有数据。它会把 msafd.dll 下发的这个 IRP 放到 FCB->PendingIrpList 中，并挂起，所以到 tcpip.sys 的请求都是由在 Bind 最后发送的那个导火索引起。回到 PacketSocketRecvComplete 中。它会从FCB->PendingIrpList 中摘掉一个 IRP 并插入一个数据包到 FCB->DatagramList 中，最后完毕这个 IRP。那么 RecvFrom 下发的这个 IRP 就完毕了。
最后它又调用TdiReceiveDatagram 来投递一个接收请求，然后周而复始。
一个 UDP Socket的大致过程就到此为止了。