Network Programming on 纪伟的个人博客

epoll 的前世今生：从 select/poll 的性能困局到 io_uring 的挑战

Sat, 28 Feb 2026 10:00:00 +0800

epoll 是 Linux 高并发网络编程的重要基础。Nginx、Redis 以及多种语言运行时或事件库在 Linux 上通常会使用 epoll；具体后端仍取决于版本、构建选项和运行环境。很多人把 epoll 简单理解成“支持更多连接的 select”，但两者管理兴趣集和交付就绪事件的方式不同。

这个理解是错的。epoll 不是改良，是一次模型换轨。

select/poll 每次调用都提交整个 fd 集合，并由内核检查；epoll 则把兴趣集保留在内核，在就绪状态变化时把对象加入就绪集合。epoll_wait 的返回成本主要随本次交付的事件数增长，但注册、回调、锁竞争和拷贝仍有成本，不能把整个 epoll 路径概括成严格的 O(1)。

本文从 select 的诞生讲起，把这条演进线（select → poll → kqueue → epoll → io_uring）串起来，再钻进 epoll 内核实现（红黑树、就绪链表、回调链路）、LT/ET 的本质、标志位的演进史，最后聊聊 io_uring 这位新挑战者。前序的 I/O 模型全解和 Reactor 模式讲过宏观定位，这里把 epoll 这一环彻底拆透。

一、故事的起点：一个线程伺候一个连接

在多路复用出现之前，高并发服务器长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Apache prefork / thread-per-connection 模型：

 主线程 accept() → 拿到一个连接
 ↓
 fork() 一个子进程（或 new 一个线程）
 ↓
 子线程: read() → process() → write()
 （阻塞在这个连接上，直到客户端断开）

 1 个连接 = 1 个线程/进程 全程占用

这套模型在连接数几百时没毛病，代码也最直观。但到了 1999 年，互联网开始膨胀，Dan Kegel 在他那篇著名的 The C10K problem 里把窗户纸捅破了：一台机器要同时扛 1 万个连接，怎么办？

1
2
3
4
5
6
7
8


若某运行时为每线程保留 8 MiB 栈 → 1 万个线程会保留约 78 GiB 虚拟地址空间
 （32 位时代直接撞 4GB 地址墙——C10K 在 2000 年前后成为问题就是这个背景）
1 万个线程频繁切换 → CPU 全耗在 context switch
而且这 1 万个连接 99% 时间都在"等数据"（keep-alive、长轮询、聊天）
 → 1 万个线程傻等，CPU 空转

 结论：在当年的 32 位硬件与线程实现下，thread-per-connection 很难经济地处理 C10K
 现代线程栈、调度器和硬件已经变化，是否可行仍要实测

破局的关键不是"更多线程"，而是"一个线程同时等很多 fd，谁有数据就处理谁"——这就是 I/O 多路复用（I/O multiplexing）。第一个吃螃蟹的，是 1983 年的 select。

二、第一代多路复用：select（1983，4.2BSD）

select 是 BSD UNIX 在 4.2BSD（1983）引入的，思路是：把"我关心的 fd"打包成三组位图，一次性扔给内核，让内核帮你看哪些就绪。

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


#include <sys/select.h>

fd_set readfds;
FD_ZERO(&readfds);
FD_SET(fd1, &readfds);
FD_SET(fd2, &readfds);
// ... 最多 FD_SETSIZE 个

struct timeval tv = { .tv_sec = 5 };
int n = select(maxfd + 1, &readfds, NULL, NULL, &tv);
// ↑ ↑ ↑ ↑
// 读集合 写集 异常集 超时

if (n > 0) {
 for (int fd = 0; fd <= maxfd; fd++) {
 if (FD_ISSET(fd, &readfds)) {
 // fd 就绪，去 read
 }
 }
}

1
2
3
4
5
6
7
8
9


select 的工作流程：

 1. 应用把 3 个 fd_set（读/写/异常）从用户空间拷贝到内核
 2. 内核遍历所有 fd，挨个检查是否就绪，标记到 fd_set 里
 3. 内核把标记后的 fd_set 拷回用户空间
 4. 应用再遍历一遍 fd_set，找出哪些被标记了
 5. 对就绪的 fd 调 read/write

 → 每次调用都重复 1-4 整个流程

select 解决了"一个线程等多个 fd"的问题，功不可没。但它有四个硬伤，每一个都在 C10K 面前致命：

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


硬伤 1：fd_set 容量受 FD_SETSIZE 限制
 glibc 等常见实现中 FD_SETSIZE 通常为 1024，fd_set 是固定位图
 → 把大于等于 FD_SETSIZE 的 fd 交给 FD_SET/select 会越界或产生未定义行为
 → 这不是简单修改内核参数就能安全突破的运行时上限

硬伤 2：每次调用都要传"全部 fd"
 三组 fd_set 在用户↔内核之间来回拷贝
 1 万个 fd 的位图约 1.2 KB，每次 select 都拷两次
 → 连接越多，单次调用越慢

硬伤 3：内核线性扫描 O(n)
 内核要把所有 fd 走一遍查就绪状态
 1 万个 fd 里只有 10 个就绪 → 也要扫 1 万次
 → 浪费的 CPU 与活跃连接数无关，与总连接数成正比

硬伤 4：返回后用户还得再扫一遍 O(n)
 select 只告诉你"有 n 个就绪"，不告诉你哪几个
 你得 FD_ISSET(fd) 从 0 遍历到 maxfd 把就绪的挑出来
 → 第二次 O(n)

1
2


一句话：select 的复杂度是 O(n)，而且 n 是"总连接数"不是"活跃连接数"。
 连接越多越慢，哪怕它们都闲着。

select 不是没救——在连接数少、活跃率高的场景（比如几十个 fd 全都很忙），它简单够用，至今还在用。但 C10K 这种"海量连接、大多空闲"的场景，它扛不住。

三、poll：去掉了 1024，但没去根

poll 是 System V 的产物（SVR3，约 1986），思路和 select 一样，只是换了数据结构：用数组代替位图，每个元素是 struct pollfd。

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


#include <poll.h>

struct pollfd fds[10000];
fds[0].fd = fd1; fds[0].events = POLLIN;
fds[1].fd = fd2; fds[1].events = POLLIN;
// ...

int n = poll(fds, 10000, 5000); // 5000ms 超时
for (int i = 0; i < 10000; i++) {
 if (fds[i].revents & POLLIN) {
 // fds[i].fd 就绪
 }
}

1
2
3
4


poll 相比 select 的改进：
 ✓ 用数组代替位图 → 没有 1024 上限，想多少传多少
 ✓ events/revents 分离 → 不用每次重建"输入"（revents 由内核写，events 不变）
 ✓ 语义更清晰（POLLIN/POLLOUT/POLLERR...）

但 select 的后三个硬伤，poll 一个都没解决：

1
2
3


硬伤 2 仍在：每次调用还是传"全部 fd"（整个 pollfd 数组用户↔内核拷贝）
硬伤 3 仍在：内核还是线性扫描所有 fd O(n)
硬伤 4 仍在：返回后用户还是得遍历整个数组找 revents

1
2


poll 解决的是"数量"问题，没解决"性能"问题。
1 万个连接里只有 10 个活跃？poll 照样每次扫 1 万个。

为什么 poll 没能根治？因为它的模型没变——仍然是"每次调用都把全集扔给内核线性扫"。只要模型是"轮询全集"，复杂度就永远是 O(总连接数)。真正要破 C10K，得换模型。

四、同时代的另一条路：kqueue 与 /dev/poll

Linux 不是唯一被 C10K 逼着想办法的系统。90 年代末到 2000 年初，几条路同时在试：

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


FreeBSD kqueue（2000，4.1-RELEASE）：
 - 不仅告诉你"谁就绪"，还告诉你"发生了什么变化"
 - kevent 结构 + 一次 kevent() 调用既可注册又可取事件
 - 支持 filter（读/写/信号/定时器/子进程...）统一抽象
 - 思路接近"边缘触发"——返回的是"变化"而非"当前状态"
 - 业界公认设计比 epoll 优雅

Solaris /dev/poll（约 1998）：
 - 写一次"兴趣集"到一个特殊设备，内核常驻
 - 后续 poll 只查"就绪"，不用重传全集
 - 第一个把"兴趣集常驻内核"落地的方案

Linux 早期的失败尝试：realtime signals + SIGIO
 - fd 就绪时内核发实时信号
 - 信号队列会溢出（OOM 时丢事件）
 - 信号乱序、合并，无法可靠对应到具体 fd
 - 实践证明不可靠，被放弃

