零拷贝与网络 IO on Dorkytiger 的小屋

传统 IO 的四次拷贝与上下文切换痛点

Mon, 01 Jan 0001 00:00:00 +0000

1. 传统 IO 读取一个文件的完整硬件旅程

以 Linux 上执行 read(fd, buf, count) 为例，从应用程序发出指令到数据到达用户缓冲区，硬件层面经历了以下阶段：

[用户态应用] 
    │
    ├─① 执行 syscall (int 0x80 / syscall 指令)
    │   └─ CPU 从 Ring 3 切换到 Ring 0，陷入内核
    │
    ▼
[内核 VFS 层]
    │
    ├─② 检查文件是否已在页缓存 (Page Cache) 中
    │   ├─ 命中 → 直接跳到 ④
    │   └─ 未命中 → 触发缺页中断，进入 ③
    │
    ▼
[块设备层 / 驱动]
    │
    ├─③ 构造 I/O 请求，提交给磁盘驱动程序
    │   └─ 驱动配置 DMA 控制器，告诉它：把磁盘扇区数据搬运到主存 [物理地址]
    │
    ▼
[硬件层]
    │
    ├─④ 磁盘控制器通过 DMA 将数据直接写入主存（内核缓冲区）
    │   └─ DMA 传输期间，CPU 完全空闲，可以执行其他任务
    │   └─ 传输完成后，磁盘控制器发出硬中断 (IRQ)
    │
    ▼
[内核中断处理]
    │
    ├─⑤ 中断处理程序唤醒等待该 I/O 的进程
    │   └─ 将数据从页缓存 (内核空间) CPU 拷贝到用户缓冲区 (用户空间)
    │
    ▼
[用户态]
    │
    ├─⑥ syscall 返回，CPU 从 Ring 0 切回 Ring 3
    └─ 用户程序拿到数据

2. 四次拷贝的真正定义（按硬件参与者区分）

编号	拷贝路径	执行者	是否消耗 CPU 周期	数据形态
①	磁盘扇区 → 主存（内核缓冲区）	DMA 控制器	❌ 不消耗	物理内存写入
②	内核缓冲区 → 用户缓冲区	CPU（`memcpy`）	✅ 消耗	物理内存→物理内存
③	用户缓冲区 → Socket 缓冲区（内核）	CPU（`memcpy`）	✅ 消耗	物理内存→物理内存
④	Socket 缓冲区 → 网卡 DMA 缓冲区	DMA 控制器	❌ 不消耗	主存→网卡缓存

结论：

零拷贝核心武器 1：`mmap` 内存映射与 DMA

Mon, 01 Jan 0001 00:00:00 +0000

mmap 是零拷贝技术的第一把核心武器。它解决的是传统 IO 中最痛苦的一步：内核缓冲区 → 用户缓冲区的 CPU 拷贝。

它的核心思想极其简单，但硬件实现极其精妙：让用户态程序直接看到内核的 Page Cache，而不是把数据拷贝一份给用户。

1. 传统 read() 的内存布局 vs mmap 的内存布局

传统 `read()`：数据被拷贝了一次

+-------------------+          +-------------------+
|   用户态地址空间   |          |   内核态地址空间   |
|                   |          |                   |
|  +-------------+  |          |  +-------------+  |
|  | 用户缓冲区   |  |          |  | Page Cache  |  |
|  | (buf)       |  |          |  | (磁盘数据)   |  |
|  +------^------+  |          |  +------^------+  |
|         |         |          |         |         |
|         +---- CPU 拷贝 (memcpy) ----+         |
|                   |          |                   |
|                   |          |  +------+------+  |
|                   |          |  | 磁盘/文件    |  |
|                   |          |  +-------------+  |
+-------------------+          +-------------------+

数据路径：磁盘 → (DMA) → Page Cache → (CPU 拷贝) → 用户缓冲区

零拷贝核心武器 2：Linux 新一代 `io_uring`

Mon, 01 Jan 0001 00:00:00 +0000

io_uring 可以理解为 Linux 在 I/O 模型上的一个分水岭。它设计的目标，就是彻底解决 epoll 等传统模型在应对海量 I/O 时的根本性能痛点，为无锁队列和零拷贝提供了一条直达内核的“绿色通道”。

1. 破局：从“系统调用”到“共享队列”

传统 I/O 模型（如 epoll）的性能瓶颈在于，每次发起和完成 I/O 操作，都需要通过系统调用陷入内核，这伴随着昂贵的上下文切换和 CPU 缓存污染。

io_uring 最核心的变革在于：它创建了两个在用户态和内核态之间共享的环形缓冲区（Ring Buffer），作为通信的主通道，从而极大减少了系统调用次数。

2. 架构：SQ 与 CQ 双环形缓冲区

io_uring 的核心就是两个通过 mmap 共享的队列：

提交队列（Submission Queue, SQ）：这是用户态向内核“派发任务”的地方。你只需要将描述 I/O 操作的**提交队列条目（SQE）**放入 SQ 的尾部。
完成队列（Completion Queue, CQ）：这是内核向用户态“返回结果”的地方。内核完成 I/O 操作后，会将包含结果（如返回码）的**完成队列条目（CQE）**放入 CQ 的尾部，供用户态程序读取。

+----------------------------------------------------------+
|  用户态地址空间                  内核态地址空间             |
|                                    |                       |
|  +-----------------+  mmap映射  +---------------------+    |
|  | 提交队列 (SQ)   |<---------->| 内核处理 SQ 中的请求 |    |
|  |  [SQE] [SQE]    |            |                     |    |
|  +-----------------+            +---------------------+    |
|         |                              |                    |
|         | 放置请求                      | 执行结果           |
|         v                              v                    |
|  +-----------------+  mmap映射  +---------------------+    |
|  | 完成队列 (CQ)   |<---------->| 内核将结果写入 CQ    |    |
|  |  [CQE] [CQE]    |            |                     |    |
|  +-----------------+            +---------------------+    |
+----------------------------------------------------------+

3. 零拷贝的硬件基础

io_uring 实现高性能的核心在于其与硬件的协同工作：

零拷贝与网络 IO on Dorkytiger 的小屋

传统 IO 的四次拷贝与上下文切换痛点

1. 传统 IO 读取一个文件的完整硬件旅程

2. 四次拷贝的真正定义（按硬件参与者区分）

零拷贝核心武器 1：`mmap` 内存映射与 DMA

1. 传统 read() 的内存布局 vs mmap 的内存布局

传统 read()：数据被拷贝了一次

零拷贝核心武器 2：Linux 新一代 `io_uring`

1. 破局：从“系统调用”到“共享队列”

2. 架构：SQ 与 CQ 双环形缓冲区

3. 零拷贝的硬件基础

传统 `read()`：数据被拷贝了一次