Linux 的 Socket IO 模型

前言

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

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

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

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

1、同步阻塞模型

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

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

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

如图1所示：

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

这种模型很是经典，也被普遍使用。

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

2、同步非阻塞模型

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

这就是同步非阻塞模型；

同步阻塞 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模型比较少用

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

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

这就是异步阻塞模型；

在这种模型中，配置的是非阻塞 I/O，而后使用阻塞 select 系统调用来肯定一个 I/O 描述符什么时候有操做。

使 select 调用很是有趣的是它能够用来为多个描述符提供通知，而不只仅为一个描述符提供通知。

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

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

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

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

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

perl实现:

4、信号驱动 I/O 模型

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

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

咱们也能够用信号，让内核在描述字就绪时发送SIGIO信号通知咱们。

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

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

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

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

5、异步非阻塞模式

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操做完成了。

6、总结

到目前为止，已经将四个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发个短信。

阅读

投诉

精选留言

该文章做者已设置需关注才能够留言

写留言

该文章做者已设置需关注才能够留言

写留言

加载中

以上留言由公众号筛选后显示

了解留言功能详情

微信扫一扫
关注该公众号

来自为知笔记(Wiz)