这几条路给出了同一个关键启发：把"我关心哪些 fd"这个状态常驻内核，别每次重传；就绪事件让内核主动通知，别让应用轮询。 Linux 吸收了这些思路，做出了 epoll。

五、epoll 登场（Linux 2.5.44，2002）

epoll 在 2002 年 10 月进入 Linux 2.5.44，2003 年底随 2.6 稳定。API 三个，干净利落：

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


#include <sys/epoll.h>

// 1. 创建一个 epoll 实例（内核里建好数据结构）
int epfd = epoll_create1(0);

// 2. 注册/修改/删除关心的 fd（状态常驻内核）
struct epoll_event ev = { .events = EPOLLIN, .data.fd = fd };
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev); // ADD / MOD / DEL

// 3. 等待就绪（只返回就绪的 fd）
struct epoll_event events[128];
int n = epoll_wait(epfd, events, 128, -1); // -1 = 阻塞
for (int i = 0; i < n; i++) {
 handle(events[i].data.fd); // events 里全是就绪的
}

表面看和 select/poll 差不多，但内核里的机制完全不同。epoll 的三大核心创新：

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


创新 1：兴趣集常驻内核（不再每次重传）
 epoll_ctl ADD 时，fd 被记进内核的"兴趣集"（一棵红黑树）
 后续 epoll_wait 不用再传全集，只传一个输出数组
 → 硬伤 2 消除：没有全集的用户↔内核拷贝

创新 2：就绪靠回调维护，不在每次等待时扫描全部兴趣集
 注册 fd 时，内核在它的等待队列上挂一个回调（ep_poll_callback）
 数据到达时，驱动触发回调，把这个 fd 主动塞进"就绪链表"
 epoll_wait 只需把就绪链表里的元素拷给用户
 → 硬伤 3 消除：不再线性扫描全集，复杂度 O(就绪数)

创新 3：返回的就是就绪的（不用再扫）
 events[] 数组里前 n 个全是就绪 fd，直接用
 → 硬伤 4 消除：不需要 FD_ISSET 二次遍历

1
2
3
4
5
6
7
8


对比一眼就懂：

 select/poll：每次 select() → 内核扫 N 个 fd → 返回 → 用户再扫 N 个找就绪
 复杂度 O(N)，N = 总连接数

 epoll： epoll_ctl ADD（一次性）→ 内核挂回调
 epoll_wait() → 内核把"被回调塞进链表"的就绪 fd 拷给你
 复杂度 O(就绪数)，与总连接数无关

这就是 epoll 适合“大量注册、少量就绪”负载的重要原因：等待时无需每次线性检查全部兴趣集。不过总连接数仍会影响内核内存、epoll_ctl、fd 表、socket 缓冲区和缓存局部性，不能说与总连接数无关。

六、钻进内核：红黑树、就绪链表与回调链路

光说"回调"太虚。来看 epoll 在内核里到底长什么样。核心是 struct eventpoll（在 fs/eventpoll.c）：

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


struct eventpoll（简化）：
 ┌─────────────────────────────────────────────┐
 │ rbr : 红黑树根 —— 兴趣集（所有注册的 fd）│
 │ rdllist : 双向链表 —— 就绪链表（已就绪的 fd）│
 │ wq : 等待队列 —— epoll_wait 在此睡眠 │
 │ ovflist : 溢出链表（遍历 rdllist 期间的暂存）│
 └─────────────────────────────────────────────┘

每个注册的 fd 对应一个 struct epitem：
 - rb_node：挂在 rbr 红黑树上（按 fd 排序，去重）
 - rdllist_node：就绪时挂在 rdllist 链表上
 - ffd：指向 file + fd
 - event：关心的事件（EPOLLIN/OUT/ET...）
 - 注册时在 file 的等待队列上挂了 ep_poll_callback

1
2
3
4


为什么兴趣集用红黑树？
 - epoll_ctl ADD/MOD/DEL 要按 fd 查找/增删 → 红黑树 O(log n)，自平衡、按 fd 有序、天然去重
 - 不用数组：fd 值可能很大（几万甚至十几万），按 fd 直接建数组会浪费巨量空间
 - 当前实现使用内核的红黑树结构获得稳定的对数级查找；为什么没有选择其他结构属于实现权衡，不应只归因于某一个性能指标

完整的数据到达链路（这是 epoll 的灵魂）：

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


 ① 网卡收到数据包 → DMA 写入 ring buffer → 触发硬件中断
 ↓
 ② 中断处理（NAPI）→ 软中断 NET_RX_SOFTIRQ
 ↓
 ③ 协议栈处理 → 数据挂到 socket 的接收队列
 ↓
 ④ sock_def_readable() → 唤醒 socket 的等待队列
 ↓
 ⑤ 等待队列上有 epoll 挂的 ep_poll_callback → 触发回调
 ↓
 ⑥ ep_poll_callback 把这个 fd 的 epitem 挂到 eventpoll->rdllist
 ↓
 ⑦ 唤醒在 eventpoll->wq 上睡眠的 epoll_wait
 ↓
 ⑧ epoll_wait 醒来 → 把 rdllist 里的就绪事件拷到用户 events[]

1
2
3
4


关键洞察：
 - "fd 是否就绪"这个判断，是由数据到达时的回调"推"出来的，不是 epoll_wait 主动"拉"的
 - 所以 epoll_wait 的开销只取决于"有多少 fd 就绪"，与"注册了多少 fd"无关
 - 这是从"轮询"到"事件驱动"的范式转换——和 select/poll 的本质区别就在这一步

1
2
3
4
5
6
7


epoll_wait 内部的小细节：
 - 进 epoll_wait 时先看 rdllist 非空？有就拷给用户（最多 maxevents 个）
 - 空就睡到 wq 上，等回调唤醒
 - 拷出去的 epitem：
 LT 模式：如果拷完发现还就绪（数据没读完），留在 rdllist 里下次还返回
 ET 模式：拷出去就从 rdllist 摘掉，只有"下次有新数据"才重新挂回
 - ovflist：防止"遍历 rdllist 拷给用户"期间又有新就绪 fd 来插队丢事件

七、LT vs ET：两种触发模式，两种哲学

epoll 最容易被用错的地方，是 水平触发（LT） 和 边缘触发（ET） 的选择。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


LT（Level Triggered，默认）：
 只要 fd 上"还有数据没读完"，每次 epoll_wait 都会返回它
 类似 select/poll 的语义
 → 你读一点、剩一点，下次还会通知你

ET（Edge Triggered，EPOLLET）：
 只在 fd "状态变化"时通知一次（从无数据到有数据）
 通知之后你必须一口气把数据读完（读到 EAGAIN）
 否则剩下的数据再也不会通知你 → 数据饥饿
 → 类似"边沿触发"的电路：只在跳变时反应

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


场景：socket 一次到达 4 KB 数据，你的 buf 只有 1 KB

 LT：
 epoll_wait 返回 fd → read 1KB → 剩 3KB
 下次 epoll_wait → 还会返回这个 fd → 再 read 1KB
 ... 直到读完

 ET：
 epoll_wait 返回 fd 一次 → read 1KB → 剩 3KB
 下次 epoll_wait → 不再返回这个 fd（没有"新"数据到达）
 → 那 3KB 可能一直留在接收缓冲区，直到新的状态变化或应用再次主动读取
 → 数据饥饿 / 对端以为你收到了

ET 的纪律（违反任何一条都会出 bug）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


1. fd 必须设为非阻塞（O_NONBLOCK）
 ET 下你要循环 read 到 EAGAIN，阻塞 fd 会在数据读完时卡死整个线程

2. read/write 必须循环到返回 EAGAIN/EWOULDBLOCK
 一次没读完 = 下次没通知 = 数据丢

3. accept 也要循环到 EAGAIN
 listen fd 在 ET 模式下，一次只 accept 一个会导致后续连接排队甚至被拒绝

4. 收到 EAGAIN 不是错误，是"本轮读完了"的正常信号

为什么 ET 理论上更快？

1
2
3
4
5
6
7
8


LT：数据没读完，每次 epoll_wait 都返回 → 可能很多次唤醒
ET：一次跳变只通知一次 → 减少 epoll_wait 的返回次数和用户态↔内核态切换

 一个慢消费者（4KB 数据，每次 read 1KB）：
 LT：4 次 epoll_wait 返回 + 4 次 read
 ET：1 次 epoll_wait 返回 + 4 次循环 read（在用户态连读）

 → ET 把"读完"的循环放在用户态，少了内核唤醒的开销

但 ET 更难写对。生产实践：

1
2
3
4
5
6


