学步园

转自:http://blog.csdn.net/jjdiaries/article/details/16357313

在linux网络编程【1-3】中，我们编写的网络程序仅仅是为了了解网络编程的基本步骤，实际应用当中的网络程序并不会用那样的。实际网络程序多使用select、poll、epoll等多路IO复用。在进入主题之前，我们先来了解一下linux的IO模型。

现有的linux IO模型有5种：阻塞式IO模型，非阻塞式IO模型，IO复用模型，信号驱动式IO模型，异步IO模型。

关于阻塞、非阻塞、同步、异步，甚至并发等待，这些概念一直没有很好的理解，特意翻阅一些资料和博文，汇总如下：

1.阻塞IO模型

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

2.非阻塞IO模型

　　linux下，可以通过设置socket使其变为non-blocking，从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。所以，用户进程其实是需要不断的主动询问kernel数据好了没有。这种模型需要用户进程不断的查询内核，比较消耗cpu，所以应用得比较少。

3.IO多路复用模型

　　IO multiplexing这个词可能有点陌生，但是如果我说select，epoll，大概就都能明白了。有些地方也称这种IO方式为event driven 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。

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

4.信号驱动的IO模型

　　首先通过sigaction系统调用注册信号处理函数，然后立即返回，进程继续运行，这一过程是非阻塞的。当数据准备好后，内核发送SIGIO信号给进程，进程收到该信号后，读取准备好的数据。

5.异步IO模型

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

总结对比：

　　从上面表格所列的我们对阻塞非阻塞，同步异步的理解，我们编写的网络程序基本上很少使用异步。事实上，我们用的最多的模型应该是IO多路复用模型，且通常将其中的每一个socket都设置为非阻塞。

　　next.....