Linux 的 Socket IO 模型

之前有看到用很幽默的方式讲解Windows的socket IO模型，借用这个故事，讲解下linux的socket IO模型；

老陈有一个在外地工作的女儿，不能经常回来，老陈和她通过信件联系。

他们的信会被邮递员投递到他们小区门口的收发室里。这和Socket模型非常类似。

下面就以老陈接收信件为例讲解linux的 Socket I/O模型。

一、同步阻塞模型

老陈的女儿第一次去外地工作，送走她之后，老陈非常的挂心她安全到达没有；于是老陈什么也不干，一直在小区门口收发室里等着她女儿的报平安的信到；这就是linux的同步阻塞模式；

在这个模式中，用户空间的应用程序执行一个系统调用，并阻塞，直到系统调用完成为止(数据传输完成或发生错误)。

Socket设置为阻塞模式，当socket不能立即完成I/O操作时，进程或线程进入等待状态，直到操作完成。

如图1所示：

显然，代码中的connect, send, recv都是同步阻塞工作模式，在结果没有返回时，程序什么也不做。

这种模型非常经典，也被广泛使用。

优势在于非常简单，等待的过程中占用的系统资源微乎其微，程序调用返回时，必定可以拿到数据；但简单也带来一些缺点，程序在数据到来并准备好以前，不能进行其他操作，需要有一个线程专门用于等待，这种代价对于需要处理大量连接的服务器而言，是很难接受的。

二、同步非阻塞模型

收到平安信后，老陈稍稍放心了，就不再一直在收发室前等信；而是每隔一段时间就去收发室检查信箱；这样，老陈也能在间隔时间内休息一会，或喝杯荼，看会电视，做点别的事情；

这就是同步非阻塞模型；

同步阻塞 I/O 的一种效率稍低的变种是同步非阻塞 I/O。

在这种模型中，系统调用是以非阻塞的形式打开的。

这意味着 I/O 操作不会立即完成， 操作可能会返回一个错误代码，说明这个命令不能立即满足（EAGAIN 或 EWOULDBLOCK），非阻塞的实现是 I/O 命令可能并不会立即满足，需要应用程序调用许多次来等待操作完成。

这可能效率不高，因为在很多情况下，当内核执行这个命令时，应用程序必须要进行忙碌等待，直到数据可用为止，或者试图执行其他工作。

因为数据在内核中变为可用到用户调用 read 返回数据之间存在一定的间隔，这会导致整体数据吞吐量的降低。

如图2所示：

这种模式在没有数据可以接收时，可以进行其他的一些操作，比如有多个socket时，可以去查看其他socket有没有可以接收的数据；实际应用中，这种I/O模型的直接使用并不常见，因为它需要不停的查询，而这些查询大部分会是无必要的调用，白白浪费了系统资源；

非阻塞I/O应该算是一个铺垫，为I/O复用和信号驱动奠定了非阻塞使用的基础。我们可以使用 fcntl(fd, F_SETFL, flag | O_NONBLOCK);

将套接字标志变成非阻塞，调用recv，如果设备暂时没有数据可读就返回-1，同时置errno为EWOULDBLOCK（或者EAGAIN，这两个宏定义的值相同），表示本来应该阻塞在这里（would block，虚拟语气），事实上并没有阻塞而是直接返回错误，调用者应该试着再读一次（again）。

这种行为方式称为轮询（Poll），调用者只是查询一下，而不是阻塞在这里死等，这样可以同时监视多个设备：

while(1)
{
非阻塞read(设备1);
if(设备1有数据到达)
处理数据;

非阻塞read(设备2);
if(设备2有数据到达)
处理数据;

…………………………
}

如果read(设备1)是阻塞的，那么只要设备1没有数据到达就会一直阻塞在设备1的read调用上，即使设备2有数据到达也不能处理，使用非阻塞I/O就可以避免设备2得不到及时处理。

非阻塞I/O有一个缺点，如果所有设备都一直没有数据到达，调用者需要反复查询做无用功，如果阻塞在那里，操作系统可以调度别的进程执行，就不会做无用功了，在实际应用中非阻塞I/O模型比较少用

三、I/O 复用(异步阻塞)模式

频繁地去收发室对老陈来说太累了，在间隔的时间内能做的事也很少，而且取到信的效率也很低.于是，老陈向小区物业提了建议；小区物业改进了他们的信箱系统：住户先向小区物业注册，之后小区物业会在已注册的住户的家中添加一个提醒装置，每当有注册住房的新的信件来临，此装置会发出 “新信件到达”声，提醒老陈去看是不是自己的信到了。

