高性能网络编程 - 解读5种I/O模型

文章目录

服务端处理网络请求流程图
基础概念
- 阻塞调用 vs 非阻塞调用
- 同步处理 vs 异步处理
- 阻塞、非阻塞和同步、异步的区别
- recvfrom 函数
五种I/O模型
- I/O模型1：阻塞式 I/O 模型(blocking I/O）
- I/O模型2：非阻塞式 I/O 模型(non-blocking I/O）
- I/O模型3：I/O 复用模型(I/O multiplexing）
- I/O模型4：信号驱动式 I/O 模型（signal-driven I/O)
- I/O模型5：异步 I/O 模型（即AIO，全称asynchronous I/O）
5 种 I/O 模型总结

在这里插入图片描述

服务端处理网络请求流程图

在这里插入图片描述

大致流程如下：

1）获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）；
2）构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）；
3）返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）。

设计服务端并发模型时，主要有如下两个关键点：

1）服务器如何管理连接，获取输入数据；
2）服务器如何处理请求。

以上两个关键点最终都与操作系统的 I/O 模型以及线程(进程)模型相关，我们先详细看一下I/O模型。

基础概念

阻塞调用 vs 非阻塞调用

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

两者的最大区别在于被调用方在收到请求到返回结果之前的这段时间内，调用方是否一直在等待。

阻塞是指调用方一直在等待而且别的事情什么都不做；非阻塞是指调用方先去忙别的事情。

同步处理 vs 异步处理

同步处理是指被调用方得到最终结果之后才返回给调用方；
异步处理是指被调用方先返回应答，然后再计算调用结果，计算完最终结果后再通知并返回给调用方

阻塞、非阻塞和同步、异步的区别

阻塞、非阻塞和同步、异步其实针对的对象是不一样的

1）阻塞、非阻塞的讨论对象是调用者；
2）同步、异步的讨论对象是被调用者。

recvfrom 函数

recvfrom 函数(经 Socket 接收数据)，这里把它视为系统调用

阻塞式 I/O 模型中的 recvfrom 是一个用于接收数据报的系统调用或函数。它通常用于网络编程中，特别是在UDP协议中。这个函数会阻塞应用程序的进程，直到有数据报准备好可以被接收。

具体来说，recvfrom 通常用于接收来自网络的数据报，例如从套接字（socket）中接收数据。当应用程序调用 recvfrom 时，如果没有数据报可用，它会等待直到有数据报到达，然后将数据报的内容复制到应用程序指定的缓冲区中，并返回成功。

在阻塞式 I/O 模型中，这个调用会导致应用程序阻塞，即应用程序的执行被暂停，直到数据可用为止。这通常意味着应用程序无法执行其他操作，直到 recvfrom 返回并提供接收的数据。这种模型在某些情况下非常简单，但也可能导致应用程序出现延迟，因为它必须等待数据的到达。

一个输入操作通常包括两个不同的阶段：

1）等待数据准备好；
2）从内核向进程复制数据。

对于一个套接字上的输入操作，

第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。
第二步就是把数据从内核缓冲区复制到应用进程缓冲区。

实际应用程序在系统调用完成上面的 2 步操作时，

调用方式的阻塞、非阻塞，
操作系统在处理应用程序请求时，处理方式的同步、异步处理的不同，可以分为 5 种 I/O 模型

五种I/O模型

I/O模型1：阻塞式 I/O 模型(blocking I/O）

在这里插入图片描述
在阻塞式 I/O 模型中，应用程序在从调用 recvfrom 开始到它返回有数据报准备好这段时间是阻塞的，recvfrom 返回成功后，应用进程开始处理数据报。

比喻：一个人在钓鱼，当没鱼上钩时，就坐在岸边一直等。
优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源。
缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，这种模型在实际生产中很少使用。

I/O模型2：非阻塞式 I/O 模型(non-blocking I/O）

在这里插入图片描述

在非阻塞式 I/O 模型中，应用程序把一个套接口设置为非阻塞，就是告诉内核，当所请求的 I/O 操作无法完成时，不要将进程睡眠。

而是返回一个错误，应用程序基于 I/O 操作函数将不断的轮询数据是否已经准备好，如果没有准备好，继续轮询，直到数据准备好为止

比喻：边钓鱼边玩手机，隔会再看看有没有鱼上钩，有的话就迅速拉杆。
优点：不会阻塞在内核的等待数据过程，每次发起的 I/O 请求可以立即返回，不用阻塞等待，实时性较好。
缺点：轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，所以一般 Web 服务器不使用这种 I/O 模型。

EWOULDBLOCK 是一个错误码（或错误常量），通常在网络编程和非阻塞 I/O 中使用。它表示某个操作（通常是非阻塞的）因为当前状态而无法立即执行，但并不算是一种错误。在不同的操作系统和编程语言中，它有时也被称为 EAGAIN，表示 “操作再次尝试”。

当你在非阻塞模式下进行 I/O 操作（如读取或写入数据），有时可能会遇到 EWOULDBLOCK 错误。这通常发生在以下情况下：

针对非阻塞套接字的读取操作，但没有数据可供读取，因此需要稍后再次尝试。
针对非阻塞套接字的写入操作，但发送缓冲区已满，因此需要稍后再次尝试。

这并不是一种严重的错误，而是提示应用程序需要稍后再次尝试相同的操作，因为当前条件不允许立即执行。应用程序可以通过重新调用相同的操作来处理 EWOULDBLOCK 错误，直到操作成功完成。

在C语言中，通常使用 errno 变量来获取最后一次发生的错误码，而 EWOULDBLOCK 可以表示为 EAGAIN。例如：

if (recvfrom(socket_fd, buffer, buffer_size, 0) == -1) {
    if (errno == EWOULDBLOCK || errno == EAGAIN) {
        // 需要稍后再次尝试
    } else {
        // 处理其他错误
    }
}