重叠I/O模型的另外几个优点在于，微软针对重叠I/O模型提供了一些特有的扩展函数。当使用重叠I/O模型时，可以选择使用不同的完成通知方式。 

采用事件对象通知的重叠I/O模型是不可伸缩的，因为针对发出WSAWaitForMultipleEvents调用的每个线程，该I/O模型一次最多都只能支持6 4个套接字。假如想让这个模型同时管理不止64个套接字，必须创建额外的工作者线程，以便等待更多的事件对象。因为操作系统同时能够处理的事件对象是有限的，所以基于事件对象的I/O模型不具备伸缩性。 
使用完成例程通知的重叠I/O模型，因为以下几个原因，也不是开发高性能服务器的最佳选择。首先，许多扩展功能不允许使用APC（Asyncroneus Procedure Call，异步过程调用）完成通知。其次，由于APC在系统内部特有的处理机制，应用程序线程可能无限等待而得不到完成通知。当一个线程处于“可警告状态”时，所有挂起的APC按照先进先出的顺序（FIFO）接受处理。现在考虑这样一种情况，服务器已经建立起了一个连接，并且调用含有完成例程指针的WSARecv投递了一个重叠I/O请求。当有数据到达时（即I/O完成时），完成例程执行并且再次调用WSARecv抛出另外一个重叠I/O请求。一个APC抛出的I/O操作需要一定的时间才能完成，所以这期间可能另外一个完成例程等待执行（比如本次WSARecv还没接收完时，又有一个新的客户接入并发来数据），因为还有更多的数据需要读取（上一个客户发来的数据尚未读完）。只要（投递WSARecv的）那个套接字上还有“未决”（未接收完）的数据，就会导致调用线程长久阻塞。 
基于完成端口通知的重叠I/O模型是Windows NT系统提供的一个真正支持高伸缩性的I/O模型。在上一章中，探讨了Winsock几种常见的I/O模型，并且说明了当应对大规模客户连接时，完成端口是最佳的选择，因为它提供了最好的伸缩性。 
对不同Winsock I/O模型的性能测试结果如图1所示。其中服务器采用Pentium 4 1.7 GHz Xeon的CPU，768M内存；客户端有3台PC，配置分别是Pentium 2 233MHz ，128 MB 内存，Pentium 2 350 MHz ，128 MB内存，Itanium 733 MHz ，1 GB内存。服务器、客户端安装的操作系统都是Windows XP。

图1 不同I/O模型的性能比较 

1.分析图表1提供的测试结果可知，在所用的I/O模型中，阻塞模式性能最差。这个测试程序中，服务器为每个客户创建两个线程：一个负责处理数据的接收，一个负责处理数据的发送。在多次测试中的共同问题就是，阻塞模式难以应对大规模的客户连接，因为它在创建线程上耗费了太多的系统资源。因此，服务器创建太多的线程后，再调用CreateThread函数时，将返回ERROR_NOT_ENOUGH_MEMORY的错误，这个错误码提示内存不够。那些发出连接请求的客户则收到WSAECONNREFUSED的错误提示，表示连接的尝试被拒绝。 
让我们来看看监听函数listen，其原型如下： 
WINSOCK_API_LINKAGE int WSAAPI listen（SOCKET s, int backlog ）; 
参数一s已绑定了地址的监听套接字。 
参数二backlog指定了正在等待连接的最大队列长度。 
参数backdog非常重要, 因为完全可能同时出现几个对服务器的连接请求。例如，假定backlog参数为2时有三个客户机同时发出连接请求，那么前两个会被放在一个“等待处理”队列中，以便应用程序依次为它们提供服务。而第三个连接的请求就会造成一个WSAECONNREFUSED错误。一旦服务器接受了一个连接请求，那个连接请求就会从队列中删去，以便可以继续接收其他客户发出的连接请求。即当一个连接请求到来时队列已满，那么客户将收到一个WSAECONNREFUSED错误。而backlog参数本身的大小就存在着限制，这个限制是由协议提供者决定的。 
故阻塞模式下，由于系统资源的限制，其并发处理量是极难突破的。 

2.非阻塞模式表现出的性能要比阻塞模式稍好，但是占用了太多的CPU处理时间。测试服务器将所有客户对应的socket分类放到FD_SET集合中，然后调用select函数筛选出对应集合中有事件发生的socket，并对集合更新。接下来调用FD_ISSET宏重新判断一个套接字是否在原来加入的FD_SET集合中。随着客户连接数量的增多，这种模型的局限性逐渐凸现。仅仅为了判断一个套接字是否有网络事件发生，就需要对集合FD_SET执行一次遍历!使用迭代搜索来对select更新的FD_SET进行扫描，性能可以得到一些提升。瓶颈在于，服务器必须能够很快地扫描出FD_SET集合中的有网络事件发生的套接字的相关信息。针对这个问题，可以使用更复杂的扫描算法，如哈希搜索，它的效率是极高的。还需要注意的一个问题就是，非分页池（即直接在物理内存中分配的内存）的使用极高。这是因为AFD（Ancillary Function Driver,由afd.sys提供的支持Windows Sockets应用程序的底层驱动程序，其中运行在内核模式下afd.sys驱动程序主要管理Winsock TCP/IP通信）和TCP都将使用I/O缓存，因为服务器读取数据的速度是有限的，相对于CPU的处理速度而言，I/O基本是零字节的吞吐量。 

3.基于Windows消息机制的WSAAsyncSelect模型能够处理一定的客户连接量，但是扩展性也不是很好。因为消息泵很快就会阻塞，降低了消息处理的速度。在几次测试中，服务器只能处理大约1/3的客户端连接。过多的客户端连接请求都将返回错误提示码WSAECONNREFUSED，说明服务器不能及时处理FD_ACCEPT消息导致连接失败，这样监听队列中待处理的连接请求不致于爆满。然而，通过上表中的数据可以发现，对那些已经建立的连接，其平均吞吐量也是极低的（即使对于那些对比特率进行了限制的客户也如此）。 

4.基于事件通知的WSAEventSelect模型表现得出奇的不错。在所有的测试中，大多数时候，服务器基本能够处理所有的客户连接，并且保持着较高的数据吞吐量。这种模型的缺点是，每当有一个新连接时，需要动态管理线程池，因为每个线程只能够等待64个事件对象。当客户连接量超过64个后再有新客户接入时，需要创建新的线程。在最后一次测试中，建立起了超过45,000个的客户连接后，系统响应速度变得非常缓慢。这时由于为处理大规模的客户连接创建了大量的线程，占用了过多的系统资源。791个线程基本达到了极限，服务器不能再接受更多的连接了，原因是WSAENOBUFS：无可用的缓冲区空间，套接字无法创建。另外，客户端程序也达到了极限，不能维持已经建立的连接。 
使用事件通知的重叠I/O模型和WSAEventSelect模型在伸缩性上差不多。这两种模型都依赖于等待事件通知的线程池，处理客户通信时，大量线程上下文的切换是它们共同的制约因素。重叠I/O模型和WSAEventSelect模型的测试结果很相似，都表现得不错，直到线程数量超过极限。