相信以下内容就是你想要的 ：）
Socket 体系结构
Winsock2.0规范支持多种协议以及相关的支持服务。这些用户模式服务支持可以基于其他现存服务提供者来扩展他们自己的功能。比如，一个代理层服务支持（LSP）可以把自己安装在现存的TCP/IP服务顶层。这样，代理服务就可以截取和重定向一个对底层功能的调用。
与其他操作系统不同的是，WinNT和Win2000的传输协议层并不直接给应用程序提供socket风格的接口，不接受应用程序的直接访问。而是实现了更多的通用API，称为传输驱动接口(Transport Driver Interface,TDI).这些API把WinNT的子系统从各种各样的网络编程接口中分离出来。然后，通过Winsock内核模式驱动提供了sockets方法（在AFD.SYS里实现）。这个驱动负责连接和缓冲管理，对应用程序提供socket风格的编程接口。AFD.SYS则通过TDI和传输协议驱动层交流数据。
缓冲区由谁来管理
如上所说，对于使用socket接口和传输协议层交流的应用程序来说，AFD.SYS负责缓冲区的管理。也就是说，当一个程序调用send或WSASend函数发送数据的时候，数据被复制到AFD.SYS的内部缓冲里（大小根据SO_SNDBUF设置），然后send和WSASend立刻返回。之后数据由AFD.SYS负责发送到网络上，与应用程序无关。当然，如果应用程序希望发送比SO_SNDBUF设置的缓冲区还大的数据，WSASend函数将会被堵塞，直到所有数据均被发送完毕为止。
同样，当从远地客户端接受数据的时候，如果应用程序没有提交receive请求，而且线上数据没有超出SO_RCVBUF设置的缓冲大小，那么AFD.SYS就把网络上的数据复制到自己的内部缓冲保存。当应用程序调用recv或WSARecv函数的时候，数据即从AFD.SYS的缓冲复制到应用程序提供的缓冲区里。
在大多数情况下，这个体系工作的很好。尤其是应用程序使用一般的发送接受例程不牵涉使用Overlapped的时候。开发人员可以通过使用setsockopt API函数把SO_SNDBUF和SO_RCVBUF这两个设置的值改为0关闭AFD.SYS的内部缓冲。但是，这样做会带来一些后果：
比如，应用程序把SO_SNDBUF设为0,关闭了发送缓冲（指AFD.SYS里的缓冲），并发出一个同步堵塞式的发送操作，应用程序提供的数据缓冲区就会被内核锁定，send函数不会返回，直到连接的另一端收到整个缓冲区的数据为止。这貌似一种挺不错的方法，用来判断是否你的数据已经被对方全部收取。但实际上，这是很糟糕的。问题在于：网络层即使收到远端TCP的确认，也不能保证数据会被安全交到客户端应用程序那里，因为客户端可能发生“资源不足”等情况，而导致应用程序无法从AFD.SYS的内部缓冲复制得到数据。而更重大的问题是：由于堵塞，程序在一个线程里只能进行一次send操作，非常的没有效率。
如果关闭接受缓冲（设置SO_RCVBUF的值为0），也不能真正的提高效率。接受缓冲为0迫使接受的数据在比winsock内核层更底层的地方被缓冲，同样在调用recv的时候进行才进行缓冲复制，这样你关闭AFD缓冲的根本意图（避免缓冲复制）就落空了。关闭接收缓冲是没有必要的，只要应用程序经常有意识的在一个连接上调用重叠WSARecvs操作，这样就避免了AFD老是要缓冲大量的到来数据。
到这里，我们应该清楚关闭缓冲的方法对绝大多数应用程序来说没有太多好处的了。
然而，一个高性能的服务程序可以关闭发送缓冲，而不影响性能。这样的程序必须确保它在同时执行多个Overlapped发送，而不是等待一个Overlapped发送结束之后，才执行另一个。这样如果一个数据缓冲区数据已经被提交，那么传输层就可以立刻使用该数据缓冲区。如果程序“串行”的执行Overlapped发送，就会浪费一个发送提交之后另一个发送执行之前那段时间。
