菜狗杂谈----浅谈UNIX/Linux系统IO

IO模型：

英文术语	翻译
blocking IO	阻塞IO
nonblocking IO	非阻塞IO
IO myltiplexing	IO多路复用
signal driven IO	信号驱动IO
asynchronous IO	异步IO

IO是通过共享一条总线的方式来实现的，总线也就是一条或者多条物理上的导线，每个部件都接到这些导线上，导线上的电位每个时刻都是相等的，这样总线上的所有部件都会受到相同的信号。也就是说，这条总线是共享的，同一个时刻只能有一个部件在接收或者发送，是全单工的工作模式
所有的部件按照另一条总线，也就是仲裁总线或者中断总线上给出的信号来判断这个时刻总线可以由哪个部件来使用。产生仲裁总线或者中断电位的可以是CPU，也可以是总线上的其他设备

由于signal driven IO在实际中并不常用，这里只看剩下的四种IO Model

当操作系统里发生一个IO的读操作时，会涉及到系统中的两个对象，一个是调用这个IO的process(或者thread)，另一个就是系统内核(kernel)

发生这个read读操作时，在系统中通常会经历两个阶段：
等待接收数据阶段(waiting for data to be ready)
将数据从内核拷贝到进程中(copying data from kernel to process)
各种IO模型的区别就是这两个阶段中的不同操作

0x1.blocking IO(阻塞IO)

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

0x2.non-blocking IO(非阻塞IO)

linux中，可以通过设置socket使其变为non-blocking

当用户进程发出read操作时，kernel没有准备好的时候，系统并不会block用户进程，而是立刻返回一个error
对用户来说，发起一个read操作后，并不需要等待，而是马上就得到了一个结果。
用户进程发现返回结果是一个error时，用户进程就知道kernel数据还没有准备好，于是用户进程就可以再次发送read操作

等到kernel中的数据准备好了，并且又再次收到了用户进程的系统调用(system call)，recvfrom就马上将数据拷贝到用户内存，然后返回
在这段时间内，进程是被block的。所以用户进程需要不断的主动询问kernel数据好了没有

在网络IO时候，非阻塞IO也会进行recvfrom的系统调用，检查数据是否准备好。

与阻塞IO不一样，非阻塞IO将大的整片时间的阻塞分成多个小的阻塞，所以非阻塞IO的recvfrom被系统调用之后，进程并没有被阻塞，内核返回信息给用户进程
如果数据没准备好，返回信息就为error。进程在返回之后，可以执行别的任务，然后再发起recvfrom系统调用。

重复上面的过程，循环往复的进行recvfrom系统调用，这个过程通常称为轮询

轮询检查内核数据是否准备好，等到数据准备好，再拷贝数据到进程，由进程对数据进行处理
拷贝整个数据的过程，进程仍然是属于阻塞的状态

非阻塞IO的优点：
能够在等待任务完成的时间里执行其他任务
非阻塞IO的缺点：
每过一段时间轮询一次，而任务可能在两次轮询之间的任意时间完成了，所以任务完成的响应延迟增大了，也会导致整体数据吞里吐量的降低

0x3.IO multiplexing(IO多路复用)

IO multiplexing也可以称作select或者epoll。
其好处就在于单个process就可以同时处理多个网络连接的IO

其基本有原理就是select/epoll这个function会不断的轮询所负责的所有socket。
当某个socket有数据到达了，就通知用户进程处理。
当用户进程调用了select，那么整个进程会被block，同时，kernel会“监视”所有select负责的socket
当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程

IO multiplexing和blocking IO其实并没有太大的不同，因为IO mmultiplexing需要使用两个system call(select和recvfrom)
而blocking IO只需要一个system call。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。
如果处理的连接数不是很高的话，使用select/epoll的服务端不一定比使用multithreading+blocking IO的服务端性能更好，可能延迟还更大。

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

0x4.Asynchronous IO(异步IO)

用户进程发起read操作后，立刻就可以开始去做其它的事
而从kernel的角度，当它受到一个异步读取操作之后，首先评它会立刻返回，所以不会对用户进程产生任何阻塞
然后，kernel会等待数据准备完成。然后将数据拷贝到用户内存，拷贝完成后，kernel会给用户进程发送一个signal,交由用户进程操作

0x5.IO模块比较分析

blocking与non-blocking的区别在于:
blocking IO会一直阻塞用户进程直到操作完成
non-blocking IO在kernel还准备数据的情况下会立刻返回，执行别的操作，直到kernel给出数据已准备好的信号，再执行这个操作

synchronous IO和asynchronous IO的区别就在于：
synchronous IO做IO操作的时候会将process阻塞
按照这个说法，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO
而asynchronous IO则不一样，当进程发起IO 操作之后，就不管了。直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block

如图所示：

总结

经过上面的比较，会发现non-blocking IO和asynchronous IO的区别还是很明显的

在non-blocking IO中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。

而asynchronous IO则完全不同。它是用户进程将整个IO操作交给kernel操作，然后kernel操作完成后发信号通知用户进程。在此期间，用户进程不需要去检查IO操作的状态，也不需要主动的去拷贝数据