这就是异步阻塞模型；

在这种模型中，配置的是非阻塞 I/O，然后使用阻塞 select 系统调用来确定一个 I/O 描述符何时有操作。

使 select 调用非常有趣的是它可以用来为多个描述符提供通知，而不仅仅为一个描述符提供通知。

对于每个提示符来说，我们可以请求这个描述符可以写数据、有读数据可用以及是否发生错误的通知

I/O复用模型能让一个或多个socket可读或可写准备好时，应用能被通知到；

I/O复用模型早期用select实现，它的工作流程如下图：

用select来管理多个I/O，当没有数据时select阻塞，如果在超时时间内数据到来则select返回，再调用recv进行数据的复制，recv返回后处理数据。

下面的C语言实现的例子，它从网络上接受数据写入一个文件中:

perl实现:

四、信号驱动 I/O 模型

老陈接收到新的信件后，一般的程序是：打开信封—-掏出信纸 —-阅读信件—-回复信件 ……为了进一步减轻用户负担，小区物业又开发了一种新的技术：住户只要告诉小区物业对信件的操作步骤，小区物业信箱将按照这些步骤去处理信件，不再需要用户亲自拆信 /阅读/回复了！

这就是信号驱动I/O模型

我们也可以用信号，让内核在描述字就绪时发送SIGIO信号通知我们。

首先开启套接口的信号驱动 I/O功能，并通过sigaction系统调用安装一个信号处理函数。

该系统调用将立即返回，我们的进程继续工作，也就是说没被阻塞。

当数据报准备好读取时，内核就为该进程产生一个SIGIO信号，我们随后既可以在信号处理函数中调用recvfrom读取数据报，并通知主循环数据已准备好待处理，也可以立即通知主循环，让它读取数据报。

无论如何处理SIGIO信号，这种模型的优势在于等待数据报到达期间，进程不被阻塞，主循环可以继续执行，只要不时地等待来自信号处理函数的通知：既可以是数据已准备好被处理，也可以是数据报已准备好被读取。

五、异步非阻塞模式

linux下的asynchronous IO其实用得很少。

与前面的信号驱动模型的主要区别在于：信号驱动 I/O是由内核通知我们何时可以启动一个 I/O操作，而异步 I/O模型是由内核通知我们 I/O操作何时完成 。

先看一下它的流程：

这就是异步非阻塞模式

以read系统调用为例

steps：

a. 调用read;
b. read请求会立即返回，说明请求已经成功发起了。
c. 在后台完成读操作这段时间内，应用程序可以执行其他处理操作。
d. 当 read 的响应到达时，就会产生一个信号或执行一个基于线程的回调函数来完成这次 I/O 处理过程。

server端程序:

用户进程发起read操作之后，立刻就可以开始去做其它的事。

而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。

然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

六、总结

到目前为止，已经将四个IO Model都介绍完了。

现在回过头来回答两个问题：

• blocking和non-blocking的区别在哪?

• synchronous IO和asynchronous IO的区别在哪。

先回答最简单的这个：blocking vs non-blocking。前面的介绍中其实已经很明确的说明了这两者的区别。

• 调用blocking IO会一直block住对应的进程直到操作完成，

• 而non-blocking IO在kernel还在准备数据的情况下会立刻返回。

在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。

Stevens给出的定义（其实是POSIX的定义）是这样子的：

• A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;

• An asynchronous I/O operation does not cause the requesting process to be blocked;

两者的区别就在于:

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。

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

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

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

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

最后，再举几个不是很恰当的例子来说明这五个IO Model:

有A，B，C，D，E五个人钓鱼：

• A用的是最老式的鱼竿，所以呢，得一直守着，等到鱼上钩了再拉杆；

• B的鱼竿有个功能，能够显示是否有鱼上钩，所以呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；

• C用的鱼竿和B差不多，但他想了一个好办法，就是同时放好几根鱼竿，然后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；

• D是个有钱人，他没耐心等， 但是又喜欢钓上鱼的快感，所以雇了个人，一旦那个人发现有鱼上钩，就会通知D过来把鱼钓上来；

• E也是个有钱人，干脆雇了一个人帮他钓鱼，一旦那个人把鱼钓上来了，就给E发个短信。