Linux中的五种I/O模型


一、阻塞I/O模型

进程读取数据时会一直阻塞等待,等待内核通过系统调用对数据进行处理,直到数据包到达且被复制到缓冲区或者发生错误时才返回。

I/O中的阻塞等待一般指的是等待内核数据准备好数据从内核态拷贝到用户态这两个过程

阻塞I/O模型的特点是实现难度低,应用开发较为容易。但由于每次I/O请求都会阻塞进程,所以需要为每个请求分配一个进程或线程以确保及时响应,系统开销大,并不适用于并发量较大的应用。


二、非阻塞I/O模型

进程读取数据时可以通过MSG_DONTWAIT标志位非阻塞读,此时如果缓冲区没有数据,会直接返回一个EAGAIN或EWOULDBLOCK错误,而不会让进程一直等待。但这也意味着如果进程想要读取数据就需要不断发起读请求,直到读取到数据为止。

非阻塞I/O模型的特点是实现难度低,应用开发较为容易。但是进程轮询会消耗大量的CPU资源,不适用于并发量较大的应用。


三、I/O复用模型

I/O复用模型的思路就是将多个进程的I/O注册到一个复用器(select、poll或epoll)上,并由该复用器对数据读取进行监听。

以select为例,如果select监听的I/O在内核缓冲区都没有可读数据,select调用进程就会被阻塞。但只要当任一I/O在内核缓冲区中有可读数据时,select调用就会返回,这时select进程再去通知I/O进程读取内核中准备好的数据。

可以看到,在采用I/O复用模型后,尽管有多个进程注册了I/O,但只有一个select进程会被阻塞。

Linux中I/O复用的实现方式主要有select、poll和epoll。

1.select

select基于轮询的方式进行对文件描述符进行监听,因此需要在内核反复遍历传递进来的所有文件描述符,这在注册了大量I/O时会导致性能急剧下降。

此外,每次调用select时都需要把文件描述符集合从用户态拷贝到内核态,这个开销在文件描述符很多时也会很大。

同时select的监听数量也有限制

2.poll

poll与select一样,也是基于轮询的方式进行对文件描述符进行监听,只不过修改了文件描述符集合的结构,没有了监听数量的限制。

但是轮询监听整体复制导致的开销问题依然没有解决。

3.epoll

epoll从Linux 2.6后开始支持,底层数据结构为红黑树,增删改综合效率高。而且epoll模型修改主动轮询为被动通知,所以epoll在注册套接字后,主程序可做其他事情,当事件发生时,接收到通知后再去处理。同时由mmap实现内核与用户空间的消息传递,监听数量大效率高。

可以将epoll理解为event poll,epoll会通知其他进程哪个流发生了哪种I/O事件,所以epoll是事件驱动

epoll触发方式分为水平触发和边缘触发:

  • 水平触发(LT):默认触发方式,只要该文件描述符还有数据可读,每次epoll_wait都会返回它的事件,提醒数据处理进程去操作。
  • 边缘触发(ET):高速触发方式,只会提示一次,无论文件描述符中是否还有数据可读,在下次数据流入之前都不会再提示。所以在ET模式读取时是一定要将数据尽量一次全部取出。

四、信号驱动I/O模型

当进程发起一个IO操作,会通过系统调用sigaction向内核注册一个信号处理函数,然后进程返回不阻塞。当内核中有数据就绪时会发送一个信号给读取进程,读取进程会在信号处理回掉函数中调用I/O读取数据。

信号驱动I/O模型基于回调机制实现,但应用开发难度较大,且实际应用较少。


五、异步I/O模型

当进程发起一个I/O操作后会告知内核处理I/O,随后该进程直接返回不阻塞,但也不能立刻得到结果。等到内核把整个I/O处理完后会通知该进程,如果I/O操作成功则进程直接获取到数据。

异步I/O模型与信号驱动模型的主要区别在于:信号驱动I/O是由内核通知应用程序何时启动一个I/O操作,而异步I/O模型是由内核通知应用程序I/O操作何时完成,不需要该进程进行数据读取。

无论阻塞I/O还是非阻塞I/O都是同步调用。因为数据读取时,内核将数据从内核空间拷贝到用户空间的过程都是需要等待的,也就是说这个过程是同步的,如果内核的拷贝效率不高,就会在这个同步过程中等待比较长的时间。而真正的异步I/O是内核数据准备好数据从内核态拷贝到用户态这两个过程都不用等待

异步I/O能够充分利用DMA特性,让I/O操作与计算重叠。但要实现真正的异步I/O需要操作系统做大量的工作。目前Windows下通过IOCP实现了真正的异步I/O,Linux系统在Linux2.6才引入AIO且并不完善,因此在Linux下实现高并发网络编程时仍然是以I/O复用模型为主

基于同步异步,有Reactor和Proactor两种网络模式:

  • Reactor是非阻塞同步网络模式,感知的是就绪可读写事件。在每次感知到可读就绪事件后,需要应用进程主动完成数据读取,也就是要应用进程主动将socket接收到缓存中的数据读到应用进程内存中,这个过程是同步的,读取完数据后应用进程才能处理数据。
  • Proactor是异步网络模式,感知的是已完成的读写事件。在发起异步读写请求时,需要传入数据缓冲区的地址等信息,这样系统内核才可以自动帮我们把数据的读写工作完成。这里的读写工作全程由操作系统来做,并不需要像Reactor那样还需要应用进程主动读写数据,操作系统完成读写工作后,就会通知应用进程直接处理数据。

猜你喜欢

转载自blog.csdn.net/qq_43686863/article/details/129916544