IO多路复用、 Epoll（二）

先看这几个问题

进程阻塞为什么不占用CPU资源?

  网络数据流通过硬件传输，网卡接收的数据存放到内存中。操作系统就可以去读取它们。一般而言，由硬件产生的信号需要CPU立马做

出回应（不然数据可能就丢失），所以它的优先级很高。CPU理应中断掉正在执行的程序，去做出响应；当CPU完成对硬件CPU的响应后，

再重新执行用户程序。

  当网卡把数据写入到内存后，网卡向cpu发出一个中断信号，操作系统便能得知有新数据到来，再通过网卡中断程序去处理数据。

  比如服务器端运行到 recv() 函数的时候，如果对端没有数据发送过来，那么程序会一直阻塞在这里，其实操作系统为了支持多任务，实

现了进程调度的功能，会把进程分为 运行 和 等待 。。。几种状态，行状态是进程获得cpu使用权，正在执行代码的状态；等待状态是阻

塞状态，比如上述程序运行到 recv 时，程序会从运行状态变为等待状态，接收到数据后又变回运行状态。操作系统会分时执行各个运行状

态的进程，由于速度很快，看上去就像是同时执行多个任务。
  
  

等待队列

（1）创建socket :当进程A执行到创建socket的语句时，操作系统会创建一个由文件系统管理的 socket对象（如下图）。这个socket对象包

含了发送缓冲区、接收缓冲区、等待队列等成员。等待队列是个非常重要的结构，它指向所有需要等待该socket事件的进程。

(2) socket的等待队列：

  当程序执行到recv时，操作系统会将进程A从工作队列移动到该socket的等待队列中（如下图）。由于工作队列只剩下了进程B和C，依

据进程调度，cpu会轮流执行这两个进程的程序，不会执行进程A的程序。所以进程A被阻塞，不会往下执行代码，也不会占用cpu资源。

  操作系统添加等待队列只是添加了对这个“等待中”进程的引用，以便在接收到数据时获取进程对象、将其唤醒，而非直接将进程管理纳

入自己之下。

 
 
 

唤醒进程

  当socket接收到数据后，操作系统将该socket等待队列上的进程重新放回到工作队列，该进程变成运行状态(当socket事件触发是，也就

是有数据到来，会取下一个进程结构调用其回调，将其挂到工作队列中),继续执行代码。同时也由于socket的接收缓冲区已经有了数据，recv

可以返回接收到的数据。

这一步，贯穿网卡、中断、进程调度的知识，叙述阻塞recv下，内核接收数据全过程。

进程在recv阻塞期间，计算机收到了对端传送的数据（步骤①）。
          数据经由网卡传送到内存（步骤②），
          然后网卡通过中断信号通知cpu有数据到达，cpu执行中断程序（步骤③）。
          此处的中断程序主要有两项功能，先将网络数据写入到对应socket的接收缓冲区里面（步骤④），
          再唤醒进程A（步骤⑤），重新将进程A放入工作队列中。

唤醒进程的过程如下图所示

  
 
  客户端 服务器端 靠socket连接，监听socket相当于监听文件描述符，这时候就回到 如何监听多个文件描述符的问题 ? ，服务端需要

管理多个客户端连接，而recv只能监视单个socket，使用IO多路复用，就可以监听多个 socket

  IO多路复用的方法用三种：select、poll、epoll，是逐步发展的，现在主流是 epoll ，select的实现思路很直接。假如程序同时监视如下

图的sock1、sock2和sock3三个socket，那么在调用select之后，操作系统把进程A（包括了select逻辑）分别加入这三个socket的等待队列

中（前文说过，放的其实是进程A的引用）。

 
 

select的流程

   假如能够预先传入一个socket列表，如果列表中的socket都没有数据，挂起进程，直到有一个socket收到数据，唤醒进程。这种方法很

直接，也是select的设计思想。

   为方便理解，我们先复习select的用法。在如下的代码中，先准备一个数组（下面代码中的fds），让fds存放着所有需要监视的

socket。然后调用select，如果fds中的所有socket都没有数据，select会阻塞，直到有一个socket接收到数据，select返回，唤醒进程。用户

