深入理解Linux的五种IO模型

Linux系统为我们提供了五种可用的IO模型，分别是阻塞式IO、非阻塞式IO、IO多路复用、信号驱动式IO和异步IO。这些模型的作用是让应用程序能够更好地管理和处理输入输出操作。

每种模型都有其优缺点，具体使用哪种模型取决于应用场景。

Linux的I/O模型可以运用到所有的文件读写。在Linux中，一切设备皆文件，我们可以使用系统调用中的I/O函数（如open()、close()、write()、read()等）对文件进行相应的操作。但是下面是以网络作为例子。

当一个网络请求到达操作系统时，涉及到多个步骤，下面是一个典型的流程：

当一个网络请求到达操作系统时，它需要经过多个步骤才能到达用户进程，并最终生成响应。操作系统内核负责处理网络请求、管理套接字和转发响应，而用户进程负责处理请求和生成响应。

在上面中有一个步骤是网络请求到达网卡和内核将网卡的网络数据封装到对应的套接字中。用户线程并不知道网卡有数据到达操作系统的套接字（因为对应的套接字在系统内核空间中），所以需要进行网络监听，及向操作系统询问对应的套节字是否有数据到达，所以监听的过程实际上是向操作系统询问是否有数据到达内核空间的套接字。

网络监听只是知道了有数据到达系统内核空间的套接字，但是对应的数据并不在用户空间中，所以，用户空间需要调用系统调用，将操作系统内核空间的套接字数据复制到用户空间，这个过程也需要花费时间。

Linux的I/O模型是对用户进程从套接字读取和写入数据的步骤进行优化。在一个典型的网络应用中，数据通常通过套接字进行传输，而套接字是一个系统调用接口，它允许用户进程从操作系统内核中读取和写入数据。因此，套接字通信的效率直接影响到整个应用的性能。

不同的I/O模型提供了不同的优化策略，比如阻塞I/O模型会阻塞用户进程直到数据传输完成，非阻塞I/O模型会通过轮询的方式实现数据传输，I/O复用模型会允许用户进程同时处理多个套接字，信号驱动I/O模型会通过信号通知用户进程数据传输完成，而异步I/O模型则通过回调函数的方式通知用户进程数据传输完成。

因此，Linux的I/O模型是对用户进程从套接字读取和写入数据的步骤进行优化，以提高应用程序的性能和可伸缩性。

阻塞I/O（Blocking I/O）是一种I/O模型，它会阻塞用户进程直到数据传输完成。在阻塞I/O模型中，在阻塞式IO模型中，如果内核缓冲区中没有数据可读，那么read函数会一直阻塞，直到有数据可读为止。在这段时间里，应用进程无法执行其他操作。(在调用accept的过程会发生阻塞直至有客户端和服务器建立连接)

在阻塞I/O模型中，用户进程会通过系统调用进入内核，系统调用会一直阻塞用户进程，直到数据传输完成。在这个过程中，用户进程会一直占用CPU时间片，无法处理其他任务，因此阻塞I/O模型通常会导致应用程序的性能和可伸缩性受到限制。

下面是阻塞I/O模型的一些特点：

虽然阻塞I/O模型在某些情况下非常实用，但是在高并发、大规模应用中，阻塞I/O模型的性能和可伸缩性会变得非常糟糕，因此需要采用其他的I/O模型，比如非阻塞I/O、I/O复用、信号驱动I/O和异步I/O等。

非阻塞IO是指在进行输入输出操作时，程序不会阻塞等待结果返回，而是可以继续执行其他操作，等到结果返回时再去获取结果。非阻塞IO的accept和read都不需要阻塞。这意味着当你调用这些函数时，它们会立即返回一个结果。这种方式通常与异步IO配合使用，以提高程序的性能和响应速度。

在传统的阻塞IO中，程序会一直等待IO操作完成，直到结果返回后才会继续执行。这种方式会导致程序长时间处于等待状态，浪费CPU资源。而非阻塞IO可以在IO操作的同时，执行其他操作，从而提高程序的效率和吞吐量。

