Linux 5种IO模型
用户空间和内核空间
任何Linux发行版,其系统内核都是Linux,我们的应用都需要通过linux内核和硬件交互。
为了避免用户应用导致冲突甚至内核崩溃,用户空间和内核分离的。
- 进程的寻址空间会划分为两部分:内核空间、用户空间
Linux 5-IO模型
阻塞IO
顾名思义,阻塞IO就是两个阶段都必须阻塞等待。
非阻塞IO
顾名思义,非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。
- 用户进程一直循环 在问内核空间数据是否准备好了,没有准备好返回错误,ok的话,返回数据。盲等空转的情况下,可能导致cpu暴增。
- 当内核空间数据没有准备好的情况下,从内核空间给用户空间copy的线程,是阻塞的。
无论是阻塞IO还是非阻塞IO,用户应用在一阶段都需要调用recvfrom来获取数据,差别在与无数据时的处理方案
- 如果调用recvfrom时,恰好没有数据,阻塞IO会使进程阻塞,非阻塞IO使CPU空转,都不能充分发挥CPU的性能
- 如果调用recvfrom时,恰好有数据,则用户进程可以直接进入第二阶段,读取并处理数据。
比如服务端处理客户端Socket请求时,在单线程情况下,智能一次处理每一个socket,如果正在处理的socket恰好未就绪,线程就会被阻塞,所有其他客户端socket都必须等待,性能自然会差。
多路复用IO
文件描述符:简称FD(File Description),是一个从0开始递增的无符号整数,用来关联linux中的一个文件。在linux 中,一切皆文件,例如常规文件、视频、硬件设备等,当然有包括套接字(socket)。
IO多路复用:是利用单个线程来同时监听多个FD,并在某个FD可读、可写时得到通知,从而避免无效的等待,充分利用CPU资源。
监听FD的方式、通知的方式有多种实现,常见的有一下几种
Select模式
select模式存在的问题
- 需要将整个fd_set从用户空间拷贝到内核空间,select结束还要再次拷贝回用户空间
- select 无法得知具体是哪个fd就绪,需要遍历整个fd_set
- fd_set 监听的fd数量不能超过1024
Poll模式
poll模式对select模式做了简单改进,但性能提升不明显。
IO流程
- 创建pollfd数组,向其中添加关注的fd信息,数组大小自定义
- 调用poll函数,将pollfd数据拷贝到内核空间,转链表存储,无上限
- 内核遍历fd,判断是否就绪
- 数据就绪或者超时后,拷贝pollfd数组到用户空间,返回就绪的fd数量n
- 用户进程判断n是否大于0
- 大于0则遍历pollfd数组,找到就绪的fd。
与select对比
- select模式中的fd_set大小固定为1024,而pollfd在内核中采用链表,理论上无上限
- 监听fd越多,每次遍历消耗时间越长,性能反而下降
Epoll模式
Epoll模式中如何解决这些问题?
- 基于epoll实例中的红黑树保存要监听的FD,理论上无上限,而且增删改查效率都非常高,性能不会随监听的FD数量增多而下降
- 每个FD只需要执行一次epoll_ctl 添加到红黑树,以后每次epol_wait无需传递任何参数,无需重复拷贝FD 到内核空间
- 内核会将就绪的FD直接拷贝到用户空间的指定位置,用户进程无需遍历所有的Fd就知道就绪的FD是谁
总结
- select 和poll 只会通知用户进程有FD就绪,但不确定具体是哪个FD,需要用户进程逐个遍历FD 来确认。
- epoll 则会在通知用户进程的FD 就绪的同时,把已就绪的FD写入用户空间
信号驱动IO
信号驱动IO:是与内核建立SIGIO的信号关联并设置回调,当内核有Fd就绪时,会发出SIGIO信号通知用户,期间用户应用可以执行其他业务,无需阻塞等待。
缺点:
当有大量IO操作时,信号较多,SIGIO处理函数不能及时处理可能导致信号队列溢出。
而且内核空间与用户空间的频繁信号交互性能也比较低。
异步IO
异步IO 的整个过程都是非阻塞的,用户进程调用完异步api 就可以去做其他的事情,内核等待数据就绪并拷贝到用户空间后才会递交信号,通知用户进程。
同步和异步
IO 操作是同步还是异步,关键看数据在内核空间还是用户空间的拷贝过程,(数据读写的IO操作)。也就是阶段二是同步还是异步。