关于epoll的ET和LT模型的相关知识点汇总

以下均来自网络，但是文章抄来抄去连几个错别字都懒的矫正，实在看不下去，自己再在这里汇总以下。

epoll是Linux下的一个多路复用API，当处理大并发的事件时，其性能远强于古老的poll和select。epoll可以工作在两种模式下，LT（水平触发）、ET（边缘触发），接下来将讨论这两种模式的区别。

ET（边缘触发）和LT（水平触发）

---

默认情况下，epoll采用LT模式工作，该模式支持阻塞和非阻塞套接字，如果想采用ET模式，可以使用EPOLLET参数。ET模式只支持非阻塞套接字，其效率要高于LT模式，两者的区别在于，当一个新的事件到来时，LT、ET模式下都可以通过epoll_wait方法来获取到这个事件，但是如果这次没有把这个事件对应的套接字缓冲区处理完，在这个套接字没有新的事件再次到来时，在ET模式下是无法再次从epoll_wait方法中获取到这个事件的；而LT模式则可以再次获取到，进而再次进行处理，其只要一个事件对应的套接字缓冲区还有数据，就总能从epoll_wait中获取到这个事件，因此，如果采用ET模式进行开发时，要特别注意，如果没有彻底的将缓冲区中的数据处理完，则会导致缓冲区中的用户请求得不到响应。

（来自：https://zhongwuzw.github.io/2016/09/21/epoll%E7%9A%84%E4%B8%A4%E7%A7%8D%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F/）

 

Epoll之ET、LT模式

在使用epoll时，在函数 epoll_ctl中如果不设定，epoll_event 的event默认为LT（水平触发）模式。

使用LT模式意味着只要fd处于可读或者可写状态，每次epoll_wait都会返回该fd，这样的话会带来很大的系统开销，且处理时候每次都需要把这些fd轮询一遍，如果fd的数量巨大，不管有没有事件发生，epoll_wait都会触发这些fd的轮询判断。

         在ET模式下，当有事件发生时，系统只会通知你一次，即在调用epoll_wait返回fd后，不管这个事件你处理还是没处理，处理完没有处理完，当再次调用epoll_wait时，都不会再返回该fd，这样的话程序员要自己保证在事件发生时要及时有效的处理完该事件。例如：fd发生了IN事件，在调用epoll_wait后发现了该事件，程序员要保证在本次轮询中对该fd做了读操作，且还要循环调用recv操作，直到读到的recv的返回值小于请求值，或者遇到EAGAIN错误，否则，在下次轮询时，如果该fd没有再次触发事件，你就没有机会知道这个fd需要处理。这样就会增加程序员的负担和出错的机会（可能有些数据没有来得及处理，丢失数据）。

         在LT模式下，无论fd是否有事件发生，或者还有一些事件没有处理完，每次调用epoll_wait时，总会得到该fd让你处理（只要有没事件没有处理，会一直通知你处理，直到你处理完为止，这样就保证了数据的不丢失）。

         操作系统在LT模式下维护的就绪队列大小相对于ET模式肯定大，且LT轮询所有的fd总比ET轮询的fd大。自然在性能上LT不如ET，但是在使用ET模式的时，需要循环调用recv,send等处理函数，得保证其事件处理完毕，这样也会带来开销且容易出错。

从 kernel 代码来看，ET/LT模式的处理逻辑几乎完全相同，差别仅在于 LT模式在 event 发生时不会将其从 ready list 中移除，略为增大了event 处理过程中 kernel space 中记录数据的大小。

 

总结：

1. epoll 的 ET和 LT 模式处理逻辑差异极小，性能测试结果表明常规应用场景中二者性能差异可以忽略。
2. 使用 ET 的程序比使用LT 的逻辑复杂，出错概率更高。
3. ET 和LT 的性能差异主要在于 epoll_wait 系统调用的处理速度，是否是程序的性能瓶颈需要视应用场景而定，不可一概而论。

个人建议使用LT模式

 

 

epoll LT/ET 深入剖析（讲的不错）

EPOLL事件有两种模型：

Level Triggered (LT) 水平触发
.socket接收缓冲区不为空 有数据可读 读事件一直触发
.socket发送缓冲区不满 可以继续写入数据 写事件一直触发
符合思维习惯，epoll_wait返回的事件就是socket的状态

Edge Triggered (ET) 边沿触发
.socket的接收缓冲区状态变化时触发读事件，即空的接收缓冲区刚接收到数据时触发读事件
.socket的发送缓冲区状态变化时触发写事件，即满的缓冲区刚空出空间时触发读事件
仅在状态变化时触发事件

ET还是LT?

LT的处理过程：
. accept一个连接，添加到epoll中监听EPOLLIN事件
. 当EPOLLIN事件到达时，read fd中的数据并处理
. 当需要写出数据时，把数据write到fd中；如果数据较大，无法一次性写出，那么在epoll中监听EPOLLOUT事件
. 当EPOLLOUT事件到达时，继续把数据write到fd中；如果数据写出完毕，那么在epoll中关闭EPOLLOUT事件

