网络编程 on 纪伟的个人博客

操作系统学习笔记（四）：零拷贝技术

Mon, 11 May 2026 10:00:00 +0800

写在前面

本文讲零拷贝（Zero-Copy）——把数据从磁盘发到网络，能少拷贝几次就少几次。这是 Nginx 静态文件飞快、Kafka 高吞吐的关键技术之一。

一、传统读写的开销

场景：服务器从磁盘读一个文件，通过网络发给客户端。

1.1 传统方式

1
2
3
4


// 传统 4 步
char buf[4096];
read(fd, buf, 4096); // 磁盘 → 用户态
write(sock, buf, 4096); // 用户态 → 网络

看似两行，实际发生了4 次数据拷贝 + 4 次上下文切换：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 内核空间 用户空间
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 磁盘 │──DMA──→│ 内核缓冲区 │──CPU拷贝─→│ 用户buf │ read()
 └─────────┘ └──────────┘ └──────────┘
 ↑ │
 （步骤1,2） CPU拷贝
 ↓
 ┌──────────┐ ┌──────────┐
 │ Socket │←─CPU拷贝─│ 用户buf │ write()
 │ 缓冲区 │ └──────────┘
 └─────┬────┘
 DMA
 ┌─────▼────┐
 │ 网卡 │
 └──────────┘
 （步骤3,4）

 4 次拷贝：
 1. 磁盘 → 内核缓冲区（DMA）
 2. 内核缓冲区 → 用户 buf（CPU） ← 多余！用户根本没处理数据
 3. 用户 buf → Socket 缓冲区（CPU） ← 多余！
 4. Socket 缓冲区 → 网卡（DMA）

 4 次上下文切换：read(2次) + write(2次)

1
2
3
4
5
6


问题：
 数据从磁盘到网卡，根本不需要经过用户空间
 但传统 read+write 强制数据绕道用户态
 白白多了 2 次 CPU 拷贝 + 2 次上下文切换

 零拷贝的目标：消除这 2 次多余的 CPU 拷贝

二、mmap + write（减少一次拷贝）

mmap 把内核缓冲区和用户空间映射到同一块内存，省去内核→用户的拷贝。

1
2
3


char *p = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0); // 映射
write(sock, p, size); // 直接从映射区写
munmap(p, size);

1
2
3
4
5
6
7
8


拷贝流程：
 磁盘 →(DMA)→ 内核缓冲区（= 用户映射区，共享）
 内核缓冲区 →(CPU)→ Socket 缓冲区 →(DMA)→ 网卡

 省了「内核缓冲区→用户buf」这次拷贝
 剩 3 次拷贝（2 DMA + 1 CPU），4 次上下文切换

 适合：用户需要读数据内容（如处理后再发）

三、sendfile（真正的零拷贝）

Linux 2.1 引入，专门为"文件→Socket"传输设计。数据全程不进用户空间。

1
2


#include <sys/sendfile.h>
sendfile(sock, fd, &offset, size); // 一步到位

1
2
3
4
5
6
7
8


拷贝流程（原始 sendfile）：
 磁盘 →(DMA)→ 内核缓冲区 →(CPU)→ Socket 缓冲区 →(DMA)→ 网卡

 数据不进用户态！
 2 次拷贝（2 DMA）+ 1 次 CPU 拷贝
 2 次上下文切换（一次系统调用）

 对比传统：4次拷贝+4次切换 → 3次拷贝+2次切换

SG-DMA 优化（Linux 2.4+，终极零拷贝）

如果网卡支持 SG-DMA（Scatter-Gather DMA），连那 1 次 CPU 拷贝都省了：

1
2
3
4
5
6
7


拷贝流程（SG-DMA）：
 磁盘 →(DMA)→ 内核缓冲区
 内核只把「缓冲区地址 + 长度」描述符发给 Socket 缓冲区
 网卡根据描述符直接从内核缓冲区 DMA → 网卡

 全程只有 2 次 DMA 拷贝，0 次 CPU 拷贝！
 这就是真正的"零拷贝"（CPU 零拷贝）

1
2


 Nginx 的 sendfile on; 就是开启这个
 静态文件传输极快的根本原因

四、splice（管道零拷贝）

sendfile 只能文件→Socket。splice 更通用，任意两个 fd 之间（通过管道）零拷贝。

1
2
3
4


int pipefd[2];
pipe(pipefd);
splice(fd, &offset, pipefd[1], NULL, size, SPLICE_F_MOVE); // 文件 → 管道
splice(pipefd[0], NULL, sock, NULL, size, SPLICE_F_MOVE); // 管道 → Socket

1
2


适合：两个非 Socket 的 fd 间传输（如文件→文件、管道中转）
本质：用内核管道缓冲区做中转，避免数据进用户态

五、对比总结

1
2
3
4
5
6
7


