网络编程学习(六)_epoll原理详细解析

一、Epoll原理详细解析

  如果对select、epoll模型一点概念都没有建议看以下博文，文章从网卡接收数据的流程讲起，串联起 CPU 中断、操作系统进程调度等知识;再一步步分析阻塞接收数据、Select 到 Epoll 的进化过程;最后探究 Epoll 的实现细节。

https://blog.csdn.net/armlinuxww/article/details/92803381?

二、select到epoll的进化

1、select 的问题

• select 的问题在于描述符的限制，能监控的文件描述符最大为 FD_SETSIZE，对于连接数很多的场景就无法满足；
• 另外select 还有一个问题是，每次调用 select 都需要从用户空间把描述符集合拷贝到内核空间，当描述符集合变大之后，用户空间和内核空间的内存拷贝会导致效率低下；
• 另外每次调用 select 都需要在内核线性遍历文件描述符的集合，当描述符增多，效率低下。

2、epoll的进化

• 针对第一点：如何突破文件描述符数量的限制，程序在内核空间开辟一块缓存，用来管理 epoll 红黑树，高效添加和删除socket
• 针对第二点：如何避免用户态和内核态对文件描述符集合的拷贝，其实对于 select 来说，由于这个集合是保存在用户态的，所以当调用
  select 时需要屡次的把这个描述符集合拷贝到内核空间。所以如果要解决这个问题，可以直接把这个集合放在内核空间进行管理。没错，epoll
  就是这样做的，epoll 在内核空间创建了一颗红黑树，应用程序直接把需要监控的 socket
  对象添加到这棵树上，直接从用户态到内核态了，而且后续也不需要再次拷贝了。
• 针对第三点：socket就绪后，如何避免内核线性遍历文件描述符集合， epoll 使用了一个双向链表来保存就绪的
  socket，这样当活跃连接数不多的情况下，应用程序只需要遍历这个就绪链表就行了。这里需要注意的是，这个就绪链表保存活跃链接，数量是较少的，也需要从内核空间拷贝到用户空间。

三、结合API解析epoll原理

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关，如下所示：

struct eventpoll {
　　…
　　/红黑树的根节点，这棵树中存储着所有添加到epoll中的事件，
　　也就是这个epoll监控的事件/
　　struct rb_root rbr;
　　/双向链表rdllist保存着将要通过epoll_wait返回给用户的、满足条件的事件/
　　struct list_head rdllist;
　　…
};

我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个rdllist双向链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个rdllist双向链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。

所有添加到epoll中的事件都会与设备(如网卡)驱动程序建立回调关系，也就是说相应事件的发生时会调用这里的回调方法。这个回调方法在内核中叫做ep_poll_callback，它会把这样的事件放到上面的rdllist双向链表中。

在epoll中对于每一个事件都会建立一个epitem结构体，如下所示：

struct epitem {
　　…
　　//红黑树节点
　　struct rb_node rbn;
　　//双向链表节点
　　struct list_head rdllink;
　　//事件句柄等信息
　　struct epoll_filefd ffd;
　　//指向其所属的eventepoll对象
　　struct eventpoll *ep;
　　//期待的事件类型
　　struct epoll_event event;
　　…
}; // 这里包含每一个事件对应着的信息。

当调用epoll_wait检查是否有发生事件的连接时，只是检查eventpoll对象中的rdllist双向链表是否有epitem元素而已，如果rdllist链表不为空，则这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此epoll_waitx效率非常高。epoll_ctl在向epoll对象中添加、修改、删除事件时，从rbr红黑树中查找事件也非常快，也就是说epoll是非常高效的，它可以轻易地处理百万级别的并发连接。

执行epoll_create()时 epoll 在内核开辟了一块缓存，创建了一颗红黑树(缓存所有的 socket，支持 O(log(n)) 的插入和查找)以及一个就绪的双向链表（当然还有其他的成员）

执行epoll_ctl()时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据；

执行epoll_wait()时立刻返回准备就绪链表里的数据即可。

三、epoll的两种触发模式

epoll有EPOLLLT和EPOLLET两种触发模式，LT是默认的模式，ET是“高速”模式。

LT（水平触发）模式下，只要这个文件描述符还有数据可读，每次 epoll_wait都会返回它的事件，提醒用户程序去操作；

ET（边缘触发）模式下，在它检测到有 I/O 事件时，通过 epoll_wait 调用会得到有事件通知的文件描述符，对于每一个被通知的文件描述符，如可读，则必须将该文件描述符一直读到空，让 errno 返回 EAGAIN 为止，否则下次的 epoll_wait 不会返回余下的数据，会丢掉事件。如果ET模式不是非阻塞的，那这个一直读或一直写势必会在最后一次阻塞。

还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

【epoll为什么要有EPOLLET触发模式？】：

如果采用EPOLLLT模式的话，系统中一旦有大量你不需要读写的就绪文件描述符，它们每次调用epoll_wait都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的效率.。而采用EPOLLET这种边缘触发模式的话，当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你！！！这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符。

【总结】：

ET模式（边缘触发）只有数据到来才触发，不管缓存区中是否还有数据，缓冲区剩余未读尽的数据不会导致epoll_wait返回；

LT 模式（水平触发，默认）只要有数据都会触发，缓冲区剩余未读尽的数据会导致epoll_wait返回。