Unix中select,poll,epoll详解

in Unix网络编程

Unix中select,poll,epoll详解

网络应用需要处理的问题无非两类,网络I/O和数据计算问题。
在处理计算密集型任务的时候,期间会有一些网络IO操作(如写数据库的操作，非本机)，此时若使用同步IO,则会造成大量的IO等待，造成CPU使用率较低。所以此时考虑其他IO模型如异步模型。

Unix下网络I/O模型包括五类:

  • 阻塞式IO
  • 非阻塞式IO
  • 多路复用IO
  • 信号驱动IO(边缘触发)
  • 异步IO

其中多路复用I/O机制是通过select,poll以及epoll进行监视。这里暂时只介绍多路复用IO,若想了解其他IO模型,参考《Unix网络编程》第六章

多路复用I/O模型

网络I/O的本质是socket的读取,socket在linux系统中被抽象为流,所以I/O操作可以理解为对流的操作。这个操作包括两个阶段:

  • 等待流数据准备就绪(wait for data be ready)
  • 从内核相进程复制数据

由于非阻塞调用的过程中，轮训占据了大部分的过程，所以轮训会占据大量的CPU时间。如果轮训不是进程的用户态，而是有人帮忙就好了。多路复用正好处理这样的问题。

多路复用的过程：多路复用有两个特别的系统调用select和poll。select调用是内核级别的，select轮训相对于非阻塞的轮训区别在于：前者可以等待多个socket，当其中一个socket数据准备好了，就能返回进行可读，然后进程再进行recvform系统调用，将数据由内核拷贝到进程中，拷贝的过程是阻塞的。

多路复用有两种阻塞，select或poll调用之后，会阻塞进程，与第一种阻塞不同在于，此时的select不是等到socket数据全部到达再处理, 而是有了一部分数据就会调用用户进程来处理。如何知道有一部分数据到达了呢？监视的事情交给了内核，内核负责数据到达的处理。也可以理解为”非阻塞”吧。

类比钓鱼过程:在钓鱼的时候,我们雇了一个帮手，他可以同时抛下多个鱼竿，任何一个鱼竿的鱼一上钩，他就会拉杆。他只负责帮我们钓鱼，并不处理，所以我们在一旁等着，等他收杆之后，我们再进行处理。

多路复用既然可以处理多个IO,也就带来了新的问题：多个IO的顺序不能保证

多路复用的特点多路复用通过一种机制一个进程能同时等待多个IO文件描述符，内核监视这些文件描述符（socket描述符），其中任意一个进入读就绪状态时，select,poll.epoll函数就可以返回。对于监视的方式，有可以分为select,poll,和epoll三种方式。

select函数详解

###　函数原型

1
2
3
#include <select.h>
#include <time.h>
int select(int maxfdp1, fd_set* readset, fd_set* writeset, fd_set* except_set, const struct timeval* timeout);

函数功能

该函数允许进程指示内核等待多个事件中的其中一个发生，并只在有一个或多个事件发生或者经历了一段时间之后才唤醒它。

其中等待的事件类型包括三种:指定集合中的描述符处于可读状态,执行集合中的描述符处于可写状态,指定集合中的描述符有异常未处理。

描述符就绪的条件如下:

可读就绪

当描述符满足下列四个条件中的其中一个,表示该描述符已经准备好读

  • 该套接字接收缓冲区的字节数大于等于套接字接收缓冲区的低水位标记的大小。一般对于TCP和UDP该值默认为1,我们也可以通过SO_RCVLOWAT套接字选项设置该套接字的低水位标记。
  • 该连接读半部关闭(接受了FIN的TCP连接)，此时函数返回0。
  • 该套接字是一个监听套接字且完成的连接数不为0。对于这种套接字,accept通常不会阻塞。
  • 其上有一个套接字错误待处理.对这种套接字的读操作将不阻塞病返回-1。

可写就绪

当描述符满足下列四个条件中的其中一个,表示该描述符已经准备好写

  • 该套接字的发送缓冲区的可用空间字节大于等于套接字发送缓冲区的低水位标记大小。TCP和UDP的默认大小一般为2048。可以使用SO_SNDLOWAT套接字选项来设置该套接字的低水位标记
  • 该链接的写半部关闭
  • 使用非阻塞式connect的套接字建立连接，或者connect以失败告终
  • 其上有一个套接字错误未处理

函数参数

  • maxfdp1 : fd_set中最大的描述符+1(特别注意不要忘了+1)，如readset中有{1,2,4}，writeset中有{5,7,9}，except_set中有{2,3,6,10}，则此时的maxfdp1为11
  • readset : 需要监听的满足可读条件的描述符集合
  • writeset : 需要监听的满足可写条件的描述符集合
  • except_set : 需要监听的满足异常的描述符集合
  • timeout : 等待的时间，若超过此时间,函数返回

