IOCP模型与EPOLL模型的比较
by 项籍 / 生活 · 记录 /

一: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):指针数据,消息均不可信理念。