iocp模型

参考文献
手把手叫你玩转网络编程系列之三—完成端口(Completion Port)详解 ----- By PiggyXP(小猪)
http://www.cnblogs.com/lancidie/archive/2011/12/19/2293773.html

1 IOCP

发现Windows下有一种号称性能最好的通信模型，叫做IOCP，中文名称叫做完成端口模型。

2 完成端口的相关概念

异步通信机制及其几种实现方式的比较
我们从前面的文字中了解到，高性能服务器程序使用异步通信机制是必须的。
而对于异步的概念，为了方便后面文字的理解，这里还是再次简单的描述一下：
异步通信就是在咱们与外部的I/O设备进行打交道的时候，我们都知道外部设备的I/O和CPU比起来简直是龟速，比如硬盘读写、网络通信等等，我们没有必要在咱们自己的线程里面等待着I/O操作完成再执行后续的代码，而是将这个请求交给设备的驱动程序自己去处理，我们的线程可以继续做其他更重要的事情，大体的流程如下图所示:

我可以从图中看到一个很明显的并行操作的过程，而“同步”的通信方式是在进行网络操作的时候，主线程就挂起了，主线程要等待网络操作完成之后，才能继续执行后续的代码，就是说要末执行主线程，要末执行网络操作，是没法这样并行的；

“异步”方式无疑比 “阻塞模式+多线程”的方式效率要高的多，这也是前者为什么叫“异步”，后者为什么叫“同步”的原因了，因为不需要等待网络操作完成再执行别的操作。

而在Windows中实现异步的机制同样有好几种，而这其中的区别，关键就在于图1中的最后一步“通知应用程序处理网络数据”上了，因为实现操作系统调用设备驱动程序去接收数据的操作都是一样的，关键就是在于如何去通知应用程序来拿数据。

(4) 完成端口，不用说大家也知道了，最后的压轴戏就是使用完成端口，对比上面几种机制，完成端口的做法是这样的：事先开好几个线程，你有几个CPU我就开几个，首先是避免了线程的上下文切换，因为线程想要执行的时候，总有CPU资源可用，然后让这几个线程等着，等到有用户请求来到的时候，就把这些请求都加入到一个公共消息队列中去，然后这几个开好的线程就排队逐一去从消息队列中取出消息并加以处理，这种方式就很优雅的实现了异步通信和负载均衡的问题，因为它提供了一种机制来使用几个线程“公平的”处理来自于多个客户端的输入/输出，并且线程如果没事干的时候也会被系统挂起，不会占用CPU周期，挺完美的一个解决方案，不是吗？哦，对了，这个关键的作为交换的消息队列，就是完成端口。

熟悉网络编程的朋友可能会问到，为什么没有提到WSAAsyncSelect或者是WSAEventSelect这两个异步模型呢，对于这两个模型，我不知道其内部是如何实现的，但是这其中一定没有用到Overlapped机制，就不能算作是真正的异步，可能是其内部自己在维护一个消息队列吧，总之这两个模式虽然实现了异步的接收，但是却不能进行异步的发送，这就很明显说明问题了，我想其内部的实现一定和完成端口是迥异的，并且，完成端口非常厚道，因为它是先把用户数据接收回来之后再通知用户直接来取就好了，而WSAAsyncSelect和WSAEventSelect之流只是会接收到数据到达的通知，而只能由应用程序自己再另外去recv数据，性能上的差距就更明显了。

最后，我的建议是，想要使用 基于事件通知的重叠I/O和基于完成例程的重叠I/O的朋友，如果不是特别必要，就不要去使用了，因为这两种方式不仅使用和理解起来也不算简单，而且还有性能上的明显瓶颈，何不就再努力一下使用完成端口呢？

3.2 重叠结构(OVERLAPPED)

我们从上一小节中得知，要实现异步通信，必须要用到一个很风骚的I/O数据结构，叫重叠结构“Overlapped”，Windows里所有的异步通信都是基于它的，完成端口也不例外。

至于为什么叫Overlapped？Jeffrey Richter的解释是因为“执行I/O请求的时间与线程执行其他任务的时间是重叠(overlapped)的”，从这个名字我们也可能看得出来重叠结构发明的初衷了，对于重叠结构的内部细节我这里就不过多的解释了，就把它当成和其他内核对象一样，不需要深究其实现机制，只要会使用就可以了，想要了解更多重叠结构内部的朋友，请去翻阅Jeffrey Richter的《Windows via C/C++》 5th 的292页，如果没有机会的话，也可以随便翻翻我以前写的Overlapped的东西，不过写得比较浅显……

