Linux高级IO

GG_Bond21

已于 2023-08-25 16:24:16 修改

阅读量1.1k

点赞数 3

分类专栏： Linux系统文章标签： linux 服务器

于 2023-05-24 21:04:30 首次发布

本文链接：https://blog.csdn.net/GG_Bruse/article/details/130817818

版权

Linux系统专栏收录该内容

17 篇文章 3 订阅

订阅专栏

本文介绍了IO的基本概念，通过钓鱼故事生动地解释了IO的等待和拷贝两个步骤，并分析了五种IO模型：阻塞式IO、非阻塞式IO、信号驱动IO、IO多路转接和异步IO。每种模型的特点和应用场景，以及它们如何影响系统的效率。重点强调了高效IO的关键在于减少等待时间，增加数据拷贝的效率。

摘要由CSDN通过智能技术生成

一、IO基本概念

什么是IO？

I/O（input/output）即输入和输出，在冯诺依曼体系结构中，将数据从输入设备拷贝到内存就即输入，将数据从内存拷贝到输出设备就即输出

对文件进行的读写操作本质就是一种IO，文件IO对应的外设是磁盘
对网络进行的读写操作本质也是一种IO，网络IO对应的外设是网卡

OS如何得知外设中有数据可读取？

输入就是操作系统将数据从外设拷贝到内存的过程，操作系统一定要通过某种方法得知特定外设上是否有数据就绪

并不是操作系统想要从外设读取数据时外设上就一定有数据。如用户正在访问某台服务器，当用户的请求报文发出后就需等待从网卡中读取服务器发来的响应数据，但此时服务器可能还没有收到请求报文，或是正在对请求报文进行数据分析，也可能服务器发来的响应数据还在网络中路由
但操作系统不会主动去检测外设上是否有数据就绪，这种做法会降低操作系统的工作效率，因为大部分情况下外设中都是没有数据的，因此操作系统所做的大部分检测工作其实都是徒劳的
操作系统实际采用的是中断的方式来得知外设上是否有数据就绪的，当某个外设上面有数据就绪时，该外设就会向CPU中的中断控制器发送中断信号，中断控制器再根据产生的中断信号的优先级按顺序发送给CPU
每一个中断信号都有一个对应的中断处理程序，存储中断信号和中断处理程序映射关系的表被称为中断向量表，当CPU收到某个中断信号时就会自动停止正在运行的程序，然后根据该中断向量表执行该中断信号对应的中断处理程序，处理完毕后再返回原被暂停的程序继续运行

注意：CPU不直接和外设交互指的是在数据层面上，而外设其实是可以直接将某些控制信号发送给CPU中的某些控制器的。

OS如何处理从网卡中读取到的数据包？

操作系统任何时刻都可能会收到大量的数据包，因此操作系统须将这些数据包管理起来。所谓的管理即"先描述，再组织"，在内核中有一个结构sk_buff，该结构就是用来管理和控制接收或发送数据包的信息

简化版的sk_buff结构：

当操作系统从网卡中读取到一个数据包后，会将该数据依次交给链路层、网络层、传输层、应用层进行解包和分用，最终将数据包中的数据交给了上层用户，那对应到这个sk_buff结构来说具体是如何进行数据包的解包和分用的呢？

当操作系统从网卡中读取到一个数据包后，就会定义一个sk_buff结构，然后用sk_buff结构中的data指针指向这个读取到的数据包，并将这个sk_buff结构与其他sk_buff结构以双链表的形式组织起来，此时操作系统对各个数据包的管理就变成了对双链表的增删查改等操作
接下来需要将读取上来的数据包交给最底层的链路层处理，进行链路层的解包和分用，让sk_buff结构中的mac_header指针指向最初的数据包，然后向后读取链路层的报头，剩下的就是要交给网络层处理的有效载荷了，此时便完成了链路层的解包
这时链路层就需要将有效载荷向上交付给网络层进行解包和分用了，所谓的向上交付只是形象的说法，实际向上交付并不是要将数据从链路层的缓冲区拷贝到网络层的缓冲区，只需让sk_buff结构中的network_header指针，指向数据包中链路层报头后的数据即可，然后继续向后读取网络层的报头，便完成了网络层的解包
紧接着就是传输层对数据进行处理，同样的道理，让sk_buff结构中的transport_header指针，指向数据包中网络层报头后的数据，然后继续向后读取传输层的报头，便完成了传输层的解包
传输层解包后就可以根据具体使用的传输层协议，对应将剩下的数据拷贝到TCP或UDP的接收缓冲区供用户读取即可

