Linux系统IO模型及select、poll、epoll原理和应用

理解Linux的IO模型之前，首先要了解一些基本概念，才能理解这些IO模型设计的依据

*** 作系统使用虚拟内存来映射物理内存，对于32位的 *** 作系统来说，虚拟地址空间为4G（2^32）。 *** 作系统的核心是内核，为了保护用户进程不能直接 *** 作内核，保证内核安全， *** 作系统将虚拟地址空间划分为内核空间和用户空间。内核可以访问全部的地址空间，拥有访问底层硬件设备的权限，普通的应用程序需要访问硬件设备必须通过 系统调用 来实现。

对于Linux系统来说，将虚拟内存的最高1G字节的空间作为内核空间仅供内核使用，低3G字节的空间供用户进程使用，称为用户空间。

又被称为标准I/O，大多数文件系统的默认I/O都是缓存I/O。在Linux系统的缓存I/O机制中， *** 作系统会将I/O的数据缓存在页缓存（内存）中，也就是数据先被拷贝到内核的缓冲区（内核地址空间），然后才会从内核缓冲区拷贝到应用程序的缓冲区（用户地址空间）。

这种方式很明显的缺点就是数据传输过程中需要再应用程序地址空间和内核空间进行多次数据拷贝 *** 作，这些 *** 作带来的CPU以及内存的开销是非常大的。

由于Linux系统采用的缓存I/O模式，对于一次I/O访问，以读 *** 作举例，数据先会被拷贝到内核缓冲区，然后才会从内核缓冲区拷贝到应用程序的缓存区，当一个read系统调用发生的时候，会经历两个阶段：

正是因为这两个状态，Linux系统才产生了多种不同的网络I/O模式的方案

Linux系统默认情况下所有socke都是blocking的，一个读 *** 作流程如下：

以UDP socket为例，当用户进程调用了recvfrom系统调用，如果数据还没准备好，应用进程被阻塞，内核直到数据到来且将数据从内核缓冲区拷贝到了应用进程缓冲区，然后向用户进程返回结果，用户进程才解除block状态，重新运行起来。

阻塞模行下只是阻塞了当前的应用进程，其他进程还可以执行，不消耗CPU时间，CPU的利用率较高。

Linux可以设置socket为非阻塞的，非阻塞模式下执行一个读 *** 作流程如下：

当用户进程发出recvfrom系统调用时，如果kernel中的数据还没准备好，recvfrom会立即返回一个error结果，不会阻塞用户进程，用户进程收到error时知道数据还没准备好，过一会再调用recvfrom，直到kernel中的数据准备好了，内核就立即将数据拷贝到用户内存然后返回ok，这个过程需要用户进程去轮询内核数据是否准备好。

非阻塞模型下由于要处理更多的系统调用，因此CPU利用率比较低。

应用进程使用sigaction系统调用，内核立即返回，等到kernel数据准备好时会给用户进程发送一个信号，告诉用户进程可以进行IO *** 作了，然后用户进程再调用IO系统调用如recvfrom，将数据从内核缓冲区拷贝到应用进程。流程如下：

相比于轮询的方式，不需要多次系统调用轮询，信号驱动IO的CPU利用率更高。

异步IO模型与其他模型最大的区别是，异步IO在系统调用返回的时候所有 *** 作都已经完成，应用进程既不需要等待数据准备，也不需要在数据到来后等待数据从内核缓冲区拷贝到用户缓冲区，流程如下：

在数据拷贝完成后，kernel会给用户进程发送一个信号告诉其read *** 作完成了。

是用select、poll等待数据，可以等待多个socket中的任一个变为可读，这一过程会被阻塞，当某个套接字数据到来时返回，之后再用recvfrom系统调用把数据从内核缓存区复制到用户进程，流程如下：

流程类似阻塞IO，甚至比阻塞IO更差，多使用了一个系统调用，但是IO多路复用最大的特点是让单个进程能同时处理多个IO事件的能力，又被称为事件驱动IO，相比于多线程模型，IO复用模型不需要线程的创建、切换、销毁，系统开销更小，适合高并发的场景。

select是IO多路复用模型的一种实现，当select函数返回后可以通过轮询fdset来找到就绪的socket。

优点是几乎所有平台都支持，缺点在于能够监听的fd数量有限，Linux系统上一般为1024，是写死在宏定义中的，要修改需要重新编译内核。而且每次都要把所有的fd在用户空间和内核空间拷贝，这个 *** 作是比较耗时的。

poll和select基本相同，不同的是poll没有最大fd数量限制（实际也会受到物理资源的限制，因为系统的fd数量是有限的），而且提供了更多的时间类型。

总结：select和poll都需要在返回后通过轮询的方式检查就绪的socket，事实上同时连的大量socket在一个时刻只有很少的处于就绪状态，因此随着监视的描述符数量的变多，其性能也会逐渐下降。

epoll是select和poll的改进版本，更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

