大家好，我是「云舒编程」，今天我们来聊聊IO多路复用。

文章首发于微信公众号：云舒编程

关注公众号获取： 1、大厂项目分享 2、各种技术原理分享 3、部门内推

前言

通过前面的文章我们已经了解了「数据包从HTTP层->TCP层->IP层->网卡->互联网->目的地服务器」以及「数据包怎么从网线到进程，在被应用程序使用」涉及的知识。

本文将继续介绍网络编程中的各种细节和IO多路复用的原理。

系列文章

每天5分钟玩转计算机网络-(数据链路层、物理层)工作原理
 每天5分钟玩转计算机网络-(网络层ip)工作原理
 每天5分钟玩转计算机网络-(传输层tcp)工作原理
 每天5分钟玩转计算机网络-(应用层)工作原理
 Linux是怎么从网络上接收数据包的

通过本文你可学到：

阻塞IO、非阻塞IO的区别、优缺点；
IO多路复用的原理，为什么高性能；
select原理、优缺点；
poll原理、优缺点；
epoll原理、优缺点
select、poll、epoll 到底是同步IO还是异步IO?
epoll边缘触发、水平触发的区别、适合场景
为什么在 Linux 网络编程中最好用非阻塞式 IO？
Linux 常见网络IO事件定义

一、从一次网络调用说起

假设应用A想要请求应用B获取数据，那么他会经历以下步骤：

应用A将请求报文写入自己的TCP写缓冲区
应用A的请求报文经过网线到达应用B的TCP读缓冲区
应用B获得请求报文后，进行业务逻辑处理
应用B业务逻辑处理完成后，将响应报文写入自己的TCP写缓冲区，然后经过网线达到应用A的TCP读缓冲区

现在我们将注意力放到应用A上，应用A将请求发送出去后，就会开始调用系统调用从TCP读缓冲区读取数据，由于无法知道应用B什么时候会把响应数据返回，那么就会两种情况：

应用B响应速度很快，在应用A读取TCP缓冲区时，就已经把响应数据返回了。那么应用A就可以顺利获取到数据，皆大欢喜。
应用B响应比较慢，在应用A读取TCP缓冲区时，还没有将响应数据返回了。这个时候操作系统就面临两种选择：

选择一：把应用A的本次调用阻塞在这，等到应用B的数据达到了缓冲区再重新唤醒应用A。

选择二：告诉应用A你要的数据还没来，你等会再来问。

二、阻塞IO

对于选择一，就是我们常说的阻塞式IO。

学术点的说法：当用户进程发起read调用时，如果内核的数据没有准备好，那么操作系统就会把该进程挂起来，进入等待状态(不消耗CPU)。直到数据准备好了或者发生了错误，该进程才会被唤醒。

整体流程如图：

三、非阻塞IO

对于选择二，就是我们常说的非阻塞式IO。

学术点的说法：当用户进程发起read调用时，如果内核的数据没有准备好，那么操作系统会返回一个EAGAIN error，用户进程可以根据该error判断出是数据未准备好，可以等会再来问。如果在轮询期间，内核准备好数据了，用户进程就可以把数据拷贝到用户态空间了。

整体流程如图：

四、IO多路复用

阻塞IO和非阻塞IO都是早期最常见的网络编程模型，但是他们有着致命的缺点。考虑如下场景：

每个用户请求都需要使用一个单独的线程进行服务，同时还要请求应用B才能完成业务逻辑。
由于不知道应用B的响应数据何时会返回，那么只能选择阻塞IO或者非阻塞IO进行轮询。

然而阻塞IO会导致线程被挂起，非阻塞IO会导致线程一直处于轮询状态。这两种情况都会导致线程无法被释放或者复用。随着用户请求数的增多，应用A不得不创建更多的线程。

然而对于操作系统来说，可以创建的线程是有上限的，并且过多的线程会导致线程切换的时间变多，严重时可能导致系统卡死，无法对外提供服务。这也是著名的C10K问题。

为了解决这个问题，于是人们就提出了方案：由一个或者几个线程去监控多个网络请求，由他们去完成数据准备阶段的操作。当有数据准备就绪之后再分配对应的线程去读取数据，这样就可以使用少量的线程维护大量的网络请求，这就是IO多路复用。