方式 CPU拷贝 DMA拷贝 上下文切换 数据进用户态
────────────────────────────────────────────────────────────────
传统 read+write 2 2 4 是
mmap + write 1 2 4 是（映射）
sendfile 1 2 2 否
sendfile + SG-DMA 0 2 2 否 ← 最优
splice 0 2 2 否

六、实际应用

6.1 Nginx

1
2
3
4
5
6


http {
 sendfile on; # 开启 sendfile 零拷贝
 tcp_nopush on; # 配合 sendfile，等数据攒够再发
}

# 静态文件传输直接走 sendfile，磁盘→网卡不进用户态

6.2 Kafka

1
2
3
4
5
6
7


Kafka 高吞吐的关键之一：消费者拉消息用 sendfile

 消息存在磁盘日志（顺序写，快）
 消费者拉取 → 直接 sendfile 从磁盘文件发到网络
 不经过 JVM 堆，无 GC 压力，无内存拷贝

 这让 Kafka 能轻松百万级 TPS

6.3 Java 的零拷贝 API

1
2
3
4
5


Java NIO：
 FileChannel.transferTo() → 底层就是 sendfile
 MappedByteBuffer → 底层是 mmap

 Kafka、Netty 都用这些实现零拷贝

七、.NET 的零拷贝

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


.NET 用 Stream 的 CopyToAsync 在内部尽量优化
 但不是直接对应 sendfile

ASP.NET Core 的静态文件中间件：
 用一些平台优化（如 Linux 下用 sendfile 语义）
 + Pipelines 减少分配

Span<T> / Memory<T>：
 不是网络零拷贝，但提供了"零拷贝切片"内存视图
 避免切片字符串/数组时的拷贝

八、小结

传统读写：4 次拷贝（2 CPU + 2 DMA）+ 4 次切换，数据多余绕道用户态
mmap：内核/用户共享内存，省 1 次 CPU 拷贝（适合需要读内容）
sendfile：文件→Socket 不进用户态，省拷贝 + 切换
sendfile + SG-DMA：CPU 零拷贝，只剩 2 次 DMA（最优）
splice：任意两 fd 间零拷贝（通过管道）
应用：Nginx sendfile、Kafka transferTo、Java FileChannel.transferTo

零拷贝 + I/O 多路复用 + Reactor = 高性能网络服务器三件套。下一篇讲内存管理（虚拟内存、页表、malloc）。

操作系统学习笔记（三）：Reactor 与 Proactor 模式

Sun, 10 May 2026 10:00:00 +0800

写在前面

上一篇讲了 I/O 模型（epoll、AIO）。但 epoll 只是底层机制，要变成一个能用的网络服务器，需要一套设计模式把"事件分发"和"业务处理"组织起来——这就是 Reactor 和 Proactor。Netty、Nginx、Redis、Kestrel 都基于这些模式。

一、Reactor 模式

1.1 核心思想

Reactor = 基于同步 I/O 多路复用的事件驱动模式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


核心组件：
 1. Reactor（事件分发器）
 用 epoll/select 监听所有 fd，事件就绪时分发给对应 Handler

 2. Acceptor（接收器）
 处理新连接（accept）

 3. Handler（处理器）
 处理具体连接的读写、业务

流程：
 Reactor 监听 → 新连接来了，Acceptor 接收 → 注册到 Reactor
 → 数据来了，Reactor 通知 Handler → Handler 读写+处理

1
2
3
4


关键特征（同步）：
 I/O 操作（read/write）还是由 Handler 同步执行
 Reactor 只负责"通知就绪"，不做实际 I/O
 本质是「事件来了 → 你自己去读」

1.2 三种 Reactor 实现

单 Reactor 单线程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


 一个线程，一个 Reactor 干所有事：
 accept、read、业务处理、write 全在一个线程

 ┌─────────────────┐
 │ Reactor（1线程） │
 │ accept + IO + 业务 │
 └─────────────────┘

 代表：Redis 6.0 之前

 优点：极简，无线程同步问题
 缺点：一个连接的慢操作卡死所有连接
 无法利用多核

单 Reactor 多线程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 Reactor（1线程）只负责 accept + 读写分发
 业务处理交给线程池

 ┌──────────┐ ┌──────────────┐
 │ Reactor │────→│ 业务线程池 │
 │ accept+IO │ │ 多线程处理 │
 └──────────┘ └──────────────┘

 优点：业务多线程，利用多核
 缺点：Reactor 单线程仍是瓶颈（所有 I/O 集中）
 Handler 和业务线程间要同步

主从 Reactor 多线程（最常用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 MainReactor 专门 accept 新连接
 SubReactor（多个）处理已建立连接的读写
 业务可选交给线程池

 ┌────────────┐
 │ MainReactor │ accept
 └─────┬──────┘
 │ 新连接分发
 ┌─────▼──────┐ ┌──────────┐ ┌──────────┐
 │ SubReactor │ │SubReactor │ │SubReactor │ 各自 epoll 处理 IO
 └────────────┘ └──────────┘ └──────────┘

 代表：Netty、Nginx（主进程accept + worker处理）

 优点：充分利用多核，accept 和 IO 分离，吞吐高
 这是高性能服务器的标准架构