实现非阻塞IO的方式一般是通过轮询或事件驱动的方式。轮询是指程序会不断地询问IO操作是否完成，如果没有完成就会继续执行其他操作，直到IO操作完成为止。事件驱动则是通过注册事件回调函数，当IO操作完成时自动调用该回调函数，从而实现非阻塞IO操作。

在使用非阻塞IO时，需要注意一些问题。首先，由于程序并不会等待IO操作完成，因此需要采用一些方式来判断IO操作是否完成，例如轮询或事件回调。其次，在使用非阻塞IO时，需要考虑线程安全和竞争条件等问题，以保证程序的正确性和稳定性。

非阻塞I/O的accept函数不会阻塞，因为它是在非阻塞模式下工作的。当没有新的连接请求到达时，accept函数会立即返回-1，并且设置errno为EAGAIN或EWOULDBLOCK。这表示当前没有新的连接请求需要处理。

在使用非阻塞I/O的情况下，通常需要使用select、poll或epoll等I/O多路复用机制来监听多个套接字的状态变化，包括是否有新的连接请求到来。当有新的连接请求时，可以使用accept函数接受连接，并将新的客户端套接字设置为非阻塞模式。

需要注意的是，使用非阻塞I/O需要谨慎处理返回值和错误码，避免出现死循环或错误的处理逻辑。通常需要使用状态机等技术来处理I/O事件。

在非阻塞I/O模式下，read函数会立即返回，而不会等待数据到达。如果没有数据可用，read函数将返回-1，并设置errno为EAGAIN或EWOULDBLOCK，表示当前没有数据可用。

I/O多路复用是一种通用的高效I/O处理机制，它允许一个进程可以同时监视多个文件描述符（套接字），并且可以在其中任何一个文件描述符上等待数据可读或可写，从而实现并发I/O操作。

I/O多路复用机制通常由select、poll和epoll等系统调用实现。这些系统调用允许用户进程注册一组文件描述符，并且在这些文件描述符上等待某些事件的发生，例如是否有数据可读或可写。当有数据可读或可写时，进程可以进行相应的操作，例如读取数据或将数据写入文件。

在网络编程中，I/O多路复用通常用于同时监听多个套接字，以实现高效的并发网络通信。通过使用I/O多路复用机制，服务器进程可以同时处理多个客户端连接请求，并且可以避免使用阻塞I/O导致的性能瓶颈和资源浪费问题。相比之下，非阻塞I/O需要对每个套接字分别进行操作，而I/O多路复用可以在一个线程中处理多个套接字，从而减少系统调用的次数和CPU使用率。

I/O多路复用是一种高效的I/O处理机制，可以用于实现并发网络通信和其他需要同时监视多个文件描述符的应用场景。

select函数的原型是

它接收五个参数，分别是最大的fd值加1、可读fd集合、可写fd集合、异常fd集合和超时时间。

select函数在用户空间和内核空间之间有两次数据拷贝，一次是将用户空间的fd集合拷贝到内核空间，另一次是将就绪的fd集合拷贝回用户空间。这些拷贝操作会消耗一定的时间和内存。

select函数在内核空间中调用了do_select函数，该函数遍历所有的fd，并调用每个fd对应的设备驱动程序中的poll方法，检查设备是否就绪。如果有设备就绪，就将其加入到就绪链表中，并唤醒等待在select上的进程。如果没有设备就绪，就将进程挂起到等待队列中，并设置超时定时器。

do_select函数返回后，select函数会检查返回值和信号状态，如果有信号发生或者超时发生，就返回错误码或者0。如果有设备就绪，就将就绪链表中的设备复制到用户空间的fd集合中，并返回就绪设备的数量。