❝

IO 多路复用的复用指的是复用线程，而不是IO连接；目的是让少量线程能够处理多个IO连接。

❞

IO多路复用又主要由以下函数分别实现，分别是select、poll、epoll。

select

select是Linux最早支持IO多路复用的函数。

select原理

通过select函数可以完成多个IO事件的监听。

c 复制代码

#define __FD_SETSIZE 1024

typedef struct {
unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(long))];
} __kernel_fd_set;

struct timeval {
time_t      tv_sec;         /* seconds */
suseconds_t tv_usec;        /* microseconds */
};

//函数声明
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

函数参数：

readfds：内核检测该集合中的IO是否可读。如果想让内核帮忙检测某个IO是否可读，需要手动把文件描述符加入该集合。
writefds：内核检测该集合中的IO是否可写。同readfds，需要手动加入
exceptfds：内核检测该集合中的IO是否异常。同readfds，需要手动加入
nfds：以上三个集合中最大的文件描述符数值 + 1，例如集合是{0,1,4}，那么 maxfd 就是 5
timeout：用户线程调用select的超时时长。
- 设置成NULL，表示如果没有 I/O 事件发生，则 select 一直等待下去。
- 设置为非0的值，这个表示等待固定的一段时间后从 select 阻塞调用中返回。
- 设置成 0，表示根本不等待，检测完毕立即返回。

函数返回值：

大于0：成功，返回集合中已就绪的IO总个数
等于-1：调用失败
等于0：没有就绪的IO

从上述的select函数声明可以看出，fd_set本质是一个数组，为了方便我们操作该数组，操作系统提供了以下函数：

c 复制代码

// 将文件描述符fd从set集合中删除 
void FD_CLR(int fd, fd_set *set); 

// 判断文件描述符fd是否在set集合中 
int  FD_ISSET(int fd, fd_set *set); 

// 将文件描述符fd添加到set集合中 
void FD_SET(int fd, fd_set *set); 

// 将set集合中, 所有文件描述符对应的标志位设置为0
void FD_ZERO(fd_set *set);

select缺点

fd_set长度限制：由于fd_set本质是一个数组，同时操作系统限制了其长度，导致其只能接受文件描述符数值在1024以内的。
select函数的返回值是int，导致每次返回后，用户得手动检测集合中哪些值被改为1了(被改为1的表示产生了IO就绪事件)
每次调用 select，都需要把 fd 集合从用户态拷贝到内核态，当fd很多时，开销很大。
由于fd_set本质是数组，所以每次内核都是线性扫描整个 fd_set，判断是否有IO就绪事件，导致随着监控的描述符 fd 数量增长，其性能会线性下降

poll

poll是在select之后出现的另一种I/O 多路复用技术。和 select 相比，它使用了不同的方式存储文件描述符，也解决文件描述符的个数限制。

poll原理

c 复制代码

struct pollfd {
    int fd; /* file descriptor */
    short events; /* events to look for */
    short revents; /* events returned */
};

int poll(struct pollfd *fds, unsigned long nfds, int timeout);

函数参数：

fds：struct pollfd类型的数组, 存储了待检测的文件描述符，struct pollfd有三个成员：
- fd：委托内核检测的文件描述符
- events：委托内核检测的fd事件（输入、输出、错误），每一个事件有多个取值
- revents：这是一个传出参数，数据由内核写入，存储内核检测之后的结果
nfds：描述的是数组 fds 的大小
timeout: 指定poll函数的阻塞时长
- -1：一直阻塞，直到检测的集合中有就绪的IO事件，然后解除阻塞函数返回
- 0：不阻塞，不管检测集合中有没有已就绪的IO事件，函数马上返回
- 大于0：表示 poll 调用方等待指定的毫秒数后返回

函数返回值：

-1：失败
大于0：表示检测的集合中已就绪的文件描述符的总个数

在 select 里面，文件描述符的个数已经随着 fd_set 的实现而固定，没有办法对此进行配置；而在 poll 函数里，我们可以自由控制 pollfd 结构的数组大小，从而突破select中面临的文件描述符个数的限制。

poll缺点

