【Linux】浅谈I/O模型

关于I/O模型的引出

我们都知道，为了OS的安全性等的考虑，进程是无法直接操作I/O设备的，其必须通过系统调用请求内核来协助完成I/O动作，而内核会为每个I/O设备维护一个buffer。如下图所示：因此整个请求过程即为：用户进程发起请求，内核接受到请求后，从I/O设备中获取数据到buffer中，再将buffer中的数据copy到用户进程的地址空间，该用户进程获取到数据后再响应客户端。

在整个请求的过程中，数据输入至buffer需要时间，而从buffer复制数据至进程也需要时间。因此根据在这两段时间内等待方式的不同，I/O动作可以分为以下五种模式：

阻塞I/O (Blocking I/O)
非阻塞I/O (Non-Blocking I/O)
I/O复用（I/O Multiplexing)
信号驱动的I/O (Signal Driven I/O)
异步I/O (Asynchrnous I/O)

关于I/O模型的划分

概念解释：

阻塞：调用的进程一直处于等待状态，直到操作完成。其实对于操作系统而言，阻塞不是什么坏事，不然要我操作系统干嘛。操作系统功能之一就是系统资源的调度，当某个进程（线程）阻塞了，它就能调度CPU资源给别的进程。
非阻塞：在内核的数据还未准备好时，会立即返回，进程可以去干其他事情。它是让应用不断的轮询，直到拿到数据。它相比于阻塞，会浪费一些CPU，自然性能也就会差一些了。

阻塞其实就是把调度的权力给了操作系统，让操作系统来提高利系统用率。非阻塞则是把这个权力给了开发者，因为不阻塞的话我们可以做些别的事情，类似于程序内部的一个调度功能。

同步：由应用向内核发起请求，到应用获取数据，期间一直是应用作为会话的发起者。
异步：应用获取数据这次会话，是由内核发起的。

可以看出，二者的区别就是在于最终获取到数据这个会话，是哪边发起的。对于应用而言，主动就是同步，被动就是异步。（这个有点像CPU的同步/异步中断），二者的区别在于代价，也就是管理的灵活和切换的性能损耗。因为在同步程序中，第一步完成后，需要切换任务。而异步程序就不需要了，它继续干它自己的活。那么切换的代价就小了。

从同步异步，以及阻塞、非阻塞两个维度来划分来看

I/O模型分述

1. 阻塞I/O

首先，要从你常用的IO操作谈起，比如read和write，通常IO操作都是阻塞I/O的，也就是说当你调用read时，如果没有数据收到，那么线程或者进程就会被挂起，直到收到数据。

从上图可以看到在整个过程中，当用户进程进行系统调用是，内核就开始了I/O的第一个阶段，准备数据到缓冲区中，当数据都准备完成后，则将数据从内核缓冲区中拷贝到用户进程的内存中，这时用户进程才解除block的状态重新运行。所以，Blocking I/O的特点就是在I/O执行的两个阶段都被block了。

这样，当服务器需要处理1000个连接的的时候，而且只有很少连接忙碌的，那么会需要1000个线程或进程来处理1000个连接，而1000个线程大部分是被阻塞起来的。由于CPU的核数或超线程数一般都不大，比如4,8,16,32,64,128，比如4个核要跑1000个线程，那么每个线程的时间槽非常短，而线程切换非常频繁。

这样是有问题的：

1. 线程是有内存开销的，1个线程可能需要512K（或2M）存放栈，那么1000个线程就要512M（或2G）内存。

2. 线程的切换，或者说上下文切换是有CPU开销的，当大量时间花在上下文切换的时候，分配给真正的操作的CPU就要少很多。

那么，我们就要引入非阻塞I/O的概念

2. 非阻塞I/O

非阻塞IO很简单，通过fcntl（POSIX）或ioctl（Unix）设为非阻塞模式，这时，当你调用read时，如果有数据收到，就返回数据，如果没有数据收到，就立刻返回一个错误，如EWOULDBLOCK。这样是不会阻塞线程了，但是你还是要不断的轮询来读取或写入。

从上图可以看到在I/O执行的两个阶段中，用户进程只有在第二个阶段被阻塞了，而第一个阶段没有阻塞，但是在第一个阶段中，用户进程需要盲等，不停的去轮询内核，看数据是否准备好了，因此该模型是比较消耗CPU的。

于是，我们需要引入IO多路复用的概念。

3. I/O多路复用

多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）。

从上图可以看到在I/O复用模型中，I/O执行的两个阶段都是用户进程都是阻塞的，但是两个阶段是独立的，在一次完整的I/O操作中，该用户进程是发起了两次系统调用。这样在处理1000个连接时，只需要1个线程监控就绪状态，对就绪的每个连接开一个线程处理就可以了，这样需要的线程数大大减少，减少了内存开销和上下文切换的CPU开销。

使用select函数的方式如下图所示：

4. 信号驱动的I/O

该模型也叫作基于事件驱动的I/O模型，可以看到该模型中，只有在I/O执行的第二阶段阻塞了用户进程，而在第一阶段是没有阻塞的，乍看起来感觉和非阻塞模型很相似，其实不同之处就在于，该模型在I/O执行的第一阶段，当数据准备完成之后，会主动的通知用户进程数据已经准备完成，即对用户进程做一个回调。该通知分为两种，一为水平触发，即如果用户进程不响应则会一直发送通知，二为边缘触发，即只通知一次。

5. 异步I/O

在该模型中，当用户进程发起系统调用后，立刻就可以开始去做其它的事情，然后直到I/O执行的两个阶段都完成之后，内核会给用户进程发送通知，告诉用户进程操作已经完成了。

五种模型总结

以上全由自己所理解的一点点东西来写，因此可能会有诸多不当之处，还望指正，谢谢！