linux epoll 模型详解

关注

转载最新推荐文章于 2026-06-06 13:18:03 发布 600 阅读 AI 写同款· GEO 优化 ›

Linux网络编程——epoll原理详解及epoll反应堆模型设想一个场景：有100万用户同时与一个进程保持着TCP连接，而每一时刻只有几十个或几百个TCP连接是活跃的(接收TCP包)，也就是说在每一时刻进程只需要处理这100万连接中的一小部分连接。那么，如何才能高效的处理这种场景呢？进程是否在每次询问操作系统收集有事件发生的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出其中有事件发生的几百个连接呢？实际上，在Linux2.4版本以前，那时的select或者poll事件驱动方式是这样做的。阅读详情

在 linux 的网络编程中，很长的时间都在使用 select 来做事件触发。在 linux 新的内核中，有了一种替换它的机制，就是 epoll 。

相比于 select ， epoll 最大的好处在于它不会随着监听 fd 数目的增长而降低效率。因为在内核中的 select 实现中，它是采用轮询来处理的，轮询的 fd 数目越多，自然耗时越多。并且，在 linux/posix_types.h 头文件有这样的声明：

#define __FD_SETSIZE 1024

表示 select 最多同时监听 1024 个 fd ，当然，可以通过修改头文件再重编译内核来扩大这个数目，但这似乎并不治本。

epoll 的接口非常简单，一共就三个函数：

1. int epoll_create(int size);

创建一个 epoll 的句柄， size 用来告诉内核这个监听的数目一共有多大。这个参数不同于 select() 中的第一个参数，给出最大监听的 fd+1 的值。需要注意的是，当创建好 epoll 句柄后，它就是会占用一个 fd 值，在 linux 下如果查看 /proc/ 进程 id/fd/ ，是能够看到这个 fd 的，所以在使用完 epoll 后，必须调用 close() 关闭，否则可能导致 fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll 的事件注册函数，它不同与 select() 是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

第一个 参数是 epoll_create() 的返回值，

第二个 参数表示动作，用三个宏来表示：

EPOLL_CTL_ADD ：注册新的 fd 到 epfd 中；

EPOLL_CTL_MOD ：修改已经注册的 fd 的监听事件；

EPOLL_CTL_DEL ：从 epfd 中删除一个 fd ；

第三个 参数是需要监听的 fd ，

第四个 参数是告诉内核需要监听什么事， struct epoll_event 结构如下：

struct epoll_event {

__uint32_t events; /* Epoll events */

epoll_data_t data; /* User data variable */

};

events 可以是以下几个宏的集合：

EPOLLIN ：表示对应的文件描述符可以读（包括对端 SOCKET 正常关闭）；

EPOLLOUT ：表示对应的文件描述符可以写；

EPOLLPRI ：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；

EPOLLERR ：表示对应的文件描述符发生错误；

EPOLLHUP ：表示对应的文件描述符被挂断；

EPOLLET ：将 EPOLL 设为边缘触发 (Edge Triggered) 模式，这是相对于水平触发 (Level Triggered) 来说的。

EPOLLONESHOT ：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个 socket 的话，需要再次把这个 socket 加入到 EPOLL 队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

等待事件的产生，类似于 select() 调用。参数 events 用来从内核得到事件的集合， maxevents 告之内核这个events 有多大，这个 maxevents 的值不能大于创建 epoll_create() 时的 size ，参数 timeout 是超时时间（毫秒，0 会立即返回， -1 将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回 0 表示已超时。

从 man 手册中，得到 ET 和 LT 的具体描述如下

EPOLL 事件有两种模型：

Edge Triggered (ET) 边缘触发只有数据到来，才触发，不管缓存区中是否还有数据。

Level Triggered (LT) 水平触发只要有数据都会触发。

假如有这样一个例子：

1. 我们已经把一个用来从管道中读取数据的文件句柄 (RFD) 添加到 epoll 描述符

2. 这个时候从管道的另一端被写入了 2KB 的数据

3. 调用 epoll_wait(2) ，并且它会返回 RFD ，说明它已经准备好读取操作

4. 然后我们读取了 1KB 的数据

