select、poll、epoll对比总结

一、select和poll的缺点

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024），但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差
2. 内核和用户空间之间的内存拷贝问题，因为我们每次调用select和poll时。都会填写相应的位数组和其他的参数，select和poll需要复制大量的句柄数据结构到内核空间进行监听，监听完成后需要把发生事件句柄再拷贝到用户空间，会产生巨大的开销
3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件。poll和select一样，都是轮询
4. select和poll的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select和poll调用还是会将这些文件描述符通知进程。同一个事件，数据没有读完，会多次触发，效率低

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制（1024），但其他三个缺点依然存在

以select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，每个进程监听1024个连接，则我们至少需要开辟1k个进程才能实现100万的并发连接。一般来说，我们不会开启这么多进程或线程，除非是协程

除了进程间上下文切换的时间消耗外，从内核/用户空间大量的句柄结构内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到100万级别的并发访问，是一个很难完成的任务

二、epoll原理以及优势

epoll的实现机制与select/poll机制完全不同，它们的缺点在epoll上不复存在

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百个TCP连接是活跃的(事实上大部分场景都是这种情况)，如何实现这样的高并发？

在select / poll时代，服务器进程每次都把这100万个连接告诉操作系统（从用户态复制句柄数据结构到内核态），让操作系统内核去查询这些套接字上是否有事件发生，轮询完成后，再将句柄数据拷贝到用户空间，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此select/poll一般只能处理几千的并发连接

epoll的设计和实现与select完全不同，epoll通过在Linux内核中申请一个简易的文件系统（文件系统一般用B+树实现，磁盘IO消耗低，效率很高）

把原先的select/poll调用分成以下3个部分：

• 调用epoll_create()建立一个epoll对象（在epoll文件系统中为这个句柄对象分配资源）
• 调用epoll_ctl向epoll对象中添加这100万个连接的套接字，以红黑树的形式组织，增删查是$O(lo{g}_{2}n)$
• 调用epoll_wait收集发生的事件的fd资源，发生事件的fd会从红黑树上拷贝到双向链表，用于返回给用户。用户拿到的就只有发生事件的文件描述符了

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后向这个epoll对象中添加或者删除事件。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有向内核空间拷贝这100万个连接的句柄数据，因为前面通过epoll_ctl把感兴趣的句柄数据放在了内核的红黑树上。红黑树遍历是对数复杂度，内核也不需要去遍历全部的连接

epoll_create在内核上创建的eventpoll结构如下：

