linux epoll 模型详解

在 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)

        return -1;

      // 当 socket 是非阻塞时 , 如返回此错误 , 表示写缓冲队列已满 ,

      // 在这里做延时后再重试 .

      if(errno == EAGAIN)

      {

        usleep(1000);

        continue;

      }

      return -1;

    }

    if((size_t)tmp == total)

      return buflen;

    total -= tmp;

    p += tmp;

  }

 

  return tmp;

}