IOCP完成端口原理-详解

本文主要探讨一下windows平台上的完成端口开发及其与之相关的几个重要的技术概念，这些概念都是与基于IOCP的开发密切相关的，对开发人员来讲，又不得不给予足够重视的几个概念:
1) 基于IOCP实现的服务吞吐量
2）IOCP模式下的线程切换
3）基于IOCP实现的消息的乱序问题。

一、IOCP简介
提到IOCP，大家都非常熟悉，其基本的编程模式，我就不在这里展开了。

在这里我主要是把IOCP中所提及的概念做一个基本性的总结。

IOCP的基本架构图如下：
如图所示：在IOCP中，主要有以下的参与者：
--》完成端口：是一个FIFO队列，操作系统的IO子系统在IO操作完成后，会把相应的IO packet放入该队列。

--》等待者线程队列：通过调用GetQueuedCompletionStatus API，在完成端口上等待取下一个IO packet。

--》执行者线程组：已经从完成端口上获得IO packet，在占用CPU进行处理。

除了以上三种类型的参与者。

我们还应该注意两个关联关系，即：
--》IO Handle与完成端口相关联：任何期望使用IOCP的方式来处理IO请求的，必须将相应的IO Handle与该完成端口相关联。

需要指出的时，这里的IO Handle，可以是File的Handle,或者是Socket的Handle。

--》线程与完成端口相关联：任何调用GetQueuedCompletionStatus API的线程，都将与该完成端口相关联。

在任何给定的时候，该线程只能与一个完成端口相关联，与最后一次调用的GetQueuedCompletionStatus为准。

二、高并发的服务器(基于socket)实现方法
一般来讲，实现基于socket的服务器，有三种实现的方式(thread per request的方式，我就不提了:))：
第一、线程池的方式。

使用线程池来对客户端请求进行服务。

使用这种方式时，当客户端对服务器的连接是短连接（所谓的短连接，即：客户端对服务器不是长时间连接）时，是可以考虑的。

但是，如若客户端对服务器的连接是长连接时，我们需要限制服务器端的最大连接数目为线程池线程的最大数目，而这应用的设计本身来讲，是不好的设计方式，scalability会存在问题。

第二、基于Select的服务器实现。

其本质是，使用Select(操作系统提供的API)来监视连接是否可读，可写，或者是否出错。

相比于前一种方式，Select允许应用使用一个线程(或者是有限几个线程)来监视连接的可读写性。

当有连接可读可写时，应用可以以non-bolock的方式读写socket上的数据。

使用Select的方式的缺点是，当Select所监视的连接数目在千的数量级时，性能会打折扣。

这是因为操作系统内核需要在内部对这些Socket进行轮询，以检查其可读写性。

另一个问题是：应用必须在处理完所有的可读写socket的IO请求之后，才能再次调用Select,进行下一轮的检查，否则会有潜在的问题。

这样，造成的结果是，对一些请求的处理会出现饥饿的现象。

一般common的做法是Select结合Leader-Follower设计模式使用。

不过不管怎样，Select的本质造成了其在Scalability的问题是不如IOCP，这也是很多high-scalabe的服务器采用IOCP的原因。

第三、IOCP实现高并发的服务器。

IOCP是实现high-scalabe的服务器的首选。

其特点我们专门在下一小姐陈述。

三、IOCP开发的几个概念
第一、服务器的吞吐量问题。

我们都知道，基于IOCP的开发是异步IO的，也正是这一技术的本质，决定了IOCP所实现的服务器的高吞吐量。

我们举一个及其简化的例子，来说明这一问题。

在网络服务器的开发过程中，影响其性能吞吐量的，有很多因素，在这里，我们只是把关注点放在两个方面，即：网络IO速度与Disk IO速度。

我们假设：在一个千兆的网络环境下，我们的网络传输速度的极限是大概125M/s，而Disk IO的速度是10M/s。

在这样的前提下，慢速的Disk 设备会成为我们整个应用的瓶颈。

我们假设线程A 负责从网络上读取数据，然后将这些数据写入Disk。

如果对Disk的写入是同步的，那么线程A在等待写完Disk的过程是不能再从网络上接受数据的，在写入Disk的时间内，我们可以认为这时候Server的吞吐量为0(没有接受新的客户端请求)。

对于这样的同步读写Disk，一些的解决方案是通过增加线程数来增加服务器处理的吞吐量，即：当线程A从网络上接受数据后，驱动另外单独的线程来完成读写Disk任务。

这样的方案缺点是：需要线程间的合作，需要线程间的切换（这是另一个我们要讨论的问题）。

而IOCP的异步IO本质，就是通过操作系统内核的支持，允许线程A以非阻塞的方式向IO子系统投递IO请求，而后马上从网络上读取下一个客户端请求。

这样，结果是：在不增加线程数的情况下，IOCP 大大增加了服务器的吞吐量。

说到这里，听起来感觉很像是DMA。

的确，许多软
件的实现技术，在本质上，与硬件的实现技术是相通的。