poll 的实现和 select 非常相似，只是poll 使用 pollfd 结构，而 select 使用fd_set 结构，poll 解决了文件描述符数量限制的问题，但是同样需要从用户态拷贝所有的 fd 到内核态，也需要线性遍历所有的 fd 集合，所以它和 select 并没有本质上的区别。

epoll

epoll 是 Linux kernel 2.6 之后引入的新 I/O 事件驱动技术，它解决了select、poll在性能上的缺点，是目前IO多路复用的主流解决方案。

《The Linux Programming Interface》中用了一张图直观的展示了 select、poll、epoll在不同数量的文件描述符下的性能。

从上图可以明显地看到，随着文件描述符数量的上涨，epoll 的性能还是很优异。而select、poll则随着描述符数量的上涨性能逐渐变差。

epoll 原理

epoll 的 API 非常简洁，由3个系统函数组成：

c 复制代码

int epoll_create(int size);  
int epoll_create1(int flags);

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

struct epoll_event {
    __uint32_t events;
    epoll_data_t data;
};

union epoll_data {
 void     *ptr;
 int       fd;
 uint32_t  u32;
 uint64_t  u64;
};
typedef union epoll_data  epoll_data_t;

epoll_creare、epoll_create1：这两个函数的作用是一样的，都是创建一个epoll实例。
epoll_ctl：在创建完 epoll 实例之后，可以通过调用 epoll_ctl 往 epoll 实例增加或删除需要监控的IO事件。
- epfd：调用 epoll_create 创建的 epoll 获得的返回值，可以简单理解成是 epoll 实例的唯一标识。
- op：表示是增加还是删除一个监控事件，它有三个选项可供选择：
  - EPOLL_CTL_ADD：向 epoll 实例注册文件描述符对应的事件；
  - EPOLL_CTL_DEL：向 epoll 实例删除文件描述符对应的事件；
  - EPOLL_CTL_MOD：修改文件描述符对应的事件。
- fd：需要注册的事件的文件描述符。
- epoll_event：表示需要注册的事件类型，并且可以在这个结构体里设置用户需要的数据。
  - events：表示需要注册的事件类型，可选值在下文的 Linux 常见网络IO事件定义中列出
  - data：可以存放用户自定义的数据。
epoll_wait：调用者进程调用该函数等待I/O 事件就绪。
- epfd： epoll 实例的唯一标识。
- epoll_event：同2.4
- maxevents：一个大于 0 的整数，表示 epoll_wait 可以返回的最大事件值。
- timeout：
  - -1：一直阻塞，直到检测的集合中有就绪的IO事件，然后解除阻塞函数返回
  - 0：不阻塞，不管检测集合中有没有已就绪的IO事件，函数马上返回
  - 大于0：表示 epoll 调用方等待指定的毫秒数后返回

epoll 工作流程

epoll 主要的结构对象为eventpoll，其主要包含几个重要属性成员：

c 复制代码

struct eventpoll {
   /* Wait queue used by sys_epoll_wait() */
 wait_queue_head_t wq;

 /* List of ready file descriptors */
 struct list_head rdllist;

    /* RB tree root used to store monitored fd structs */
 struct rb_root_cached rbr;
}

wq：当用户进程执行了epoll_wait导致了阻塞后，用户进程就会存储到这，等待后续数据准备完成后唤醒。
rdllist：当某个文件描述符就绪了后，就会从rbr移动到这。其本质是一个链表。
rbr：用户调用epoll_ctl增加的文件描述都存储在这，其本质是一颗红黑树。

其工作流程主要如图所示：

epoll 相比select、poll为什么高效？

epoll 采用红黑树管理文件描述符

从上图可以看出，epoll使用红黑树管理文件描述符，红黑树插入和删除的都是时间复杂度 O(logN)，不会随着文件描述符数量增加而改变。

select、poll采用数组或者链表的形式管理文件描述符，那么在遍历文件描述符时，时间复杂度会随着文件描述的增加而增加。
epoll 将文件描述符添加和检测分离，减少了文件描述符拷贝的消耗

select&poll 调用时会将全部监听的 fd 从用户态空间拷贝至内核态空间并线性扫描一遍找出就绪的 fd 再返回到用户态。下次需要监听时，又需要把之前已经传递过的文件描述符再读传递进去，增加了拷贝文件的无效消耗，当文件描述很多时，性能瓶颈更加明显。