发送数据时对数据进行封装也是同样的道理，即依次在数据前面拷贝上对应的报头。应用层以下，数据包在进行封装和解包的过程中，本质数据的存储位置是没有发生变化的，实际只是在用不同的指针对数据进行操作

但内核中的sk_buff并不像上面那样简单：

一方面，为了保证高效的网络报文处理效率，要求sk_buff的结构必须是高效的
另一方面，sk_buff结构需要被内核协议中的各个协议共同使用，因此sk_buff必须能够兼容所有网络协议

什么是高效的IO？

IO主要分为两步：

第一步是等，即等待IO条件就绪
第二步是拷贝，即当IO条件就绪后将数据拷贝到内存或外设

任何IO的过程，都包含"等"和"拷贝"这两个步骤，但在实际的应用场景中"等"消耗的时间往往比"拷贝"消耗的时间多，因此要让IO变得高效，最核心的办法就是尽量减少"等"的时间

二、钓鱼故事理解IO

IO的过程其实和钓鱼是非常类似的

钓鱼的过程同样分为"等"和"拷贝"两个步骤，只不过这里的"等"指的是等鱼上钩，"拷贝"指的是当鱼上钩后将鱼从河里"拷贝"到鱼桶中
IO时"等"消耗的时间往往比"拷贝"消耗的时间多，钓鱼也符合这个特点，钓鱼时大部分时间都在等鱼上钩，而当鱼上钩后只需要一瞬间就能将鱼"拷贝"上来

下面给出五个人的钓鱼方式：

张三：拿1个鱼竿，将鱼钩抛入水中后就死死的盯着浮漂，什么也不做，当有鱼上钩后就挥动鱼竿将鱼钓上来
李四：拿1个鱼竿，将鱼钩抛入水中后就去玩手机了，然后定期观察浮漂，若有鱼上钩则挥动鱼竿将鱼钓上来，否则继续去做其他事情
王五：拿1个鱼竿，将鱼钩抛入水中后在鱼竿顶部绑一个铃铛，然后就去玩手机了，若铃铛响了就挥动鱼竿将鱼钓上来，否则就不管鱼竿
赵六：拿100个鱼竿，将100个鱼竿抛入水中后就定期观察这100个鱼竿的浮漂，如果某个鱼竿有鱼上钩则挥动对应的鱼竿将鱼钓上来。
田七：田七是一个有钱的老板，他给了自己的司机一个桶、一个电话、一个鱼竿，让司机去钓鱼，当鱼桶装满的时候再打电话告诉田七来拿鱼，而田七自己则开车去做其他事情去了

张三、李四、王五的钓鱼效率是否一样？为什么？

张三、李四、王五的钓鱼效率本质上是一样的

其钓鱼方式都是一样的，都是先等鱼上钩，然后再将鱼钓上来
其次，因为他们每个人都是拿的一根鱼竿，当河里有鱼来咬鱼钩时，这条鱼咬哪一个鱼钩的概率都是相等的

因此张三、李四、王五三个人的钓鱼的效率是一样的，只是等鱼上钩的方式不同而已，张三是死等，李四是定期检测浮漂，而王五是通过铃铛来判断是否有鱼上钩

问题是钓鱼效率是否是一样的，而不是问整体谁做的事最多，若说整体做事情的量的话，那一定是王五做得最多，李四次之，张三最少

张三、李四、王五它们三个人分别和赵六比较，谁的钓鱼效率更高？

赵六是四个人中钓鱼效率最高的，因为赵六同时在等多个鱼竿上有鱼上钩，因此在单位时间内，赵六的鱼竿有鱼上钩的概率是最大的

为了方便计算，假设赵六拿了97个鱼竿，加上张三、李四、王五的鱼竿一共就有100个鱼竿
当河里有鱼来咬鱼钩时，这条鱼咬张三、李四、王五的鱼钩的概率都是百分之一，而咬赵六的鱼钩的概率就是百分之九十七
因此在单位时间内，赵六的鱼竿上有鱼的概率是张三、李四、王五的97倍

而高效的钓鱼就是要减少单位时间内"等"的时间，增加"拷贝"的时间，所以说赵六的钓鱼效率是这四个人中最高的

赵六的钓鱼效率之所以高，是因为赵六一次等待多个鱼竿上的鱼上钩，可以将"等"的时间进行重叠

如何看待田七的这种钓鱼方式？