谁用 ET：nginx（ET + 多 worker，榨干性能）、早期高性能网络库
谁用 LT：Redis（单线程 LT，简单可靠）、Java NIO 默认、大多数业务服务
 → LT 行为接近 select/poll，迁移成本低，不容易出 bug

 教训：除非你清楚知道为什么需要 ET，否则用默认 LT。
 ET 的性能优势在大多数业务场景被"代码复杂度 + bug 风险"抵消。

八、epoll 的演进史：API 与标志位

epoll 不是一蹴而就的，它自己也在长。每个新标志位都对应一个真实痛点。

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


2002 Linux 2.5.44 epoll 初登场
 epoll_create(size) / epoll_ctl / epoll_wait
 （size 参数其实没用，内核动态扩展，留着只是兼容）

2003 Linux 2.6 稳定
 EPOLLET（边缘触发）

2007 Linux 2.6.22 signalfd / timerfd / eventfd
 "一切皆文件描述符"——信号、定时器、事件都能变成 fd
 → 可以统一塞进 epoll，一个 wait 等所有事件源
 （timerfd 2.6.25 补齐）

2008 Linux 2.6.27 epoll_create1(flags)
 + EPOLL_CLOEXEC（fork+exec 时不泄漏 fd）
 → 废弃 size 参数，更干净
 + epoll_pwait（2.6.19 引入，可指定信号屏蔽，原子地"等+改屏蔽"）

2003 Linux 2.6 EPOLLONESHOT
 一个 fd 被通知一次后自动禁用，直到 EPOLL_CTL_MOD 重新 arm
 → 线程池场景：保证一个 fd 同一时刻只被一个工作线程处理
 （避免两个线程同时 read 同一个 fd 的竞态）

2016 Linux 4.5 EPOLLEXCLUSIVE
 多个 epoll 实例监听同一个 fd 时，减少以 exclusive 方式等待者的唤醒数量
 → 解决"惊群"（thundering herd）：一个连接到来，N 个 worker 全被唤醒
 抢同一个 accept，N-1 个白跑

1
2
3
4
5


演进脉络能看出 epoll 的设计取向：
 ① 把更多事件源（信号/定时器）统一成 fd → 一个 epoll 管所有
 ② 减少多线程下的竞争（ONESHOT / EXCLUSIVE）
 ③ API 清理化（create1 废弃无用参数）
 → 朝"统一、可扩展、低竞争"走，但本质模型（就绪通知）没变

九、实战：一个 epoll echo server

把前面所有概念落成一个能跑的程序。LT 版（默认，推荐起步）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90


#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <arpa/inet.h>

#define PORT 9000
#define MAX_EVENTS 1024
#define BUF_SIZE 1024

static int set_nonblocking(int fd) {
 int flags = fcntl(fd, F_GETFL, 0);
 if (flags == -1) return -1;
 return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

int main(void) {
 /* 1. listening socket */
 int lfd = socket(AF_INET, SOCK_STREAM, 0);
 int opt = 1;
 setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
 set_nonblocking(lfd);

 struct sockaddr_in addr = {0};
 addr.sin_family = AF_INET;
 addr.sin_addr.s_addr = INADDR_ANY;
 addr.sin_port = htons(PORT);
 bind(lfd, (struct sockaddr *)&addr, sizeof(addr));
 listen(lfd, SOMAXCONN);

 /* 2. epoll 实例 + 注册 listen fd */
 int epfd = epoll_create1(0);
 struct epoll_event ev = {0};
 ev.events = EPOLLIN; /* LT（默认） */
 ev.data.fd = lfd;
 epoll_ctl(epfd, EPOLL_CTL_ADD, lfd, &ev);

 struct epoll_event events[MAX_EVENTS];
 char buf[BUF_SIZE];
 printf("listening on %d (epoll, LT)\n", PORT);

 /* 3. 事件循环 */
 for (;;) {
 int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
 for (int i = 0; i < n; i++) {
 int fd = events[i].data.fd;

 if (fd == lfd) {
 /* 新连接：循环 accept 到 EAGAIN（LT 下其实 accept 一次也行，循环更稳） */
 for (;;) {
 int cfd = accept(lfd, NULL, NULL);
 if (cfd < 0) {
 if (errno == EAGAIN || errno == EWOULDBLOCK) break;
 perror("accept"); break;
 }
 set_nonblocking(cfd);
 ev.events = EPOLLIN;
 ev.data.fd = cfd;
 epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &ev);
 }
 } else {
 /* 已连接 fd：循环读到 EAGAIN（LT 下推荐，ET 下必须） */
 for (;;) {
 ssize_t r = read(fd, buf, sizeof(buf));
 if (r > 0) {
 /* 教学简化：生产代码必须处理 partial write、EAGAIN，并按需监听 EPOLLOUT */
 if (write(fd, buf, r) < 0 && errno != EAGAIN && errno != EWOULDBLOCK)
 perror("write");
 } else if (r == 0) {
 /* 对端关闭 */
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 close(fd);
 break;
 } else {
 if (errno == EAGAIN || errno == EWOULDBLOCK) break;
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 close(fd);
 break;
 }
 }
 }
 }
 }
}

1
2
3
4
5
6
7


关键点：
 - listen fd 和 conn fd 都设 O_NONBLOCK
 （epoll 高并发下阻塞 fd 会卡死整个事件循环）
 - accept / read 都循环到 EAGAIN
 LT 下这是"推荐"，ET 下这是"必须"
 - 对端关闭（read 返回 0）或出错时 EPOLL_CTL_DEL + close
 （不 DEL 直接 close 也行，内核会自动清理；但显式 DEL 更清晰）

注册为 ET 需要改两处标志位，但完整 ET 服务还要正确处理写缓冲：

1
2
3
4
5


// listen fd 注册：加 EPOLLET
ev.events = EPOLLIN | EPOLLET;

// conn fd 注册：加 EPOLLET
ev.events = EPOLLIN | EPOLLET;

1
2
3
4
5
6


ET 版的硬性要求（上面代码已满足）：
 ✓ fd 非阻塞（已 set_nonblocking）
 ✓ accept 循环到 EAGAIN（已循环）
 ✓ read 循环到 EAGAIN（已循环）
 注意：上面的 echo 示例明确简化了 partial write。生产 ET 代码需要保存未写完的数据，
 在 socket 可写时继续发送，并动态管理 EPOLLOUT；不能只加 EPOLLET 就宣称迁移完成。

十、epoll 的陷阱与坑

坑 1：ET 模式不读到 EAGAIN → 数据饥饿

1
2
3
4
5
6
7


ET 下 read 一次就返回，没读干净
 → 剩下的数据卡在内核缓冲区
 → 没有新的"跳变"，epoll_wait 不再通知
 → 对端以为你收到了，业务层丢数据

 根因：误把 ET 当 LT 用
 修复：ET 下必须循环 read 到 EAGAIN（见上一节的代码）

坑 2：ET 下忘了设 O_NONBLOCK → 线程卡死

1
2
3
4
5
6
7


ET + 阻塞 fd：
 循环 read，最后数据读完时 read 不返回 EAGAIN，而是阻塞
 → 整个事件循环线程挂在一个 fd 上
 → 其他所有连接全部卡死

 根因：ET 的"循环到 EAGAIN"前提是 fd 非阻塞
 修复：epoll 注册的 fd 一律 O_NONBLOCK，无例外

坑 3：accept 惊群 → EPOLLEXCLUSIVE

1
2
3
4
5
6
7
8
9


多个 worker 进程/线程各自 epoll_wait 同一个 listen fd
 新连接到达 → 所有 worker 被唤醒
 只有一个 accept 成功，其余 accept 返回 EAGAIN
 → N-1 个 worker 白醒一次，context switch 浪费

 修复：Linux 4.5+ 给 listen fd 注册时加 EPOLLEXCLUSIVE
 ev.events = EPOLLIN | EPOLLEXCLUSIVE;
 内核会从以 exclusive 方式等待的集合中唤醒一个或较少数量的 waiter；
 与非 exclusive 注册混用时还要按 epoll(7) 的语义分析

坑 4：EPOLLONESHOT 用完不重新 arm → fd 失联

1
2
3
4
5
6
7


ONESHOT 模式：fd 通知一次后自动禁用
 worker 处理完必须 EPOLL_CTL_MOD 重新 arm，否则这个 fd 再也不会有事件
 → 连接"假死"

 适合：线程池模型，保证一个 fd 同一时间只被一个线程碰
 代价：每次处理完多一次 epoll_ctl 系统调用
 陷阱：处理中途异常退出没 arm → fd 保持禁用

坑 5：大量短连接不适合 epoll

1
2
3
4
5
6
7
8


