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请求到它的请求队列中。

三：网络游戏服务器注意事项，优化措施
1：IO操作是最大的性能消耗点，注意优化余地很大。
2：算法数据结构。排序寻路算法的优化。list,vector,hashmap的选择。大数据寻址，不要考虑遍历，注意考虑hash.
3：内存管理。重载new/delete，内存池，对象池的处理。
4：数据的提前准备和即时计算。
5：CPU方面的统计监视。逻辑帧计数（应当50ms以内）。
6：预分配池减少切换和调度，预处理的线程池和连接池等。
7：基与消息队列的统计和信息监视框架。
8：CPU消耗排名：第一AOI同步，第二网络发包I/O操作，第三技能/BUFF判定计算处理，第四定时器的频率。
9：内存泄露检测，内存访问越界警惕，内存碎片的回收。
10：内存消耗排名：第一玩家对象包括其物品，第二网络数据缓冲。
11：注意32位和64位的内存容错。
12：减少不必要的分包发送。
13：减少重复包和重拷贝包的代价。
14：建议分紧急包（立刻发送）和非紧急包（定时轮训发送）。
15：带宽消耗排名：第一移动位置同步，第二对象加载，第三登陆突发包，第四状态机定时器消息。
16：客户端可做部分预判断机制，部分操作尽量分包发送。
17：大量玩家聚集时，部分非紧急包进行丢弃。
18：注意数据库单表内key数量。
19：活跃用户和非活跃用户的分割存取处理。
20：控制玩家操作对数据库的操作频率。
21：注意使用共享内存等方式对数据进行安全备份存储。
22：注意安全策略，对内网进行IP检查，对日志进行记录，任意两环点内均使用加密算法会更佳。
23：实时注意对网关，数据库等接口进行监察控制。
24：定时器应当存储一个队列，而非单向定位。
25：九宫格数据同步时，不需要直接进行九宫格的同步，对角色加一个AOI，基于圆方碰撞原理，抛弃不必要的格信息，可大幅节省。
26：客户端做部分的预测机制，服务器检测时注意时间戳问题。
27：定期心跳包，检查死链接是必要的。
28：为了实现更加负责多种类的AI，AI寻路独立服务器设计已经是必须的了。其次需要考虑的是聊天，同步。
29：服务器内网间可以考虑使用UDP。
30：注意所有内存池，对象池等的动态扩张分配。

1：以内存换取CPU的理念。
2：NPC不死理念。(只会disable)
3：动态扩展理念，负载均衡理念。
4：客户端不可信理念。
5：指针数据，消息均不可信理念。