IO

Bbober
135 阅读8分钟

IO

用户空间和内核空间

服务器大多都采用Linux系统，这里我们以Linux为例来讲解

为了避免用户应用导致冲突甚至内核崩溃，用户应用于内核分离：

  • 进程的寻址空间会划分为两部分：内核空间、用户空间

  • 用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问

  • 内核空间可以执行特权命令（Ring0），调用一切系统资源

    Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区

    • 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
    • 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

阻塞IO

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：

image-20240411221114283.png

可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

非阻塞IO

顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

image-20240411221527659.png

可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等会导致CPU空转，CPU使用率暴增。

IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案：

  • 如果调用recvfrom时，恰好没有数据，阻塞IO会使进程阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。
  • 如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

比如服务端处理客户端Socket请求时，在单线程情况下，只能依次处理每一个socket，如果正在处理socket恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有其他客户端socket都必须等待，性能自然会很差。

这就像服务员给顾客点餐，分两步：

  1. 顾客思考要吃什么（等待数据就绪）
  2. 顾客想好了，开始点餐（读取数据）

要提高效率有几种方法：

  • 方案一：增加更多的服务员（多线程）
  • 方案二：不排队，谁想好了吃什么（数据就绪了），服务员就给谁点餐（用户应用就去读取数据）

那么问题来了：用户进程如何知道内核中数据是否就绪呢？

文件描述符：简称FD，是一个从0开始递增的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

**IO多路复用：**是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

image-20240411232305212.png

不过监听FD的方式、通知的方式又有多种实现，常见的有：

  • select
  • poll
  • epoll

差异：

  • select和poll只会通知用户进程有FD就绪，但不确定具体是哪个FD，需要用户进程逐个遍历FD来确认
  • epoll则会在通知用户进程FD就绪的同时，把已就绪的FD写入用户空间

select

select是Linux中最早的I/O多路复用实现方案：

// 定义类型别名 __fd_mask，本质是 long int 4字节 32bit
typedef long int __fd_mask;

// fds_bits 记录要监听的fd集合，及其对应状态
typedef struct {
    // fds_bits是long类型数组，长度为1024/32 = 32
    // 共1024个bit位，每个bit位代表一个fd，0代表未就绪，1代表就绪
    __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
    // ...
} fd_set;

//select函数，用于监听多个fd的集合
int select(
	int nfds,	// 要监听的fd_set的最大fd + 1
    fd_set *readfds,	// 要监听读事件的fd集合
    fd_set *write,	// 要监听写事件的fd集合
    fd_set *exceptfds,	//要监听异常事件的fd集合
    //超时时间，null-永不超时；0-不阻塞等待；大于0-固定等待时间
    struct timeval *timeout
);

用户空间 1.1 创建fd_set rfds 每一个bit位都会被初始化为0 1.2 假如要监听 fd = 1，2，5 将1，2，5位对应的bit位置为1 1.3 执行select（5 + 1，rfds，null，null，3） 3.1 将覆盖后的fd_set拷贝回来覆盖1.1创建的 fd_set 3.2 遍历fd_set，找到就绪的fd，读取其中数据

内核空间 2.1 将 rfds 拷贝至内核态 2.2 遍历fd_set (从最低为开始遍历，直到传入的最大值) 2.3 没有就绪，则休眠 2.4 等待数据就绪被唤醒或超时 2.5 将就绪数据的fd写入并覆盖fd_set 2.6 返回给用户态就绪的个数

select模式存在的问题：

  • 需要将多个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间。
  • select无法得知具体是哪个fd就绪，需要遍历整个fd_set
  • fd_set监听的fd数量不能超过1024

poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下：

// pollfd中的事件类型
#define POLLIN	// 可读事件
#define POLLOUT	// 可写事件
#define POLLERR	// 错误事件
#define POLLNVAL	// fd未打开

// pollfd结构
struct polled {
    int fd;	// 要监听的fd
    short int events;	// 要监听的事件类型：读、写、异常
    short int revents;	// 实际发生的事件类型
};

// poll函数
int poll{
    struct pollfd *fds;	// pollfd数组，可以自定义大小
    nfds_t nfds,	// 数组元素个数
    int timeout	// 超时时间
}

IO流程：

  1. 创建pollfd数组，向其中添加关注的fd信息，数组大小自定义
  2. 调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限
  3. 内核遍历fd，判断是否就绪
  4. 数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n
  5. 用户进程判断n是否大于0
  6. 大于0则遍历pollfd数组，找到就绪的fd

与select对比：

  • select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论无上限
  • 监听FD越多，每次遍历消耗的时间也越久，性能反而会下降

epoll

epoll模式是对select和poll的改进，它提供了三个函数

struct eventpoll{
    //...
    struct re_root rbr;	// 一颗红黑树，记录要监听的FD
    struct list_head rdlist;	// 一个链表，记录就绪的FD
};

// 1.会在内核创建eventpoll结构体，返回对应的句柄epfd（eventpoll的唯一标识）
int epoll_creat(int size);

// 2.将一个FD添加到epoll的红黑树中，并设置ep_poll_callback
// callback触发时，就把对应的FD加入到rdlist这个就绪列表中
int epoll_ctl(
	int epfd,	// epoll实例的句柄
    int op,	// 要执行的操作，包括：ADD、MOD、DEL
    int fd,	// 要监听的FD
    struct epoll_event *event	// 要监听的事件类型：读、写、异常等
);

// 3.检查rdlist列表是否为空，不为空则返回就绪的FD的数量
int epoll_wait(
	int epfd,	// eventpoll实例的句柄
    struct epoll_event *events,	// 空event数组，用于接收就绪的FD
    int maxevents,	// events数组的最大长度
    int timeout	// 超时时间，-1永不超时；0不阻塞；大于0为阻塞时间
)

用户空间

  1. epoll_create(1)创建epoll实例
  2. epoll_ctl(..)添加要监听的FD，关联callback
  3. epoll_wait(...，events)等待FD就绪

内核空间

image-20240412004519119.png

  • 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高，性能不会随监听的FD数量增多而下降
  • 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
  • 内核会将就绪的FD直接拷贝到用户空间的指定位置，用户进程无需遍历所有FD就能直到就绪的FD是谁

事件通知机制

当FD有数据可读时，我们调用epoll_wait就可以得到通知。但是事件通知的模式有两种：

  • LevelTriggered：简称LT。当FD有数据可读时，会重复通知多次，直至数据处理完成。是Epoll的默认模式。
  • EdgeTriggered：简称ET。当FD有数据可读时，只会被通知一次，不管数据是否处理完成

举个例子：

  1. 假设一个客户端socket对应的FD已经注册到了epoll实例中
  2. 客户端socket发送了2kb的数据
  3. 服务端调用epoll_wait，得到了通知说FD就绪
  4. 服务端从FD读取了1kb数据
  5. 回到步骤3（再次嗲用epoll_wait，形成循环）

在epoll中就绪链表返回后，会将内核态的就绪链表断开，然后检查模式

  1. LT模式-会将断开的链表进行检查，如果其中的FD还有数据，将会重新加入就绪链表
  2. ET模式-会直接丢弃掉返回过的链表的结点

LT模式存在的问题：

  1. 重复通知，对于效率和性能会有影响
  2. 惊群现象，一个FD就绪，唤醒了所有等待该FD的线进程
avatar
文章
阅读
粉丝