epoll_ctl ADD/DEL 不是免费的：
 - ADD 要建 epitem、插红黑树、在 file 等待队列挂回调
 - DEL 要拆回调、从树里删
 短连接频繁建断 → epoll_ctl 开销可能超过收益

 对比：极低并发 + 短连接，select 反而最简单够用
 实践：nginx 用连接池 + 长连接，避免频繁 ADD/DEL
 短连接密集的场景考虑连接复用或上游加 keepalive

坑 6：fork 后 epoll fd 的继承

1
2
3
4
5
6


fork() 后子进程继承 epoll fd（指向同一个内核 eventpoll）
 但通常你不想父子进程同时 epoll_wait 同一个 epfd
 → `EPOLL_CLOEXEC` 只控制 exec 时关闭，不阻止 fork 继承；通常应使用
 epoll_create1(EPOLL_CLOEXEC) 防止执行新程序时泄漏，并明确设计 fork 后谁负责等待

 陷阱：多进程共享 epfd 的语义复杂，一般每进程一个 epfd 更清晰

十一、谁在用 epoll（后端视角）

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


nginx
 ET + 多 worker（每 worker 一个 epfd）
 经典的 Reactor：主 worker epoll_wait → 就绪后非阻塞处理
 → 高并发静态/代理的标杆

Redis
 单线程 + epoll（LT）
 6.0 引入多线程 IO，仍是 epoll 驱动，只是把 read/write 分摊到 IO 线程
 → LT 足够，简单可靠优先

Go runtime netpoller
 runtime 把 epoll 封装成"同步接口 + goroutine 调度"
 你写 conn.Read() 看起来是阻塞的，底层 goroutine 在 epoll_wait 上 park
 fd 就绪时 runtime 唤醒对应 goroutine
 → "同步写法、异步底层"，epoll 是 Go 网络的隐藏地基

Java NIO Selector
 Linux 上 SelectorProvider 默认用 epoll
 Netty 在此之上做 Reactor/多线程

Node.js libuv
 Linux 后端就是 epoll（封装成事件循环）

.NET Kestrel（Linux）
 SocketAsyncEventArgs 在 Linux 上映射到 epoll
 → 你写的 async network 代码，到了 Linux 就是 epoll

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


后端工程师的现实：
 你写 await httpClient.GetAsync(...) / go conn.Read() / channel.send()
 ↓
 框架/runtime 把它翻译成 epoll 注册 + 等待
 ↓
 Linux 内核用回调把就绪 fd 推上来

 → epoll 是你所有"高并发网络代码"在 Linux 上的共同底层
 哪怕你从不直接调 epoll API，理解它也能解释你遇到的
 "连接数上不去""CPU 被 epoll_wait 吃了""ET 丢数据"等问题

十二、终章：io_uring 的挑战（2019，Linux 5.1）

epoll 至今仍是主流，但它有一个根本性的局限：它只告诉你"就绪"，不替你干活。

1
2
3
4
5
6
7


epoll 的模型：就绪通知（readiness notification）
 epoll_wait → "fd 可读了" → 你自己调 read() → 阻塞/拷贝
 → 阶段1（等数据）交给内核，阶段2（拷贝）还是你自己干
 → 仍是"同步 I/O"（详见 [I/O 模型全解](../internals/01-io-models/)）

 每次就绪后还要一次 read() 系统调用 → 用户态↔内核态切换
 高 QPS 下系统调用本身就是开销

2019 年，Jens Axboe（Linux 块层维护者）在 Linux 5.1 引入 io_uring，这是一次更大的换轨：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


io_uring 的模型：完成通知（completion notification）
 - 两个共享内存环形缓冲：SQ（提交队列）+ CQ（完成队列）
 - 你往 SQ 塞一个"读请求"（SQE）→ 内核自己去等数据 + 拷贝
 - 完成后内核往 CQ 塞一个"完成结果"（CQE）
 → 阶段1 + 阶段2 全由内核完成，真正的异步 I/O

 杀手锏：
 ① 共享内存 → SQE/CQE 不走系统调用拷贝
 ② 批量提交 → 一次 syscall 提交一摞请求
 ③ 可选 sqpoll → 内核常驻一个线程轮询 SQ，连提交 syscall 都省了

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


epoll vs io_uring：

 维度 epoll io_uring
 ─────────────────────────────────────────────────────────
 模型 就绪通知（你再去 read） 完成通知（内核替你 read）
 真/伪异步 伪（拷贝阶段自己做） 真
 系统调用数 每次就绪后还要 read() 可批量、可零（sqpoll）
 数据拷贝 每次系统调用拷贝 共享内存环形缓冲
 复杂度 简单，API 三个 复杂，SQE/CQE/注册/缓冲管理
 生态成熟度 20 年，绝对主流 2019 起，快速演进中

但 io_uring 的路并不平坦。2023–2024 年，Google 安全团队接连披露多个通过 io_uring 触发的内核提权漏洞，导致：

1
2
3
4
5
6
7


2024 安全风波：
 - io_uring 的攻击面大（内核里加了太多代码、与各种子系统交互）
 - Google 在 Android / ChromeOS 默认关闭 io_uring
 - systemd、部分发行版讨论默认禁用
 - 5.x→6.x 期间多次收紧 io_uring 权限（io_uring_disabled sysctl）

 → io_uring 性能极强，但"是否默认可用"成了新的不确定性

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


epoll 会不会被 io_uring 取代？
 短期不会：
 - epoll 简单、稳定、20 年生态，几乎所有运行时都依赖它
 - io_uring 复杂、API 仍在演进、安全争议未平
 - 对绝大多数应用，epoll + 非阻塞 I/O 已经足够快

 长期看：
 - 极致吞吐（存储、数据库、超高 QPS 网关）会逐步倒向 io_uring
 - 新运行时（如 Rust 的 tokio-uring、Go 的实验性 io_uring 支持）在试水
 - 但 epoll 作为"默认通用方案"的地位，十年内不动摇

 → 类比：io_uring 之于 epoll，像 epoll 之于 select——新方案更优，但老方案不会消失

十三、小结

从 1983 年的 select 到 2019 年的 io_uring，Linux I/O 多路复用走了 40 年。主线只有一条：从"轮询全集"到"回调通知"，从"就绪通知"到"完成通知"——每一次换轨都是把更多工作下沉到内核、减少用户态的无效扫描和系统调用。

select（1983）：位图 + 三组 fd_set，1024 上限，O(n) 双重扫描，每次重传全集
poll（1986）：数组去 1024，但模型没变，仍是 O(n) 全集轮询
epoll（2002）：兴趣集常驻内核 + 回调维护就绪集合，等待交付成本主要随就绪事件数增长
epoll 内核机制：epoll_ctl 挂回调 → 数据到达触发 ep_poll_callback → 入 rdllist → epoll_wait 取件
LT vs ET：LT 重复通知（像 select），ET 只通知跳变一次（必须读到 EAGAIN）
标志位演进：EPOLLET / EPOLLONESHOT（线程池）/ EPOLLEXCLUSIVE（防惊群）/ signalfd·timerfd·eventfd（统一事件源）
实战坑：ET 不耗尽本轮 I/O 会饥饿、忘 O_NONBLOCK 会卡死、短连接会增加注册成本、ONESHOT 不 rearm 会失联
生态：nginx、Redis 和多种运行时在常见 Linux 配置下使用 epoll，但后端取决于具体版本与环境
io_uring（2019）：完成通知 + 共享环 + 批量，是 epoll 的挑战者，但简单可靠的 epoll 仍长期主流

1
2
3
4


记住三句话：
 1. epoll 的本质是把兴趣集常驻内核并维护就绪集合，避免每次等待都扫描全部注册 fd
 2. LT 像电平（有数据就一直通知），ET 像边沿（跳变才通知一次）——ET 必须读到 EAGAIN，否则饥饿
 3. epoll 只告诉你"就绪"，io_uring 替你"完成"——前者是现在的地基，后者是未来的方向

下次看到 epoll_wait 占 CPU、连接数上不去、或者纠结 ET/LT，回头看这条演进线，问题多半能对上号。和本站的 Reactor 模式、零拷贝配起来读，Linux 高并发网络的全貌就齐了。

跟着一个 API 请求走完全程：后端全链路解剖

Thu, 27 Nov 2025 10:00:00 +0800

写在前面

Nginx、Kestrel、Redis、数据库——单看每一层，这个博客都有专文讲过。但它们怎么串成一次真实的请求？这篇把所有层穿起来，跟着一个 GET /api/orders/123 走完全程。

每一跳只讲三件事：原理（链到已有专文，不重复展开）、大概多慢（链到《每个程序员都该知道的延迟数字》）、怎么优化。这是博客的"集大成"篇——读完你会看到这些独立的文章其实是一条线上的事。

场景

用户在 App 里点开一个订单详情，前端发：