可以遍历fds，通过FD_ISSET判断具体哪个socket收到数据，然后做出处理。

int s = socket(AF_INET, SOCK_STREAM, 0);  
bind(s, ...)
listen(s, ...)

int fds[] =  存放需要监听的socket

while(1){
    int n = select(..., fds, ...)
    for(int i=0; i < fds.count; i++){
        if(FD_ISSET(fds[i], ...)){
            //fds[i]的数据处理
        }
    }
}

   select的实现思路很直接。假如程序同时监视如下图的sock1、sock2和sock3三个socket，那么在调用select之后，操作系统把进程A分

别加入这三个socket的等待队列中。

 
 
 
当任何一个socket收到数据后，中断程序将唤起进程。下图展示了sock2接收到了数据的处理流程。

 
 
 
所谓唤起进程，就是将进程从所有的 等待队列 中移除，加入到工作队列里面。如下图所示。

  经由这些步骤，当 进程A 被唤醒后，它知道至少有一个 socket (socket1、socket2、socket3其中的) 接收了数据。程序只需遍历一遍

socket列表，就可以得到就绪的socket。

  这种简单方式行之有效，在几乎所有操作系统都有对应的实现。

工作流程如下图：

select的缺点

 
 
但是简单的方法往往有缺点，主要是：
 
 
其一，每次调用select都需要将进程加入到所有监视socket的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历（遍历进程A关心的所有socket，需要注意的是添加从等待队列头部添加，删除通过回调直接实现，所以每个socket的等待队列不用遍历），而且每次都要将整个fds列表传递给内核，有一定的开销。正是因为遍历操作开销大，出于效率的考量，才会规定select的最大监视数量，默认只能监视1024个socket。
 
 
其二，进程被唤醒后，程序并不知道哪些socket收到数据，还需要遍历一次（这一次遍历是在 应用层 ）。那么，有没有减少遍历的方法？有没有保存就绪socket的方法？这两个问题便是epoll技术要解决的。当程序调用select时，内核会先遍历一遍socket，如果有一个以上的socket接收缓冲区有数据，那么select直接返回，不会阻塞。这也是为什么select的返回值有可能大于1的原因之一。如果没有socket有数据，进程才会阻塞。
 
 
 

epoll的设计思路

epoll是在select出现N多年后才被发明的，是select和poll的增强版本。epoll通过以下一些措施来改进效率。

措施一：功能分离

select低效的原因之一是将“维护等待队列”和“阻塞进程”两个步骤合二为一。如下图所示，每次调用select都需要这两步操作，然而大多数应

用场景中，需要监视的socket相对固定，并不需要每次都修改。epoll将这两个操作分开，先用epoll_ctl维护等待队列，再调用epoll_wait阻塞

进程（解耦）。显而易见的，效率就能得到提升。

措施二： 就绪列表

select低效的另一个原因在于程序不知道哪些socket收到数据，只能一个个遍历。如果内核维护一个“就绪列表”，引用收到数据的socket，就

能避免遍历。如下图所示，计算机共有三个socket，收到数据的sock2和sock3被rdlist（就绪列表）所引用。当进程被唤醒后，只要获取rdlist

的内容，就能够知道哪些socket收到数据。

 
 

epoll的原理和流程

 

创建epoll对象

  当某个进程调用epoll_create方法时，内核会创建一个eventpoll对象（也就是程序中epfd所代表的对象）。eventpoll对象也是文件系统

中的一员，和socket一样，它也会有等待队列（有线程会等待其事件触发，比如调用epoll_wait的线程就会阻塞在其上）

创建一个代表该epoll的eventpoll对象是必须的，因为内核要维护 “就绪列表” 等数据， “就绪列表” 可以作为eventpoll的成员。
 
 

维护监视列表

创建epoll对象后，可以用epoll_ctl添加或删除所要监听的socket。以添加socket为例，如下图，如果通过epoll_ctl添加sock1、sock2和sock3

的监视，内核会将eventpoll添加到这三个socket的等待队列中。

当socket收到数据后，中断程序会操作eventpoll对象，而不是直接操作进程（也就是调用epoll的进程）

 
 