timeout的三种情况

  • timeout=NULL,等待时间无限长,即不限等待时间
  • timeout->sec=0,timeout->usec=0。此时不等待，函数立即返回
  • timeout->sec!=0 || timeout->usec != 0。此时为等待时间

函数返回值

  • 当监视的相应的文件描述符集合中存在满足条件的描述符时，比如说读文件描述符集中有数据到来时,内核IO根据状态修改文件描述符集，并返回一个大于0的数
  • 当没有满足条件的描述符且设置的timeval超时时,select函数返回0
  • 出错返回负数

若存在满足条件的描述符时，内核会将满足条件的描述符置位，并将其他描述符清0.这时，我们可以通过FD_ISSET来判断当前描述符是否满足条件.
如:
假设set为8位表示，起始为0000 0000。此时将{1,2,5}设置到读文件描述符集合中,即:

1
2
3
FD_SET(1, &readset);
FD_SET(2, &readset);
FD_SET(3, &readset);

置位以后set的位为:0000 0111

当调用select函数，并文件描述符2准备就绪时,此时select函数返回大于0的值，set的值变为:0000 0010。此时使用FD_ISSET可以检测到文件描述符2已经就绪。

fd_set相关操作

1
2
3
4
void FD_ZERO(fd_set* set);          //将fd_set清空，一般声明fd_set第一步现先将其清空
void FD_SET(int fd, fd_set* set);   //将某个fd置位
void FD_CLR(int fd, fd_set* set);   //清空某个fd
int FD_ISSET(int fd, fd_set* set);  //判断fd是否在set中

select函数底层实现原理

select底层实现的大致原理是,通过轮训文件描述符集中的文件描述符，检查描述符是否达到条件，若达到符合的相关条件则返回，否则轮训，但是当轮训的机制虽然是死循环，但是不是一直轮训，当内核轮训一遍文件描述符之后，会调用schedule_timeout函数挂起，等待fd设备或定时器来唤醒自己，然后再继续循环体看看哪些fd可用，以此提高效率。

若要了解详细的select实现原理参考如下博客:
http://janfan.cn/chinese/2015/01/05/select-poll-impl-inside-the-kernel.html
http://zhangyafeikimi.iteye.com/blog/248815

select函数的特点

select和poll为水平触发,epoll即支持水平触发也支持边缘触发。

缺点:

  • 最大并发数限制:从上面可以看出，被监听的描述符集合的大小受fe_set大小的限制，所以select监听的描述符的个数是有限制的,一般默认个数为1024或4096个等。
  • 效率问题:从select的底层实现可以看出，select每次调用都会线性扫描全部的fd集合,这样效率会出现线性下降,当把FD_SETSIZE增大可能会出现超时.
  • 内核用户空间拷贝问题:从select实现源码中不难看出,描述符集合以及timeout参数都是通过内存拷贝的方式从用户空间拷贝到了内核空间，也是会影响函数的性能。

poll函数详解

函数原型

1
2
3
4
5
6
7
8
9
10
#include <poll.h>
#include <time.h>
struct pollfd{
  int fd;     //file descriptor
  short events; //被监听的事件状态(即select中监听当前描述符是否可写或者可读或者异常等等)
  shor revents; //函数返回时该文件描述符的状态
};
int poll(struct pollfd* fds, unsigned long nfds, int timeout);

函数功能

poll的函数功能与select功能基本类似。但是poll函数可监听的文件描述符的个数基本没有限制，poll管理多个文件描述符的方式与select一致,都是轮训，并且都是讲文件描述符数组从用户空间复制到内核空间。

函数参数

  • fds : 被监听的描述符的数组
  • nfds : 数组中描述符的个数,这个大小足以监听linux所有的文件描述的符
  • timeout : 等待的时间

events的合法事件:

1
2
3
4
5
6
7
8
POLLIN      ---       有数据可读(普通或优先级带数据)等价于POLLRDNORM||POLLRDBAND
POLLRDNORM  ---       有普通数据可读
POLLRDBAND  ---       有优先级带数据可读
POLLPRI     ---       有高优先级数据可读
POLLOUT     ---       有数据可写(普通数据)等价于POLLWRNORM
POLLWRNORM  ---       有普通数据可写
POLLWRBBAND ---       有优先级带数据可写

初此之外,revents返回的事件还有:

1
2
3
POLLER      ---       发生错误
POLLHUP     ---       发生挂起
POLLNVAL    ---       指定的描述符非法，没有打开

POLLIN | POLLPRI等价于select的读事件