1
2


GET https://api.example.com/orders/123
Authorization: Bearer <JWT>

后端要做：验 JWT → 查 Redis 订单缓存 → 没命中就查 DB → 订单里要显示用户名，可能调下游用户服务 → 返回 JSON。

一次请求，按本文模型拆成十个阶段（编号 0–9）：

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


浏览器 / App
 │ GET /orders/123 (JWT)
 ▼
[DNS] api.example.com → IP 第 0 跳
 ▼
[TCP + TLS 握手] 冷启动 2-3 RTT / 复用 0 第 1 跳
 ▼
[四层 LB (LVS / 云 SLB)] ───▶ [Nginx 反代] 第 2-3 跳
 │ TLS 终止 / 路由 / 限流
 ▼
 [Kestrel] epoll / IOCP 第 4 跳
 │ 中间件管线 第 5 跳
 ▼
 [Controller]
 │ │
 Redis ◀───┘ └──▶ 数据库 第 6-7 跳
 (缓存命中) (索引 / 磁盘 IO)
 │
 ▼ (可选)
 [下游用户服务] 第 8 跳
 HttpClient + 可能穿 sidecar
 │
 ▼
 JSON 返回 ▶ gzip ▶ TLS ▶ 客户端 第 9 跳

第 0 跳：DNS 解析

api.example.com 要先变成 IP。浏览器、OS 或本地解析器缓存命中通常很快；未命中时，递归解析器可能继续查询权威 DNS，耗时受缓存状态、网络路径和解析链影响，不能固定写成一个范围。

优化：DNS 预解析、合理 TTL、HTTPDNS（绕过运营商）。冷启动才痛，热请求基本免费。

第 1 跳：TCP + TLS 握手

TCP 三次握手 1 RTT；TLS 1.3 握手 1 RTT（1.2 是 2 RTT）。所以冷启动一个 HTTPS 请求要付 2–3 RTT，同机房就是 1–2ms，跨城就是几十 ms。

这一跳最重要的结论：连接复用通常是高杠杆优化。keep-alive / 连接池让后续请求复用已经建立的连接，避免重复支付 TCP 和 TLS 握手。TLS 1.3 会减少完整握手往返；0-RTT 只适用于会话恢复，并有重放风险，不能无条件用于有副作用的请求。

这正是《HttpClient 的前世今生》那篇的核心——new HttpClient() 每次新建连接，把本该复用的 TCP 连接主动掐断、端口踢进 TIME_WAIT，是 .NET 史上最著名的反模式之一。

第 2 跳：入口（CDN / 四层负载均衡）

静态资源走 CDN 就近返回（不进后端）；动态 API 进四层负载均衡（LVS / 云 SLB / NLB），按 IP + 端口把包转发到某一台 Nginx。LB 本身 μs–ms 级，几乎不花钱。

优化：CDN 边缘缓存把静态挡在外面；LB 健康检查要及时摘掉挂掉的 Nginx，别把流量往死节点送。

第 3 跳：Nginx 反向代理

到七层入口 Nginx 了，它可以做四件事：TLS 终止、路由（按 path / host 转发到对应上游）、限流（limit_req）、可选的鉴权前置。TLS 是否在此终止、到上游是否重新加密，取决于信任边界和部署配置，不能默认上游一定走明文。

详见《Nginx 学习笔记（二）：反向代理与负载均衡》《（三）：HTTPS、性能优化与实战》。Nginx 自身处理是 ms 级。

优化：最容易忘的一条是 upstream keepalive——Nginx 到 Kestrel 也要复用连接，别每个请求都新建一次 TCP（又掉进第 1 跳的坑）。其次是 HTTP/2、gzip 压缩响应。

第 4 跳：Kestrel 接收（I/O 模型 + Pipelines + 线程池）

包到内核了。Kestrel 使用操作系统的异步/事件驱动 I/O 机制，并利用 System.IO.Pipelines 的池化缓冲区减少分配和不必要的复制，再把请求交给 ASP.NET Core 管线。异步 I/O 避免在等待网络时长期占用请求线程，但业务代码仍可能因同步阻塞、锁竞争或 CPU 密集工作占住线程。

这一跳的关键是避免在线程上同步等待慢 I/O：等待期间线程无法处理其他请求，负载升高时容易造成线程池排队。完整的 I/O 模型谱系（阻塞/非阻塞/IO多路复用/异步）见《操作系统学习笔记（一）：I/O 模型全解》，.NET 视角的落地见《.NET 高并发编程全景》。

延迟：内核↔用户态拷贝 μs 级，几乎可以忽略。

第 5 跳：ASP.NET Core 中间件管线

请求流过中间件链：路由匹配 → 鉴权（验 JWT 签名和过期）→ 限流 → 日志 / 追踪埋点 → 进 Controller。这一段是纯 CPU，μs–ms 级。

详见《ASP.NET Core 学习笔记（一）：基础架构与启动流程》（中间件管线的本质）。

优化：中间件顺序有讲究（能短路的尽量靠前，比如鉴权失败直接 401，别白跑后面的活）；热路径上别 new 重对象、别做重活；依赖注入按需，别把瞬态服务当万金油。

第 6 跳：Redis 缓存层

Controller 先查 Redis（order:123）。命中 → 直接反序列化返回，跳过第 7 跳。

详见《Redis 学习笔记（二）：缓存实战》。同机房 GET 大约 ~0.1–0.3ms。

优化：缓存 key 设计、过期 + 预刷新、防穿透（空值也缓存一层）、防击穿（热 key 互斥重建）、防雪崩（过期时间加随机抖动）。

这一跳命中省下的是第 7 跳的 ~ms–10ms，是全链路杠杆最大的一处。缓存命中率从 90% 提到 99%，DB 压力差 10 倍。

第 7 跳：数据库（缓存未命中）

Redis 没命中 → 查 DB。SELECT ... WHERE id = 123 走一遍：解析 → 优化器选执行计划 → 走索引（B+ 树）→ 命中 buffer pool 直接返回；没命中触发磁盘 IO。

buffer pool 命中：~0.5–2ms；
触发磁盘 IO：再 +1ms（SSD）/ +10ms（HDD）。

索引原理见《数据库系列（三）：索引原理》，慢查询定位和 SQL 调优见《数据库性能优化实战》，《数据库系列（四）：事务与 ACID》里给过 fsync 的实测对照（HDD ~10ms / SSD ~1ms / NVMe ~0.1ms）。

优化：索引建对是 DB 性能的头号杠杆（一个该建没建的索引能让查询从 1ms 变 100ms）；其次是连接池、慢查询监控、把随机写转顺序写（WAL）。绝大多数"接口慢"的根因在这一跳，不在代码里。

第 8 跳：下游服务调用（微服务场景）

订单要显示用户名，本地没有，得调用户服务：应用层 HttpClient 发请求 → 可能穿过 sidecar（Envoy / ztunnel）→ 网络 → 对端 sidecar → 对端应用。

延迟 = 网络往返 + 两端序列化 + 对端处理 + 可能的代理成本。代理会增加数据路径、CPU 和排队成本，但没有适用于所有环境的固定“每 hop 2–5ms”。Istio 官方基准明确指出，延迟取决于协议、连接数、请求率、负载、worker 数和启用的功能；应在自己的拓扑和策略下测 p50/p99。

优化：

并行调用——要调多个下游，用 Task.WhenAll 并发，别串行 await 三次（串行 vs 并行差的是整倍 RTT，见《.NET 高并发编程全景》）；
连接池（同第 1 跳，HttpClient 必须复用）；
缓存下游结果（用户名这种不常变的，缓存几分钟省一次跨服务调用）；
如果 sidecar 税痛，考虑 sidecar-less（Ambient / Cilium）。

第 9 跳：序列化 + 返回

对象 → JSON（中等对象 ~10–100μs）→ 原路返回：中间件收尾 → Kestrel 写响应 → Nginx gzip 压缩 → TLS 加密 → 客户端。

优化：压缩省带宽（但别 gzip 已经压过的图/视频）；大响应用异步流，别一次性 buffer 进内存；字段精简，别返回前端用不上的列（既浪费序列化又浪费带宽）。

把全程延迟叠起来

下面只是展示如何列预算的示例假设，不是可直接套用的基准。真实系统要用 trace 分阶段测量，并分别观察 p50、p95 和 p99：

跳	热请求	冷启动 / 缓存未命中
DNS	<1ms（命中）	10–100ms
TCP + TLS	0（连接复用）	1–2ms（2–3 RTT）
LB + Nginx	~1ms	~1ms
Kestrel + 中间件	~1ms	~1ms
Redis（命中）	~0.2ms	—
DB（未命中才走）	—	~2–10ms
下游服务	取决于 RTT 与对端处理	取决于 RTT、握手与对端处理
序列化 + 返回	~1ms	~1ms
合计	按各阶段实测相加	按各阶段实测相加

