Unix/Linux编程：五种I/O模型

柔光的暖阳◎ 2022-12-31 06:21 94阅读 0赞

# IO模型 #

## 阻塞IO ##

> 我和女友点完餐后，不知道什么时候能做好，只好坐在餐厅里面等，直到做好，然后吃完才离开。女友本想还和我一起逛街的，但是不知道饭能什么时候做好，只好和我一起在餐厅等，而不能去逛街，直到吃完饭才能去逛街，中间等待做饭的时间浪费掉了。这就是典型的阻塞。

在Linux中，默认情况下所有的`socket`都是阻塞的

*  读操作中的read、recv、recvfrom
 *  写操作中的write、send
 *  其他操作：accept、connect

一个典型的读操作流程如下：

*  第一步通常涉及等待数据从网络中到达。当所有等待数据到达时，它被复制到内核中的某个缓冲区
 *  第二步就是把数据从内核缓冲区复制到用用程序缓冲区

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

当用户进程调用recvfrom这个系统调用时，kernel就开始了IO的第一个阶段

*  第一个阶段：准备数据，就是数据被拷贝到内核缓冲区中的一个过程（很多网络IO数据不会那么快到达，如没收一个完整的UDP包），等数据到操作系统内核缓冲区了，就到了第二阶段
 *  第二阶段：将数据从内核缓冲区拷贝到用户内存，然后kernel返回结果，用户进程才会解除block状态，重新运行起来。**blocking IO的特点就是在IO执行的两个阶段用户进程都会block住。**

读阻塞（以read函数为例）

*  进程调用read函数从套接字上读取数据，当套接字的接收缓冲区中还没有数据可读，函数read将发生阻塞。
 *  它会一直阻塞下去，等待套接字的接收缓冲区中有数据可读。
 *  经过一段时间后，缓冲区内接收到数据，于是内核便去唤醒该进程，通过read访问这些数据。
 *  如果在进程阻塞过程中，对方发生故障，那这个进程将永远阻塞下去。

写阻塞

*  在写操作时发生阻塞的情况要比读操作少。主要发生在要写入的缓冲区的大小小于要写入的数据量的情况下。
 *  这时，写操作不进行任何拷贝工作，将发生阻塞。
 *  一量发送缓冲区内有足够的空间，内核将唤醒进程，将数据从用户缓冲区中拷贝到相应的发送数据缓冲区。
 *  UDP不用等待确认，没有实际的发送缓冲区，所以UDP协议中不存在发送缓冲区满的情况，在UDP套接字上执行的写操作永远都不会阻塞。

当进程调用阻塞IO时，除非数据报打断或者发出错误才会返回。最常见的错误时系统调用被信号中断

## 非阻塞I/O（nonblocking IO） ##

> 我女友不甘心白白在这等，又想去逛商场，又担心饭好了。所以我们逛一会，回来询问服务员饭好了没有，来来回回好多次，饭都还没吃都快累死了啦。这就是非阻塞。需要不断的询问，是否准备好了。

非阻塞IO模型，我们把一个套接字设置为非阻塞就是告诉内核，**当请求的IO操作无法完成时，不要将进程睡眠，而是返回一个错误**。

*  当一个应用程序使用了非阻塞模式的套接字，它需要使用一个循环来不停地测试是否一个文件描述符有数据可读（称做polling）。
 *  应用程序不停的polling 内核来检查是否I/O操作已经就绪。这将是一个极浪费CPU 资源的操作。
 *  这种模式使用中不普遍。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]  
从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。

从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。

*  用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次 发送read操作。
 *  一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。

**所以，用户进程第一个阶段不是阻塞的,需要不断的主动询问kernel数据好了没有；第二个阶段依然总是阻塞的。**

当你一开始建立一个套接字描述符的时候，系统内核将其设置为阻塞IO模式。可以使用函数fcntl()设置一个套接字的标志为O\_NONBLOCK 来实现非阻塞，或者ioctl设置为`FIONBIO`模式

int flag；
          flag = fcntl(sockfd, F_GETFL, 0);
          flag |= O_NONBLOCK;
          fcntl(sockfd, F_SETFL, flag);

int b_on =1;
       ioctl(sock_fd, FIONBIO, &b_on);

总结：

*  针对阻塞IO执行的系统调用可能因为无法立即完成而被操作系统挂起，直到等待的事件发生为止
 *  针对非阻塞IO执行的系统调用总是立即返回，而不管事件是否已经发生。如果事件没有发生就马上返回-1并设置error
    
     *  对于`accept、send、recv`，事件没有发生时errno通常被设置成`EAGAIN`(再来一次)或者`EWOULDBLOCK`(期望阻塞)
     *  对于`connect`，errno被设置为`EINPROGRESS`(在处理中)

非阻塞IO通常要和其他的IO通知机制一起使用，比如IO复用和SIGIO信号

## I/O多路复用模型(IO multiplexing) ##

> 与第二个方案差不多，餐厅安装了电子屏幕用来显示点餐的状态，这样我和女友逛街一会，回来就不用去询问服务员了，直接看电子屏幕就可以了。这样每个人的餐是否好了，都直接看电子屏幕就可以了，这就是典型的IO多路复用。

阻塞IO一个线程只能处理一个IO流事件，要想同时处理多个IO流事件要么多线程要么多进程，这样做效率显然不会高，

