本节的重点:
1. 理解五种IO模型,重点是非阻塞IO以及IO多路转接
2. 区分阻塞IO和非阻塞IO的区别;
3. 区分同步IO和异步IO的区别
4. 掌握select编程模型,能够实现select版本的TCP服务器
5. 掌握poll编程模型,能够实现poll版本的TCP服务器
6. 掌握epoll编程模型,能够实现epoll版本的http服务器
7. 理解epoll的LT模式和ET模式
8. select poll 和 epoll三者之间优缺点对比
本节重点需要掌握的是:
一. IO :
我们可以先看一下下面这篇文章,了解一下冯诺曼体系结构,
了解一下所有的设备都只能直接和内存打交道这个概念:
https://blog.csdn.net/qq_37941471/article/details/80668386
#### 1. IO介绍:
1. I就是input输入,O就是output输出,一起就是基本输入输出设备;
2. 每个设备都会有一个专用的I/O地址,用来处理自己的输入输出信息。
I/O地址绝对不能重复,如果两个设备的I/O地址有冲突,系统硬件就不能正常工作。
#### 2、IO模型 :
对于一次IO访问(以read举例),数据会先被拷贝到操作系统内核的缓冲区中,
然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。
所以说,当一个read操作发生时,它会经历两个阶段:
(1) 等待数据准备
(2)将数据从内核拷贝到进程中
在网络编程环境中,一次IO操作主要包括两个部分:
1. 等数据准备
2. 拷贝数据
所以如果想要提高IO效率,就应该想办法让等的比重减少。
二 . 五种IO模型:
1. IO模型分类:同步IO 和 异步IO
2. 同步IO包括:
(1)阻塞式I/O;
(2)非阻塞I/O;
(3)I/O多路转接(select poll epoll);也叫 I/O多路复用
(4)信号驱动I/O(SIGIO);
3. 同步IO 和 异步IO的区别:
首先我们关注的是:消息通信机制
同步IO : 发出一个调用时,在没有得到结果之前,该调用就不返回
自己等自己进行数据拷贝
异步IO :发出一个调用,这个调用就直接返回了
1. 自己不等也不进行数据拷贝
2. 自己只是实现了发起和接受返回
4. 阻塞IO 和 非阻塞IO 的区别:
关注的是:等待调用结果时的状态
阻塞IO : 在内核数据准备好之前,系统调用会一直等待。
非阻塞IO :在不能立刻得到结果之前,该调用不会阻塞当前线程
####1、阻塞IO
在linux中,默认情况下所有的socket都是阻塞的;
在内核数据准备好之前,系统调用会一直等待。
具体流程如下:
(1)当用户进程调用了recvfrom这个系统调用,kernel就开始了IO的第一个阶段:
准备数据(对于网络IO来说,很多时候数据在一开始还没有到达。
比如,还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来)。
这个过程需要等待,也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。
而在用户进程这边,整个进程会被阻塞(当然,是进程自己选择的阻塞)。
(2)当kernel一直等到数据准备好了,它就会将数据从kernel中拷贝到用户内存,
然后kernel返回结果,用户进程才解除block的状态,重新运行起来。
####2、非阻塞IO
如果内核还未将数据准备好,系统调用仍然会直接返回,
并且返回EWOULDBLOCK错误码。
轮询 :非阻塞IO往往需要程序员用循环的方式去反复尝试读写文件描述符
这个过程就是轮询
1. 一般非阻塞IO方式有两种:
1. 调用非阻塞接口
2. 将文件描述符设置为非阻塞的
2. 具体执行过程如下:
(1)当用户进程发出read操作时,如果kernel中的数据还没有准备好,
那么它并不会block用户进程,而是立刻返回一个error。
(2)从用户进程角度讲 ,它发起一个read操作后,并不需要等待,而是马上就得到了一个结果
用户进程判断结果是一个error时,它就知道数据还没有准备好,于是它可以再次
发送read操作(这个反复尝试读写文件描述符的过程称为轮询)。
(3)一旦kernel中的数据准备好了,并且又再次收到了用户进程的system call,
那么它马上就将数据拷贝到了用户内存,然后返回。
####3、信号驱动IO
内核将数据准备好之后,使用SIGIO信号通知程序进行IO操作
其具体过程如下:
(1)首先开启套接口信号驱动I/O功能,并通过系统调用sigaction执行一个信号处理函数
(此系统调用立即返回,进程继续工作,它是非阻塞的)。
(2)当数据准备就绪时,就为该进程生成一个SIGIO信号,通过信号回调
通知应用程序调用recvfrom来读取数据,并通知主循环函数处理数据。
####4、异步IO
由内核在数据完成拷贝时,通知应用程序。
流程图如下:
(1)用户进程发起read操作之后,立刻就可以开始去做其它的事。
(2)而另一方面,从kernel的角度,当它受到一个asynchronous read之后,
首先它会立刻返回,所以不会对用户进程产生任何block。
(3)然后,kernel会等待数据准备完成,然后将数据拷贝到用户内存,当这一切都完成之后,
kernel会给用户进程发送一个signal,告诉它read操作完成了。
#### 5. 异步IO和信号驱动IO的区别 :
信号驱动I/O : 由内核通知我们何时可以开始一个I/O操作;
异步I/O : 由内核通知我们I/O操作何时已经完成。
一个是开始IO,一个是IO已经完成。
6 . IO多路转接:
####1. IO多路转接的作用—提高效率:
在数据通信过程中,分为两部分:
1. 是等待数据到达内核;
2. 是将数据从内核拷贝到用户区。
而往往在实际应用中,等待的时间往往比拷贝的时间多,所以我们如果想要提高效率;
必然就是要将等的时间减少(在一定的时间内,减少等待的比重)
1. 这个时候,IO多路转接就是解决这个问题的:一次监视多个文件描述符
在IO多路转接中,由于一次等待多个文件描述符,
在单位时内就绪事件发生的概率就越大,所以等的比重就会越小。
2. 而这里我们会有一个问题:监视的文件描述符返回条件是什么?
答: 1. 监视的文件描述符都有自己要关注的事件(读/写/异常事件
2. 返回条件就是:我们所监视(关心)的文件描述符的事件至少一个已经就绪
3. IO多路转接的实现方式:
1. select
2. poll
3. epoll等
当然还有好多,具体下面我们来讲一下这三种实现方式以及之间的关系!
2. select模型及实现select版本的TCP服务器 :
https://blog.csdn.net/qq_37941471/article/details/80954592
3. poll模型及实现poll版本的TCP服务器 :
https://blog.csdn.net/qq_37941471/article/details/80962592
4. epoll模型及实现epoll版本的http服务器 :
https://blog.csdn.net/qq_37941471/article/details/80979422
4. select poll epoll 三者之间的优缺点对比:
下面我讲一下我对select poll epoll的理解:
首先这三个都是实现 IO多路转接 的方式:一个进程同时监视多个文件描述符
也就是三者之间的共同优点
1. select
缺点:
1. 代码编写复杂,维护起来较麻烦
2. 每次调用select,都需要重新设置文件描述符(从用户态拷贝到内核态),开销大
为什么需要重新设置?
因为select的输入输出都调用的是同一个函数select,并且输入和输出
是单独作为参数的这个时候我们就需要用一个第三方数组来保存之前的
所关心的文件描述符,以便进行select返回后,和fdset进行FDISSET
判断哪一个所监听的描述符哪个就绪,进行accept操作,并且方便下一次监听
3. 使用过程中,从内核遍历文件描述符,当fd很多的时候,则会开销很大
需要以轮询的方式去获取就绪的文件描述符
4. 能够接收的文件描述符有上限
因为有第三方数组去维护,而这个数组开的最大空间就是:sizeof(fd_set)*8
一般的操作系统,默认的是1024(一个bit位表示一个文件描述符
(因为fd_set的底层是一个位图))
2. poll
优点 :
1. select的输入输出都是调用一个函数,参数是分开的,用位图来描述,
使用起来开销会比较大;而poll使用一个pollfd的结构体来实现的
2. 解决了select能处理的文件描述符有上限的问题
因为poll解决了selec输入输出参数分开的问题,进而当然不需要再用第三方数组
去维护;所以poll能处理的文件描述符可以说是无上限了
(而这里肯定有它的一个上限,但是这个上限是操作系统的上限,和poll没有关系)
缺点:
除了解决了select的部分缺点以外,其他的缺点poll也是有的
3. epoll
在poll的基础上,又做了改进:处理了大批量句柄问题
所以这三个是一步一步改进的,最终epoll是最高效的IO多路的就绪通知机制;
(这个高效的基础是:多连接,少量活跃的机制;如果场景不合适的话,有可能适得其反)
三. 举例更好的理解五种IO模型:
(1)阻塞式I/O :
张三在钓鱼,当鱼没有上钩时,便一直进行等待;当鱼上钩后,将鱼拿出。
期间他一直在等待,不做任何事。
(2)非阻塞I/O :
张三在钓鱼,这次,当鱼没有上钩时,他便去干别的事:和旁边人聊天或者玩玩手机;
当鱼上钩后,将鱼调出。
这个时候他确实是自己等待了,但是他没有一直等待,而是在等待的过程中做了别的事。
(3)I/O多路转接:
张三在钓鱼,这次他放了一百个鱼竿。依次检查这些鱼竿;
当一个鱼竿有鱼上钩后,将鱼调出,然后继续检查所有鱼竿。
显然这个钓鱼的方式是效率很高的:因为别人都是一个人只拿一个鱼竿,
而张三用了100个鱼竿,放在鱼的角度,在100多的鱼竿中,当然张三的鱼竿被咬住的几率大
(4)信号驱动I/O模型 :
张三钓鱼时,将鱼竿上放一个铃铛,当鱼上钩后会响。
然后他便可以干自己的事情,当领响时,他知道上钩了,再去收鱼
(5)异步I/O :
张三准备钓鱼,这次他直接雇了个人给自己钓鱼。
整个过程中,张三并没有做任何事,没有等,也没有将鱼拿起来;
或者:
典型的异步编程模型比如Node.js
举个通俗的例子:你打电话问书店老板有没有《分布式系统》这本书,如果是同步通信机制,书店老板会说,你稍等,"我查一下",然后开始查啊查,等查好了(可能是5秒,也可能是一天)告诉你结果(返回结果)。而异步通信机制,书店老板直接告诉你我查一下啊,查好了打电话给你,然后直接挂电话了(不返回结果)。然后查好了,他会主动打电话给你。在这里老板通过"回电"这种方式来回调。
四. 总结:
1. 任何IO过程中,都包含两个步骤。一是等待,二是拷贝。
在实际的应用场景中,等待消耗的时间往往都远远高于拷贝的时间。
所以,让IO更高效, 最核心的办法就是 :
让等待的时间尽量少,也就是阻塞越少,理论上效率也是最优。
2. 同步IO 和 异步IO的区别:
首先我们关注的是:消息通信机制
同步IO : 发出一个调用时,在没有得到结果之前,该调用就不返回
自己等自己进行数据拷贝
异步IO :发出一个调用,这个调用就直接返回了
1. 自己不等也不进行数据拷贝
2. 自己只是实现了发起和接受返回
3. 阻塞IO 和 非阻塞IO 的区别:
关注的是:等待调用结果时的状态
阻塞IO : 在内核数据准备好之前,系统调用会一直等待。
非阻塞IO :在不能立刻得到结果之前,该调用不会阻塞当前线程
4. 异步IO和信号驱动IO的区别 :
信号驱动I/O : 由内核通知我们何时可以开始一个I/O操作;
异步I/O : 由内核通知我们I/O操作何时已经完成。
一个是开始IO,一个是IO已经完成。