标签：
一、综述
Winsock分别提供了“套接字模式”和“套接字I / O模型”，可对一个套接字上的I/O行为加以控制。其中，套接字模式用于决定在随一个套接字调用时，那些Winsock函数的行为。而另一方面，套接字模型描述了一个应用程序如何对套接字上进行的I/O进行管理及处理。
Winsock提供了两种套接字模式：锁定和非锁定。
Winsock提供五中套接字模型：这些模型包括select（选择）、WSAAsyncSelect（异步选择）、WSAEventSelect（事件选择）、Overlapped I/O（重叠式I / O）以及Completion port（完成端口）等等。
二、套接字模式
Windows套接字在两种模式下执行I/O操作：锁定和非锁定。在锁定模式下，在I / O操作完成前，执行操作的Winsock函数（比如send和recv）会一直等候下去，不会立即返回程序（将控制权交还给程序）。而在非锁定模式下， Winsock函数无论如何都会立即返回。
2.1 锁定模式
在一个锁定套接字上调用任意一个Winsock api可能都会好肥长或短的时间等待。 下列的代码片段就是一个例子。
假如没有数据处于“待决”状态，那么recv函数可能永远都无法返回。这是由于从语句可以看出：只有从系统的输入缓冲区中读回点什么东西，才允许返回！
为了防止数据的缺乏，导致数据缺乏的原因多种，比如网络故障，客户机出问题等。 这时候我们可以将应用程序化为一个读线程，一个计算线程。两个线程共享数据缓冲区，通过同步对象来实现，比如一个事件或者Mutex。
对锁定套接字来说，它的一个缺点在于：应用程序很难同时通过多个建好连接的套接字通信。使用前述的办法，我们可对应用程序进行修改，令其为连好的每个套接字都分配一个读线程，以及一个数据处理线程。尽管这仍然会增大一些开销，但的确是一种可行的方案。唯一的缺点便是扩展性极差，以后想同时处理大量套接字时，恐怕难以下手。
2.2 非锁定模式
下面就展示一个套接字，并将其设置为非锁定模式
三、套接字IO模型
Windows操作系统提供了选择（Select）、异步选择（WSAAsyncSelect）、事件选择（WSAEventSelect）、重叠I/O（Overlapped I/O）和完成端口（Completion Port)共五种I/O模型。每一种模型均适用于一种特定的应用场景。程序员应该对自己的应用需求非常明确，而且综合考虑到程序的扩展性和可移植性等因素，作出自己的选择。
3.1 select模型
Select（选择）模型是Winsock中最常见的I/O模型。之所以称其为“Select模型”，是由于它的“中心思想”便是利用select函数，实现对I/O的管理。利用select函数，我们判断套接字上是否存在数据，或者能否向一个套接字写入数据。
select的函数原型如下：
第一个参数经常被忽略，另外三个fd_set参数是，
一个用于检查可读性（readfds），一个用于检查可写性（writefds），另一个用于例外数据（excepfds）。
其中， readfds集合包括符合下述任何一个条件的套接字：
■ 有数据可以读入。
■ 连接已经关闭、重设或中止。
■ 假如已调用了l i s t e n，而且一个连接正在建立，那么a c c e p t函数调用会成功。
writefds集合包括符合下述任何一个条件的套接字：
■ 有数据可以发出。
■ 如果已完成了对一个非锁定连接调用的处理，连接就会成功。
excepfds集合包括符合下述任何一个条件的套接字：
■ 假如已完成了对一个非锁定连接调用的处理，连接尝试就会失败。
■ 有带外（OOB）数据可供读取。最后一个参数timeout对应的是一个指针，它指向一个timeval结构，用于决定select最多等待I/O操作完成多久的时间.
同时winsock提供下列宏操作，对fd_set进行处理与检查：
3.2 异步选择
Winsock提供了一个有用的异步I/O模型。利用这个模型，应用程序可在一个套接字上，接收以Windows消息为基础的网络事件通知。具体的做法是在建好一个套接字后，调用WSAAsyncSelect函数。该模型最早出现于Winsock的1.1版本中，用于帮助应用程序开发者面向一些早期的16位Windows平台（如Windows for Workgroups），适应其“落后”的多任务消息环境。应用程序仍可从这种模型中得到好处，特别是它们用一个标准的Windows例程（常称为"WndProc"），对窗口消息进行管理的时候。该模型亦得到了Microsoft Foundation Class（微软基本类，MFC）对象CSocket的采纳。（节选自《Windows网络编程》第八章)。
在我看来，WSAAsyncSelect是最简单的一种Winsock I/O模型（之所以说它简单是因为一个主线程就搞定了）。使用Raw Windows API写过窗口类应用程序的人应该都能看得懂。这里，我们需要做的仅仅是：
1.在WM_CREATE消息处理函数中，初始化Windows Socket library，创建监听套接字，绑定，监听，并且调用WSAAsyncSelect函数表示我们关心在监听套接字上发生的FD_ACCEPT事件；
2.自定义一个消息WM_SOCKET，一旦在我们所关心的套接字（监听套接字和客户端套接字）上发生了某个事件，系统就会调用WndProc并且message参数被设置为WM_SOCKET；
3.在WM_SOCKET的消息处理函数中，分别对FD_ACCEPT、FD_READ和FD_CLOSE事件进行处理；
4.在窗口销毁消息(WM_DESTROY)的处理函数中，我们关闭监听套接字，清除Windows Socket library下面这张用于WSAAsyncSelect函数的网络事件类型表可以让你对各个网络事件有更清楚的认识：
3.3 事件选择
Winsock提供了另一个有用的异步I/O模型。和WSAAsyncSelect模型类似的是，它也允许应用程序在一个或多个套接字上，接收以事件为基础的网络事件通知。对于表1总结的、由WSAAsyncSelect模型采用的网络事件来说，它们均可原封不动地移植到新模型。在用新模型开发的应用程序中，也能接收和处理所有那些事件。该模型最主要的差别在于网络事件会投递至一个事件对象句柄，而非投递至一个窗口例程。（节选自《Windows网络编程》第八章)
还是让我们先看代码然后进行分析：事件选择模型也比较简单，实现起来也不是太复杂，它的基本思想是将每个套接字都和一个WSAEVENT对象对应起来，并且在关联的时候指定需要关注的哪些网络事件。一旦在某个套接字上发生了我们关注的事件（FD_READ和FD_CLOSE），与之相关联的WSAEVENT对象被Signaled。程序定义了两个全局数组，一个套接字数组，一个WSAEVENT对象数组，其大小都是MAXIMUM_WAIT_OBJECTS（64），两个数组中的元素一一对应。
同样的，这里的程序没有考虑两个问题，一是不能无条件的调用accept，因为我们支持的并发连接数有限。解决方法是将套接字按MAXIMUM_WAIT_OBJECTS分组，每MAXIMUM_WAIT_OBJECTS个套接字一组，每一组分配一个工作者线程；或者采用WSAAccept代替accept，并回调自己定义的Condition Function。第二个问题是没有对连接数为0的情形做特殊处理，程序在连接数为0的时候CPU占用率为100%。3.4 重叠I/O模型
Winsock2的发布使得Socket I/O有了和文件I/O统一的接口。我们可以通过使用Win32文件操纵函数ReadFile和WriteFile来进行Socket I/O。伴随而来的，用于普通文件I/O的重叠I/O模型和完成端口模型对Socket I/O也适用了。这些模型的优点是可以达到更佳的系统性能，但是实现较为复杂，里面涉及较多的C语言技巧。例如我们在完成端口模型中会经常用到所谓的“尾随数据”。
1.用事件通知方式实现的重叠I/O模型
这个模型与上述其他模型不同的是它使用Winsock2提供的异步I/O函数WSARecv。在调用WSARecv时，指定一个WSAOVERLAPPED结构，这个调用不是阻塞的，也就是说，它会立刻返回。一旦有数据到达的时候，被指定的WSAOVERLAPPED结构中的hEvent被Signaled。由于下面这个语句
g_CliEventArr[g_iTotalConn] = g_pPerIODataArr[g_iTotalConn]->overlap.hEvent；
使得与该套接字相关联的WSAEVENT对象也被Signaled，所以WSAWaitForMultipleEvents的调用操作成功返回。我们现在应该做的就是用与调用WSARecv相同的WSAOVERLAPPED结构为参数调用WSAGetOverlappedResult，从而得到本次I/O传送的字节数等相关信息。在取得接收的数据后，把数据原封不动的发送到客户端，然后重新激活一个WSARecv异步操作。2.用完成例程方式实现的重叠I/O模型
用完成例程来实现重叠I/O比用事件通知简单得多。在这个模型中，主线程只用不停的接受连接即可；辅助线程判断有没有新的客户端连接被建立，如果有，就为那个客户端套接字激活一个异步的WSARecv操作，然后调用SleepEx使线程处于一种可警告的等待状态，以使得I/O完成后CompletionROUTINE可以被内核调用。如果辅助线程不调用SleepEx，则内核在完成一次I/O操作后，无法调用完成例程（因为完成例程的运行应该和当初激活WSARecv异步操作的代码在同一个线程之内）。
完成例程内的实现代码比较简单，它取出接收到的数据，然后将数据原封不动的发送给客户端，最后重新激活另一个WSARecv异步操作。注意，在这里用到了“尾随数据”。我们在调用WSARecv的时候，参数lpOverlapped实际上指向一个比它大得多的结构PER_IO_OPERATION_DATA，这个结构除了WSAOVERLAPPED以外，还被我们附加了缓冲区的结构信息，另外还包括客户端套接字等重要的信息。这样，在完成例程中通过参数lpOverlapped拿到的不仅仅是WSAOVERLAPPED结构，还有后边尾随的包含客户端套接字和接收数据缓冲区等重要信息。这样的C语言技巧在我后面介绍完成端口的时候还会使用到。3.5.完成端口模型
“完成端口”模型是迄今为止最为复杂的一种I/O模型。然而，假若一个应用程序同时需要管理为数众多的套接字，那么采用这种模型，往往可以达到最佳的系统性能！但不幸的是，该模型只适用于Windows NT和Windows 2000操作系统。因其设计的复杂性，只有在你的应用程序需要同时管理数百乃至上千个套接字的时候，而且希望随着系统内安装的CPU数量的增多，应用程序的性能也可以线性提升，才应考虑采用“完成端口”模型。要记住的一个基本准则是，假如要为Windows NT或Windows 2000开发高性能的服务器应用，同时希望为大量套接字I/O请求提供服务（Web服务器便是这方面的典型例子），那么I/O完成端口模型便是最佳选择！（节选自《Windows网络编程》第八章）
完成端口模型是我最喜爱的一种模型。虽然其实现比较复杂（其实我觉得它的实现比用事件通知实现的重叠I/O简单多了），但其效率是惊人的。我在T公司的时候曾经帮同事写过一个邮件服务器的性能测试程序，用的就是完成端口模型。结果表明，完成端口模型在多连接（成千上万）的情况下，仅仅依靠一两个辅助线程，就可以达到非常高的吞吐量。下面我还是从代码说起：首先，说说主线程：
1.创建完成端口对象
2.创建工作者线程（这里工作者线程的数量是按照CPU的个数来决定的，这样可以达到最佳性能）
3.创建监听套接字，绑定，监听，然后程序进入循环
4.在循环中，我做了以下几件事情：
(1).接受一个客户端连接
(2).将该客户端套接字与完成端口绑定到一起(还是调用CreateIoCompletionPort，但这次的作用不同)，注意，按道理来讲，此时传递给CreateIoCompletionPort的第三个参数应该是一个完成键，一般来讲，程序都是传递一个单句柄数据结构的地址，该单句柄数据包含了和该客户端连接有关的信息，由于我们只关心套接字句柄，所以直接将套接字句柄作为完成键传递；
(3).触发一个WSARecv异步调用，这次又用到了“尾随数据”，使接收数据所用的缓冲区紧跟在WSAOVERLAPPED对象之后，此外，还有操作类型等重要信息。
在工作者线程的循环中，我们
1.调用GetQueuedCompletionStatus取得本次I/O的相关信息（例如套接字句柄、传送的字节数、单I/O数据结构的地址等等）
2.通过单I/O数据结构找到接收数据缓冲区，然后将数据原封不动的发送到客户端
3.再次触发一个WSARecv异步操作四.五种I/O模型的比较
我会从以下几个方面来进行比较
*有无每线程64连接数限制
如果在选择模型中没有重新定义FD_SETSIZE宏，则每个fd_set默认可以装下64个SOCKET。同样的，受MAXIMUM_WAIT_OBJECTS宏的影响，事件选择、用事件通知实现的重叠I/O都有每线程最大64连接数限制。如果连接数成千上万，则必须对客户端套接字进行分组，这样，势必增加程序的复杂度。
相反，异步选择、用完成例程实现的重叠I/O和完成端口不受此限制。*线程数
除了异步选择以外，其他模型至少需要2个线程。一个主线程和一个辅助线程。同样的，如果连接数大于64，则选择模型、事件选择和用事件通知实现的重叠I/O的线程数还要增加。
*实现的复杂度
我的个人看法是，在实现难度上，异步选择<选择<用完成例程实现的重叠I/O<事件选择<完成端口<用事件通知实现的重叠I/O
*性能
由于选择模型中每次都要重设读集，在select函数返回后还要针对所有套接字进行逐一测试，我的感觉是效率比较差；完成端口和用完成例程实现的重叠I/O基本上不涉及全局数据，效率应该是最高的，而且在多处理器情形下完成端口还要高一些；事件选择和用事件通知实现的重叠I/O在实现机制上都是采用WSAWaitForMultipleEvents，感觉效率差不多；至于异步选择，不好比较。
所以我的结论是:选择<用事件通知实现的重叠I/O<事件选择<用完成例程实现的重叠I/O<完成端口
参考资料：
1.http://blog.csdn.net/yadong728/article/details/42153579
2.《windows》网络编程技术
标签：
原文地址：http://www.cnblogs.com/panweishadow/p/4382215.html