二、Nginx 的 Reactor 架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Nginx = 主从 Reactor 多进程版：

 Master 进程
 │ accept（但不处理，转交 worker）
 │
 Worker 进程 ×N（= CPU 核数）
 每个 Worker 自己的 epoll + Reactor
 独立处理连接的读写、业务

 特点：
 多进程（不是多线程）→ 无锁、崩溃隔离
 每个 Worker 一个 Reactor（单线程事件循环）
 用共享内存（不是锁）通信

三、Redis 的事件模型

1
2
3
4
5
6
7
8


Redis 6.0 之前：单 Reactor 单线程
 一个线程跑事件循环 + 命令执行
 为什么快：内存操作极快 + 无锁 + 无上下文切换

Redis 6.0+：单 Reactor + IO 多线程
 命令执行仍单线程（保证原子、无锁）
 网络 read/write 用多线程（IO 瓶颈在多核上并行）
 本质：IO 用 Reactor 多线程，业务仍串行

四、Proactor 模式

Proactor = 基于异步 I/O 的事件驱动模式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


核心区别（对比 Reactor）：

Reactor（同步）：
 事件就绪 → 通知 Handler → Handler 自己 read（同步拷贝）
 "数据来了，你自己读"

Proactor（异步）：
 发起异步 read → 内核读完+拷贝完 → 通知 Handler 处理
 "数据我已经读好了，你直接用"

Proactor 流程：
 1. 发起 aio_read（异步，立即返回）
 2. Handler 继续干别的
 3. 内核完成（等数据+拷贝）→ 通知
 4. Handler 拿到的数据已就绪，直接处理

1
2
3


关键特征（异步）：
 I/O 操作由内核完成，Handler 只处理就绪的数据
 本质是「我帮你读好了，告诉你」

五、Reactor vs Proactor

1
2
3
4
5
6
7
8


 Reactor Proactor
──────────────────────────────────────────────────────
I/O 模型 同步（epoll） 异步（IOCP/io_uring）
I/O 谁做 Handler 自己 内核做
通知时机 数据就绪 数据已拷贝完
实现复杂度 简单 复杂
OS 支持 Linux epoll 成熟 Windows IOCP 成熟 / Linux io_uring 新
代表 Nginx/Netty/Redis Windows IOCP、Boost.Asio

1
2
3
4
5
6
7


为什么主流还是 Reactor：
 Linux 的异步 I/O（AIO）长期不成熟
 io_uring（2019）才让 Linux 有了高性能异步 I/O
 epoll + Reactor 已足够高效，生态成熟
 Windows 用 Proactor（IOCP）

 趋势：io_uring 普及后，Linux 上的 Proactor 会越来越多

六、实际框架对应

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


框架/系统 模式 底层
──────────────────────────────────────────────────────
Nginx 主从 Reactor 多进程 epoll
Redis Reactor（IO 多线程） epoll
Netty（Java） 主从 Reactor 多线程 epoll/IOCP
libuv（Node.js） Reactor epoll/kqueue/IOCP
Kestrel（.NET） Reactor epoll/IOCP + Pipelines
Tomcat NIO Reactor epoll/IOCP
Boost.Asio 可 Reactor/Proactor io_uring/IOCP
Windows IOCP Proactor IOCP

七、.NET 的 Kestrel 怎么对应

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Kestrel 是 ASP.NET Core 的服务器，Transport 层是 Reactor：

 Transport（传输层）— Reactor 模式
 基于 epoll（Linux）/ IOCP（Windows）
 用 System.IO.Pipelines 处理网络数据
 接收连接、读取字节流

 应用层 — async/await
 看似 Proactor 风格（await 不阻塞）
 但底层 Transport 是 Reactor（事件就绪通知）
 await 在等数据时释放线程，数据就绪后继续

 所以 Kestrel = Reactor（底层）+ 异步编程模型（上层）
 这也是为什么 Kestrel 跨平台性能都强

八、小结

Reactor：同步 I/O 多路复用 + 事件分发，“数据来了你自己读”
- 单 Reactor 单线程（Redis 6.0 前）
- 单 Reactor 多线程
- 主从 Reactor 多线程/多进程（Nginx、Netty）—— 高性能标配
Proactor：异步 I/O，“我帮你读好了”
- Windows IOCP、Linux io_uring
主流是 Reactor，因为 Linux epoll 成熟；io_uring 普及后 Proactor 会更多
Kestrel = Reactor 底层 + async/await 上层

下一篇讲零拷贝技术（sendfile/mmap/splice）——高性能网络 I/O 的另一块拼图。