田七让司机帮自己钓鱼，自己开车去做其他事情去了，此时这个司机具体怎么钓鱼已经不重要了，他可以模仿张三、李四、王五、赵六任何一个人的钓鱼方式进行钓鱼

最重要的是田七本人并没有参与整个钓鱼的过程，只是发起了钓鱼的任务，而真正钓鱼的是司机，田七在司机钓鱼期间可能在做任何其他事情，若将钓鱼看作是一种IO的话，那田七的这种钓鱼方式即异步IO

而对于张三、李四、王五、赵六而言，都需要自己等鱼上钩，当鱼上钩后又需要自己把鱼从河里钓上来，对应到IO中就是需要自行进行数据的拷贝，因此他们四个人的钓鱼方式即同步IO

五种IO模型

实际这五个人的钓鱼方式分别对应的就是五种IO模型。

张三这种死等的钓鱼方式对应即阻塞式IO
李四这种定时检测是否有鱼上钩的方式即非阻塞IO
王五这种通过设置铃铛得知事件是否就绪的方式即信号驱动IO
王五这种一次等待多个鱼竿上有鱼的钓鱼方式即IO多路转接
田七这种让别人帮自己钓鱼的钓鱼方式即异步IO

通过这里的钓鱼例子可以看到发现，阻塞IO、非阻塞IO和信号驱动IO本质上是不能提高IO的效率的，但非阻塞IO和信号驱动IO能提高整体做事的效率

其中，这个钓鱼场景中的各个事物都能与IO中的相关概念对应起来，比如这里钓鱼的河对应就是内核，这里每一个人都是进程或线程，鱼竿对应的就是文件描述符或套接字，装鱼的桶对应的就是用户缓冲区

三、五种IO模型

3.1 阻塞式IO

阻塞IO即在内核将数据准备好前，系统调用会一直等待

阻塞IO是最常见的IO模型，套接字默认都是阻塞方式

如当调用recvfrom函数从某个套接字上读取数据时，可能底层数据还没准备好，此时就需等待数据就绪，当数据就绪后再将数据从内核拷贝到用户空间，最后recvfrom函数才会返回
在recvfrom函数等待数据就绪期间，在用户看来该进程或线程就阻塞了，本质就是操作系统将该进程或线程的状态设置为了某种非R状态，然后将其放入等待队列中，当数据就绪后操作系统再将其从等待队列中唤醒，然后该进程或线程再将数据从内核拷贝到用户空间

以阻塞方式进行IO操作的进程或线程，在"等"和"拷贝"期间都不会返回，在用户看来就是阻塞了，因此被称为阻塞IO

3.2 非阻塞IO

非阻塞IO：若内核还未将数据准备好，系统调用仍然会直接返回，并且返回EWOULDBLOCK错误码

非阻塞IO需要程序员以循环的方式反复尝试读写文件描述符，即轮询，这对CPU是较大的浪费，一般只有特定场景下使用

如当调用recvfrom函数以非阻塞方式从某个套接字上读取数据时，若底层数据还没有准备好，那么recvfrom函数会立马错误返回，而不会让该进程或线程进行阻塞等待
因为没有读取的数据，因此该进程或线程后续还需要继续调用recvfrom函数，检测底层数据是否就绪，若没有就绪则继续错误返回，直到某次检测到底层数据就绪后，再将数据从内核拷贝到用户空间然后进行成功返回
每次调用recvfrom函数读取数据时，就算底层数据没有就绪，recvfrom函数也会立马返回，在用户看来该进程或线程就没有被阻塞，因此被称为非阻塞IO

阻塞IO和非阻塞IO的区别在于，阻塞IO当数据没有就绪时，后续检测数据是否就绪的工作是由操作系统发起的，而非阻塞IO当数据没有就绪时，后续检测数据是否就绪的工作是由用户发起的

3.3 信号驱动IO

信号驱动IO：当内核将数据准备好后，使用SIGIO信号通知应用程序进行IO操作

当底层数据就绪的时候会向当前进程或线程递交SIGIO信号，因此可以通过signal或sigaction函数将SIGIO的信号处理程序自定义为需要进行的IO操作，当底层数据就绪时就会自动执行对应的IO操作

比如需要调用recvfrom函数从某个套接字上读取数据，那么就可以将该操作定义为SIGIO的信号处理程序
当底层数据就绪时，操作系统就会递交SIGIO信号，此时就会自动执行定义的信号处理程序，进程将数据从内核拷贝到用户空间

