【Linux】从零开始使用多路转接IO --- 理解EPOLL的 LT水平触发模式 与 ET边缘触发模式

当你偶尔发现语言变得无力时，

不妨安静下来，

让沉默替你发声。

--- 里则林 ---

---

1 EPOLL优缺点

poll 的优点(和 select 的缺点对应)

1. 接口使用方便：虽然拆分成了三个函数，但是逻辑清晰，使用起来更方便高效。不需要每次循环都设置关注的文件描述符，并且做到了输入输出参数分离开！
2. 数据拷贝轻量：只在合适的时候调用 EPOLL_CTL_ADD 将文件描述符结构拷贝到内核中，这个操作并不频繁(而 select/poll 都是每次循环都要进行拷贝)。
3. 事件回调机制：避免使用遍历, 而是使用回调函数的方式，将就绪的文件描述符结构加入到就绪队列中。epoll_wait 返回直接访问就绪队列就知道哪些文件描述符就绪。这个操作时间复杂度 O(1). 即使文件描述符数目很多，效率也不会受到影响。
4. 没有数量限制：理论上，文件描述符数目是无上限。epoll的接口支持无上限的文件描述符！

网上说:epoll 中使用了内存映射机制

• 内存映射机制: 内核直接将就绪队列通过 mmap 的方式映射到用户态。 避免了拷贝内存这样的额外性能开销。

这种说法是不准确的。我们定义的 struct epoll_event 是我们在用户空间中分配好的内存。势必还是需要将内核的数据拷贝到这个用户空间的内存中的。

可以这么说epoll几乎没有缺点！

2 EPOLL工作模式

select、poll、epoll都存在一个现象：当有事件就绪时，用户不处理就会一直通知用户处理，循环打印日志信息。

EPOLL的工作模式有两种：

1. LT水平触发
2. ET边缘触发

上面现象是LT模式下的产物，那么怎么理解LT与ET呢？我们通过快递小哥的例子进行讲解：

有两名快递员张三李四，他们一个温和老实，一个严肃霸道。
小明前几天买了5个包裹，今天一起送到了快递站。张三李四分别分到了小明的3个包裹和2个包裹。
张三首先到达了小王所在的小区，他给该小区所以的收件人都打了一遍电话：“请你下来拿快递”。小明这时正在和舍友打无畏契约，拿不了快递。过了一会张三再次给小明打电话让他下来拿快递，小明下去取了一个就立马回去了。张三一看，还有两个包裹啊，于是又给小王打电话！这时李四过来了，把两个快递交给了张三。张三就在这里一直打电话
第二天，又有小明的5个包裹，这次李四来到小区门口，开始打电话：我只给你打一次电话，你有快递到了，不拿我就走人。小明一听，这快递小哥这么硬气，哎我就不拿，那你怎么办。于是小明就没有去拿，结果李四真的走了。一会碰到了张三，张三把小明的包裹给了李四，于是李四又来到小区门口，再一次强硬的打电话。小明决定去拿了，快递不拿他是真走啊！

这里我们可以总结出来：

1. 张三：只有底层有快递，就一直打电话给小王。
2. 李四：只有包裹变化的时候，我才来通知你拿快递。

在这个例子中，快递就是数据，张三对应LT水平触发模式，李四对应ET边缘触发模式。一般情况下是LT水平触发模式。

这两种模式哪一个更加高效呢？ET模式更加高效！毕竟李四比张三打的电话少的多得多！

LT水平触发是默认的，那么一个如何设置成ET边缘触发模式呢？

• 通过EPOLLET 标志位: 将 EPOLL 设为边缘触发(Edge Triggered)模式, 这是相对于水平触发(Level Triggered)来说的

1. 水平触发 Level Triggered 工作模式
   • epoll 默认状态下就是 LT 工作模式。
   • 当 epoll 检测到 socket 上事件就绪的时候, 可以不立刻进行处理. 或者只处理一部分。
   • 如上面的例子, 由于只读了 1K 数据，缓冲区中还剩 1K 数据，在第二次调用epoll_wait 时, epoll_wait 仍然会立刻返回并通知 socket 读事件就绪。
   • 直到缓冲区上所有的数据都被处理完， epoll_wait 才不会立刻返回。
   • 支持阻塞读写和非阻塞读写。
2. 边缘触发 Edge Triggered 工作模式
   • 如果将 socket 添加到 epoll 描述符的时候使用了 EPOLLET 标志，epoll 进入 ET 工作模式。
   • 当 epoll 检测到 socket 上事件就绪时，必须立刻处理。
   • 如上面的例子，虽然只读了 1K 的数据，缓冲区还剩 1K 的数据，在第二次调用epoll_wait 的时候，epoll_wait 不会再返回了。
   • 也就是说, ET 模式下，文件描述符上的事件就绪后，只有一次处理机会。
   • ET 的性能比 LT 性能更高( epoll_wait 返回的次数少了很多). Nginx 默认采用ET 模式使用 epoll。
   • 只支持非阻塞的读写

假如服务端使用ET模式，这时服务端需要的数据是10K，客户端将这10K数据发过来，服务端第一次只读取了1K的数据。由于是ET模式，在客户端发送新的数据之前，服务端一直不会进行读取！所以ET模式下，必须一次性将数据读完，就要进行循环读取直到读取不到！这样也就必须使用非阻塞的读取了（才能支持循环读取）！LT模式没有这种问题。

• ET模式的这种读取方式也就决定了TCP应答中TCP服务端的窗口更大，客户端下一次可以发送更多的数据！增加IO效率！

那么LT设置成非阻塞呢？那么是不是和ET模式一样了呢？所以一般不能说ET模式一定比LT模式的效率更高。可是，ET强制程序员必须使用非阻塞进行读取！LT不会强制程序员使用非阻塞读取！所以可以认为ET模式更加高效！