POLLOUT | POLLWRBBAND 等价于select的写事件

函数返回值

  • 若监听的描述符满足条件,返回revents域不为0的文件描述符的个数
  • 若没有描述符满足条件且已过超时时间,poll返回0
  • 出错返回-1，并设置errno为以下值:
1
2
3
4
5
EBADF      ---        一个或多个结构体中的描述符无效
EFAULTfds  ---        指针指向的地址超出进程的地址空间
EINTR      ---        请求的时间之前产生一个信号，调用可以重新发起
EINVALnfds ---        参数超出PLIMIT_NOFILE的值
ENOMEM     ---        可用内存不足，无法完成请求

poll函数优缺点

优点：

  • poll函数不需要计算最大的文件描述符加1.
  • poll函数监听的文件描述符的个数不受限制
  • poll相对于select函数应付大数目的描述符的效率较高。

缺点:

  • poll函数没有解决select轮训所有文件描述符的问题
  • poll函数和select相同都是将文件描述符信息从用户空间拷贝到内核空间。

epoll函数详解

函数原型

epoll相关数据结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//epoll_data保存触发事件相关的数据。(数据类型与具体使用方式有关)
typedef union epoll_data{
  void* ptr;
  int fd;
  _uint32_t u32;
  _uint64_t u64;
} epoll_data_t;
//保存感兴趣的事件和被触发的事件
struct epoll_event{
  _uint32_t events;
  epoll_data_t data;
};

其中events是一个美剧类型的集合,我们可以使用”|”来增加感兴趣的事件。枚举类型的值包括下面:

  • EPOLLIN : 表示关联的fd可以进行读操作
  • EPOLLOUT :表示关联的fd可以进行写操作
  • EPOLLRDHUP(2.6.17之后):表示套接字关闭了连接，或关闭了正写的一半的连接
  • EPOLLPRI : 表示关联的fd有紧急优先事件可以进行读操作。
  • EPOLLERR : 表示关联的fd发生了错误，epoll_wait会一直等待这个事件,所以一般没有必要设置这个属性
  • EPOLLHUP : 表示关联的fd被挂起，epoll_wait会一直等待这个事件,所以一般没有必要设置这个属性
  • EPOLLET : 设置关联的fd为ET的工作方式,即边缘触发
  • EPOLLONESHOT : 设置关联的fd为one-shot工作方式,表示只监听一次事件,如果要再次监听，需要把socket放入到epoll队列中。

epoll相关的函数有三个。

1
2
3
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event);
int epoll_wait(int epfd, struct epoll_event* events, int maxevents, int timeout);
  • epoll_create : 创建一个epoll句柄，注意创建epoll句柄会占用一个文件描述符，在使用完之后需要关闭。否则可能会导致文件描述符耗尽。
    • size : size为最大的监听文件描述符数，监听的文件描述符的个数不能超过size可以手动指定，但是这个数值可以达到系统可以开的最大的文件描述符数。
  • epoll_ctl : epoll的事件注册函数，它不同于select的是，它不是在监听事件的时候告诉内核要监听什么类型的时间，而是先注册要监听的事件类型。
    • epfd : epoll文件描述符，即epoll_ create的返回值，表示该epoll描述符注册事件
    • op : 注册事件的类型包括以下三类。
      • EPOLL_CTL_ADD : 注册行的fd到epfd中
      • EPOLL_CTL_MOD : 修改已经注册的fd的事件类型
      • EPOLL_CTL_DEL : 删除已经注册的fd
    • fd : 注册的文件描述符
    • event : 注册的时间的类型，告诉内核需要监听什么事件，类型包括上面几种。
  • epoll_wait :　收集epoll监控的时间中已经就绪的事件，若调用成功，返回就绪的文件描述符的个数，返回0表示超时。
    • epfd : epoll的文件描述符
    • events : 已经就绪的事件集合.内核不分配内存，需要程序自己分配内存传给内核，内核只负责将书复制到这里
    • maxevents : events数组的大小。
    • timeout : 超时时间。

水平触发(LT)与边缘触发(ET)

epoll的默认工作模式是水平触发(LT)。NGINX使用的epoll的ET工作模式

水平触发（level_triggered）:当被监控的文件描述符上有可读可写事件的时,epoll_wait()会通知处理程序去读写。如果程序没有一次性把缓冲区的数据读完或者写完,那么下次调用epoll_wait的时候，他还会通知你该文件描述符仍可读写,如果你一直不去读写,它会一直通知你。如果系统中有大量你不需要读写的文件描述符,而他们每次都返回,这样会大大降低处理程序检索自己关心的就绪文件描述符的效率。

