epoll LT 模式和 ET 模式详解（文末赠书）

与 poll 的事件宏相比，epoll 新增了一个事件宏 EPOLLET，这就是所谓的边缘触发模式（Edge Trigger，ET），而默认的模式我们称为 水平触发模式（Level Trigger，LT）。这两种模式的区别在于：

• 对于水平触发模式，一个事件只要有，就会一直触发；
• 对于边缘触发模式，只有一个事件从无到有才会触发。

这两个词汇来自电学术语，你可以将 fd 上有数据认为是高电平，没有数据认为是低电平，将 fd 可写认为是高电平，fd 不可写认为是低电平。那么水平模式的触发条件是状态处于高电平，而边缘模式的触发条件是新来一次电信号将当前状态变为高电平，即：

水平模式的触发条件

边缘模式的触发条件

说的有点抽象，以 socket 的读事件为例，对于水平模式，只要 socket 上有未读完的数据，就会一直产生 EPOLLIN 事件；而对于边缘模式，socket 上每新来一次数据就会触发一次，如果上一次触发后，未将 socket 上的数据读完，也不会再触发，除非再新来一次数据。对于 socket 写事件，如果 socket 的 TCP 窗口一直不饱和，会一直触发 EPOLLOUT 事件；而对于边缘模式，只会触发一次，除非 TCP 窗口由不饱和变成饱和再一次变成不饱和，才会再次触发 EPOLLOUT 事件。

socket 可读事件水平模式触发条件：

socket 可读事件边缘模式触发条件：

socket 可写事件水平模式触发条件：

socket 可写事件边缘模式触发条件：

也就是说，如果对于一个非阻塞 socket，如果使用 epoll 边缘模式去检测数据是否可读，触发可读事件以后，一定要一次性把 socket 上的数据收取干净才行，也就是说一定要循环调用 recv 函数直到 recv 出错，错误码是EWOULDBLOCK（EAGAIN 一样）（此时表示 socket 上本次数据已经读完）；如果使用水平模式，则不用，你可以根据业务一次性收取固定的字节数，或者收完为止。边缘模式下收取数据的代码写法示例如下：

下面我们来看几个具体的例子来比较一下 LT 模式与 ET 模式的区别。

先来测试一下 LT 模式 与 ET 模式在处理读事件上的区别。

代码如下：

我们先来看水平模式的行为，将代码 79 行和 134 行注释掉则使用 LT 模式，我们编译下程序并运行：

然后再另外开启一个 shell 窗口，使用 nc 命令模拟一个客户端，连接服务器成功后，我们给服务器发送一个消息"abcef"：

此时服务器端输出：

nc 命令实际发送了 a、b、c、d、e、f 和 \n 七个字符，由于服务器端使用的是 LT 模式，每次接收一个字符，只要 socket 接收缓冲区中仍有数据可读，POLLIN 事件就会一直触发，所以服务器一共有 7 次输出，直到 socket 接收缓冲区没有数据为止。

我们将代码 79 行和 134 行注释取消掉，使用 ET 模式再试一下，修改代码并重新编译，然后重新运行一下。再次使用 nc 命令模拟一个客户端连接后发送"abcef"，服务器只会有一次输出，效果如下：

由于使用了 ET 模式，只会触发一次 POLLIN 事件，如果此时没有新数据到来，就再也不会触发。所以，如果我们继续给服务器发送一条新数据，如 123，服务器将再次触发一次 POLLIN 事件，然后打印出字母 b，效果如下：

所以如果使用 ET 模式 处理读事件，切记要将该次 socket 上的数据收完。

再来测试一下 LT 模式 与 ET 模式在处理写事件上的区别。

修改上述代码如下：

上述代码中，我们对新来的连接 fd 同时注册读和写事件（代码 133 行），再次编译程序执行：

然后使用 nc 命令模拟一个客户端去连接 epoll_server：

此时服务器端（epoll_server）会疯狂的输出可写事件触发消息：

之所以是这样，是因为我们注册了可写事件且使用的是 LT 模式，LT 模式下，由于这里的服务器端对应的客户端 fd 一直是可写的，有写事件一直触发，所以看到屏幕不断输出。

我们再将服务器端与客户端建立连接时新建的 fd 设置为 ET 模式再实验一下：

上述逻辑中，服务器端在每次收到客户端消息时会重新给客户端 fd 注册检测可写事件（EPOLLOUT），重新编译代码，启动 epoll_server，再次使用 nc 命令模拟客户端给 epoll_server 发送几条消息，结果如下：

通过上述输出，我们可以发现，epoll_server 使用 ET 模式下即使给客户端 fd 注册了检测可写事件不会一直触发，只会触发一次，触发完后只有再次注册检测可写事件才会继续触发，这里是靠客户端来新消息驱动再次注册检测可写事件。也就是说，如果我们使用 ET 模式去处理可写事件时不必像 LT 模式那样为了避免不必要的可写触发在触发后需要立即移除检测可写事件。

这就意味着，使用 LT 模式，如果你的实现依赖于可写事件触发去发送数据，那么你一定要在数据发送完之后移除检测可写事件，避免没有数据发送时无意义的触发；使用 ET 模式时，如果你的实现也依赖于可写事件触发去发送数据，可写事件触发后，你调用 send 函数（Linux 平台也可以使用 write）去发送数据，如果数据本次不能全部发送完（对于非阻塞的 socket，此时 send 函数返回 -1，错误码为 EAGAIN 或 EWOULDBLOCK），你一定要继续注册检测可写事件，否则你剩余的数据就再也没有机会发送了，因为 ET 模式的可写事件再也不会触发。

最后容我再啰嗦几句，总结起来：

• LT 模式下，读事件触发后，可以按需收取想要的字节数，不用把本次接收到的数据收取干净（即不用循环到 recv 或者 read 函数返回 -1，错误码为 EWOULDBLOCK 或 EAGAIN）；ET 模式下，读事件必须把数据收取干净，因为你不一定有下一次机会再收取数据了，即使有机会，也可能存在上次没读完的数据没有及时处理，造成客户端响应延迟。
• LT 模式下，不需要写事件一定要及时移除，避免不必要的触发，浪费 CPU 资源；ET 模式下，写事件触发后，如果还需要下一次的写事件触发来驱动任务（例如发上次剩余的数据），你需要继续注册一次检测可写事件。
• LT 模式和 ET 模式各有优缺点，无所谓孰优孰劣。使用 LT 模式，我们可以自由决定每次收取多少字节（对于普通 socket）或何时接收连接（对于侦听 socket），但是可能会导致多次触发；使用 ET 模式，我们必须每次都要将数据收完（对于普通 socket）或必须理解调用 accept 接收连接（对于侦听socket），其优点是触发次数少。