ET的处理过程：
. accept一个一个连接，添加到epoll中监听EPOLLIN|EPOLLOUT事件
. 当EPOLLIN事件到达时，read fd中的数据并处理，read需要一直读，直到返回EAGAIN为止
. 当需要写出数据时，把数据write到fd中，直到数据全部写完，或者write返回EAGAIN
. 当EPOLLOUT事件到达时，继续把数据write到fd中，直到数据全部写完，或者write返回EAGAIN

从ET的处理过程中可以看到，ET的要求是需要一直读写，直到返回EAGAIN，否则就会遗漏事件。而LT的处理过程中，直到返回EAGAIN不是硬性要求，但通常的处理过程都会读写直到返回EAGAIN，但LT比ET多了一个开关EPOLLOUT事件的步骤

LT的编程与poll/select接近，符合一直以来的习惯，不易出错
ET的编程可以做到更加简洁，某些场景下更加高效，但另一方面容易遗漏事件，容易产生bug

（来自：https://segmentfault.com/a/1190000004597522）

【这段话的讲解和这里差不多：https://juejin.im/post/6844903878685622285】

 

 

select/epoll的区别

select的特点：select 选择句柄的时候，是遍历所有句柄，也就是说句柄有事件响应时，select需要遍历所有句柄才能获取到哪些句柄有事件通知，因此效率是非常低。但是如果连接很少的情况下， select和epoll的LT触发模式相比， 性能上差别不大。
这里要多说一句，select支持的句柄数是有限制的， 同时只支持1024个，这个是句柄集合限制的，如果超过这个限制，很可能导致溢出，而且非常不容易发现问题， TAF就出现过这个问题， 调试了n天，才发现：）当然可以通过修改linux的socket内核调整这个参数。
epoll的特点：epoll对于句柄事件的选择不是遍历的，是事件响应的，就是句柄上事件来就马上选择出来，不需要遍历整个句柄链表，因此效率非常高，内核将句柄用红黑树保存的。
对于epoll而言还有ET和LT的区别，LT表示水平触发，ET表示边缘触发，两者在性能以及代码实现上差别也是非常大的。

epoll的LT和ET的区别

LT：水平触发，效率会低于ET触发，尤其在大并发，大流量的情况下。但是LT对代码编写要求比较低，不容易出现问题。LT模式服务编写上的表现是：只要有数据没有被获取，内核就不断通知你，因此不用担心事件丢失的情况。
ET：边缘触发，效率非常高，在并发，大流量的情况下，会比LT少很多epoll的系统调用，因此效率高。但是对编程要求高，需要细致的处理每个请求，否则容易发生丢失事件的情况。
下面举一个列子来说明LT和ET的区别（都是非阻塞模式，阻塞就不说了，效率太低）：
采用LT模式下， 如果accept调用有返回就可以马上建立当前这个连接了，再epoll_wait等待下次通知，和select一样。
但是对于ET而言，如果accpet调用有返回，除了建立当前这个连接外，不能马上就epoll_wait还需要继续循环accpet，直到返回-1，且errno==EAGAIN，TAF里面的示例代码：

（来自：https://www.cnblogs.com/tangr206/articles/3118126.html）

 

另外还有一个牛客网的题目也在这里记录一下

请你说说select，epoll的区别，原理，性能，限制都说一说

链接：https://www.nowcoder.com/questionTerminal/894d71ef93ce487e9c7243c4bc53eee7?toCommentId=2670697
来源：牛客网
 

1）IO多路复用

IO复用模型在阻塞IO模型上多了一个select函数，select函数有一个参数是文件描述符集合，意思就是对这些的文件描述符进行循环监听，当某个文件描述符就绪的时候，就对这个文件描述符进行处理。

这种IO模型是属于阻塞的IO。但是由于它可以对多个文件描述符进行阻塞监听，所以它的效率比阻塞IO模型高效。

 

IO多路复用就是我们说的select，poll，epoll。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。

I/O多路复用和阻塞I/O其实并没有太大的不同，事实上，还更差一些。因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom)。但是，用select的优势在于它可以同时处理多个connection。

所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）

在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

2、select

select：是最初解决IO阻塞问题的方法。用结构体fd_set来告诉内核监听多个文件描述符，该结构体被称为描述符集。由数组来维持哪些描述符被置位了。对结构体的操作封装在三个宏定义中。通过轮寻来查找是否有描述符要被处理。

存在的问题：

1. 内置数组的形式使得select的最大文件数受限与FD_SIZE；

2. 每次调用select前都要重新初始化描述符集，将fd从用户态拷贝到内核态，每次调用select后，都需要将fd从内核态拷贝到用户态；

3. 轮寻排查当文件描述符个数很多时，效率很低；

3、poll

poll：通过一个可变长度的数组解决了select文件描述符受限的问题。数组中元素是结构体，该结构体保存描述符的信息，每增加一个文件描述符就向数组中加入一个结构体，结构体只需要拷贝一次到内核态。poll解决了select重复初始化的问题。轮寻排查的问题未解决。

4、epoll

epoll：轮寻排查所有文件描述符的效率不高，使服务器并发能力受限。因此，epoll采用只返回状态发生变化的文件描述符，便解决了轮寻的瓶颈。

epoll对文件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式

1. LT模式

LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的。

2. ET模式

ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)

 

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

3、LT模式与ET模式的区别如下：
LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。
ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。