poll_wqueues结构体用于维护一组等待队列（wait queue）和相关的信息，以在内核实现的select/poll/epoll等函数中实现等待多个文件描述符上的事件。当某个进程需要对socket进行读写的时候，如果发现此socket并不能读写， 那么就可以添加到此socket的等待队列中进行休眠，当此socket可以读写时再唤醒队列中的进程。具体来说，该结构体的各个成员的作用如下：

poll_table 结构体用于注册和传递等待条件，通常与 poll_wait() 函数一起使用。

在 Linux 内核中，当驱动程序或其他内核代码需要等待某个事件发生时，可以使用 poll_table 结构体来指定等待的事件类型。在 poll_wait() 函数调用期间，进程被标记为等待状态，并且将传递的 poll_table 结构体存储在等待队列中。当事件发生时，内核将通知等待队列中的所有进程，并让它们恢复运行。

poll_table 结构体包含两个字段：

poll_table_page结构体的作用是作为多路复用机制中的等待队列，用于存储需要等待的文件描述符以及它们感兴趣的事件类型。它包含以下成员：

当一个进程调用poll函数时，它需要传递一个poll_table结构体作为参数，并在该poll_table中指定关心的事件类型和等待的文件描述符。poll函数内部会创建一个poll_table_page结构体，并将其中的poll_table_entry结构体用于表示一个文件描述符以及它感兴趣的事件类型。在多个进程都需要等待同一个文件描述符的情况下，这些poll_table_page结构体会以链表的形式组成一个等待队列，以便内核能够更快速地遍历所有等待该文件描述符的进程，从而快速唤醒它们。

结构体定义了一个等待队列的入口，用于将进程添加到相应的等待队列中。具体来说：

poll_table_entry结构体通常嵌套在poll_table_page结构体中，用于表示一个等待队列中的一个节点。当进程调用poll函数时，内核将使用该结构体表示进程需要等待的事件，并将其添加到相应的等待队列中。

该函数是Linux内核中实现select系统调用的主要函数之一。它的作用是等待一组文件描述符中的某些就绪，并返回就绪的文件描述符集合。

该函数的主要参数包括：

该函数的主要流程如下：

在等待事件的过程中，该函数使用了一些优化技巧，包括：

这个函数的作用是查询一个文件描述符的读写状态，并返回一个表示可读或可写的 mask 值。如果文件描述符没有 poll 函数，就返回默认的 mask 值。这个函数还可以在 poll 表中注册一个回调函数，用来在文件描述符可读或可写时唤醒相关进程。

在上面的poll实际上调用的是socket_poll,该函数的作用是处理对一个套接字文件描述符的轮询操作（polling）请求。

具体来说，该函数的输入参数为一个 file 结构体指针和一个 poll_table 结构体指针，其中 file 结构体指向一个套接字文件描述符，poll_table 结构体用于等待事件的发生。该函数的返回值是一个 __poll_t 类型的值，表示哪些事件已经发生。

函数内部的第一行代码 struct socket *sock = file->private_data; 将套接字文件描述符所对应的 private_data 指针转换为一个 struct socket 类型的指针，以便后续对套接字的操作。

接下来的一行代码 __poll_t events = poll_requested_events(wait), flag = 0; 获取了调用 poll 系统调用时请求的事件集合，并初始化一个标志变量 flag。

接着的代码 if (!sock->ops->poll) return 0; 检查套接字的操作结构体中是否存在 poll 函数指针，如果不存在则直接返回 0。