边缘触发(edge-triggered):当被监控的文件描述符上有读写事件发生时，epoll_wait会通知处理程序去读写，如果数据没有一次性读写完,那么下次你再调用epoll_wait的时候,它不会通知你，只有等到下一次发生读写事件的时候,它才会通知你。这种模式比水平触发的效率高，系统不会充斥大量你不关心的文件描述符。

注意:epoll工作在ET模式的时候,必须使用非阻塞的套接字,以避免由于一个文件句柄的阻塞读/阻塞写把多个文件描述符的任务饿死。最好以下面两种方式调用epoll接口

  • 基于非阻塞文件句柄
  • 只有当read/write返回值为EAGAIN时才需要挂起。但这不是说每次都需要循环读，直到读到产生EAGAIN才结束,只要读取到的长度小于预期的长度就说明缓冲区的数据我们已经读完了。

epoll族函数底层实现

epoll的使用方法上面已经有详细的描述，借口也简单易用。首先我们通过epoll_create创建一个epoll文件描述符，然后在epoll文件描述符上注册需要监听的事件，最后使用epoll_wait等待准备就绪的文件描述符。然而在每一步的过程中，内核都做了哪些操作？底层的实现方式是怎么样的？

内核使用了slab机制，为epoll提供了高效快速的数据结构。在内核中,epoll向内核注册了一个文件系统，用于存储被监控的文件描述符的信息。epoll在被内核初始化的时候（操作系统启动），同时会开辟出epoll自己的告诉cache区，用于安置我们需要监控的fd信息,这些fd信息会以红黑树的结构保存在内核cache中，以支持快速的查找,插入删除操作。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。

epoll fd在内核中对应的数据够如下:

1
2
3
4
5
6
7
8
9
struct eventpoll {
    spin_lock_t       lock;        //对本数据结构的访问
    struct mutex      mtx;         //防止使用时被删除
    wait_queue_head_t     wq;      //sys_epoll_wait() 使用的等待队列
    wait_queue_head_t   poll_wait;       //file->poll()使用的等待队列
    struct list_head    rdllist;        //事件满足条件的链表
    struct rb_root      rbr;            //用于管理所有fd的红黑树（树根）
    struct epitem      *ovflist;       //将事件到达的fd进行链接起来发送至用户空间
}

当向系统中添加一个fd时，就创建一个epitem结构体，这是内核管理epoll的基本数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
struct epitem {
    struct rb_node  rbn;        //用于主结构管理的红黑树
    struct list_head  rdllink;  //事件就绪队列
    struct epitem  *next;       //用于主结构体中的链表
    struct epoll_filefd  ffd;   //这个结构体对应的被监听的文件描述符信息
    int  nwait;                 //poll操作中事件的个数
    struct list_head  pwqlist;  //双向链表，保存着被监视文件的等待队列，功能类似于select/poll中的poll_table
    struct eventpoll  *ep;      //该项属于哪个主结构体（多个epitm从属于一个eventpoll）
    struct list_head  fllink;   //双向链表，用来链接被监视的文件描述符对应的struct file。因为file里有f_ep_link,用来保存所有监视这个文件的epoll节点
    struct epoll_event  event;  //注册的感兴趣的事件,也就是用户空间的epoll_event
}
  1. 当调用epoll_create的时候，会首先在epoll内存中为分配一个eventpoll的内存大小，以保存当前的epoll描述符(epfd)结构，然后在这块内存上打开一个epoll文件。
  2. 当调用epoll_ctl的时候，如果增加fd（socket），则检查在红黑树中是否存在，存在立即返回，不存在则添加到红黑树上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪list链表中插入数据。当我们调用epoll_ctl往里塞入百万个fd时，epoll_wait仍然可以飞快的返回，并有效的将发生事件的fd给我们用户。这是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的fd外，还会再建立一个list链表，用于存储准备就绪的事件。
  3. 调用epoll_wait的时候立即返回准备就绪链表中的数据即可。

如此，一颗红黑树，一张准备就绪fd链表，少量的内核cache，就帮我们解决了大并发下的fd（socket）处理问题。

如果需要了解更详细的epoll底层实现，参考一下链接:
http://www.cnblogs.com/apprentice89/p/3234677.html

epoll特点

  • 没有文件描述符个数限制
  • 使用注册监听时间的方式，无需每次wait时都将时间从用户空间拷贝到内核空间，节省了内存拷贝的时间。
  • 使用回调机制,无需轮训所有的文件描述符检查状态。
  • 返回值只有准备就绪的文件描述符，检查准备就绪的文件描述符也不需要轮训。

Comment and share

  • page 1 of 1

魏传柳(2824759538@qq.com)

author.bio


Tencent


ShenZhen,China