而epoll只需要使用epoll_ctl添加一次，后续的检查使用epoll_wait，减少了文件拷贝的消耗。

select、poll、epoll 到底是同步IO还是异步IO?

在神书《UNIX 网络编程》里，提供了5种IO模型的比较，可以看出无论是同步和异步 I/O，获取数据都分为了两步：

等待数据
将数据从内核拷贝到用户空间

判定一个 I/O 模型是同步还是异步，一般主要看第二步数据拷贝时是否会阻塞用户进程。基于这个原则，从上图可以看出只有异步IO才是异步的。其余的，包括基于IO多路复用的思路的selec、poll、epoll都是同步IO。

epoll的边缘触发与水平触发

水平触发(LT)

关注点是数据，只要读缓冲区不为空，写缓冲区不满，那么epoll_wait就会一直返回就绪，水平触发是epoll的默认工作方式。

边缘触发(ET)

关注点是变化，只要缓冲区的数据有变化，epoll_wait就会返回就绪。

这里的数据变化并不单纯指，缓冲区从有数据变为没有数据，或者从没有数据变为有数据，还包括了数据变多或者变少。换句话说，当buffer长度有变化时，就会触发。

假设epoll被设置为了边缘触发，当客户端写入了10个字符，由于缓冲区从0变为了10，于是服务端epoll_wait触发一次就绪，服务端读取了2个字节后不再读取。这个时候再去调用epoll_wait会发现不会就绪，只有当客户端再次写入数据后，才会触发就绪。

这就导致如果使用ET模式，那就必须保证要「一次性把数据读取/写入完」，否则会导致数据长期无法读取/写入。

LT模式则没有这个问题。

为什么在 Linux 网络编程中最好用非阻塞式 IO？

前面提到过，如果使用阻塞IO，假如某个文件描述符长期不可读，那么对应的线程就会长期阻塞，导致资源被浪费。

但是当使用了select、poll、epoll后，函数调用返回的fd都是就绪的，这种情况下还需要使用非阻塞IO吗？答案是肯定的，依旧需要使用非阻塞IO，原因如下：

1、fd从返回就绪，到用户线程去read。存在时间间隔，在这段时间，有可能该fd已经被其他线程读取了(惊群问题)。这个时候如果再去读取，如果是阻塞IO，那么用户线程就会被阻塞了。

2、fd还有可能被内核抛弃了，这个时候如果再去读取，如果是阻塞IO，那么用户线程就会被阻塞了。

3、select、poll、epoll只是返回了可读事件，并没有返回可读的数据量。因此，使用非阻塞 IO的一般做法是读多次，直到不能读为止。而阻塞IO却不一样，每次读了数据后都需要重新调用epoll_wait再次判断是否可读，不能连续的读多次。因为如果上一次就把数据读完了，不判断就直接read 就会导致用户线程阻塞。

Linux 常见网络IO事件定义

EPOLLIN	表示对应的文件描述字可以读；
EPOLLOUT	表示对应的文件描述字可以写；
EPOLLRDHUP	表示套接字的一端已经关闭，或者半关闭； 1、对端发送FIN（调用了close或者shutdown(SHUT_WR)) 2、本端调用shutdown（SHUT_RD），一般不会这么用有些系统不一定支持EPOLLRDHUP，可以考虑使用「EPOLLIN + read返回0」替代
EPOLLHUP	表示套接字读写都关闭： 1、本端调用shutdown（SHUT_RDWR） 2、本端，对端都调shutdown（SHUT_WR） 3、对端调用close
EPOLLERR	发生了错误

IO多路复用(select、poll、epoll)到底是异步IO还是同步IO

前言

系列文章

通过本文你可学到：

一、从一次网络调用说起

二、阻塞IO

三、非阻塞IO

四、IO多路复用

select

select原理

select缺点

poll

poll原理

poll缺点

epoll

epoll 原理

epoll 工作流程

epoll 相比select、poll为什么高效？

select、poll、epoll 到底是同步IO还是异步IO?

epoll的边缘触发与水平触发

水平触发(LT)

边缘触发(ET)

为什么在 Linux 网络编程中最好用非阻塞式 IO？

Linux 常见网络IO事件定义

推荐阅读