接收数据

  当socket收到数据后，中断程序会给eventpoll的“就绪列表”添加socket引用。如下图展示的是sock2和sock3收到数据后，中断程序让

rdlist引用这两个socket。

  eventpoll对象相当于是socket和进程之间的中介，socket的数据接收并不直接影响进程，而是通过改变eventpoll的就绪列表来改变进程

状态。当程序执行到epoll_wait时，如果rdlist已经引用了socket，那么epoll_wait直接返回，如果rdlist为空，阻塞进程。这里可以看博客

Epoll总结，ET和LT模式、Epoll(一)
 
 
 

阻塞和唤醒进程

  假设计算机中正在运行进程A和进程B，在某时刻进程A运行到了 epoll_wait 语句。如下图所示，内核会将进程A放入eventpoll的等待

队列中，阻塞当前进程。

    
  
  
  
  当socket接收到数据，中断程序一方面修改rdlist，另一方面唤醒eventpoll等待队列中的进程，进程A再次进入运行状态（如下图）。也

因为 rdlist 的存在，进程A可以知道哪些socket发生了变化。

 

epoll唤醒进程
流程图如下

epoll初始化时，内核开辟了epoll缓冲区，缓冲区内事件以epitem结点挂载到红黑树上，通过epoll_ctl的任何操作都是O(logN)

向内核中断处理注册回调，一旦关心的事件触发，回调自动将socket对应的epitem添加到rdlist中
 

 

epoll的实现细节

至此，相信读者对epoll的本质已经有一定的了解。但我们还留有一个问题，eventpoll的数据结构是什么样子?

就绪队列应该应使用什么数据结构？

eventpoll 应使用什么数据结构来管理通过epoll_ctl添加或删除的socket？

struct eventpoll {
	 spinlock_t lock;
	 struct mutexmtx;
	 wait_queue_head_t wq;
	 wait_queue_head_t poll_wait;
	 struct list_headrdllist;
	 struct rb_rootrbr;
	 struct epitem *ovflist;
	 struct user_struct *user;
	 struct file *file;
	 int visited;
	 structl ist_headvisited_list_link;
};

如下图所示，eventpoll包含了 lock、mtx、wq（等待队列）、rdlist等成员。rdlist 和 rbr 是我们所关心的

注解： eventpoll 的结构体中rdllist 和rbr  与  epitem 结构体中的 rdllink和 rbn 相关，这里我也没太明白，估计应该是某种引用，所以说红黑树中每个节点都是基于 epitem 结构中的 rdllink 成员，也是基于 rbn 成员

 
 
sys_epoll_ctl()最终会调用ep_insert()把文件句柄fd添加到eventpoll结构维护的红黑树中

使用红黑树管理epitem结构的目的是可以根据文件句柄fd快速查找到对应的epitem结构。红黑树是一棵平衡二叉树，时间复杂度为O(logN)。

 
 

添加以及返回事件

  通过epoll_ctl函数添加进来的事件都会被放在红黑树的某个节点内，所以，重复添加是没有用的。当把事件添加进来的时候时候会完成关键的一步，那就是该事件都会与相应的设备（网卡）驱动程序建立回调关系，当相应的事件发生后，就会调用这个回调函数，该回调函数在内核中被称为：ep_poll_callback,这个回调函数其实就所把这个事件添加到rdllist这个双向链表中。一旦有事件发生，epoll就会将该事件添加到双向链表中。那么当我们调用epoll_wait时，epoll_wait只需要检查rdllist双向链表中是否有存在注册的事件，效率非常可观。这里也需要将发生了的事件复制到用户态内存中即可。
 
 
 
  ep_poll()函数所做的事情很简单，就是把当前进程设置为可中断睡眠状态，然后添加eventpoll结构的等待队列中，最后调用schedule_timeout()让出CPU。这样当前进程就会进入睡眠状态，当进程醒来的时候会判断eventpoll结构的rdllist队列是否为空，然后不为空就调用ep_send_events()函数把可读写的文件拷贝到用户态的events数组中。

  那么什么时候当前进程会被唤醒呢？在分析ep_insert()函数的时候，我们提及过当文件状态发生改变时会调用ep_poll_callback()函数，而ep_poll_callback()函数会把就绪的文件添加到rdllist队列，并且就会把当前进程唤醒。
 
 
 
 
 