信号的产生是异步的，但信号驱动IO是同步IO的一种

信号的产生异步的，因为信号在任何时刻都可能产生
但信号驱动IO是同步IO的一种，因为当底层数据就绪时，当前进程或线程需要停下正在做的事情，转而进行数据的拷贝操作，当前进程或线程仍然需要参与IO过程

判断一个IO过程是同步的还是异步的，本质就是看当前进程或线程是否需要参与IO过程，若参与即为同步IO，否则为异步IO

3.4 IO多路转接

IO多路转接也被称为IO多路复用，能够同时等待多个文件描述符的就绪状态

IO多路转接的思想：

因为IO过程分为"等"和"拷贝"两个步骤，因此使用的recvfrom等接口的底层实际上都做了两件事，第一件事是数据不就绪时需要等，第二件事是数据就绪后需要进行拷贝
虽然recvfrom等接口也有"等"的能力，但这些接口一次只能"等"一个文件描述符上的数据或空间就绪，IO效率太低
因此系统提供了三组接口，即select、poll和epoll，这些接口的核心工作就是"等"，可将所有"等"的工作都交给这些多路转接接口
因为这些多路转接接口是一次"等"多个文件描述符的，因此能将"等"的时间重叠，数据就绪后再调用对应的recvfrom等函数进行数据的拷贝，此时这些函数就能够直接进行拷贝，而不需要"等"了

IO多路转接就像是帮人排队的黄牛，因为多路转接接口实际并没有进行数据拷贝。排队黄牛可以一次帮多个人排队，此时就将多个人排队的时间进行了重叠

3.5 异步IO

异步IO：由内核在数据拷贝完成时，通知应用程序

进行异步IO需调用一些异步IO接口，异步IO接口调用后会立马返回，因为异步IO不需要发起者进行"等"和"拷贝"的操作，都由操作系统来完成，只需发起IO
当IO完成后操作系统会通知应用程序，因此进行异步IO的进程或线程并不参与IO的所有细节

四、重要概念

4.1 异步通信 && 同步通信

同步和异步关注的是消息通信机制

所谓同步，在发出一个调用时，在没有得到结果之前，该调用就不返回，但是一旦调用返回，就得到返回值了；即由调用者主动等待这个调用的结果
异步则是相反，调用在发出之后，这个调用就直接返回了，所有没有返回结果；即当一个异步过程调用发出后，调用者不会立刻得到结果；而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用

为什么非阻塞IO在没有得到结果之前就返回了？

IO是分为"等"和"拷贝"两步的，当调用recvfrom进行非阻塞IO时，若数据没有就绪，那么调用会直接返回，此时这个调用返回时并没有完成一个完整的IO过程，即便调用返回了也是属于错误的返回
因此该进程或线程后续还需继续调用recvfrom，轮询检测数据是否就绪，当数据就绪后再把数据从内核拷贝到用户空间，这才是一次完整的IO过程
因此，在进行非阻塞IO时，在没有得到结果之前，虽然这个调用会返回，但后续还需要继续进行轮询检测，因此可以理解成调用还没有返回，而只有当某次轮询检测到数据就绪，并且完成数据拷贝后才认为该调用返回了

同步通信、同步与互斥

在多进程和多线程中有同步与互斥的概念，但是这里的同步通信和进程或线程之间的同步是不相干的概念

进程/线程同步指的是，在保证数据安全的前提下，让进程/线程能够按照某种特定的顺序访问临界资源，从而有效避免饥饿问题，谈论的是进程/线程间的一种工作关系
同步IO指的是进程/线程与操作系统之间的关系，谈论的是进程/线程是否需要主动参与IO过程

因此当看到"同步"这个词的时候，需先明确这个"同步"是同步通信的同步，还是同步与互斥的同步

4.2 阻塞 && 非阻塞

阻塞和非阻塞关注的是程序在等待调用结果（消息、返回值）时的状态

阻塞调用是指调用结果返回之前，当前线程会被挂起，调用线程只有在得到结果之后才会返回
非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程

4.3 其他高级IO

非阻塞IO，记录锁，系统V流机制，I/O多路转接（I/O多路复用），readv和writev函数以及存储映射IO（mmap），统称为高级IO

五、阻塞IO

系统中大部分的接口都是阻塞式接口，如使用read函数从标准输入中读取数据

#include <iostream>
#include <unistd.h>
#include <fcntl.h>
using namespace std;

