[转]IOCP模型与EPOLL模型的比较

http://www.cnblogs.com/lancidie/archive/2013/05/02/3054063.html

一：IOCP和Epoll之间的异同。
异：
1：IOCP是WINDOWS系统下使用。Epoll是Linux系统下使用。
2：IOCP是IO操作完毕之后，通过Get函数获得一个完成的事件通知。
Epoll是当你希望进行一个IO操作时，向Epoll查询是否可读或者可写，若处于可读或可写状态后，Epoll会通过epoll_wait进行通知。
3：IOCP封装了异步的消息事件的通知机制，同时封装了部分IO操作。但Epoll仅仅封装了一个异步事件的通知机制，并不负责IO读写操作。Epoll保持了事件通知和IO操作间的独立性，更加简单灵活。
4： 基于上面的描述，我们可以知道Epoll不负责IO操作，所以它只告诉你当前可读可写了，并且将协议读写缓冲填充，由用户去读写控制，此时我们可以做出额 外的许多操作。IOCP则直接将IO通道里的读写操作都做完了才通知用户，当IO通道里发生了堵塞等状况我们是无法控制的。

同：
1：它们都是异步的事件驱动的网络模型。
2：它们都可以向底层进行指针数据传递，当返回事件时，除可通知事件类型外，还可以通知事件相关数据。

二：描述一下IOCP:
扯远点。首先传统服务器的网络IO流程如下：
接到一个客户端连接->创建一个线程负责这个连接的IO操作->持续对新线程进行数据处理->全部数据处理完毕->终止线程。
但是这样的设计代价是：
1：每个连接创建一个线程，将导致过多的线程。
2：维护线程所消耗的堆栈内存过大。
3：操作系统创建和销毁线程过大。
4：线程之间切换的上下文代价过大。
此时我们可以考虑使用线程池解决其中3和4的问题。这种传统的服务器网络结构称之为会话模型。
后来我们为防止大量线程的维护，创建了I/O模型，它被希望要求可以:
1：允许一个线程在不同时刻给多个客户端进行服务。
2：允许一个客户端在不同时间被多个线程服务。
这样做的话，我们的线程则会大幅度减少，这就要求以下两点：
1：客户端状态的分离，之前会话模式我们可以通过线程状态得知客户端状态，但现在客户端状态要通过其他方式获取。
2：I/O请求的分离。一个线程不再服务于一个客户端会话，则要求客户端对这个线程提交I/O处理请求。
那么就产生了这样一个模式，分为两部分:
1：会话状态管理模块。它负责接收到一个客户端连接，就创建一个会话状态。
2：当会话状态发生改变，例如断掉连接，接收到网络消息，就发送一个I/O请求给 I/O工作模块进行处理。
3：I/O工作模块接收到一个I/O请求后，从线程池里唤醒一个工作线程，让该工作线程处理这个I/O请求，处理完毕后，该工作线程继续挂起。
上面的做法，则将网络连接 和I/O工作线程分离为两个部分，相互通讯仅依靠 I/O请求。
此时可知有以下一些建议：
1：在进行I/O请求处理的工作线程是被唤醒的工作线程，一个CPU对应一个的话，可以最大化利用CPU。所以 活跃线程的个数 建议等于 硬件CPU个数。
2：工作线程我们开始创建了线程池，免除创建和销毁线程的代价。因为线程是对I/O进行操作的，且一一对应，那么当I/O全部并行时，工作线程必须满足I/O并行操作需求，所以 线程池内最大工作线程个数 建议大于或者等于 I/O并行个数。
3：但是我们可知CPU个数又限制了活跃的线程个数，那么线程池过大意义很低，所以按常规建议 线程池大小 等于 CPU个数*2 左右为佳。例如，8核服务器建议创建16个工作线程的线程池。
上面描述的依然是I/O模型并非IOCP，那么IOCP是什么呢，全称 IO完成端口。
它是一种WIN32的网络I/O模型，既包括了网络连接部分，也负责了部分的I/O操作功能，用于方便我们控制有并发性的网络I/O操作。它有如下特点：
1：它是一个WIN32内核对象，所以无法运行于Linux.
2：它自己负责维护了工作线程池，同时也负责了I/O通道的内存池。
3：它自己实现了线程的管理以及I/O请求通知，最小化的做到了线程的上下文切换。
4：它自己实现了线程的优化调度，提高了CPU和内存缓冲的使用率。
使用IOCP的基本步骤很简单：
1：创建IOCP对象，由它负责管理多个Socket和I/O请求。CreateIoCompletionPort需要将IOCP对象和IOCP句柄绑定。
2：创建一个工作线程池，以便Socket发送I/O请求给IOCP对象后，由这些工作线程进行I/O操作。注意，创建这些线程的时候，将这些线程绑定到IOCP上。
3：创建一个监听的socket。
4：轮询，当接收到了新的连接后，将socket和完成端口进行关联并且投递给IOCP一个I/O请求。注意：将Socket和IOCP进行关联的函数和创建IOCP的函数一样，都是CreateIoCompletionPort，不过注意传参必然是不同的。
5：因为是异步的，我们可以去做其他，等待IOCP将I/O操作完成会回馈我们一个消息，我们再进行处理。
其中需要知道的是：I/O请求被放在一个I/O请求队列里面，对，是队列，LIFO机制。当一个设备处理完I/O请求后，将会将这个完成后的I/O请求丢回IOCP的I/O完成队列。
我们应用程序则需要在GetQueuedCompletionStatus去询问IOCP，该I/O请求是否完成。
其中有一些特殊的事情要说明一下，我们有时有需要人工的去投递一些I/O请求，则需要使用PostQueuedCompletionStatus函数向IOCP投递一个I/O请求到它的请求队列中。