另外一个典型的例子是硬件的流水线技术，同样，在软件领域，也有很著名的应用。

好像话题扯远了，呵呵:)
第二、线程间的切换问题。

服务器的实现，通过引入IOCP，会大大减少Thread切换带来的额外开销。

我们都知道，对于服务器性能的一个重要的评估指标就是：
System\Context Switches，即单位时间内线程的切换次数。

如果在每秒内，线程的切换次数在千的数量级上，这就意味着你的服务器性能值得商榷。

Context Switches/s应该越小越好。

说到这里，我们来重新审视一下IOCP。

完成端口的线程并发量可以在创建该完成端口时指定（即NumberOfConcurrentThreads参数）。

该并发量限制了与该完成端口相关联的可运行线程的数目(就是前面我在IOCP简介中提到的执行者线程组的最大数目)。

当与该完成端口相关联的可运行线程的总数目达到了该并发量，系统就会阻塞任何与该完成端口相关联的后续线程的执行，直到与该完成端口相关联的可运行线程数目下降到小于该并发量为止。

最有效的假想是发生在有完成包在队列中等待，而没有等待被满足，因为此时完成端口达到了其并发量的极限。

此时，一个正在运行中的线程调用GetQueuedCompletionStatus时，它就会立刻从队列中取走该完成包。

这样就不存在着环境的切换，因为该处于运行中的线程就会连续不断地从队列中取走完成包，而其他的线程就不能运行了。

完成端口的线程并发量的建议值就是你系统CPU的数目。

在这里，要区分清楚的是，完成端口的线程并发量与你为完成端口创建的工作者线程数是没有任何关系的，工作者线程数的数目，完全取决于你的整个应用的设计（当然这个不宜过大，否则失去了IOCP的本意:)）。

第三、IOCP开发过程中的消息乱序问题。

使用IOCP开发的问题在于它的复杂。

我们都知道，在使用TCP时，TCP 协议本身保证了消息传递的次序性，这大大降低了上层应用的复杂性。

但是当使用IOCP时，问题就不再那么简单。

如下例：
三个线程同时从IOCP中读取Msg1, Msg2,与Msg3。

由于TCP本身消息传递的有序性，所以，在IOCP队列内，Msg1-Msg2-Msg3保证了有序性。

三个线程分别从IOCP中取出Msg1,Msg2与Msg3,然后三个线程都会将各自取到的消息
投递到逻辑层处理。

在逻辑处理层的实现，我们不应该假定Msg1-Msg2-Msg3顺序，原因其实很简单，在Time 1~Time 2的时间段内，三个线程被操作系统调度的先后次序是不确定的，所以在到达逻辑处理层，
Msg1,Msg2与Msg3的次序也就是不确定的。

所以，逻辑处理层的实现，必须考虑消息乱序的情况，必须考虑多线程环境下的程序实现。

在这里，我把消息乱序的问题单列了出来。

其实在IOCP的开发过程中，相比于同步的方式，应该还有其它更多的难题需要解决，这也是与Select 方式相比，IOCP的缺点，实现复杂度高。

结束语：
ACE的Proactor Framework，对windows平台的IOCP做了基于Proactor 设计模式的，面向对象的封装，这在一定程度上简化了应用开发的难度，是一个很好的异步IO的开发框架，推荐学习使用。

Reference:
Microsoft Technet,Inside I/O Completion Ports
在WINDOWS下进行网络服务端程序开发，毫无疑问，Winsock 完成端口模型是最高效的。

Winsock 的完成端口模型借助Widnows的重叠IO和完成端口来实现，完成端口模型懂了之后是比较简单的，但是要想掌握Winsock完成端口模型，需要对WINDOWS下的线程、线程同步，Winsock API以及WI NDOWS IO机制有一定的了解。

如果不了解，推荐几本书：《Inside Windows 2000，《WINDOWS 核心编程》，《WIN32多线程程序设计》、《WINDOWS网络编程技术》。

在去年，我在C语言下用完成端口模型写了一个WEBSERVER，前些天，我决定用C++重写这个WEBSERVER，给这个WEBSER VER增加了一些功能，并改进完成端口操作方法，比如采用AcceptEx来代替accept和使用LOOKASI DE LIST来管理内存，使得WEBSERVER的性能有了比较大的提高。

一：完成端口模型
至于完成端口和Winsock完成端口模型的详细介绍，请参见我上面介绍的那几本书，这里只是我个人对完成端口模型理解的一点心得。

首先我们要抽象出一个完成端口大概的处理流程：
1：创建一个完成端口。

2：创建一个线程A。

3：A线程循环调用GetQueuedCompletionStatus()函数来得到IO操作结果，这个函数是个阻塞函数。

4：主线程循环里调用accept等待客户端连接上来。

5：主线程里accept返回新连接建立以后，把这个新的套接字句柄用CreateIoCompletionPort关联到完成端口，然后发出一个异步的WSASend或者WSARecv调用，因为是异步函数，WSASend/WSAR ecv会马上返回，实际的发送或者接收数据的操作由WINDOWS系统去做。