就绪列表(rdllist)的数据结构

就绪列表引用着就绪的socket，所以它应能够快速的插入数据。

程序可能随时调用 epoll_ctl 添加监视socket，也可能随时删除。当删除时，若该socket已经存放在就绪列表中，它也应该被移除。（事实

上，每个epoll_item既是红黑树节点，也是链表节点，删除红黑树节点，自然删除了链表节点）

所以就绪列表应是一种能够快速插入和删除的数据结构。双向链表就是这样一种数据结构，epoll使用双向链表来实现就绪队列（对应上图的

rdlist）。

 
 
索引结构

既然epoll 将 “维护监视队列” 和“ 进程阻塞” 分离，也意味着需要有个数据结构来保存监视的socket。至少要方便的添加和移除，还要便于搜

索，以避免重复添加。红黑树是一种自平衡二叉查找树，搜索、插入和删除时间复杂度都是O(log(N))，效率较好。epoll使用了红黑树作为索

引结构（对应上图的 rbr ）。

 
因为操作系统要兼顾多种功能，以及由更多需要保存的数据，rdllwist 并非直接引用 socket，而是通过epitem间接引用，红黑树的节点也是

epitem 对象。同样，文件系统也并非直接引用着socket。为方便理解，本文中省略了一些间接结构。
 
 

 
 
 

select、poll和epoll的区别

  I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。select，poll，epoll都是IO多路复用的机制。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。下来，分别谈谈。

 
 
 

select——>
原理概述：

  select 的核心功能是调用tcp文件系统的poll函数，不停的查询，如果没有想要的数据，主动执行一次调度（防止一直占用cpu），直到有一个连接有想要的消息为止。从这里可以看出select的执行方式基本就是不同的调用poll,直到有需要的消息为止。
缺点：

1、每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大；

2、同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大；

3、select支持的文件描述符数量太小了，默认是1024。

优点：

1、select的可移植性更好，在某些Unix系统上不支持poll()。

2、select对于超时值提供了更好的精度：微秒，而poll是毫秒。

poll——>

原理概述：

  poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

缺点：

1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义；

2、与select一样，poll返回后，需要轮询pollfd来获取就绪的描述符。

优点：

1、poll() 不要求开发者计算最大文件描述符加一的大小。

2、poll() 在应付大数目的文件描述符的时候速度更快，相比于select。

3、它没有最大连接数的限制，原因是它是基于链表来存储的。
 
 

epoll——>
原理概述：

  epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时， 返回的不是实际的描述符，而是一个代表就绪描述符数量的值，你只需要去epoll指定的一 个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射技术，这 样便彻底省掉了这些文件描述符在系统调用时复制的开销。

epoll的优点就是改进了前面所说缺点：

1、支持一个进程打开大数目的socket描述符：相比select，epoll则没有对FD的限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

2、IO效率不随FD数目增加而线性下降：epoll不存在这个问题，它只会对"活跃"的socket进行操作— 这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的—比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

3、使用mmap加速内核与用户空间的消息传递：这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就 很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。

三者对比与区别：
1、select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

2、select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
 
 
 
 
  等待列表中的进程，我的理解是系统每次有空闲进程，就将其放入等待列表中阻塞，epoll_wait有一个time_out参数，在这个等待时间time里，如果就绪队列有socket需要处理，就调用阻塞的进程运行，如果一直为空，当计时器到了，进程变为非阻塞继续去干活。
  其实还要区分的就是哪些事情是操作系统做的（进程调度、epoll功能的实现），哪些事情是用户自己写是（调用epoll_wait…）。像“中断系统里注册一个监听回调函数”都是操作系统做的事情。
 
 
 

向内核中断处理注册回调，一旦关心的事件触发，回调自动将socket对应的epitem添加到rdlist中
 
 
 
 
 

参考资料
如果这篇文章说不清epoll的本质，那就过来掐死我吧！ （1）
硬核分享，（最全）TCP/IP协议栈，epoll的内部实现原理

Epoll的实现原理，了解epoll高效背后的魔法