这里我想要解释的是，这个重叠结构是异步通信机制实现的一个核心数据结构，因为你看到后面的代码你会发现，几乎所有的网络操作例如发送/接收之类的，都会用WSASend()和WSARecv()代替，参数里面都会附带一个重叠结构，这是为什么呢？因为重叠结构我们就可以理解成为是一个网络操作的ID号，也就是说我们要利用重叠I/O提供的异步机制的话，每一个网络操作都要有一个唯一的ID号，因为进了系统内核，里面黑灯瞎火的，也不了解上面出了什么状况，一看到有重叠I/O的调用进来了，就会使用其异步机制，并且操作系统就只能靠这个重叠结构带有的ID号来区分是哪一个网络操作了，然后内核里面处理完毕之后，根据这个ID号，把对应的数据传上去。
你要是实在不理解这是个什么玩意，那就直接看后面的代码吧，慢慢就明白了……

3.3 完成端口(CompletionPort)

对于完成端口这个概念，我一直不知道为什么它的名字是叫“完成端口”，我个人的感觉应该叫它“完成队列”似乎更合适一些，总之这个“端口”和我们平常所说的用于网络通信的“端口”完全不是一个东西，我们不要混淆了。

首先，它之所以叫“完成”端口，就是说系统会在网络I/O操作“完成”之后才会通知我们，也就是说，我们在接到系统的通知的时候，其实网络操作已经完成了，就是比如说在系统通知我们的时候，并非是有数据从网络上到来，而是来自于网络上的数据已经接收完毕了；或者是客户端的连入请求已经被系统接入完毕了等等，我们只需要处理后面的事情就好了。

各位朋友可能会很开心，什么？已经处理完毕了才通知我们，那岂不是很爽？其实也没什么爽的，那是因为我们在之前给系统分派工作的时候，都嘱咐好了，我们会通过代码告诉系统“你给我做这个做那个，等待做完了再通知我”，只是这些工作是做在之前还是之后的区别而已。

其次，我们需要知道，所谓的完成端口，其实和HANDLE一样，也是一个内核对象，虽然Jeff Richter吓唬我们说：“完成端口可能是最为复杂的内核对象了”，但是我们也不用去管他，因为它具体的内部如何实现的和我们无关，只要我们能够学会用它相关的API把这个完成端口的框架搭建起来就可以了。我们暂时只用把它大体理解为一个容纳网络通信操作的队列就好了，它会把网络操作完成的通知，都放在这个队列里面，咱们只用从这个队列里面取就行了，取走一个就少一个…。

关于完成端口内核对象的具体更多内部细节我会在后面的“完成端口的基本原理”一节更详细的和朋友们一起来研究，当然，要是你们在文章中没有看到这一节的话，就是说明我又犯懒了没写…在后续的文章里我会补上。

四． 使用完成端口的基本流程

说了这么多的废话，大家都等不及了吧，我们终于到了具体编码的时候了。

使用完成端口，说难也难，但是说简单，其实也简单 ---- 又说了一句废话=。=

大体上来讲，使用完成端口只用遵循如下几个步骤：

(1) 调用 CreateIoCompletionPort() 函数创建一个完成端口，而且在一般情况下，我们需要且只需要建立这一个完成端口，把它的句柄保存好，我们今后会经常用到它……

(2) 根据系统中有多少个处理器，就建立多少个工作者(为了醒目起见，下面直接说Worker)线程，这几个线程是专门用来和客户端进行通信的，目前暂时没什么工作；

(3) 下面就是接收连入的Socket连接了，这里有两种实现方式：一是和别的编程模型一样，还需要启动一个独立的线程，专门用来accept客户端的连接请求；二是用性能更高更好的异步AcceptEx()请求，因为各位对accept用法应该非常熟悉了，而且网上资料也会很多，所以为了更全面起见，本文采用的是性能更好的AcceptEx，至于两者代码编写上的区别，我接下来会详细的讲。

(4) 每当有客户端连入的时候，我们就还是得调用CreateIoCompletionPort()函数，这里却不是新建立完成端口了，而是把新连入的Socket(也就是前面所谓的设备句柄)，与目前的完成端口绑定在一起。

至此，我们其实就已经完成了完成端口的相关部署工作了，嗯，是的，完事了，后面的代码里我们就可以充分享受完成端口带给我们的巨大优势，坐享其成了，是不是很简单呢？

(5) 例如，客户端连入之后，我们可以在这个Socket上提交一个网络请求，例如WSARecv()，然后系统就会帮咱们乖乖的去执行接收数据的操作，我们大可以放心的去干别的事情了；

(6) 而此时，我们预先准备的那几个Worker线程就不能闲着了， 我们在前面建立的几个Worker就要忙活起来了，都需要分别调用GetQueuedCompletionStatus() 函数在扫描完成端口的队列里是否有网络通信的请求存在(例如读取数据，发送数据等)，一旦有的话，就将这个请求从完成端口的队列中取回来，继续执行本线程中后面的处理代码，处理完毕之后，我们再继续投递下一个网络通信的请求就OK了，如此循环。

关于完成端口的使用步骤，用文字来表述就是这么多了，很简单吧？如果你还是不理解，我再配合一个流程图来表示一下：