6：主线程继续下一次循环，阻塞在accept这里等待客户端连接。

7：WINDOWS系统完成WSASend或者WSArecv的操作，把结果发到完成端口。

8：A线程里的GetQueuedCompletionStatus()马上返回，并从完成端口取得刚完成的WSASend/WS ARecv的结果。

9：在A线程里对这些数据进行处理(如果处理过程很耗时，需要新开线程处理)，然后接着发出WSASen d/WSARecv，并继续下一次循环阻塞在GetQueuedCompletionStatus()这里。

具体的流程请看附图，其中红线表示是WINDOWS系统进行的处理，不需要我们程序干预。

归根到底概括完成端口模型一句话：
我们不停地发出异步的WSASend/WSARecv IO操作，具体的IO处理过程由WINDOWS系统完成，WINDOWS系统完成实际的IO处理后，把结果送到完成端口上（如果有多个IO都完成了，那么就在完成端口那里排成一个队列）。

我们在另外一个线程里从完成端口不断地取出IO操作结果，然后根据需要再发出WSASend/WSARecv IO操作。

二：提高完成端口效率的几种有效方法
1：使用AcceptEx代替accept。

AcceptEx函数是微软的Winsosk 扩展函数，这个函数和accept的区别就是：accept是阻塞的，一直要到有客户端连接上来后accept才返回，而AcceptEx是异步的，直接就返回了，所以我们利用AcceptEx可以发出多个AcceptEx调用
等待客户端连接。

另外，如果我们可以预见到客户端一连接上来后就会发送数据（比如WEBSERVER的客户端浏览器），那么可以随着AcceptEx投递一个BUFFER进去，这样连接一建立成功，就可以接收客户端发出的数据到BUFFER里，这样使用的话，一次AcceptEx调用相当于accpet和recv的一次连续调用。

同时，微软的几个扩展函数针对操作系统优化过，效率优于WINSOCK 的标准API函数。

2：在套接字上使用SO_RCVBUF和SO_SNDBUF选项来关闭系统缓冲区。

这个方法见仁见智，详细的介绍可以参考《WINDOWS核心编程》第9章。

这里不做详细介绍，我封装的类中也没有使用这个方法。

3：内存分配方法。

因为每次为一个新建立的套接字都要动态分配一个“单IO数据”和“单句柄数据”的数据结构，然后在套接字关闭的时候释放，这样如果有成千上万个客户频繁连接时候，会使得程序很多开销花费在内存分配和释放上。

这里我们可以使用lookaside list。

开始在微软的platform sdk里的SAMPLE 里看到lookaside list，我一点不明白，MSDN里有没有。

后来还是在DDK的文档中找到了，，
lookaside list
A system-managed queue from which entries of a fixed size can be allocated and into which entries can be deallocated dynamically. Callers of the Ex(ecutive) Support lookasi de list routines can use a lookaside list to m anage any dynamically sized set of fixed-si ze buffers or structures with caller-determined contents.
For example, the I/O Manager uses a lookaside for fast allocation and deallocation of I RPs and MDLs. As another example, some of the system-supplied SCSI class drivers us e lookaside lists to allocate and release memory for SRBs.
lookaside list名字比较古怪（也许是我孤陋寡闻，第一次看到），其实就是一种内存管理方法，和内存池使用方法类似。

我个人的理解：就是一个单链表。

每次要分配内存前，先查看这个链表是否为空，如果不为空，就从这个链表中解下一个结点，则不需要新分配。

如果为空，再动态分配。

使用完成后，把这个数据结构不释放，而是把它插入到链表中去，以便下一次使用。

这样相比效率就高了很多。

在我的程序中，我就使用了这种单链表来管理。

在我们使用AcceptEx并随着AcceptEx投递一个BUFFER后会带来一个副作用：比如某个客户端只执行一个connect操作，并不执行send操作，那么AcceptEx这个请求不会完成，相应的，我们用GetQue uedCompletionStatus在完成端口中得不到操作结果，这样，如果有很多个这样的连接，对程序性能会造成巨大的影响，我们需要用一种方法来定时检测，当某个连接已经建立并且连接时间超过我们规定的时间而且没有收发过数据，那么我们就把它关闭。

检测连接时间可以用SO_CONNECT_TIME来调用gets ockopt得到。

还有一个值得注意的地方：就是我们不能一下子发出很多AcceptEx调用等待客户连接，这样对程序的性能有影响，同时，在我们发出的AcceptEx调用耗尽的时候需要新增加AcceptEx调用，我们可以把FD_ ACCEPT事件和一个EVENT关联起来，然后
用WaitForSingleObject等待这个Event，当已经发出AccpetEx调用数目耗尽而又有新的客户端需要连接上来，FD_ACCEPT事件将被触发，EVENT变为已传信状态，
WaitForSingleObject返回，我们就重新发出足够的AcceptEx调用。

关于完成端口模型就介绍到这里。

下面介绍我封装的类，这个类写完后，我用这个类做了个ECHOSERVE R。