核心洞察：总延迟是各跳之和，抓最贵的那几跳——几乎总是 DB 的磁盘 IO + 网路的 RTT。在一个 μs 级的 JSON 序列化上纠结，不如把一个 DB 查询的索引建对（省 10ms）、把一个跨服务调用并行化（省一个 RTT）。这就是延迟数字篇"把现实操作拆回原子项"方法论的全链路应用。

全链路可观测

这么多跳，出问题了怎么定位"慢在哪"？给每个请求一个 traceId，跨所有跳透传（HTTP header），每一跳是一个 span。OpenTelemetry 把它们串成一条 trace，一眼看到哪一跳吃了 80% 的时间。

没有全链路追踪，慢请求是个黑盒；有了它，瓶颈一目了然。详见《后端架构实战（七）：可观测性——微服务的神经系统》。这是全链路的"运维面"，和前面十跳的"原理面"同样重要。

小结

一次请求可以拆成十个阶段（编号 0–9）：DNS → TCP/TLS → LB → Nginx → Kestrel → 中间件 → Redis → DB →（下游服务）→ 序列化返回。不是每个部署都包含全部阶段。
总延迟 = 各阶段之和，先抓实测大头：远程 I/O 和网络 RTT 经常占主要部分，但 CPU、锁竞争和排队在高负载下同样可能成为瓶颈。
杠杆最大的两处：缓存命中（直接省掉 DB 那一跳）+ 连接复用（省掉握手那两跳）。
微服务多一层通信成本：RTT、序列化、对端处理和代理都会进入预算，能安全并行的独立调用不要无谓串行。
排障靠全链路 trace：traceId 贯穿所有跳，是"慢在哪"的答案。

单看每一层是知识点，把它们串成一次请求，才是系统。这也是这个博客写到一百多篇时，该有的那张"总图"。

参考资料

这篇是 capstone，主要交叉链接本博客的专题文章（见正文《》引用）。延迟量级全部来自《每个程序员都该知道的延迟数字》。想看跨层的系统性视角，推荐《Designing Data-Intensive Applications》（Martin Kleppmann）。

HttpClient 的前世今生：从 Socket 耗尽到 .NET 8 韧性管线

Thu, 13 Nov 2025 10:00:00 +0800

写在前面

.NET 里很少有哪个类型像 HttpClient 这样：API 简单到五分钟就能上手，却又被全社区的工程师集体用错了十年。它的每一个“坑”——socket 耗尽、DNS 不刷新、超时分不清——背后其实都是同一个设计张力的不同投影：

HTTP 连接是昂贵资源，必须复用；而复用又与世界的变化（DNS、故障、超时）天然冲突。

理解了这层张力，HttpClient 的“前世今生”就不再是一堆要背诵的最佳实践，而是一条清晰的演进脉络：从无脑 new、到静态单例、到 IHttpClientFactory、再到 .NET 8 的标准韧性管线，每一步都是在重新回答“怎么既复用、又保鲜”。

一、前世：`using (var client = new HttpClient())` 为什么是反模式

先看那段几乎每个 .NET 新手都写过的代码：

1
2
3
4
5


public async Task<string> GetAsync(string url)
{
 using var client = new HttpClient(); // ← 灾难的起点
 return await client.GetStringAsync(url);
}

它看起来人畜无害，但在高并发下，服务会以 Unable to connect to the remote server / SocketException 集体阵亡。根因不是 HttpClient 有 bug，而是你误用了 TCP。

先把一次 TCP 连接的生命周期拉出来看：

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


客户端 服务端
 │ │
 │ ── SYN ────────────────────────▶ │ ① 三次握手
 │ ◀── SYN+ACK ─────────────────── │
 │ ── ACK ────────────────────────▶ │ ESTABLISHED
 │ │
 │ ◀═══ HTTP 请求 / 响应 ═════════▶ │ ② 数据传输
 │ │
 │ ── FIN ────────────────────────▶ │ ③ 四次挥手
 │ ◀── ACK ─────────────────────── │ （客户端先发 FIN → 它就是主动关闭方）
 │ ◀── FIN ─────────────────────── │
 │ ── ACK ────────────────────────▶ │
 │ │
 │ TIME_WAIT（≈ 2×MSL） │ ④ 主动关闭方卡在这里
 │ 本地端口在此期间被占用 │

图里的报文标志：SYN = synchronize（同步，建立连接用）、ACK = acknowledgment（确认收到）、FIN = finish（结束，关闭连接用）；ESTABLISHED 表示连接已建立。

关键：TIME_WAIT 只落在"主动关闭连接"的那一端。 HTTP 客户端通常是自己发请求、用完就关，于是客户端几乎总是那个主动关闭方——也就总是 TIME_WAIT 的承担方。

为什么主动关闭方要留在 TIME_WAIT？ 具体时长由操作系统 TCP 实现决定，核心原因有两个：

让旧报文自然消亡：等待足够长时间，让旧连接中延迟的报文失效，避免污染将来复用同一四元组的新连接。
可靠收尾：最后那个 ACK 可能丢。若丢了，对端会重发 FIN；主动关闭方待在 TIME_WAIT 里才能再回一个 ACK，让对端正常关闭。若主动关闭方立刻消失，对端就只能超时强退。

代价就是：TIME_WAIT 期间，这个本地端口被占用，同一个四元组（源 IP:源端口 → 目的 IP:目的端口）不能立刻被新连接复用。

问题在于：反复创建并释放拥有独立 handler 的 HttpClient 会频繁关闭连接；高连接创建率会消耗有限且可配置的临时端口，并留下大量 TIME_WAIT，最终可能导致新连接失败。

这是 .NET 团队当年在官方文档里专门加警告的著名陷阱。Dispose 不但没帮你，反而加速了耗尽，因为它把本该复用的连接主动掐断了。

排障信号：netstat -an | findstr TIME_WAIT（Windows）或 ss -tan state time-wait（Linux）可以辅助观察 TIME_WAIT；还要结合进程、目的端、端口范围和连接创建率，单看数量不能证明根因。

二、第一次救赎：静态单例与 DNS 陈旧

既然不能每次 new，那就复用——进程内共享一个静态 HttpClient：

1

private static readonly HttpClient _client = new();

socket 耗尽立刻消失，因为连接被池化复用、不再频繁关闭。但这套方案运行一段时间后，会在某些场景下出现一种更隐蔽的故障：服务偶尔连不上，且恰好发生在对端故障转移之后。

这就是 DNS 陈旧（DNS staleness）。HttpClient 在创建新连接时解析 DNS，不会主动跟踪 DNS 记录的 TTL；现有连接可继续复用原 IP，直到连接被替换。对端故障转移或地址变化后，过长的连接生命周期因此可能延迟切换。

于是我们陷入了一个死结：

复用连接 → socket 不耗尽，但 DNS 不刷新；
每次新建 → DNS 是新的，但 socket 耗尽。

这是 HttpClient 演进的核心驱动力——如何在“连接复用”和“端点保鲜”之间找到平衡。后续所有方案（IHttpClientFactory、SocketsHttpHandler.PooledConnectionLifetime）本质上都在回答这一个问题。

三、原理：HttpClient 其实是个“门面”

要看懂后面的方案，先得看清 HttpClient 的分层。它本身几乎是空的——真正干活的是它持有的 HttpMessageHandler：

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


HttpClient ← 薄薄的门面（Facade），公开 GetAsync/PostAsync
 │
 ▼
HttpMessageHandler 管线 ← 真正的架构在这里
 │ DelegatingHandler：日志 / 追踪
 ▼
 │ DelegatingHandler：韧性（重试 / 熔断 / 超时）
 ▼
 │ DelegatingHandler：认证 / 签名
 ▼
SocketsHttpHandler（主处理器） ← 连接池、HTTP/2、HTTP/3，真正收发字节
 │
 ▼
TCP / HTTP/2 / HTTP/3

这张图藏着三层关键设计：

HttpClient 是门面，不是实现。 你调用的 GetAsync 只是把请求顺着一条 handler 链往下传，最后由“主处理器”（primary handler）真正发到网络上。这解释了为什么“换一个 handler”就能换一套行为——比如测试时换成 mock handler，连线都不用发。
DelegatingHandler 就是出站中间件。 它和 ASP.NET Core 的入站中间件是同一个思想，只不过方向相反——请求在这里被一层层加工：加日志、加重试、加 Authorization 头。横向关注点（cross-cutting concerns）从业务代码里剥离，干净地组合进管线。
连接池不在 HttpClient 里，而在主处理器里。 HttpClient 本身相对轻量，但只有共享或由工厂池化底层 handler，创建多个 client 才不会同时创建多个独立连接池；不能脱离 handler 生命周期说“可随意创建”。