int main()
{
	char buffer[1024];
	while (true){
		ssize_t size = read(0, buffer, sizeof(buffer)-1);
		if (size < 0){
			cerr << "read error" << endl;
			break;
		}
		else {
            buffer[size] = '\0';
		    cout << "echo# " << buffer << endl;
        }
	}
	return 0;
}

程序运行后，若不进行输入操作，该进程就会阻塞，根本原因就是因为此时底层数据不就绪，因此read函数需进行阻塞等待

一旦进行输入操作，此时read函数就会检测到底层数据就绪，然后将数据读取到从内核拷贝到程序员传入的buffer数组中，并且将读取到的数据输出到显示器上面，最后就看到了输入的字符串

六、非阻塞IO

打开文件时默认都是以阻塞的方式打开的，若要以非阻塞的方式打开某个文件，需在使用open函数打开文件时携带O_NONBLOCK或O_NDELAY选项，此时就能够以非阻塞的方式打开文件

fcntl函数

int fcntl(int fd, int cmd, ... /* arg */);

参数说明：

fd：已打开的文件描述符
cmd：需要进行的操作
…：可变参数，传入的cmd值不同，后面追加的参数也不同

fcntl函数常用的5种功能与其对应的cmd取值如下：

复制一个现有的描述符（cmd=F_DUPFD）
获得/设置文件描述符标记（cmd=F_GETFD或F_SETFD）
获得/设置文件状态标记（cmd=F_GETFL或F_SETFL）
获得/设置异步I/O所有权（cmd=F_GETOWN或F_SETOWN）
获得/设置记录锁（cmd=F_GETLK, F_SETLK或F_SETLKW）

返回值说明：

若函数调用成功，则返回值取决于具体进行的操作
若函数调用失败，则返回-1，同时错误码被设置

实现SetNonBlock函数

可定义一个函数，该函数用于将指定的文件描述符设置为非阻塞状态

先调用fcntl函数获取该文件描述符对应的文件状态标记（位图结构），此时调用fcntl函数时传入的cmd值为F_GETFL
在获取到的文件状态标记上添加非阻塞标记O_NONBLOCK，再次调用fcntl函数对文件状态标记进行设置，此时调用fcntl函数时传入的cmd值为F_SETFL

#include <iostream>
#include <fcntl.h>
#include <unistd.h>
#include <cstring>
using namespace std;

bool SetNonBloack(int fd) 
{
    int fl = fcntl(fd, F_GETFL);//获取该fd对应的文件读写标志位
    if(fl < 0) return false;
    fcntl(fd, F_SETFL, fl | O_NONBLOCK);//设置非阻塞
    return true;
}

int main()
{
    SetNonBloack(0);
    char buffer[1024];
    while(true) 
    {
        sleep(1);
        errno = 0;
        ssize_t size = read(0,buffer,sizeof(buffer) - 1);
        if(size > 0) {
            buffer[size - 1] = 0;
            cout << "echo# " << buffer << " errno[success]:" << errno << " errString:" << strerror(errno) <<endl;
        }
        else {
            if(errno == EWOULDBLOCK || errno == EAGAIN) {
                cout << "当前0号fd数据没有就绪,请待会再进行尝试" << endl;
                continue;
            } 
            else if(errno == EINTR) {
                cout << "当前IO可能被信号中断,请再次尝试" << endl;
                continue;
            }
            else {//差错处理
                cout << "read error" << " errno:" << errno << " errString:" << strerror(errno) <<endl;
            }
        }
    }
    return 0;
}

当read函数以非阻塞方式读取标准输入时，若底层数据不就绪，那么read函数就会立即返回，并且是以出错的形式返回的，此时的错误码会被设置为 EAGAIN 或 EWOULDBLOCK
因此在以非阻塞方式读取数据时，若调用read函数时得到的返回值是-1，此时还需通过错误码进一步进行判断，若错误码的值是EAGAIN或EWOULDBLOCK，说明本次调用read函数出错是因为底层数据还没有就绪，因此后续还应该继续调用read函数进行轮询检测数据是否就绪，当数据继续时再进行数据的读取
调用read函数在读取到数据前可能被其他信号中断，此时read函数也会以出错的形式返回，此时的错误码会被设置为EINTR，应重新执行read函数进行数据的读取

因此在以非阻塞的方式读取数据时，若调用read函数读取到的返回值为-1，此时并不应该直接认为read函数在底层读取数据时出错，而应该继续判断错误码，若错误码的值为EAGAIN、EWOULDBLOCK 或 EINTR则应该继续调用read函数再次进行读取