聊聊IO多路复用之select、poll、epoll详解

本文转载自： http://mp.weixin.qq.com/s?__biz=MzAxODI5ODMwOA==&mid=2666538922&idx=1&sn=e6b436efd6a4f53dcbf20f4ce11a986a&scene=23&srcid=0425xFfzV9LmmVrdeEQ4He1W#rd

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。IO多路复用适用以下场合：

 

1. 当客户处理多个描述符时（通常是交互式输入和网络套接口），必须使用I/O复用。

    

2. 当一个客户同时处理多个套接口时，而这种状况是可能的，但不多出现。

    

3. 若是一个TCP服务器既要处理监听套接口，又要处理已链接套接口，通常也要用到I/O复用。

    

4. 若是一个服务器即要处理TCP，又要处理UDP，通常要使用I/O复用。

    

5. 若是一个服务器要处理多个服务或多个协议，通常要使用I/O复用。

    

与多进程和多线程技术相比，I/O多路复用技术的最大优点是系统开销小，系统没必要建立进程/线程，也没必要维护这些进程/线程，从而大大减少了系统的开销。

 

目前支持I/O多路复用的系统调用有 select，pselect，poll，epoll，I/O多路复用就是经过一种机制，一个进程能够监视多个描述符，一旦某个描述符就绪（通常是读就绪或者写就绪），可以通知程序进行相应的读写操做。但select，pselect，poll，epoll本质上都是同步I/O，由于他们都须要在读写事件就绪后本身负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需本身负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

 

对于IO多路复用机制不理解的同窗，能够先行参考《聊聊 Linux 中的五种 IO 模型》，来了解Linux五种IO模型。

 

1 select、poll、epoll简介

 

epoll跟select都能提供多路I/O复用的解决方案。在如今的Linux内核里有都可以支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，通常操做系统均有实现。

 

1.1 select

 

基本原理：

 

select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，若是当即返回设为null便可），函数返回。当select函数返回后，能够经过遍历fdset，来找到就绪的描述符。

 

基本流程，如图所示：

 

 

select目前几乎在全部的平台上支持，其良好跨平台支持也是它的一个优势。select的一个缺点在于单个进程可以监视的文件描述符的数量存在最大限制，在Linux上通常为1024，能够经过修改宏定义甚至从新编译内核的方式提高这一限制，可是这样也会形成效率的下降。

 

select本质上是经过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

 

1. select最大的缺陷就是单个进程所打开的FD是有必定限制的，它由FD_SETSIZE设置，默认值是1024。

   
   通常来讲这个数目和系统内存关系很大，具体数目能够cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.

    

2. 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低。

   
   当套接字比较多的时候，每次select()都要经过遍历FD_SETSIZE个Socket来完成调度，无论哪一个Socket是活跃的，都遍历一遍。这会浪费不少CPU时间。若是能给套接字注册某个回调函数，当他们活跃时，自动完成相关操做，那就避免了轮询，这正是epoll与kqueue作的。

    

3. 须要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大.

 

 

1.2 poll

 

基本原理：

 

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，而后查询每一个fd对应的设备状态，若是设备就绪则在设备等待队列中加入一项并继续遍历，若是遍历完全部fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了屡次无谓的遍历。

 

它没有最大链接数的限制，缘由是它是基于链表来存储的，可是一样有一个缺点：

 

1. 大量的fd的数组被总体复制于用户态和内核地址空间之间，而无论这样的复制是否是有意义。

    

2. poll还有一个特色是“水平触发”，若是报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

 

注意：

 

从上面看，select和poll都须要在返回后，经过遍历文件描述符来获取已经就绪的socket。事实上，同时链接的大量客户端在一时刻可能只有不多的处于就绪状态，所以随着监视的描述符数量的增加，其效率也会线性降低。

 

1.3 epoll

 

epoll是在2.6内核中提出的，是以前的select和poll的加强版本。相对于select和poll来讲，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

 

基本原理：

 

epoll支持水平触发和边缘触发，最大的特色在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，而且只会通知一次。还有一个特色是，epoll使用“事件”的就绪通知方式，经过epoll_ctl注册fd，一旦该fd就绪，内核就会采用相似callback的回调机制来激活该fd，epoll_wait即可以收到通知。

 

epoll的优势：

 

1. 没有最大并发链接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。

    

2. 效率提高，不是轮询的方式，不会随着FD数目的增长效率降低。只有活跃可用的FD才会调用callback函数；即Epoll最大的优势就在于它只管你“活跃”的链接，而跟链接总数无关，所以在实际的网络环境中，Epoll的效率就会远远高于select和poll。

    

3. 内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减小复制开销。

 

 

epoll对文件描述符的操做有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别以下：

 

LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序能够不当即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。

 

ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须当即处理该事件。若是不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。

 

1. LT模式

   
   LT(level triggered)是缺省的工做方式，而且同时支持block和no-block socket。在这种作法中，内核告诉你一个文件描述符是否就绪了，而后你能够对这个就绪的fd进行IO操做。若是你不做任何操做，内核仍是会继续通知你的。

    

2. ET模式

   
   ET(edge-triggered)是高速工做方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核经过epoll告诉你。而后它会假设你知道文件描述符已经就绪，而且不会再为那个文件描述符发送更多的就绪通知，直到你作了某些操做致使那个文件描述符再也不为就绪状态了(好比，你在发送，接收或者接收请求，或者发送接收的数据少于必定量时致使了一个EWOULDBLOCK 错误）。可是请注意，若是一直不对这个fd做IO操做(从而致使它再次变成未就绪)，内核不会发送更多的通知(only once)。ET模式在很大程度上减小了epoll事件被重复触发的次数，所以效率要比LT模式高。epoll工做在ET模式的时候，必须使用非阻塞套接口，以免因为一个文件句柄的阻塞读/阻塞写操做把处理多个文件描述符的任务饿死。

    

3. 在select/poll中，进程只有在调用必定的方法后，内核才对全部监视的文件描述符进行扫描，而epoll事先经过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用相似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便获得通知。(此处去掉了遍历文件描述符，而是经过监听回调的的机制。这正是epoll的魅力所在。)

 

注意：

若是没有大量的idle-connection或者dead-connection，epoll的效率并不会比select/poll高不少，可是当遇到大量的idle-connection，就会发现epoll的效率大大高于select/poll。

 

2 select、poll、epoll区别

 

1. 支持一个进程所能打开的最大链接数

 

 

  2.  FD剧增后带来的IO效率问题

 

 

  3.  消息传递方式

 

 

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特色：

 

1. 表面上看epoll的性能最好，可是在链接数少而且链接都十分活跃的状况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制须要不少函数回调。

    

2. select低效是由于每次它都须要轮询。但低效也是相对的，视状况而定，也可经过良好的设计改善。