epoll和select I/O模型研究

水平触发和边缘触发

这两种触发方式是I/O模型中常见的事件触发方式，所以这里有必要提一下两者的区别，这两个词来源于计算机硬件设计。它们的区别是只要句柄满足某种状态，水平触发就会发出通知；而只有当句柄状态改变时，边缘触发才会发出通知。例如一个socket经过长时间等待后接收到一段100k的数据，两种触发方式都会向程序发出就绪通知。假设程序从这个socket中读取了50k数据，并再次调用监听函数，水平触发依然会发出就绪通知，而边缘触发会因为socket“有数据可读”这个状态没有发生变化而不发出通知且陷入长时间的等待。

因此在使用边缘触发的 api 时，要注意每次都要读到 socket返回 EWOULDBLOCK为止。

select模型

select诞生于4.2BSD，在几乎所有平台上都支持，其良好的跨平台支持是它的主要的也是为数不多的优点之一。

select的缺点：

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；
2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

poll

poll 诞生于UNIX System V Release 3，那时AT&T已经停止了UNIX的源代码授权，所以显然也不会直接使用BSD的select，所以AT&T自己实现了一个和select没有多大差别的poll。

poll和select是名字不同的孪生兄弟，除了没有监视文件数量的限制，poll使用链表保存文件描述符，所以可以没有限制，select后面3条缺点同样适用于poll。

epoll

epoll诞生于Linux 2.6内核，被公认为是Linux2.6下性能最好的多路IO复用方法。

epoll的特点：

1.  Epoll 没有最大并发连接的限制，上限是最大可以打开文件的数目，这个数字一般远大于 2048, 一般来说这个数目和系统内存关系很大 ，具体数目可以 cat /proc/sys/fs/file-max 察看；
2. 效率提升， Epoll 最大的优点就在于它只管“活跃”的连接 ，而跟连接总数无关，因此在实际的网络环境中， Epoll 的效率就会远远高于 select 和 poll ；
3. 内存拷贝， Epoll 在这点上使用了“共享内存 ”，这个内存拷贝也省略了。

epoll的接口，epoll的接口非常简单，就三个函数：

1. int epoll_create(int size)；

创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：

• EPOLL_CTL_ADD：注册新的fd到epfd中；
• EPOLL_CTL_MOD：修改已经注册的fd的监听事件；
• EPOLL_CTL_DEL：从epfd中删除一个fd；

第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：

struct epoll_event {

__uint32_t events; /* Epoll events */

epoll_data_t data; /* User data variable */

};

events可以是以下几个宏的集合：

• EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
• EPOLLOUT：表示对应的文件描述符可以写；
• EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
• EPOLLERR：表示对应的文件描述符发生错误；
• EPOLLHUP：表示对应的文件描述符被挂断；
• EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
• EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里
  

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

等待事件的产生，类似于select()调用。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。

通过上述的分析得出select 比 epoll效率差的原因: select是轮询、epoll是触发式的，所以epoll效率高。

select 模式低效是由select的定义所决定的，与操作系统实现无关，任何内核在实现select时必须做轮循，才能知道这些socket的情况，这是会消耗 cpu的。此外，当你拥有一个很大socket集的时候，尽管任一时间只有小部分的socket是"活跃"的，但每次你都不得不将所有的socket填入到一个FD_SET中，这也会消耗一些cpu，并且当select返回后，处理业务时你可能还需要做“上下文映射”，同样也会有一些性能影响，因此 select比epoll相对低效。
epoll的适用情景就是大量的socket，但是活跃多不是很高的情况。