NingG +

IO 模型

2015-10-21

疑问：

本文最重要的参考文献是Richard Stevens的UNIX® Network Programming Volume 1, Third Edition 6.2节 I/O Models，Stevens在这节中详细说明了各种IO的特点和区别，如果英文够好的话，推荐直接阅读。

简介

IO 模型，解决哪些问题？

IO模型，要解决的根本问题：应用程序，如何高效率的，读写多个文件？

内核，屏蔽底层硬件的差异。

对一个socket的读写也会有相应的描述符，称为socketfd(socket描述符）。描述符就是一个数字，指向内核中一个结构体（文件路径，数据区，等一些属性）。那么我们的应用程序对文件的读写就通过对描述符的读写完成。

linux将内存分为内核区，用户区。linux内核给我们管理所有的硬件资源，应用程序通过调用系统调用和内核交互，达到使用硬件资源的目的。应用程序通过系统调用read发起一个读操作，这时候内核创建一个文件描述符，并通过驱动程序向硬件发送读指令，并将读的的数据放在这个描述符对应结构体的内核缓存区中，然后再把这个数据读到用户进程空间中，这样完成了一次读操作。

一个文件，需要通过内核缓冲区与用户进程交互，其中，内核缓冲区包含：读缓冲区、写缓冲区。

[补充]：IO 模型，还有一个类似的概念：服务器并发模型，其中会提到多进程并发、多线程并发等

IO 模型

Stevens在文章中一共比较了五种IO Model：

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

再说一下IO发生时涉及的对象和步骤。

对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process (or thread)，另一个就是系统内核(kernel)。当一个read操作发生时，它会经历两个阶段：

  1. 等待数据准备 (Waiting for the data to be ready)
  2. 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

记住这两点很重要，因为这些IO Model的区别就是在两个阶段上各有不同的情况。

blocking IO

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

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以，blocking IO的特点就是在IO执行的两个阶段都被block了。

non-blocking IO

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

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。

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

IO multiplexing

IO multiplexing这个词可能有点陌生，但是如果我说select，epoll，大概就都能明白了。有些地方也称这种IO方式为 Event driven IO (事件驱动 IO)。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了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。

Asynchronous I/O

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

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

小结

到目前为止，已经将四个IO Model都介绍完了。现在回过头来回答最初的那几个问题：

先回答最简单的这个：blocking vs non-blocking。前面的介绍中其实已经很明确的说明了这两者的区别。调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。即，关键是「数据准备」阶段，是否block。

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

两者的区别就在于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。即，关键是「数据从kernel buffer拷贝到process buffer」阶段，是否block。

各个IO Model的比较如图所示：

小结：

再举几个不是很恰当的例子来说明这四个IO Model:

有A，B，C，D四个人在钓鱼：

  1. A用的是最老式的鱼竿，所以呢，得一直守着，等到鱼上钩了再拉杆；
  2. B的鱼竿有个功能，能够显示是否有鱼上钩，所以呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；
  3. C用的鱼竿和B差不多，但他想了一个好办法，就是同时放好几根鱼竿，然后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；
  4. D是个有钱人，干脆雇了一个人帮他钓鱼，一旦那个人把鱼钓上来了，就给D发个短信。

补充说明

阻塞IO vs. 多路复用IO

IO多路复用模型与前面介绍的阻塞IO模型相比，似乎并没有优势，甚至还多一次系统调用。

事实上，若应用程序操作的fd只有1个时，通过select实现IO多路复用模式确实没有优势，但当进程操作的fd远不只1个时，select的优势就会体现出来，此时，这些fd通过select进行统一管理，这极大地简化了编程实现细节。

但目前kernel的select实现代码中，它能管理的fd上限默认只有1024个，且它在内部是通过依次遍历来确定某个fd是否可读/写的。因此，即使可以通过修改kernel相关代码来增加其管理的fd上限，但遍历fd数组仍然是个线性操作。因此，在fd数量较大时，通过select或poll实现的IO多路复用模型也会存在性能问题。

select vs. poll vs. epoll

详细介绍和比较参考：IO模型：阻塞/非阻塞/IO复用 同步/异步 Select/Epoll/AIO.

目前流行的Web Server（如Nginx）通常是通过内核提供的epoll或kqueue来管理fd的。

以epoll为例，其工作模式与本文介绍的I/O多路复用模型类似，只不过其管理的fd(s)满足读/写条件时，内核会通过回调通知epoll来获取这些fd，应用程序调用的epoll_wait会将这些可读/写的fd返回给应用程序；而采用select方式实现IO多路复用模式时，符合读/写条件的fd是通过select内部遍历整个fd数组来获取的，显然，epoll方式下的fd触发方式更高效。也正是由于回调触发避免了线性遍历，epoll可管理的fd数量可以很大且不影响触发性能。

由于epoll是通过事件驱动的（其事件触发方式分为Edge Triggered和Level Triggered两种，二者区别可通过man epoll查看），因此，借助epoll实现的IO操作模式又被称为 Event-Driven I/O模型。

在epoll模式下，由于epoll_wait通常是个阻塞调用，故epoll是个阻塞模型；至于同步还是异步，与epoll管理的fd被触发后的处理方式有关。 具体而言：

  1. 若其管理的fd可读/写条件触发后，进程主线程负责处理该fd对应的数据，则由于回调函数中真正进行数据读/写的IO操作仍然会阻塞（这里的阻塞是指从内核缓冲区拷贝数据至应用进程缓冲区的过程中，进程主线程会阻塞，阻塞时间取决于数据量），因此，从POSIX规范对同步/异步的定义来看，这种处理逻辑下的epoll模型是个同步模型。
  2. 若其管理的fd可读/写条件触发后，进程主线程将该fd压入队列，由其它线程负责从队列中消费该fd，则由于主线程不会阻塞，故这种处理逻辑下，此时的epoll模型是个异步模型。

多路复用IO

在IO编程过程中，当需要处理多个请求的时，可以使用多线程和IO复用的方式进行处理。上面的图介绍了整个IO复用的过程，它通过把多个IO的阻塞复用到一个select之类的阻塞上，从而使得系统在单线程的情况下同时支持处理多个请求。和多线程/进程比较，I/O多路复用的最大优势是系统开销小，系统不需要建立新的进程或者线程，也不必维护这些线程和进程。IO复用常见的应用场景：

参考来源

原文地址：https://ningg.top/io-model/
微信公众号 ningg, 联系我

同类文章:

微信搜索: 公众号 ningg, 联系我, 交个朋友.

京ICP备19013747号-1
Top