当然，我这里假设你已经对网络编程的基本套路有了解了，所以略去了很多基本的细节，并且为了配合朋友们更好的理解我的代码，在流程图我标出了一些函数的名字，并且画得非常详细。

另外需要注意的是由于对于客户端的连入有两种方式，一种是普通阻塞的accept，另外一种是性能更好的AcceptEx，为了能够方面朋友们从别的网络编程的方式中过渡，我这里画了两种方式的流程图，方便朋友们对比学习，图a是使用accept的方式，当然配套的源代码我默认就不提供了，如果需要的话，我倒是也可以发上来；图b是使用AcceptEx的，并配有配套的源码。

采用accept方式的流程示意图如下：

采用AcceptEx方式的流程示意图如下：

两个图中最大的相同点是什么？是的，最大的相同点就是主线程无所事事，闲得蛋疼……

为什么呢？因为我们使用了异步的通信机制，这些琐碎重复的事情完全没有必要交给主线程自己来做了，只用在初始化的时候和Worker线程交待好就可以了，用一句话来形容就是，主线程永远也体会不到Worker线程有多忙，而Worker线程也永远体会不到主线程在初始化建立起这个通信框架的时候操了多少的心……

图a中是由 _AcceptThread()负责接入连接，并把连入的Socket和完成端口绑定，另外的多个_WorkerThread()就负责监控完成端口上的情况，一旦有情况了，就取出来处理，如果CPU有多核的话，就可以多个线程轮着来处理完成端口上的信息，很明显效率就提高了。

图b中最明显的区别，也就是AcceptEx和传统的accept之间最大的区别，就是取消了阻塞方式的accept调用，也就是说，AcceptEx也是通过完成端口来异步完成的，所以就取消了专门用于accept连接的线程，用了完成端口来进行异步的AcceptEx调用；然后在检索完成端口队列的Worker函数中，根据用户投递的完成操作的类型，再来找出其中的投递的Accept请求，加以对应的处理。

读者一定会问，这样做的好处在哪里？为什么还要异步的投递AcceptEx连接的操作呢？

首先，我可以很明确的告诉各位，如果短时间内客户端的并发连接请求不是特别多的话，用accept和AcceptEx在性能上来讲是没什么区别的。

按照我们目前主流的PC来讲，如果客户端只进行连接请求，而什么都不做的话，我们的Server只能接收大约3万-4万个左右的并发连接，然后客户端其余的连入请求就只能收到WSAENOBUFS (10055)了，因为系统来不及为新连入的客户端准备资源了。

需要准备什么资源？当然是准备Socket了……虽然我们创建Socket只用一行SOCKET s= socket(…) 这么一行的代码就OK了，但是系统内部建立一个Socket是相当耗费资源的，因为Winsock2是分层的机构体系，创建一个Socket需要到多个Provider之间进行处理，最终形成一个可用的套接字。总之，系统创建一个Socket的开销是相当高的，所以用accept的话，系统可能来不及为更多的并发客户端现场准备Socket了。

而AcceptEx比Accept又强大在哪里呢？是有三点：

(1) 这个好处是最关键的，是因为AcceptEx是在客户端连入之前，就把客户端的Socket建立好了，也就是说，AcceptEx是先建立的Socket，然后才发出的AcceptEx调用，也就是说，在进行客户端的通信之前，无论是否有客户端连入，Socket都是提前建立好了；而不需要像accept是在客户端连入了之后，再现场去花费时间建立Socket。如果各位不清楚是如何实现的，请看后面的实现部分。

(2) 相比accept只能阻塞方式建立一个连入的入口，对于大量的并发客户端来讲，入口实在是有点挤；而AcceptEx可以同时在完成端口上投递多个请求，这样有客户端连入的时候，就非常优雅而且从容不迫的边喝茶边处理连入请求了。

(3) AcceptEx还有一个非常体贴的优点，就是在投递AcceptEx的时候，我们还可以顺便在AcceptEx的同时，收取客户端发来的第一组数据，这个是同时进行的，也就是说，在我们收到AcceptEx完成的通知的时候，我们就已经把这第一组数据接完毕了；但是这也意味着，如果客户端只是连入但是不发送数据的话，我们就不会收到这个AcceptEx完成的通知……这个我们在后面的实现部分，也可以详细看到。

最后，各位要有一个心里准备，相比accept，异步的AcceptEx使用起来要麻烦得多……

五． 完成端口的实现详解

又说了一节的废话，终于到了该动手实现的时候了……

这里我把完成端口的详细实现步骤以及会涉及到的函数，按照出现的先后步骤，都和大家详细的说明解释一下，当然，文档中为了让大家便于阅读，这里去掉了其中的错误处理的内容，当然，这些内容在示例代码中是会有的。
原文剩余部分链接
https://www.cnblogs.com/lancidie/archive/2011/12/19/2293773.html