五种IO模型祥解

在学习nginx的架构时讲到：NGINX是最知名的模块化，事件驱动，异步，单线程Web服务器和Web代理之一。所以就稍微了解下网络IO模型的基础知识。
IO有内存IO、网络IO和磁盘IO三种，通常我们说的IO指的是后两者。网络IO的本质是socket的读取，socket在linux系统被抽象为流，IO可以理解为对流的操作。对于一次IO访问（以read举例）当一个read操作发生时，它会经历两个阶段：

1. 第一阶段：等待数据准备，数据从磁盘拷贝到内核空间 (Waiting for the data to be ready)。
2. 第二阶段：将数据从内核空间拷贝到进程空间 (Copying the data from the kernel to the process)。

网络IO的模型大致有如下几种：

1. 阻塞IO（bloking IO）
2. 非阻塞IO（non-blocking IO）
3. 多路复用IO（multiplexing IO） select，poll，epoll
4. 信号驱动式IO（signal-driven IO）
5. 异步IO（asynchronous IO）

1 阻塞式IO模型

去餐馆吃饭，点一个自己最爱吃的盖浇饭，然后在原地等着一直到盖浇饭做好，自己端到餐桌就餐。这就是典型的同步阻塞。当厨师给你做饭的时候，你需要一直在那里等着。

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

2 非阻塞IO模型

接着上面的例子，你每次点完饭就在那里等着，突然有一天你发现自己真傻。于是，你点完之后，就回桌子那里坐着，然后估计差不多了，就问老板饭好了没，如果好了就去端，没好的话就等一会再去问，依次循环直到饭做好。这就是同步非阻塞。

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
在非阻塞式IO中，用户进程其实是需要不断的主动询问kernel数据准备好了没有。用户线程每次请求IO都可以立即返回，但是为了拿到数据，需不断轮询，无谓地消耗了大量的CPU。

3 I/O复用模型

接着上面的列子，你点一份饭然后循环的去问好没好显然有点得不偿失，还不如就等在那里直到准备好，但是当你点了好几样饭菜的时候，你每次都去问一下所有饭菜的状态(未做好/已做好)肯定比你每次阻塞在那里等着好多了。当然，你问的时候是需要阻塞的，一直到有准备好的饭菜或者你等的不耐烦(超时)。这就引出了IO复用，也叫多路IO就绪通知。这是一种进程预先告知内核的能力，让内核发现进程指定的一个或多个IO条件就绪了，就通知进程。使得一个进程能在一连串的事件上等待。

IO多路复用建立在内核提供的阻塞函数select上，用户先将需要进行IO操作的socket添加到select中，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

这个图和blocking IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。（多说一句：所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）

为什么epoll,kqueue比select高级？
答案是，他们无轮询。因为他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

4 信号驱动IO模型

上文的就餐方式还是需要你每次都去问一下饭菜状况。于是，你再次不耐烦了，就跟老板说，哪个饭菜好了就通知我一声吧。然后就自己坐在桌子那里干自己的事情。更甚者，你可以把手机号留给老板，自己出门，等饭菜好了直接发条短信给你。这就类似信号驱动的IO模型。

应用进程告诉内核：当你的数据报准备好的时候，给我发送一个信号哈，并且调用我的信号处理函数来获取数据报。这个模型是由信号进行驱动。

5 异步IO模型

真正的异步IO需要操作系统更强的支持。Linux下的asynchronous IO其实用得不多，从内核2.6版本才开始引入。

之前的就餐方式，到最后总是需要你自己去把饭菜端到餐桌。这下你也不耐烦了，于是就告诉老板，能不能饭好了直接端到你的面前或者送到你的家里(外卖)。这就是异步非阻塞IO了。

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

IO多路复用模型中，数据到达内核后通知用户线程，用户线程负责从内核空间拷贝数据;
而在异步IO模型中，当用户线程收到通知时，数据已经被操作系统从内核拷贝到用户指定的缓冲区内，用户线程直接使用即可。

相比于IO多路复用，异步IO并不常用，因为目前操作系统对异步IO的支持并不完善，IO多路复用也基本够用. 有很多做法是用IO多路复用模型模拟异步IO（IO事件触发时不直接通知用户线程，而是将数据读写完毕后放到用户指定的缓冲区中）。