非阻塞IO可以一个线程处理多个流事件，只要不停的轮询所有流事件即可，当然这个方式也不好，当大多数流没数据时，也会大量浪费CPU资源，为了**避免CPU空转，引进代理**（select和poll)。

代理可以观察多个流IO事件，空闲时会把当前线程阻塞，当有一个或者多个IO事件时，就从阻塞态醒过来，把所有IO流轮询一遍，于是没有IO事件我们的程序就阻塞在select方法处

即便这样依然存在问题，我们从select出只是知道有IO事件发生，却不知道是哪几个流，还是只能轮询所有流，epoll这样的代理就可以把哪个流发生怎样的IO事件通知我们

**select/epoll的好处在于单个process就可以同时处理多个网络连接的IO**

IO复用和非阻塞IO本质一样，不过利用了新的select系统调用，由内核来符则本来是请求进程该做的轮询操作。看似比非阻塞IO还多了一个系统调用开销，不过因为可以支持多路IO，才算提高了效率。

它的基本原理就是`select/epoll`这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]  
当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个 socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

这个图和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。即**进程被阻塞在select处，而不是read、write等处**

综上所述：IO复用的核心思想是**将系统调用导致的进程阻塞都转移到一个代理处，代理在阻塞期间不断查看多个文件描述符的IO准备情况，有事件发生时则返回**，这样后面真正做事情的系统调用比如accept、read就不在阻塞进程了，大大提高了效率，并且可以让单线程程序具备了并发处理的能力

I/O 多路复用允许我们同时检查多个文件描述符，看其中任意一个是否可执行 I/O 操作，这对提高程序的性能很重要。通常，网络程序在下列情况下需要使用IO复用技术：

*  客户端程序要同时处理多个socket
 *  客户端程序要同时处理用户输入和网络连接
 *  TCP服务器要同时监听socket和连接socket。这是IO复用使用最多的场合
 *  服务器要同时处理TCP请求和UDP请求

需要指出的是，IO复用虽然能够同时监听多个文件描述符，但它本身是阻塞的。并且当多个文件描述符同时就绪时，如果不采取额外的措施，程序就只能按照顺序依次处理其中的每一个文件描述符，这使得服务器程序看起来像是串行工作的。如果要实现并发，只能使用多进程或者多线程等编程方法

## 信号驱动I/O模型 ##

信号驱动式I/O：首先我们允许Socket进行信号驱动IO,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。过程如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]

## 异步 I/O(asynchronous IO) ##

> 女友不想逛街，又餐厅太吵了，回家好好休息一下。于是我们叫外卖，打个电话点餐，然后我和女友可以在家好好休息一下，饭好了送货员送到家里来。这就是典型的异步，只需要打个电话说一下，然后可以做自己的事情，饭好了就送来了。

这类函数的工作机制是告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到用户空间）完成后通知我们。如图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]

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

# 各种I/O模型的比较 #

阻塞IO、IO复用、信号驱动IO都是同步IO模型。因为这三种IO模型中，IO的读写操作都是在IO事件发生之后，由应用程序来完成的

对于异步IO而言，用户可以直接对IO执行读写操作，这些操作告诉内核用户读写缓冲区的位置，以及IO操作完成之后内核通知应用程序的方式。异步IO读写操作总是逻辑返回，因为真正的读写操作已经由内核接管

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]  
从图6可以看到，前四种I/O模型的主要区别在于第一个阶段，它们的第二个阶段是一样的：在数据从内核复制到应用进程的缓冲区期间，进程会被阻塞于recvfrom系统调用。  
而异步I/O模型则是整个操作完成内核才通知应用进程。

也就是说：

*  同步：用户进程发起IO后，进行就绪判断，轮询内核状态。
 *  异步：用户进程发起IO后，可以做其他事情，等待内核通知。

同步和异步区分的是内核向应用程序是何种IO事件(是就绪事件还是完成事件)，以及该有谁来完成IO读写(是应用程序还是内核)

*  同步IO模型要求用户代码自行执行IO操作(将数据从内核缓冲区读入用户缓冲区或者将数据从用户缓冲区写入内核缓冲区)
 *  异步IO机制则由内核来执行IO操作（数据在内核缓冲区和数据缓冲区之间的移动是由内核在“后台”完成的）

换句话说：

*  同步IO向应用程序通知的是IO就绪事件
 *  异步IO向应用程序通知的是IO完成之间

![在这里插入图片描述][20210104115024921.png]

*  阻塞IO是最常用的，大部分程序使用的都是阻塞模式的IO
 *  非阻塞IO：可以防止进程阻塞在IO模型上，需要轮循，常与其他IO通知模型复用
 *  IO复用：允许同时对多个IO进行控制
 *  信号驱动IO：常用于异步通信

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221120/ba26e1846a144ffe8f5b57d72bcc9a95.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221120/26eb0c8d0d1c416aa6d0add3f6fb8178.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20221120/9bf99bf5947f46b685e9b1c5c73c9708.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]: /images/20221120/f1266ea114304de2920c5337a54f1395.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]: /images/20221120/87652ca8c2064d838dd2a7779ba388d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]: /images/20221120/1deead2d99e04369804816d47416cbf7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]: /images/20221120/e602d00a92a4448f8feb00099ed457a1.png
[20210104115024921.png]: /images/20221120/5544f3eccb9c45889316747c26521e8d.png