5. 调用 epoll_wait(2)......

Edge Triggered 工作模式：

如果我们在第 1 步将 RFD 添加到 epoll 描述符的时候使用了 EPOLLET 标志，那么在第 5 步调用 epoll_wait(2) 之后将有可能会挂起，因为剩余的数据还存在于文件的输入缓冲区内，而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第 5 步的时候，调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。在上面的例子中，会有一个事件产生在 RFD句柄上，因为在第 2 步执行了一个写操作，然后，事件将会在第 3 步被销毁。因为第 4 步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第 5 步调用 epoll_wait(2) 完成后，是否挂起是不确定的。 epoll 工作在 ET 模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读 / 阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用 ET 模式的 epoll 接口，在后面会介绍避免可能的缺陷。

i 基于非阻塞文件句柄

ii 只有当 read(2) 或者 write(2) 返回 EAGAIN 时才需要挂起，等待。但这并不是说每次 read() 时都需要循环读，直到读到产生一个 EAGAIN 才认为此次事件处理完成，当 read() 返回的读到的数据长度小于请求的数据长度时，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

Level Triggered 工作模式

相反的，以 LT 方式调用 epoll 接口的时候，它就相当于一个速度比较快的 poll(2) ，并且无论后面的数据是否被使用，因此他们具有同样的职能。因为即使使用 ET 模式的 epoll ，在收到多个 chunk 的数据的时候仍然会产生多个事件。调用者可以设定 EPOLLONESHOT 标志，在 epoll_wait(2) 收到事件后 epoll 会与事件关联的文件句柄从epoll 描述符中禁止掉。因此当 EPOLLONESHOT 设定后，使用带有 EPOLL_CTL_MOD 标志的 epoll_ctl(2) 处理文件句柄就成为调用者必须作的事情。

然后详细解释 ET, LT:

LT(level triggered) 是缺省的工作方式 ，并且同时支持 block 和 no-block socket. 在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的 fd 进行 IO 操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的 select/poll 都是这种模型的代表．

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

在许多测试中我们会看到如果没有大量的 idle -connection 或者 dead-connection ， epoll 的效率并不会比select/poll 高很多，但是当我们遇到大量的 idle- connection( 例如 WAN 环境中存在大量的慢速连接 ) ，就会发现epoll 的效率大大高于 select/poll 。（未测试）

另外，当使用 epoll 的 ET 模型来工作时，当产生了一个 EPOLLIN 事件后，

读数据的时候需要考虑的是当 recv() 返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取：

while(rs)

{

buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);

if(buflen < 0)

{

// 由于是非阻塞的模式 , 所以当 errno 为 EAGAIN 时 , 表示当前缓冲区已无数据可读

// 在这里就当作是该次事件已处理处 .

if(errno == EAGAIN)

break;

else

return;

}

else if(buflen == 0)

{

// 这里表示对端的 socket 已正常关闭 .

}

if(buflen == sizeof(buf)

rs = 1; // 需要再次读取

else

rs = 0;

}

还有，假如发送端流量大于接收端的流量 ( 意思是 epoll 所在的程序读比转发的 socket 要快 ), 由于是非阻塞的socket, 那么 send() 函数虽然返回 , 但实际缓冲区的数据并未真正发给接收端 , 这样不断的读和发，当缓冲区满后会产生 EAGAIN 错误 ( 参考 man send), 同时 , 不理会这次请求发送的数据 . 所以 , 需要封装 socket_send() 的函数用来处理这种情况 , 该函数会尽量将数据写完再返回，返回 -1 表示出错。在 socket_send() 内部 , 当写缓冲已满(send() 返回 -1, 且 errno 为 EAGAIN), 那么会等待后再重试 . 这种方式并不很完美 , 在理论上可能会长时间的阻塞在 socket_send() 内部 , 但暂没有更好的办法 .

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)

{

ssize_t tmp;

size_t total = buflen;

const char *p = buffer;

while(1)

{

tmp = send(sockfd, p, total, 0);

if(tmp < 0)

{

// 当 send 收到信号时 , 可以继续写 , 但这里返回 -1.

if(errno == EINTR)