码迷,mamicode.com
首页 > 系统相关 > 详细

Linux 的 Socket IO 模型

时间:2016-12-13 10:00:13      阅读:342      评论:0      收藏:0      [点我收藏+]

标签:lis   过程   ott   hit   虚拟   scene   model   文章   应用程序调用   

前言


之前有看到用很幽默的方式讲解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发个短信。






Linux 的 Socket IO 模型

标签:lis   过程   ott   hit   虚拟   scene   model   文章   应用程序调用   

原文地址:http://www.cnblogs.com/sanyuanempire/p/6168624.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!