epoll_create()用来创建一个epoll句柄。

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个就绪链表中管理。

epoll_wait() 可以从就绪链表中得到事件完成的描述符，因此进程不需要通过轮询来获得事件完成的描述符。

当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序可以不立即处理该事件，下次调用epoll_wait还会再次通知该事件，支持block和nonblocking socket。

当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序需要立即处理该事件，如果不立即处理，下次调用epoll_wait不会再次通知该事件。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用nonblocking socket，以避免由于一个文件句柄的阻塞读/阻塞写 *** 作把处理多个文件描述符的任务饿死。

【segmentfault】 Linux IO模式及 select、poll、epoll详解

【GitHub】 CyC2018/CS-Notes

        现在 *** 作系统都是采用虚拟存储器，那么对32位 *** 作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。 *** 作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。 为了保证用户进程不能直接 *** 作内核（kernel），保证内核的安全， *** 心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间 。针对linux *** 作系统而言， 将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF） ，供内核使用，称为内核空间， 而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。

        文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述 指向文件的引用的抽象化概念 。文件描述符在形式上是一个非负整数。 实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表 。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的 *** 作系统。

       刚才说了，对于一次IO访问（以read举例），数据会先被拷贝到 *** 作系统内核的缓冲区中，然后才会从 *** 作系统内核的缓冲区拷贝到应用程序的地址空间。所以说，当一个read *** 作发生时，它会经历两个阶段：

1、等待数据准备 (Waiting for the data to be ready)

2、将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

正式因为这两个阶段，linux系统产生了下面 五种网络模式 的方案。

阻塞 I/O（blocking IO）

非阻塞 I/O（nonblocking IO）

I/O 多路复用（ IO multiplexing）

异步 I/O（asynchronous IO）

信号驱动 I/O（ signal driven IO）

注：由于signal driven IO在实际中并不常用，所以我这只提及剩下的四种IO Model。

阻塞 I/O（blocking IO）

在linux中，默认情况下所有的socket都是blocking，一个典型的读 *** 作流程大概是这样：

        当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到 *** 作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。

所以，blocking IO的特点就是在IO执行的两个阶段都被block了（内核阻塞读取数据，内核将数据复制到应用户态）。

非阻塞 I/O（nonblocking IO）

linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读 *** 作时，流程是这个样子：

       当用户进程发出read *** 作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read *** 作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read *** 作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。

所以，nonblocking IO的特点是用户进程需要 不断的主动询问 kernel数据好了没有（ 内核读取数据时，用户态不需要阻塞，内核将数据复制到用户态时，需要阻塞 ）。

I/O 多路复用（ IO multiplexing）

         IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是 select，poll，epoll这个function会不断的轮询所负责的所有socket ，当某个socket有数据到达了，就通知用户进程。

        当用户 进程调用了select ， 那么整个进程会被block ，而同时，kernel会“监视”所有 select负责的socket（一个管理多个socket连接），当任何一个socket中的数据准备好了，select就会返回 。这个时候用户进程再调用read *** 作， 将数据从kernel拷贝到用户进程 。

所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。

这个图和blocking IO的图其实并没有太大的不同，事实上，还更差一些。 因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom) 。但是，用select的优势在于它可以同时处理多个connection。

所以，如果处理的 连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大 。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）

在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

总结：IO多路复用其实也是阻塞的，阻塞的地方在用当有socket连接有数据以后， 会阻塞知道数据从内核复制到用户态（第二步阻塞）。

异步 I/O（asynchronous IO）

inux下的asynchronous IO其实用得很少。先看一下它的流程：

        用户进程发起read *** 作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read *** 作完成了。

总结：两个阶段都不需要用户进程干涉，内核将数据准备好以后通知用户态去读取

总结

blocking和non-blocking的区别

调用blocking IO会一直block住对应的进程直到 *** 作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。

synchronous IO和asynchronous IO的区别

在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。POSIX的定义是这样子的：

- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes

- An asynchronous I/O operation does not cause the requesting process to be blocked

两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的 blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO 。

       有人会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO *** 作，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。但是， 当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。

而asynchronous IO则不一样，当进程发起IO *** 作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。

这里假设你指的异步I/O是针对的文件描述符，而信号驱动IO面向的是读写信号本身。

比较典型的例子是select和epoll的对比。使用select之前需要预先添加你所有感兴趣的文件描述符，然后再遍历这些文件描述符，找出其中有读写事件的fd，之后再对这些活跃的fd做处理。相比而言，epoll会高效得多：每当有一个fd的读写事件，内核则把该fd添加进一个事件列表，在使用的时候你只需要去取到这个事件列表（一个链表的数据结构）即可做相应 *** 作。

这样说来，就是上面说的，一个是扫描的文件描述符再判断该文件描述符是否需要处理，这个是fd驱动；一个是直接取到有事件发生的文件描述符，也就是信号，或者说是事件驱动。

---