struct eventpoll{
	....
	/*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
	struct rb_root rbr;
	/*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
	struct list_head rdlist;
	....
};

网上文章不少说，epoll_wait 返回时，对于就绪的事件，epoll 使用的是共享内存的方式，即用户态和内核态都指向了就绪链表，所以就避免了内存拷贝消耗。

这是错的！看过 epoll 内核源码的都知道，压根就没有使用共享内存这个玩意。你可以从下面这份代码看到， epoll_wait 实现的内核代码中调用了 __put_user 函数，这个函数就是将数据从内核拷贝到用户空间

https://blog.csdn.net/gc348342215/article/details/122734781

epoll如何返回？

若往fd上注册了读事件，ET模式下，该fd对应的读缓冲区由空变为不空，epoll就会返回。LT模式下，只要读缓冲区中有数据，epoll就会返回。如果epoll一次返回，有多个fd都有数据可读，就说明这些数据在很短的时间间隔内一起到达，这个很短的时间间隔由内核控制

同理，若往fd上注册了写事件，ET模式下，该fd对应的写缓冲区由满变为不满，epoll就会返回。LT模式下，只要写缓冲区不满，epoll就会返回。

缓冲区本次没读完，下次数据再到达，前一次的数据会被覆盖吗？

经测试，无论是ET还是LT模式下，都不会覆盖。

在ET模式下，一条数据到达内核TCP缓冲区，内核只会给应用程序上报一次，如果应用程序没读完，待下一条数据到达TCP缓冲区时，内核会再次上报，此时还可以读取上一次没读完的数据

而在LT模式下，如果本次没读完，不用等到下一条数据到达，内核也会再次上报

三、LT模式（Level Trigger）

水平触发：fd对应的TCP缓冲区数据没被应用程序读完，就会一直上报

应用程序可以每次读一部分数据，没读完，下一次epoll_wait时内核还会上报。能够平均地处理每个socket上的读写事件，能够及时回到epoll_wait，让所有的socket都得到及时的处理，让客户端感觉服务器延时低

四、ET模式（Edge Trigger）

边沿触发：从不可读到可读，或者从不可写到可写，这个状态的变化，内核只上报一次。如果应用程序不读完、不写完，就不会再触发了，数据会丢失

我们可能会认为ET模式只触发一次，效率高，LT模式就没有存在的价值，其实不是这样的

在极端情况下，epoll工作在ET模式下，一个socket上产生源源不断的数据，由于本次不读完，下次到来的数据会覆盖没读完的数据，所以应用程序会循环读取。
由于应用程序会循环读取这个socket上的数据，这就导致应用程序无法及时回到epoll_wait。假如此时又有其他请求到了，红黑树上有一些fd发生了事件被放到双向链表返回给应用程序，而此时应用程序还在读某个socket上的数据，无法及时回到epoll_wait，对于客户端来说，服务器就没有及时处理它的请求，客户端会觉得服务器的延时很高

五、muduo采用的是LT

• 不会丢失数据或者消息：应用没有读取完数据，内核是会不断上报的
• 低延迟处理：每次读数据只需要一次系统调用；照顾了多个连接的公平性，不会因为某个连接上的数据量过大而影响其他连接处理消息
• 跨平台处理：像select一样可以跨平台使用。由于有的系统不支持ET模式，比如Unix/mac系统是没有epoll的，但是有select / poll，这俩都是工作在LT模式

libevent是一个C语言写的网络库，底层也是事件驱动，统一事件源的epoll，采用的是ET模式，从压测的结果来看，在单线程下，muduo库和libevent库的性能差不多，在多线程情况下，muduo库的吞吐量大致可以达到libevent的近2倍

六、总结

最基础的 TCP 的 Socket 编程，它是阻塞 I/O 模型，基本上只能一对一通信，那为了服务更多的客户端，我们需要改进网络 I/O 模型。

比较传统的方式是使用多进程/线程模型，每来一个客户端连接，就分配一个进程/线程，然后后续的读写都在对应的进程/线程，这种方式处理 100 个客户端没问题，但是当客户端增大到 10000 个时，10000 个进程/线程的调度、上下文切换以及它们占用的内存，都会成为瓶颈。

为了解决上面这个问题，就出现了 I/O 的多路复用，可以只在一个进程里处理多个文件的 I/O，Linux 下有三种提供 I/O 多路复用的 API，分别是：select、poll、epoll。

select 和 poll 并没有本质区别，它们内部都是使用「线性结构」来存储进程关注的 Socket 集合

在使用的时候，首先需要把关注的 Socket 集合通过 select/poll 系统调用从用户态拷贝到内核态，然后由内核检测事件，当有网络事件产生时，内核需要遍历进程关注 Socket 集合，找到对应的 Socket，并设置其状态为可读/可写，然后把整个 Socket 集合从内核态拷贝到用户态，用户态还要继续遍历整个 Socket 集合找到可读/可写的 Socket，然后对其处理。

很明显发现，select 和 poll 的缺陷在于，需要进行 2 次「遍历」文件描述符集合， 2 次「拷贝」文件描述符集合，当客户端越多，也就是 Socket 集合越大，Socket 集合的遍历和拷贝会带来很大的开销，因此也很难应对 C10K。

epoll 是解决 C10K 问题的利器，通过两个方面解决了 select/poll 的问题。

• epoll 在内核里使用 「红黑树」 来关注进程所有待检测的 Socket，红黑树是个高效的数据结构，增删改一般时间复杂度是 O(logn)，通过对这棵黑红树的管理，不需要像 select/poll 在每次操作时都传入整个 Socket 集合，减少了内核和用户空间大量的数据拷贝和内存分配。
• epoll 使用事件驱动的机制，内核里维护了一个「双向循环链表」来记录就绪事件，通过回调的方式将有事件发生的 Socket 集合传递给应用程序，不需要像 select/poll 那样轮询扫描整个集合（包含有和无事件的 Socket ），大大提高了检测的效率。
• epoll 支持边缘触发和水平触发的方式，而 select/poll 只支持水平触发，一般而言，边缘触发的方式会比水平触发的效率高。