然后代码 if (sk_can_busy_loop(sock->sk)) { 检查套接字是否支持繁忙轮询（busy polling），如果支持则进行下一步操作。

在此之后的代码 if (events & POLL_BUSY_LOOP) sk_busy_loop(sock->sk, 1); 判断系统调用是否请求进行繁忙轮询，如果是，则调用 sk_busy_loop 函数执行一次繁忙轮询操作。

然后代码 flag = POLL_BUSY_LOOP; 将标志变量 flag 设置为表示繁忙轮询的标志。

最后的代码 return sock->ops->poll(file, sock, wait) | flag; 调用套接字操作结构体中的 poll 函数，并将其返回值与标志变量 flag 的值进行按位或操作，并将结果作为函数的返回值。

因此，该函数的作用是：处理套接字文件描述符的轮询操作请求，包括获取请求的事件集合、执行繁忙轮询操作、调用套接字操作结构体中的 poll 函数，并返回哪些事件已经发生。

假设这个链接是一个IP4的TCP连接，那上面的poll函数实际上调用的是tcp_poll。

这是一个用于TCP套接字的poll函数的实现。poll函数是用于查询一个或多个文件描述符的状态变化的系统调用，该函数可以在文件描述符上等待一个或多个事件的发生，并且可以选择阻塞或非阻塞等待模式。

该函数接收三个参数：一个指向表示套接字的文件结构体的指针，一个指向套接字的结构体的指针，以及一个指向poll_table结构体的指针，后者包含了一组需要等待的事件掩码。

该函数的主要工作如下：

总之，该函数的作用是将poll_table中的等待队列添加到套接字的等待队列中，并等待套接字的可用性事件。

poll_wait函数是用在poll系统调用中的，它的作用是将当前进程添加到指定的等待队列中，以便在设备状态发生变化时能够被唤醒。

poll_wait函数有三个参数：filp、wait_address和p。filp是一个文件结构体指针，表示要监视的设备；wait_address是一个等待队列头指针，表示要加入的等待队列；p是一个poll_table结构体指针，表示存放文件描述符集合的表。

poll_wait函数的工作流程如下：

所以，poll_wait函数完成了将当前进程注册到设备的等待队列中，并使其能够在设备状态变化时被唤醒的工作。

poll_freewait函数是用在poll系统调用结束后的，它的作用是清理之前创建的poll_table结构体，并将等待队列中的元素从相应的等待队列头中移除。

poll_freewait函数有一个参数：table。table是一个poll_wqueues结构体指针，表示存放文件描述符集合和等待队列元素的表。

poll_freewait函数的工作流程如下：

poll_freewait函数完成了清理内存资源和获取就绪事件结果的工作。

多路复用的poll实际上调用的是do_poll。其实poll和select的原理差不多，就不进行解释了。

do_poll 函数实现了 poll() 系统调用的核心功能，它轮询指定的文件描述符并等待其上的事件，直到其中至少一个描述符上发生了事件或者等待时间截止。具体来说，该函数执行以下步骤：

最终，do_poll 函数返回等待事件的文件描述符数量。

相比于select，epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。

epoll 和 select 最大的不同是 epoll 是基于事件驱动的，而 select 是基于轮询的。

在 select 中，每次调用 select 函数时，内核都需要轮询所有被 select 监听的文件描述符，来检查是否有事件发生。而在 epoll 中，首先需要通过 epoll_ctl 将文件描述符加入到 epoll 中，然后调用 epoll_wait 等待事件的发生。当有事件发生时，内核会通知应用程序，应用程序只需要处理这些发生事件的文件描述符即可。

此外，epoll 与 select 在支持的文件描述符数量上也有区别。select 支持的文件描述符数量通常受到系统内存限制，而 epoll 可以处理非常大的文件描述符集合，这是因为 epoll 内部使用的是红黑树来保存文件描述符，而非数组。

另外，当文件描述符集合变化时，select 需要重新调用 select 函数来更新内核维护的文件描述符集合，而 epoll 只需要调用 epoll_ctl 来修改文件描述符集合即可。

综上所述，epoll 相对于 select，具有更高的效率和更好的扩展性，特别是当需要处理大量文件描述符时，epoll 的优势更加明显。

表示一个事件轮询（eventpoll）对象。该结构体中的各个成员变量用于描述eventpoll对象的各个方面，包括：

struct epitem 是一个结构体，用于存储 epoll 监测的文件描述符和事件信息。它有以下成员：

rbn：一个红黑树节点，用于将这个结构体链接到 eventpoll 的红黑树中。

rcu：一个 RCU 头，用于释放这个结构体。

rdllink：一个链表头，用于将这个结构体链接到 eventpoll 的就绪列表中。

next：一个指针，用于将这个结构体链接到 eventpoll 的溢出列表中。

ffd：一个文件描述符信息结构体，包含了文件描述符和文件指针。

pwqlist：一个链表头，用于存储等待队列的入口。

ep：一个指向 eventpoll 对象的指针。

fllink：一个哈希表节点，用于将这个结构体链接到文件的项列表中。

ws：一个唤醒源指针，用于在 EPOLLWAKEUP 标志被设置时保持系统唤醒。

event：一个 epoll_event 结构体，描述了感兴趣的事件和源文件描述符。

struct epitem 的作用是在 epoll 中管理和传递文件描述符和事件的相关数据。

struct epoll_event 是用来描述一个文件描述符上注册的事件的结构体，它包含两个成员变量：

在 epoll 中，可以为一个文件描述符注册多个事件类型，例如一个 socket 可以注册 EPOLLIN 和 EPOLLOUT 事件，因此 struct epoll_event 可以表示多个事件类型。

struct epoll_event 是 epoll API 中用于描述事件的结构体，它通过 events 成员来表示事件类型，通过 data 成员来存储与事件相关的数据。

在使用epolll前需要调用epoll_create函数进行创建。epoll_create函数是Linux内核中创建epoll对象的系统调用epoll_create的实现。函数的主要作用是创建一个新的eventpoll对象和相应的文件描述符，以便用户进程可以使用它来监视多个文件描述符上的事件。

具体来说，函数执行以下步骤：

在Linux内核中，每个进程都有一张打开文件表，用于管理该进程打开的所有文件。每个打开的文件都有一个文件描述符（file descriptor），它是一个非负整数，用于唯一标识该文件。当一个进程打开一个新文件时，内核会为该文件分配一个新的文件描述符。

在epoll_create函数中，需要为新创建的eventpoll对象分配一个新的文件描述符，以便用户进程可以使用它来监视多个文件描述符上的事件。为了避免与现有的文件描述符冲突，需要使用get_unused_fd_flags()函数获取一个空闲的文件描述符，以便将新创建的eventpoll对象绑定到该文件描述符上。

一旦完成了对eventpoll对象的使用，就需要释放相应的文件描述符和eventpoll对象。为了避免文件描述符资源的浪费，需要使用put_unused_fd()函数将之前获取的文件描述符释放回内核。同样，为了避免eventpoll对象的内存泄漏，需要使用ep_free()函数释放之前分配的eventpoll对象内存。这样，就可以确保在使用完eventpoll对象后，不会浪费任何内核资源。

epoll_ctl函数是 Linux 内核中 epoll 模块的核心函数之一，用于控制 epoll 实例中的文件描述符的事件。该函数的功能如下：

do_epoll_ctl() 函数的主要作用是将文件描述符添加到 eventpoll 实例中，以便 epoll_wait() 函数可以在需要时触发该文件描述符的事件。

该函数实现了epoll_wait系统调用的具体功能，以下是每一步完成的工作：

总体而言，该函数的功能就是获取eventpoll文件关注的事件并将其填充到用户空间传递的events数组中，最后返回获取到的事件数量。

ep_poll函数是实现 epoll_wait 的核心函数之一，用于从 eventpoll 中等待和获取事件。下面是该函数的具体分析：

该函数的作用是在 eventpoll 中等待和获取事件，并将事件传输到用户空间。如果没有可读取事件，则会进入等待状态，直到超时或者有事件到达为止。在等待的过程中，该函数会使用忙等待和睡眠等待相结合的方式，以提高事件响应的效率。

Linux内核中实现的ep_send_events函数，主要的功能是在epoll实例中扫描已经准备好的epitem并将事件传递到用户空间，同时将相关的epitem从rdllist中删除或重新插入。

具体地说，该函数的实现步骤如下：

ep_send_events函数是用于处理已准备好的epitem，并将它们的事件传递给用户空间的核心函数，它在epoll实例的事件通知机制中起到了至关重要的作用。

epoll 是一种高效的 I/O 事件监测机制，它可以在 Linux 系统中监听多个文件描述符，并在 I/O 可以执行时通知进程。epoll 支持两种事件触发模式：边缘触发 (ET) 和水平触发 (LT) 。

在 epoll 中，水平触发（Level-Triggered，LT）和边缘触发（Edge-Triggered，ET）的实现方式有所不同。

在水平触发模式下，当一个文件描述符上有数据可读或可写时，内核会不断通知应用程序，直到所有数据都被读取或写入。应用程序在接收到通知后，可以选择读取或写入任意数量的数据，而不必担心是否会丢失数据。

在 epoll 中，水平触发模式是默认模式。当应用程序调用 epoll_wait 等待事件时，如果文件描述符上有事件发生，内核会返回一个标志，表示该文件描述符上有事件可以处理。

而在边缘触发模式下，内核只在文件描述符状态发生变化时才会通知应用程序。当应用程序接收到通知后，必须立即读取或写入所有可用数据，否则数据会被丢失。

在 epoll 中，可以通过设置 EPOLLET 标志将文件描述符设置为边缘触发模式。当应用程序调用 epoll_wait 等待事件时，如果文件描述符上的事件未被处理，则会阻塞等待，直到有新的事件发生为止。在边缘触发模式下，应用程序必须处理所有可用数据，并确保在下一次读取或写入之前不会发生数据丢失。

在select中我们了解到当一个事件到达后，通过回调函数完成了select中的唤醒，在epoll中通过回调数完成事件触发的，并将调用poll()函数将对应的文件描述加入以准备函数的链表中。也就是说没有实现poll的文件描述符是无法实现水平触发和边缘触发的事件通知机制的。

select、poll和epoll都是Linux下用于I/O多路复用的机制，但它们在实现和使用上有一些不同：

select和poll适用于少量文件描述符的场景，而epoll适用于大量文件描述符的场景。在高并发、高吞吐量的网络应用中，epoll是最好的选择。

信号驱动式 I/O（Signal-Driven I/O）是一种 I/O 多路复用的技术，可以用于异步处理 I/O 事件。

在信号驱动式 I/O 中，进程使用系统调用 sigaction() 来注册一个信号处理函数，该函数会在 I/O 事件就绪时被内核调用。当进程调用 sigaction() 注册一个信号处理函数时，它需要指定一个描述符和一个事件，内核在检测到该描述符上发生指定事件时，会向进程发送指定信号。进程可以通过捕获该信号并执行相应操作来实现异步 I/O。

与其他 I/O 多路复用技术相比，信号驱动式 I/O 的主要优点是可以在处理多个描述符时避免阻塞进程，提高了程序的并发性能和响应能力。同时，信号驱动式 I/O 也避免了轮询机制的开销，从而减少了 CPU 的占用。

但是，信号驱动式 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 模型更加复杂，需要使用操作系统提供的通知机制来处理 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 完成的逻辑，较为繁琐。

阻塞IO实现简单，但是性能不佳，非阻塞IO虽然不需要阻塞线程，但是他需要轮询操作低效。多路复用IO有三种实现，select和poll都是使用了轮询的方式，监听文件描述符不能太多。epoll的实现使用了红黑树，增删改文件描述符效率高，并且使用了事件触发机制，不需要进行轮询。信号IO依赖于信号机制，它对信号的处理需要一定的时间，因此它不适合高速 I/O 操作。异步 I/O 模型的实现比同步 I/O 模型更加复杂，需要使用操作系统提供的通知机制来处理 I/O 完成的事件，同时也需要考虑到异步 I/O 可能会引入的竞争条件和死锁问题。