一文了解Linux 网络 I/O 模型

最新推荐文章于 2024-07-12 14:26:59 发布

dearfulan

最新推荐文章于 2024-07-12 14:26:59 发布

阅读量413

点赞数 1

分类专栏： IO 文章标签： IO模型 linux

本文链接：https://blog.csdn.net/qq_35448165/article/details/104729007

版权

IO 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1 什么是I/O

IO中的阻塞、非阻塞、同步、异步概念分析详解
通过上面这篇文章你可以知道同步、异步、阻塞、非阻塞这些概念，并且可以了解到java中I/O编程的三种模型，阻塞IO(BIO)、非阻塞IO(NIO)和异步IO(AIO)。

Java中提供的IO有关的API，在文件处理的时候，其实依赖操作系统层面的IO操作实现的。比如在Linux 2.6以后，Java中NIO和AIO都是通过epoll来实现的，而在Windows上，AIO是通过IOCP来实现的。可以把Java中的BIO、NIO和AIO理解为是Java语言对操作系统的各种IO模型的封装。程序员在使用这些API的时候，不需要关心操作系统层面的知识，也不需要根据不同操作系统编写不同的代码。只需要使用Java的API就可以了。

网络IO的本质是socket的读取，socket在linux系统被抽象为流，IO可以理解为对流的操作。 对于一次IO访问（以read举例），数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。所以说，

当一个read操作发生时，它会经历两个阶段:

等待数据准备 (Waiting for the data to be ready)。
将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)。

对于socket流而言，

第一步：通常涉及等待网络上的数据分组到达，然后被复制到内核的某个缓冲区。
第二步：把数据从内核缓冲区复制到应用进程缓冲区。

网络应用需要处理的无非就是两大类问题，网络IO，数据计算。相对于后者，网络IO的延迟，给应用带来的性能瓶颈大于后者。如果要想提高IO效率，需要将等的时间降低。

可以通过钓鱼的例子来理解下:
是在鱼塘里面的，我们的钓鱼动作的最终结束标志是鱼从鱼塘中被我们钓上来，放入鱼篓中。
这里面的鱼塘就可以映射成磁盘，中间过渡的鱼钩可以映射成内核空间，最终放鱼的鱼篓可以映射成用户空间。一次完整的钓鱼（IO）操作，是鱼（文件）从鱼塘（硬盘）中转移（拷贝）到鱼篓（用户空间）的过程

在Linux(UNIX)操作系统中，共有五种IO模型，分别是：阻塞IO模型、非阻塞IO模型、IO复用模型、信号驱动IO模型以及异步IO模型。

2 同步IO模型

2.1 阻塞IO模型

我们钓鱼的时候，有一种方式比较惬意，比较轻松，那就是我们坐在鱼竿面前，这个过程中我们什么也不做，双手一直把着鱼竿，就静静的等着鱼儿咬钩。一旦手上感受到鱼的力道，就把鱼钓起来放入鱼篓中。然后再钓下一条鱼。

映射到Linux操作系统中，这就是一种最简单的IO模型，即阻塞IO。阻塞 I/O 是最简单的 I/O 模型，一般表现为进程或线程等待某个条件，如果条件不满足，则一直等下去。条件满足，则进行下一步操作。

应用进程通过系统调用 recvfrom 接收数据，但由于内核还未准备好数据报，应用进程就会阻塞住，直到内核准备好数据报，recvfrom 完成数据报复制工作，应用进程才能结束阻塞状态。

这种钓鱼方式相对来说比较简单，对于钓鱼的人来说，不需要什么特制的鱼竿，拿一根够长的木棍就可以悠闲的开始钓鱼了（实现简单）。缺点就是比较耗费时间，比较适合那种对鱼的需求量小的情况（并发低，时效性要求低）。

BIO模型最大的问题就是当客户端并发访问量增加后，每个客户端的请求服务端都需要一个对应的线程来处理，客户端并发数:服务端线程=1:1 ，Java中的线程是比较宝贵的系统资源，线程数量快速膨胀后，系统的性能将急剧下降，随着访问量的继续增大，系统很可能"崩溃"

2.2 非阻塞IO模型

我们钓鱼的时候，在等待鱼儿咬钩的过程中，我们可以做点别的事情，比如玩一把王者荣耀、看一集《延禧攻略》等等。但是，我们要时不时的去看一下鱼竿，一旦发现有鱼儿上钩了，就把鱼钓上来。

映射到Linux操作系统中，这就是非阻塞的IO模型。应用进程与内核交互，目的未达到之前，不再一味的等着，而是直接返回EWOULDBLOCK错误。然后通过轮询的方式，不停的去问内核数据准备有没有准备好。如果某一次轮询发现数据已经准备好了，那就把数据拷贝到用户空间中。 "非阻塞就是将大的整片时间的阻塞分成N多的小的阻塞, 所以进程不断地有机会 '被' CPU光顾"