四、SocketsHttpHandler：现代连接池的真正主角

从 .NET Core 2.1 起，所有平台的默认主处理器都是 SocketsHttpHandler（在此之前是基于各平台原生栈的 HttpClientHandler）。它用纯托管代码重写了传输层，带来几个关键能力：

连接池化：通过 PooledConnectionLifetime、PooledConnectionIdleTimeout、MaxConnectionsPerServer 精细控制连接的生命周期与并发上限。
HTTP/2 多路复用：一个 TCP 连接上跑多条并发流，连接不再是“一个请求一个”的粗粒度资源，连接池的数学模型因此改变。
HTTP/3 (QUIC)：现代 .NET 可在受支持的操作系统和服务端上使用；它避免 TCP 层跨流队头阻塞，但应用仍需正确协商版本，不能理解为所有请求都会自动升级。
低分配：基于 Span<T> / Memory<T> 的实现，请求路径上的内存分配大幅下降。

PooledConnectionLifetime 限制池化连接的寿命。寿命到期且连接完成正在处理的请求后，它会被移出池；随后创建新连接时重新解析 DNS。默认值是 InfiniteTimeSpan，示例中的 15 分钟只是任意值，应按端点变化频率选择：

1
2
3
4
5
6


// 现代“静态单例”的正确写法：复用 client，但让连接定期轮换以刷新 DNS
private static readonly SocketsHttpHandler _handler = new()
{
 PooledConnectionLifetime = TimeSpan.FromMinutes(15)
};
private static readonly HttpClient _client = new(_handler, disposeHandler: false);

注意 disposeHandler: false——HttpClient 被 dispose 时不去动底层 handler，避免又把连接池掐死。这是 .NET 官方文档里和 IHttpClientFactory 并列推荐的两种方案之一，特别适合库代码、非 DI 场景或对性能极其敏感的路径。

五、IHttpClientFactory：DI 时代的解法

IHttpClientFactory（.NET Core 2.1，Microsoft.Extensions.Http）用另一套思路解决同一个问题。它的核心招式一句话能说清：

创建瞬态的 HttpClient，但让它共享一个按固定生命周期轮换的 handler 池。

工厂把“昂贵的 handler”和“廉价的 HttpClient”彻底解耦：

HttpClient 每次 CreateClient 都新建一个（瞬态），随便用、随便 dispose；
但这些 HttpClient 背后挂的是池化的 handler，handler 的 HandlerLifetime 默认 2 分钟，到期后旧 handler 退役、新 handler 上岗——退役与重建的时机正好让 DNS 自然刷新。

工厂创建的 HttpClient 被释放时不会销毁池化 handler，因此不会拆掉共享连接池。这纠正了“HttpClient 绝对不能 dispose”的误区；HttpRequestMessage 和 HttpResponseMessage 仍应由各自的所有者单独释放。

三种用法，复杂度递增：

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


// 1) 基础用法：从工厂拿一个默认 client
public class Foo(IHttpClientFactory factory)
{
 public async Task<string> Get() =>
 await factory.CreateClient().GetStringAsync("https://api.example.com");
}

// 2) 命名 client：预配置一组客户端
builder.Services.AddHttpClient("github", c =>
{
 c.BaseAddress = new("https://api.github.com");
 c.DefaultRequestHeaders.UserAgent.ParseAdd("my-blog");
});
// 取用：factory.CreateClient("github")

// 3) 类型化 client（最推荐）：把配置和调用封装进一个类型
builder.Services.AddHttpClient<GitHubApi>(c =>
 c.BaseAddress = new("https://api.github.com"));

public class GitHubApi(HttpClient client) // HttpClient 由工厂注入，已预配置
{
 public Task<Repo?> GetRepo(string owner, string name) =>
 client.GetFromJsonAsync<Repo>($"repos/{owner}/{name}");
}

类型化 client 把“基础地址、默认头、handler 管线”全部封装在 DI 里，业务代码只管调用——这是 ASP.NET Core 应用里最干净的写法，也是后续挂载韧性 handler 的入口。

一个要权衡的成本：HandlerLifetime 设得过短会让 handler 频繁轮换，设得过长又可能延迟端点变化。默认值是 2 分钟，但是否合适要结合 DNS/服务发现变化频率评估。需要 Cookie 时还要注意 handler 池会共享并在轮换时丢弃 CookieContainer，官方建议此类场景谨慎使用工厂。

六、DelegatingHandler：把横向关注点编进管线

回到第三节那张管线图。DelegatingHandler 让你能在请求“出门”前和响应“回来”后插入逻辑——加 traceId、统一鉴权、结构化日志。写一个自定义 handler 很直观：

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


public class CorrelationIdHandler : DelegatingHandler
{
 protected override async Task<HttpResponseMessage> SendAsync(
 HttpRequestMessage request, CancellationToken ct)
 {
 var id = Guid.NewGuid().ToString("N");
 request.Headers.TryAddWithoutValidation("X-Correlation-Id", id);

 var response = await base.SendAsync(request, ct); // 交给下一层
 response.Headers.TryAddWithoutValidation("X-Correlation-Id", id);
 return response;
 }
}

// 注册到某个命名 / 类型化 client 的管线
builder.Services.AddTransient<CorrelationIdHandler>();
builder.Services.AddHttpClient<GitHubApi>(...)
 .AddHttpMessageHandler<CorrelationIdHandler>();

注意 handler 的顺序即语义：先注册的在外层、先执行。把“日志”放在最外层，就能记录到含重试在内的完整耗时；把“鉴权”放在韧性层之内，就能让重试带上最新的 token。这种“顺序敏感的洋葱模型”和 ASP.NET Core 中间件如出一辙。

七、韧性：从手写重试到 .NET 8 标准管线

网络请求天生不可靠：会超时、会抖动、会对端短暂故障。所以一个生产级 HTTP 客户端必须自带韧性（resilience）：重试、熔断、超时、降级。这条线同样经历了一次范式升级。

早期：手写 try/catch + for 循环。 散落在各处、难以一致、几乎必然漏掉某种异常类型。

Polly 时代：策略即对象。 Policy.Handle<HttpRequestException>().OrResult(...).WaitAndRetryAsync(...) 把“什么算可重试、退避多久、最多几次”抽象成可组合的策略对象，挂到管线上。这是巨大进步，但策略组合的写法仍有学习成本。

.NET 8：标准韧性管线。 Microsoft.Extensions.Http.Resilience 在 Polly v8 的 ResiliencePipeline 之上，提供了一行就能挂载的“出厂合理”配置：

1
2


builder.Services.AddHttpClient<GitHubApi>(...)
 .AddStandardResilienceHandler(); // 限并发 + 总超时 + 重试 + 熔断 + 单次尝试超时

AddStandardResilienceHandler 默认从外到内组合五个策略：rate limiter → total timeout → retry → circuit breaker → attempt timeout。熔断依据采样窗口内的失败比例和最小吞吐量，而不是简单的“连续失败”。这些是通用起点；标准重试默认覆盖所有 HTTP 方法，非幂等请求应禁用重试或使用幂等键。

还有 AddStandardHedgingHandler()——对冲（hedging）：发出第一个请求后，若它在指定时间内没返回，就并行再发一个。这是一种针对尾延迟（tail latency） 的武器：在 p99 抖动严重的分布式系统里（想想 Jeff Dean 那张著名的“延迟尾部放大”图），对冲能把慢请求的尾部显著拉平，代价是多打了一些请求。

韧性的设计思想值得单独点出来：它是一组横向关注点，应当作为管线的一部分组合进去，而不是用 try/catch 在每个调用点重复实现。 这正是把“网络不可靠”从业务逻辑里剥离出来的关键一步。

八、设计思想：HttpClient 教会了我们什么

回头看，HttpClient 的演进浓缩了几个 .NET 生态里反复出现的设计哲学：

“门面 + 可组合管线”。 HttpClient 本身是薄门面，真正的架构是那条 handler 链。同样的哲学你能在 ASP.NET Core（入站中间件）、日志（ILoggerProvider 链）、依赖注入里反复看到——把核心逻辑做成管线，把变化点做成可插拔的 handler / provider。
“池化昂贵资源，按生命周期保鲜”。 连接池的核心张力是“复用 vs 新鲜”。解法不是二选一，而是给资源加生命周期——让池里的连接 / handler 定期轮换，既享受复用的性能，又定期接触真实世界（刷新 DNS）。这是一个可以推广到连接池、缓存、长连接的通用模式。
“让正确的事更容易”。 IHttpClientFactory + 类型化 client + AddStandardResilienceHandler 提供可靠起点，但仍需处理 Cookie、幂等性、超时预算、DNS 变化和业务错误分类。
“横向关注点即中间件”。 鉴权、日志、追踪、韧性，都不该污染业务代码。把它们做成 DelegatingHandler、按顺序组合进管线，业务方法里就只剩下纯粹的领域调用。

九、生产实践与排障清单

把上面的原理落到生产线，常用的判断与排查：

端口耗尽：netstat / ss 统计连接状态并结合进程、目的端和连接创建率定位；高频创建并释放独立 handler/client 是常见原因，但代理、NAT 和其他短连接客户端也可能造成同类症状。
连接复用率低：检查是否“每请求一个 client”；HTTP/2 场景下注意 MaxConnectionsPerServer 的语义变化（多路复用下不需要太多连接）。
超时分不清：HttpClient.Timeout 默认 100 秒，几乎一定要显式覆盖。注意超时抛的是 TaskCanceledException；.NET 5 起它会包一个 TimeoutException 作为 InnerException，借此区分“客户端超时”和“外部 CancellationToken 主动取消”。
DNS 故障转移失效：云上 / K8s 场景，确认 HandlerLifetime（工厂）或 PooledConnectionLifetime（长生命周期 client）符合端点变化频率；hedging 解决的是尾延迟，不能替代连接轮换。
gRPC：Grpc.Net.Client 使用 .NET HTTP 栈，可共享连接管理经验；但 gRPC 自带重试/对冲配置，流式调用和提交点也有特殊语义，不能把 HTTP 重试策略原样套用。

十、决策清单：我该用哪一种

场景	推荐
库代码 / 非 DI / 极致性能	静态 `HttpClient` + `SocketsHttpHandler{ PooledConnectionLifetime }`
ASP.NET Core 应用	`IHttpClientFactory` + 类型化 client + `AddStandardResilienceHandler()`
需要拉平尾延迟	评估后用 `AddStandardHedgingHandler()`；不要与标准 handler 直接叠加，并确保请求可安全重复
应避免	每请求创建并释放带独立 handler 的 `HttpClient`；测试替身或明确不发送网络请求等场景另当别论

结语

HttpClient 的“难”，不在 API，而在它把一个分布式系统的本质矛盾——网络不可靠、资源要复用、世界会变化——直接暴露给了每一个写业务代码的人。从 socket 耗尽到韧性管线，它的每一次演进都在把这个矛盾往框架深处藏一点，让业务代码更干净一点。

当你下一次写出 builder.Services.AddHttpClient<T>().AddStandardResilienceHandler() 时，你其实正站在一条十年的演进线上——背后是无数人踩过的 TIME_WAIT、调过的 DNS、修过的尾延迟。理解了这条脉络，HttpClient 就从一个“容易踩坑的类型”，变成一个“设计优雅的分布式客户端”。

参考资料

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

Fri, 07 Mar 2025 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.2 引入，专门为"文件→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)→ 网卡

 数据不进用户态！
 3 次拷贝（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 的输入必须是支持类似 mmap 读取的文件，输出在 Linux 2.6.33 前只能是 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 在合适的消息大小、批量、副本和硬件条件下获得较高吞吐

6.3 Java 的零拷贝 API

1
2
3
4
5


Java NIO：
 FileChannel.transferTo() → 可由平台实现映射到 sendfile 等高效传输路径
 MappedByteBuffer → 使用内存映射文件能力

 Kafka、Netty 等系统会利用这些 API 减少用户态复制；实际路径取决于平台和运行时

七、.NET 的零拷贝

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

ASP.NET Core 的静态文件中间件：
 主要把文件流复制到响应流，配合 Pipelines 减少分配
 Linux 下默认未走内核 sendfile 路径（社区长期有相关优化请求）

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 模式

Wed, 05 Mar 2025 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 等多 Reactor 框架。Nginx 的 master 主要负责配置与 Worker 生命周期，连接通常由 Worker 接受和处理

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

二、Nginx 的 Reactor 架构

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


Nginx = 多进程 Reactor 版（与 Netty 的主从 Reactor 不同）：

 Master 进程
 │ 读取配置、管理 Worker 生命周期（不处理连接）
 │
 Worker 进程 ×N（通常 = CPU 核数）
 各 Worker 从共享监听 socket 上 accept 新连接
 每个 Worker 自己的 epoll + Reactor
 独立处理连接的读写、业务

 特点：
 多进程 Worker → 较强的故障隔离；共享状态和连接接受协调仍可能使用原子操作或锁
 每个 Worker 一个 Reactor（单线程事件循环）
 共享统计、限流等状态可放在共享内存中，并按模块需要使用同步机制

三、Redis 的事件模型

1
2
3
4
5
6
7
8


Redis 6.0 之前：单 Reactor 单线程
 一个线程跑事件循环 + 命令执行
 为什么快：内存数据结构、事件循环和较少的线程间协调；仍会发生系统调用与调度

Redis 6.0+：单 Reactor + IO 多线程
 经典执行路径主要由主线程串行处理命令；Redis 新版本的部分 I/O、后台任务和模块可使用其他线程
 网络 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 接口适用范围有限
 io_uring（2019）才让 Linux 有了高性能异步 I/O
 epoll + Reactor 已足够高效，生态成熟
 Windows 用 Proactor（IOCP）

 io_uring 扩展了完成通知式设计的选择，但框架仍可能采用 Reactor、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 多线程（Netty）、多进程 Reactor（Nginx）—— 高性能标配
Proactor：异步 I/O，“我帮你读好了”
- Windows IOCP、Linux io_uring
主流是 Reactor，因为 Linux epoll 成熟；io_uring 普及后 Proactor 会更多
Kestrel = Reactor 底层 + async/await 上层

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

Network Programming on 纪伟的个人博客

epoll 的前世今生：从 select/poll 的性能困局到 io_uring 的挑战

一、故事的起点：一个线程伺候一个连接

二、第一代多路复用：select（1983，4.2BSD）

三、poll：去掉了 1024，但没去根

四、同时代的另一条路：kqueue 与 /dev/poll

五、epoll 登场（Linux 2.5.44，2002）

六、钻进内核：红黑树、就绪链表与回调链路

七、LT vs ET：两种触发模式，两种哲学

八、epoll 的演进史：API 与标志位

九、实战：一个 epoll echo server

十、epoll 的陷阱与坑

十一、谁在用 epoll（后端视角）

十二、终章：io_uring 的挑战（2019，Linux 5.1）

十三、小结

跟着一个 API 请求走完全程：后端全链路解剖

写在前面

场景

第 0 跳：DNS 解析

第 1 跳：TCP + TLS 握手

第 2 跳：入口（CDN / 四层负载均衡）

第 3 跳：Nginx 反向代理

第 4 跳：Kestrel 接收（I/O 模型 + Pipelines + 线程池）

第 5 跳：ASP.NET Core 中间件管线

第 6 跳：Redis 缓存层

第 7 跳：数据库（缓存未命中）

第 8 跳：下游服务调用（微服务场景）

第 9 跳：序列化 + 返回

把全程延迟叠起来

全链路可观测

小结

参考资料

HttpClient 的前世今生：从 Socket 耗尽到 .NET 8 韧性管线

写在前面

一、前世：using (var client = new HttpClient()) 为什么是反模式

二、第一次救赎：静态单例与 DNS 陈旧

三、原理：HttpClient 其实是个“门面”

四、SocketsHttpHandler：现代连接池的真正主角

五、IHttpClientFactory：DI 时代的解法

六、DelegatingHandler：把横向关注点编进管线

七、韧性：从手写重试到 .NET 8 标准管线

八、设计思想：HttpClient 教会了我们什么

九、生产实践与排障清单

十、决策清单：我该用哪一种

结语

参考资料

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

写在前面

一、传统读写的开销

1.1 传统方式

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

三、sendfile（真正的零拷贝）

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

四、splice（管道零拷贝）

五、对比总结

六、实际应用

6.1 Nginx

6.2 Kafka

6.3 Java 的零拷贝 API

七、.NET 的零拷贝

八、小结

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

写在前面

一、Reactor 模式

1.1 核心思想

1.2 三种 Reactor 实现

单 Reactor 单线程

单 Reactor 多线程

主从 Reactor 多线程（最常用）

二、Nginx 的 Reactor 架构

三、Redis 的事件模型

四、Proactor 模式

五、Reactor vs Proactor

六、实际框架对应

七、.NET 的 Kestrel 怎么对应

八、小结

一、前世：`using (var client = new HttpClient())` 为什么是反模式