应用进程通过 recvfrom 调用不停的去和内核交互，直到内核准备好数据。如果没有准备好，内核会返回error，应用进程在得到error后，过一段时间再发送recvfrom请求。在两次发送请求的时间段，进程可以先做别的事情。

这种方式钓鱼，和阻塞IO比，所使用的工具没有什么变化，但是钓鱼的时候可以做些其他事情，增加时间的利用率。

优点：能够在轮询的间隔时间里处理其他事情（包括提交其他任务，也就是 “后台” 可以有多个任务在同时执行）。

缺点：任务完成的响应延迟增大了，因为每过一段时间才去轮询一次，而数据准备可能在两次轮询之间的任意时间完成。这会导致整体数据吞吐量的降低。

2.3 信号驱动IO模型

我们钓鱼的时候，为了避免自己一遍一遍的去查看鱼竿，我们可以给鱼竿安装一个重力报警器。当有鱼儿咬钩的时候立刻报警。然后我们再收到报警后，去把鱼钓起来。

映射到Linux操作系统中，这就是信号驱动IO。注册一个信号处理函数，然后应用进程告诉内核：当数据报准备好的时候，给我发送一个信号。收到信号后，对SIGIO信号进行捕捉，并且调用信号处理函数处理数据并获取结果。

应用进程预先向内核注册一个信号处理函数，然后用户进程返回，并且不阻塞，当内核数据准备就绪时会发送一个信号给进程，用户进程便在信号处理函数中开始把数据拷贝的用户空间中。

这种方式钓鱼，和前几种相比，所使用的工具有了一些变化，需要有一些定制（实现复杂）。但是钓鱼的人就可以在鱼儿咬钩之前彻底做别的事儿去了。等着报警器响就行了。

2.4 IO复用模型

我们钓鱼的时候，为了保证可以最短的时间钓到最多的鱼，我们同一时间摆放多个鱼竿，同时钓鱼。然后哪个鱼竿有鱼儿咬钩了，我们就把哪个鱼竿上面的鱼钓起来。

由于同步非阻塞方式需要不断主动轮询，轮询占据了很大一部分过程，会消耗大量的CPU资源，而 “后台” 可能有多个任务在同时进行，那么就想到了循环查询多个任务的完成状态，只要有任何一个任务完成(数据报准备号)，就去处理它。如果轮询不是使用的进程的用户态，而是有其他线程帮忙就更好了。那么这就是所谓的 “IO 多路复用”

生产中经常会用到的一种模型(Java的NIO就是基于IO复用模型)

多个进程的IO可以注册到同一个管道上，这个管道会统一和内核进行交互。当管道中的某一个请求需要的数据准备好之后，进程再把对应的数据拷贝到用户空间中。

IO多路复用使用了Linux提供的select/poll命令，进程通过将一个或多个fd传递给select或poll系统调用，当用户进程调用该select，select会监听所有注册好的fd，如果所有被监听的fd需要的数据都没有准备好时，select调用进程会阻塞。当任意一个fd处于就绪状态后，select调用就会返回，然后进程再通过recvfrom来进行数据拷贝。

select/poll是顺序扫描fd是否就绪，而且支持的fd数量有限，因此它的使用受到了一些制约。
Linux还提供一个epoll系统调用，epoll使用基于事件驱动方式代替顺序扫描，因此性能更高。当有fd就绪时，立即回调函数rollback。

这里的IO复用模型，并没有向内核注册信号处理函数，所以，他并不是非阻塞的。进程在发出select后，要等到select/epoll监听的所有IO操作中至少有一个需要的数据准备好，才会有返回，并且也需要再次发送请求去进行文件的拷贝。

这种方式的钓鱼，通过增加鱼竿的方式，可以有效的提升效率。

2.5 小结

上面的阻塞IO模型、非阻塞IO模型、IO复用模型和信号驱动IO模型都是同步的IO模型。原因是因为，无论以上那种模型，真正的数据拷贝过程，都是同步进行的。

信号驱动是内核是在数据准备好之后通知进程，然后进程在通过recvfrom操作进行数据拷贝。我们可以认为数据准备阶段是异步的，但是，数据拷贝操作是同步的。所以，整个IO过程也不能认为是异步的。

而IO复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，整个用户的进程其实是一直被block的。只不过进程是被select这个函数block，而不是被socket IO给block。所以IO多路复用是阻塞在select，epoll这样的系统调用之上，而没有阻塞在真正的I/O系统调用如recvfrom之上。

我们把钓鱼过程，可以拆分为两个步骤：1、鱼咬钩（数据准备）。2、把鱼钓起来放进鱼篓里（数据拷贝）。无论以上提到的哪种钓鱼方式，在第二步，都是需要人主动去做的，并不是鱼竿自己完成的。所以，这个钓鱼过程其实还是同步进行的。