Epoll on JasperSao的博客

io_uring（二）：QPS 实测，真的比 epoll 强吗？

Thu, 20 Aug 2026 00:00:00 +0800

一、学习目标

这部分学习主要围绕两个目标展开：

编写一个 TCP 客户端测试工具，对比 epoll 和 io_uring 服务端的性能。
整理网络相关面试题，重点理解 TCP、UDP、建链、断链、并发及分包粘包问题。

二、QPS 测试工具需求

客户端需要支持以下参数：

-n request_num 请求总数
-t thread_num 线程数量
-c connection_num 连接数量
-s server_ip 服务端 IP
-p server_port 服务端端口

使用示例：

./test_qps_tcpclient \
 -s 172.16.145.129 \
 -p 2048 \
 -t 50 \
 -c 100 \
 -n 10000

测试采用 Echo 模型：

客户端向服务端发送一段数据。
服务端将数据原样返回。
客户端比较发送和接收的数据。
数据一致则请求成功，否则失败。
最后统计总耗时和 QPS。

QPS 的计算方式为：

QPS = 完成的请求数 ÷ 耗时（秒）

代码中使用毫秒计时，因此写成：

qps = request_num * 1000 / time_used_ms;

三、测试数据的构造

测试字符串为：

#define TEST_MESSAGE \
"ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdefghijklmnopqrstuvwxyz\r\n"

这段字符串的长度正好是 64 字节：

26 个大写字母
+ 10 个数字
+ 26 个小写字母
+ \r\n 两个字符
= 64 字节

通过重复复制，可以构造不同大小的请求：

for (i = 0; i < 2; i++) {
 strcpy(
 wbuffer + i * strlen(TEST_MESSAGE),
 TEST_MESSAGE
 );
}

重复次数与数据长度的关系如下：

重复次数	数据长度
1	64 字节
2	128 字节
4	256 字节
8	512 字节
16	1024 字节

测试大包时，需要关闭服务端和客户端的数据打印，否则终端输出本身会严重影响测试结果。

四、64 bytes 测试

测试 100 万次、每次发送 64 bytes 时，结果如下：

数据长度	服务端模型	成功	失败	耗时	QPS
64 bytes	epoll	1000000	0	5132 ms	194855
64 bytes	io_uring	1000000	0	4400 ms	227272

在 64 bytes 测试中：

epoll QPS：194855
io_uring QPS：227272

io_uring 的 QPS 比 epoll 高约 16.6%。

五、不同数据长度下的测试

1. io_uring 服务端

数据长度	成功	耗时	QPS
128 bytes	1000000	4337 ms	230574
256 bytes	1000000	4268 ms	234301
512 bytes	1000000	4307 ms	232180
1024 bytes	1000000	4390 ms	227790

从结果来看，在 128～1024 bytes 范围内，io_uring 的 QPS 比较稳定，基本维持在 22 万～23 万。

1024 bytes 测试时，笔记中怀疑可能出现“粘包”。

更准确地说，TCP 本身是字节流，没有一条 send() 必须对应一条 recv() 的保证。一次发送的 1024 bytes，可能需要多次 recv() 才能完整读取，因此客户端必须实现循环接收。

2. epoll 服务端——阻塞 I/O

数据长度	成功	耗时	QPS
128 bytes	1000000	74935 ms	13344
256 bytes	1000000	147749 ms	6768
512 bytes	1000000	296207 ms	3376
1024 bytes	1000000	721163 ms	1386

这组结果明显异常：数据长度每增加一倍，耗时几乎也增加一倍，QPS 则接近减半。

问题在于 epoll 服务端使用了阻塞 socket。

epoll 的作用是通知程序某个 fd 当前可读或者可写。但即使 fd 已经可读，也不代表接下来所有的 recv() 都不会阻塞。

尤其是在循环读取时，如果已经把当前到达的数据读完，又调用了一次阻塞式 recv()，整个事件循环就可能停在某一个连接上，导致其他连接无法及时处理。

所以 epoll 一般需要与非阻塞 socket 配合：

epoll 通知 fd 可读
 ↓
循环调用 recv
 ↓
读取当前已经到达的数据
 ↓
recv 返回 EAGAIN
 ↓
处理下一个就绪事件

3. epoll 服务端——非阻塞 I/O

将 socket 设置成非阻塞后重新测试：

数据长度	成功	耗时	QPS
128 bytes	1000000	5198 ms	192381
256 bytes	1000000	5144 ms	194401
512 bytes	1000000	5141 ms	194514
1024 bytes	1000000	5216 ms	191717

修改后，epoll 的 QPS 恢复到约 19 万，并且不再随数据长度增加而大幅下降。

这说明前一组数据反映的主要不是 epoll 本身的性能，而是“epoll 配合阻塞 I/O”造成的异常。

六、epoll 与 io_uring 的完整对比

数据长度	io_uring QPS	epoll QPS
64 bytes	227272	194855
128 bytes	230574	192381
256 bytes	234301	194401
512 bytes	232180	194514
1024 bytes	227790	191717

从测试结果来看：

64 bytes 时，io_uring 比 epoll 高约 16.6%；
128～1024 bytes 时，io_uring 大约比 epoll 高 19%～21%；
所有测试包大小下，io_uring 的 QPS 都高于 epoll；
两种模型在改正 epoll 的阻塞 I/O 问题后，QPS 都没有随着数据大小增加而发生明显下降。

二者的处理思路不同。

epoll

epoll 是就绪通知模型：

先等待 fd 可读或可写
→ 得到就绪事件
→ 应用程序再调用 recv/send

也就是说，epoll 负责告诉应用程序“现在可以尝试进行 I/O”，真正的数据读写仍然由应用程序发起。

io_uring

io_uring 更接近完成通知模型：

应用程序先提交 recv/send 请求
→ 内核执行 I/O
→ I/O 完成后通知应用程序

应用程序可以提前向内核提交 I/O 请求，然后通过完成队列取得结果。

根据本次测试，可以得到以下结论：

在当前服务端实现、当前客户端模型和当前测试环境下，io_uring 的 QPS 全面高于非阻塞 epoll，整体高约 17%～21%。

这个结论应当限定在本次测试条件内，不能仅凭这一轮测试认为所有业务中 io_uring 都一定优于 epoll。

七、业务中的数据包大小

实际业务中可能同时存在小包和大包。

1. 心跳包

客户端和服务端之间通常会存在心跳包。

心跳包只用于检测连接是否仍然存活，因此数据量通常很小，可能只有几个字节。

这类场景更关注：

大量连接的管理能力；
小包的处理效率；
I/O 事件通知和调度开销；
服务端是否能够及时发现断开的连接。

2. 视频和图片传输

视频或者较大的图片需要被拆分成多个数据块。

应用层可以将每一个业务包组织成约 1 KB，再通过协议头标识数据长度、类型和序号。

这类场景除了 QPS，还需要关注：

吞吐量；
单次发送的数据大小；
分包和组包；
内存复制；
慢连接对事件循环的影响。

因此，也可以结合不同数据大小下的测试结果，理解 epoll 和 io_uring 的差别。

3. 百万并发测试

后续还可以使用 io_uring 和 epoll 测试百万并发，包括：

建立相同数量连接所需要的时间；
相同并发连接数下的 QPS；
百万连接下的内存占用；
建链事件的处理能力；
断链事件的处理能力。

断开连接涉及 TCP 协议栈中的状态转换，但应用层仍然需要正确执行 close()、移除连接状态，并释放自己管理的连接资源。

八、QPS 客户端代码详解

1. 测试上下文

struct test_context_s {
 char serverip[16];
 int port;
 int threadnum;
 int connection;
 int requestion;

#if 1
 int failed;
#endif
};

typedef struct test_context_s test_context_t;

这个结构保存测试参数：

serverip：服务端 IPv4 地址；
port：服务端端口；
threadnum：测试线程数；
connection：期望建立的连接数量；
requestion：请求总数；
failed：失败请求数。

requestion 想表达的应该是请求数量，也就是 request_count 或者 requests，只是命名不太准确，不影响程序运行。

serverip 的长度是 16，刚好可以保存最长的 IPv4 字符串和字符串结尾的 \0：

255.255.255.255\0

不过，代码使用的是：

strcpy(ctx.serverip, optarg);

如果传入的参数超过数组长度，就会发生越界写入。

2. 建立 TCP 连接

int connect_tcpserver(
 const char *ip,
 unsigned short port
)

函数首先创建 TCP socket：

int connfd = socket(AF_INET, SOCK_STREAM, 0);

其中：

AF_INET 表示使用 IPv4；
SOCK_STREAM 表示使用 TCP；
返回值 connfd 是连接对应的文件描述符。

然后构造服务端地址：

struct sockaddr_in tcpserver_addr;

memset(
 &tcpserver_addr,
 0,
 sizeof(struct sockaddr_in)
);

清零后设置地址类型：

tcpserver_addr.sin_family = AF_INET;

设置服务端 IP：

tcpserver_addr.sin_addr.s_addr = inet_addr(ip);

inet_addr() 将类似下面的 IPv4 字符串：

172.16.145.129

转换成网络地址。

设置端口：

tcpserver_addr.sin_port = htons(port);

htons() 将端口从主机字节序转换成网络字节序。

最后调用：

int ret = connect(
 connfd,
 (struct sockaddr *)&tcpserver_addr,
 sizeof(struct sockaddr_in)
);

如果连接成功，返回 connfd：

return connfd;

如果连接失败，返回 -1：

if (ret) {
 perror("connect\n");
 return -1;
}

当前代码没有检查 socket() 是否创建失败。

另外，如果 connect() 失败，已经创建的 connfd 没有关闭，会造成文件描述符泄漏。

3. 时间计算

#define TIME_SUB_MS(tv1, tv2) \
 ((tv1.tv_sec - tv2.tv_sec) * 1000 + \
 (tv1.tv_usec - tv2.tv_usec) / 1000)

这个宏用来计算两个 timeval 之间相差的毫秒数：

秒差 × 1000 + 微秒差 ÷ 1000

主函数在线程创建前记录开始时间：

struct timeval tv_begin;
gettimeofday(&tv_begin, NULL);

所有线程结束后记录结束时间：

struct timeval tv_end;
gettimeofday(&tv_end, NULL);

然后计算：

int time_used = TIME_SUB_MS(tv_end, tv_begin);

因此，当前统计结果包含：

创建线程的时间；
建立 TCP 连接的时间；
发送和接收请求的时间；
等待线程退出的时间。

所以当前 QPS 是一轮完整压测的整体 QPS，并不是纯粹的数据收发 QPS。

如果后续需要分别测试建链性能和请求处理性能，就需要把建立连接和发送请求分开计时。

4. 测试消息

#define TEST_MESSAGE \
"ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdefghijklmnopqrstuvwxyz\r\n"

#define RBUFFER_LENGTH 2048
#define WBUFFER_LENGTH 2048

TEST_MESSAGE 是 64 bytes。

读缓冲区和写缓冲区都设置为 2048 bytes。

在当前代码中，WBUFFER_LENGTH 宏并没有被使用，因为写缓冲区直接写成了：

char wbuffer[2048] = {0};

5. 单次请求过程

int send_recv_tcppkt(int fd)

这个函数完成一次请求和响应。

构造发送数据

char wbuffer[2048] = {0};
int i = 0;

for (i = 0; i < 2; i++) {
 strcpy(
 wbuffer + i * strlen(TEST_MESSAGE),
 TEST_MESSAGE
 );
}

由于 TEST_MESSAGE 为 64 bytes，循环两次后，wbuffer 中保存了 128 bytes 数据。

第一次复制的位置是：

wbuffer + 0

第二次复制的位置是：

wbuffer + 64

因此，两段 64 bytes 的数据首尾相连，组成 128 bytes 的请求。

发送数据

int res = send(
 fd,
 wbuffer,
 strlen(wbuffer),
 0
);

如果发送失败：

if (res < 0) {
 exit(1);
}

这里的主要问题是，一次 send() 不保证发送完全部数据。

例如：

send(fd, buffer, 1024, 0);

返回值可能是：

1024：全部发送完成
512：只发送了 512 bytes
-1：发送失败

所以不能只判断 res < 0，还需要判断返回值是否等于预期发送长度。

正确的逻辑应当是：

记录总共需要发送的长度
 ↓
循环调用 send
 ↓
每次根据返回值移动缓冲区指针
 ↓
直到所有字节发送完成

接收数据

char rbuffer[RBUFFER_LENGTH] = {0};

res = recv(
 fd,
 rbuffer,
 RBUFFER_LENGTH,
 0
);

如果返回值小于或者等于 0：

if (res <= 0) {
 exit(1);
}

recv() 的返回值含义是：

大于 0：本次实际读取的字节数
等于 0：对端正常关闭连接
小于 0：读取失败

和 send() 一样，一次 recv() 也不保证读取到完整的响应。

服务端即使完整返回了 1024 bytes，客户端也可能出现：

第一次 recv：读取 300 bytes
第二次 recv：读取 500 bytes
第三次 recv：读取 224 bytes

因此，需要循环接收，直到读取到预期长度。

这正是笔记中“很有必要重新封装一个 recv 和 send”的原因。

比较数据

if (strcmp(rbuffer, wbuffer) != 0) {
 printf(
 "failed: '%s'!='%s'\n",
 rbuffer,
 wbuffer
 );
 return -1;
}

这里通过 strcmp() 比较接收数据和发送数据。

但网络数据本质上是一段带长度的二进制数据，使用 strcmp() 的前提是两个缓冲区都以 \0 结尾。

更稳定的比较方式是根据实际数据长度使用：

memcmp(rbuffer, wbuffer, expected_length);

如果一次 recv() 只读到部分数据，那么当前 strcmp() 会直接认为请求失败，即使剩余数据稍后还能继续收到。

6. 工作线程

static void *test_qps_entry(void *arg)

线程首先取得测试上下文：

test_context_t *pctx =
 (test_context_t *)arg;

原始笔记中出现了：

(test\_context\_t *)arg

如果实际代码中确实包含反斜杠，需要将反斜杠删除。它也可能只是复制代码时产生的 Markdown 转义。

计算每个线程的连接数

int conn_num =
 pctx->connection / pctx->threadnum;

这里理论上表示每个线程需要管理多少个连接。

例如：

连接数：100
线程数：50
每个线程应当管理：2 个连接

但是，conn_num 后面没有被使用。

实际代码只建立了一次连接：

int connfd = connect_tcpserver(
 pctx->serverip,
 pctx->port
);

因此，每个线程只建立一个连接。

这意味着：

-t 50 -c 100

实际建立的不是 100 个连接，而是 50 个连接。

当前代码中的 -c 参数实际上没有生效。

计算每个线程的请求数

int count =
 pctx->requestion / pctx->threadnum;

例如：

请求总数：10000
线程数：50
每个线程：200 次请求

每个线程执行：

while (i++ < count) {
 res = send_recv_tcppkt(connfd);

 if (res != 0) {
 printf("send_recv_tcppkt failed\n");
 pctx->failed++;
 continue;
 }
}

线程中的请求模型为：

发送一次请求
 ↓
阻塞等待响应
 ↓
收到完整响应
 ↓
再发送下一次请求

所以每个连接同一时间最多只有一个未完成请求。

整个客户端能够同时处理的请求数量，实际上接近线程数量，而不是 -c 指定的连接数量。

请求数量不能整除线程数

如果：

-n 10003
-t 50

则：

count = 10003 / 50;

整数除法结果为：

实际发送请求数为：

200 × 50 = 10000

剩余 3 次请求不会发送。

但是，程序最后仍然按照 10003 计算成功数量和 QPS，所以统计结果会不准确。

7. 失败请求统计

失败时执行：

pctx->failed++;

所有线程共享同一个 failed，但这里没有加锁，也没有使用原子变量。

多个线程可能同时执行：

pctx->failed++;

例如，两个线程同时读到：

failed = 10

两个线程都计算得到 11，再分别写回，最终结果可能仍然是 11，而不是正确的 12。

因此，当前失败数具有以下特点：

可以粗略判断是否出现了失败；
不能保证失败数量准确；
多线程同时修改时存在数据竞争。

笔记中提到“数据没有那么重要，只需要知道有失败的可能性”，这种处理可以用于临时测试，但最终版本如果需要准确统计失败数，仍然需要使用锁或者原子操作。

8. 命令行参数解析

主函数通过 getopt() 解析参数：

while (
 (opt = getopt(
 argc,
 argv,
 "s:p:t:c:n:?"
 )) != -1
)

参数含义如下：

-s：服务端 IP
-p：服务端端口
-t：线程数量
-c：连接数量
-n：请求数量

例如：

case 's':
 strcpy(ctx.serverip, optarg);
 break;

读取 IP。

case 'p':
 ctx.port = atoi(optarg);
 break;

读取端口。

case 't':
 ctx.threadnum = atoi(optarg);
 break;

读取线程数量。

case 'c':
 ctx.connection = atoi(optarg);
 break;

读取连接数量。

case 'n':
 ctx.requestion = atoi(optarg);
 break;

读取请求总数。

getopt() 使用了一些全局状态，因此笔记中记录它不是线程安全函数。不过当前代码只在主线程、创建工作线程之前调用，所以不会产生并发调用问题。

9. 创建工作线程

程序首先根据线程数量申请线程 ID 数组：

pthread_t *ptid =
 malloc(
 ctx.threadnum * sizeof(pthread_t)
 );

然后记录开始时间：

struct timeval tv_begin;
gettimeofday(&tv_begin, NULL);

创建工作线程：

for (i = 0; i < ctx.threadnum; i++) {
 pthread_create(
 &ptid[i],
 NULL,
 test_qps_entry,
 &ctx
 );
}

所有线程都接收同一个 ctx 地址：

&ctx

其中：

IP、端口、线程数、连接数和请求数只读；
failed 会被所有线程共同修改。

创建完成后，主线程等待所有工作线程退出：

for (i = 0; i < ctx.threadnum; i++) {
 pthread_join(ptid[i], NULL);
}

只有全部线程执行完毕，主线程才会继续计算总耗时。

10. 统计 QPS

所有线程结束后，记录结束时间：

struct timeval tv_end;
gettimeofday(&tv_end, NULL);

计算总耗时：

int time_used =
 TIME_SUB_MS(tv_end, tv_begin);

最后输出：

printf(
 "success: %d,failed:%d,"
 "time_used:%d,qps:%d\n",
 ctx.requestion - ctx.failed,
 ctx.failed,
 time_used,
 ctx.requestion * 1000 / time_used
);

输出内容包括：

成功请求数；
失败请求数；
总耗时；
QPS。

当前 QPS 使用的是：

ctx.requestion * 1000 / time_used

这里使用了配置的请求数，而不是实际完成的请求数。

如果请求数不能整除线程数，或者中间出现失败，QPS 就不能准确表示真正成功完成的请求数量。

11. 资源释放

主函数结束前释放线程数组：

free(ptid);

但工作线程建立的 TCP 连接没有关闭：

close(connfd);

在线程退出前，应当关闭自己创建的连接。

虽然进程退出时，操作系统最终会回收文件描述符，但如果后续让一个进程连续执行多轮测试，不关闭连接就会逐渐产生资源泄漏。

九、当前客户端的实际测试模型

虽然命令行参数中包含 -c，但当前代码的实际模型是：

主线程
 ├─ 工作线程 1
 │ └─ 一个 TCP 连接
 │ └─ 串行发送请求
 │
 ├─ 工作线程 2
 │ └─ 一个 TCP 连接
 │ └─ 串行发送请求
 │
 ├─ 工作线程 3
 │ └─ 一个 TCP 连接
 │ └─ 串行发送请求
 │
 └─ 其他工作线程
 └─ 每个线程一个 TCP 连接

因此：

实际连接数 = 线程数
每个连接同时只有一个请求
-c 参数没有生效

当前工具比较的是：

多线程、每个线程使用一个阻塞 TCP 连接、请求与响应严格交替时，epoll 和 io_uring 服务端的处理能力。

它还不能测试固定线程数管理大量连接的能力，也不能直接用于百万并发测试。

如果需要让 -c 生效，每个线程就要创建：

connection / threadnum

个连接，并在这些连接之间分配请求。

十、当前代码需要优先处理的问题

按照对测试准确性的影响排序：

-c 参数没有生效，每个线程实际上只建立一个连接。
send() 没有循环处理短写。
recv() 没有循环处理短读。
请求数不能整除线程数时，实际请求数量少于 -n。
failed++ 存在多线程数据竞争。
工作线程结束后没有执行 close(connfd)。
QPS 使用配置的请求数计算，而不是实际完成数。
没有检查 socket()、malloc() 和 pthread_create() 的返回值。
connect() 失败后没有关闭已经创建的 socket。
工作线程中的 exit(1) 会让一个线程的网络错误终止整个压测进程。
如果源代码确实包含 test\_context\_t，需要删除反斜杠。
如果源代码第一行确实是 include<stdio.h>，需要补上 #。

十一、网络面试问题整理

原始笔记目前记录了四个核心问题，没有足够内容整理成十个，因此这里只整理已有内容，不额外补题。

1. TCP 三次握手与四次挥手

三次握手

客户端 服务端

SYN
 ------------------------>

 SYN + ACK
 <------------------------

ACK
 ------------------------>

三次握手需要确认：

客户端能够发送；
服务端能够接收；
服务端能够发送；
客户端能够接收；
双方同步初始序列号。

之所以不能只使用两次握手，是因为服务端发送 SYN + ACK 后，还需要知道客户端是否真正收到了自己的响应。

第三次 ACK 让服务端确认：

客户端已经收到服务端的 SYN
客户端也能够正常接收数据

2. 为什么建链是三次，断链通常是四次

建立连接时，服务端可以把两个操作合并：

确认客户端的 SYN
+
发送自己的 SYN

因此，服务端可以通过一个 SYN + ACK 同时完成这两个操作，最终形成三次握手。

断开连接时：

收到 FIN 后必须先回复 ACK；
但是本端可能还有数据没有发送完；
等剩余数据发送完成后，才能发送自己的 FIN。

因此，ACK 和 FIN 通常不能立即合并，形成四次挥手。

四次挥手

主动关闭方 被动关闭方

FIN
 ------------------------>

 ACK
 <------------------------

 FIN
 <------------------------

ACK
 ------------------------>

TCP 是全双工连接，两个方向需要分别关闭。

一方发送 FIN，只表示自己不再发送数据，并不表示对方也已经没有数据可发。

如果对方收到 FIN 时，刚好也没有剩余数据需要发送，那么 ACK 和 FIN 也可能合并。

3. UDP 的并发如何实现

UDP 没有 TCP 中的：

listen
accept
connection fd

客户端通过：

sendto()

向服务端指定的 IP 和端口发送数据。

服务端通过：

recvfrom()

接收数据，同时得到客户端的 IP 和端口。

假设有 100 万个客户端同时向同一个 UDP 端口发送数据，内核会按照数据报把数据放入 socket 的接收队列。

服务端每次调用 recvfrom() 时，可以获得：

一条 UDP 数据报；
发送方的 IP；
发送方的端口。

因此，不会因为多个客户端共用一个服务端端口，就直接把不同客户端的数据拼接成一条“脏数据”。

应用层可以使用：

客户端 IP + 客户端端口

标识一个逻辑会话。

笔记中提出了一种模拟 TCP 的管理方式：

客户端第一次向服务端发送握手包；
服务端得到客户端的 IP 和端口；
服务端为这个客户端建立逻辑会话；
后续通过会话信息管理双方的数据；
如果需要分散压力，可以使用多个服务端端口或者多个 UDP socket。

例如：

2000 个端口
每个端口管理约 1000 个逻辑连接
总计约 200 万个逻辑连接

但是，不一定需要为每个 UDP 客户端单独分配一个端口。

UDP 的并发数量也不是直接受 65535 个端口限制。多个客户端可以通过不同的来源 IP 和来源端口访问同一个服务端端口。

这一部分需要继续整理成一篇独立的技术笔记：

UDP 的并发实现与应用层会话管理。

4. TCP 和 UDP 有哪些区别

连接方式

TCP 是面向连接的协议。

通信前需要建立连接：

客户端连接 fd ←→ 服务端连接 fd

服务端通过 accept() 为每个客户端创建连接 fd，因此每条 TCP 连接都有独立的连接状态。

UDP 是无连接协议。

客户端不需要先建立 TCP 意义上的连接，可以直接通过 sendto() 发包，服务端通过 recvfrom() 接收。

数据形式

TCP 是字节流协议。

它传输的是连续字节流，本身不保留应用层的消息边界。

UDP 是数据报协议。

每次 sendto() 发送一条 UDP 数据报，接收端通过 recvfrom() 接收一条数据报。UDP 会保留数据报边界，但如果接收缓冲区太小，超出的部分可能被截断。

可靠性和顺序

TCP 提供：

有序传输；
丢包重传；
流量控制；
拥塞控制。

先发送的数据，在连接正常的情况下，会先交付给接收方应用程序。

UDP 本身不保证：

数据一定到达；
数据按照发送顺序到达；
数据不会重复；
丢失的数据会自动重传。

如果业务需要这些能力，就需要在 UDP 的应用层加入：

包 ID；
数据序号；
ACK 确认；
超时重传；
去重；
乱序重排。

例如，把一份大数据拆成多个 UDP 包时，可以在用户空间定义：

消息 ID
分片序号
总分片数量

接收端根据 ID 和序号判断当前收到的是第几个包，并将多个数据包重新组装。

5. TCP 的分包与粘包

TCP 是字节流。

应用层调用一次：

send(fd, buffer, 1024, 0);

并不代表接收端一定通过一次：

recv(fd, buffer, 1024, 0);

得到完整数据。

可能出现：

一次 send → 多次 recv
多次 send → 一次 recv

所以所谓的 TCP 分包和粘包，本质上是应用层没有明确消息边界。

常见解决方法有两种。

方法一：长度字段

在应用数据的头部记录消息体长度：

| 固定长度的消息头 | 消息体 |

例如使用前两个或者前四个字节表示长度：

| 2 bytes 长度 | 实际数据 |

接收端先读取固定长度的消息头：

先循环读取 2 bytes
 ↓
解析出消息体长度
 ↓
再循环 recv
 ↓
读取完整消息体

由于 TCP 保证字节流有序，因此接收端可以按照这个顺序解析数据。

方法二：分隔符

每条消息后面增加一个特殊分隔符，例如：

\r\n\r\n

接收端不断读取数据并放入缓冲区，然后查找分隔符：

收到数据
 ↓
加入接收缓冲区
 ↓
查找 \r\n\r\n
 ↓
找到后切出一条完整消息

如果消息正文中也可能出现相同分隔符，就需要进行转义，或者使用长度字段。

6. TCP 和 UDP 的并发区别

TCP 服务端通常采用：

listen socket
 ↓
accept
 ↓
每个客户端对应一个连接 fd
 ↓
使用 epoll 管理大量连接 fd

TCP 协议栈已经维护了每条连接的状态，因此应用层可以通过不同 fd 区分客户端。

UDP 没有为每个客户端创建独立的连接 fd。

服务端一般根据：

来源 IP
来源端口
应用层会话 ID

管理客户端状态。

因此，不是说 UDP 不能做高并发，而是 UDP 需要在应用层建立自己的会话管理方式。

7. UDP 的使用场景

UDP 更适合以下场景：

实时音视频；
对实时性要求较高的游戏数据；
DNS 等一次请求、一次响应的场景；
能够容忍少量丢包的场景；
由应用层自己控制可靠性的场景。

例如在游戏团战中，玩家位置、技能释放和实时状态对延迟比较敏感。

如果一个旧的位置数据由于重传很晚才到达，这个数据可能已经失去意义。因此，这类实时状态通常更偏向使用 UDP。

但是，“对战游戏没有使用 TCP”这个说法过于绝对。

更合适的理解是：

游戏中强调实时性的位置、动作等消息更倾向使用 UDP；登录、充值、聊天等要求可靠的数据仍然可能使用 TCP。

8. TCP 的使用场景

TCP 更适合：

文件传输；
需要完整交付的数据；
需要严格有序的数据；
HTTP/1.1、HTTP/2 等基于 TCP 的协议；
长连接通信。

文件下载需要保证最终文件完整，因此通常需要可靠传输。

UDP 本身没有拥塞控制和可靠重传。如果使用 UDP 传输文件，应用层就需要自己实现：

丢包检测；
重传；
顺序恢复；
流量控制；
拥塞控制。

TCP 已经提供了这些能力，因此使用 TCP 开发更加直接。

9. 短通信与长连接

DNS 是典型的短请求、短响应场景：

发送一次查询
 ↓
服务端返回查询结果
 ↓
本次通信结束

UDP 不需要建立连接，适合这种简单的请求响应。

“UDP 做短连接”更准确的说法是：

UDP 没有 TCP 意义上的连接，适合短暂的一次性请求响应。

有些业务也会选择 TCP 完成短请求，因为：

TCP 相关框架成熟；
开发更加方便；
不需要自己实现可靠性；
业务本身更重视开发成本和正确性。

TCP 则天然适合需要长期保持通信状态的长连接，但 TCP 并不是只能做长连接。

十二、阶段总结

从传统阻塞 I/O、epoll 再到 io_uring，容易产生一种混沌感。

当前最需要捋清的是三个层次之间的关系：

TCP
提供字节流、连接、可靠传输等协议能力
 ↓
epoll / io_uring
解决应用程序如何高效处理 I/O
 ↓
业务协议
解决消息边界、心跳、会话和错误处理

本轮实验可以得到三个明确认识：

epoll 应当与非阻塞 I/O 配合，否则单个连接可能阻塞整个事件循环。
当前测试中，io_uring 的 QPS 全面高于非阻塞 epoll，整体优势约为 17%～21%。
客户端的连接模型、收发方式和计数准确性，会直接影响测试结果。当前 -c 参数没有生效，循环收发也尚未实现。

十三、面试复盘

面试需要不断复盘。

简历中能够被问到的内容是有限的，每次面试后都应该记录问题，并重新整理问题背后的知识。

原笔记中的经验数据为：

面试时间	个人估计的通过概率
30 分钟	5%
45 分钟	30%
60 分钟	80%

求职过程可以通过两个比例进行观察：

邀面数量 / 投递数量
→ 反映简历的匹配度和成功度

Offer 数量 / 邀面数量
→ 反映技术能力和面试表现

io_uring（一）：与 epoll 一较高下

Wed, 19 Aug 2026 00:00:00 +0800

核心目标：能从代码上说清楚 epoll 和 io_uring 的区别，而不是只记 API。

1. 今天最重要的结论

一句话区分：

Reactor / epoll：内核通知“现在可以做 I/O 了”，真正的 accept/recv/send 由应用执行。
Proactor / io_uring：应用先提交 I/O 操作，内核完成后通知“这个操作已经做完了”。

最值得记住的一组对照：

epoll 的 EPOLLIN = 可以读了，但数据还没被应用读出
io_uring 的 READ CQE = 读操作已结束，结果在 cqe->res，数据已进入指定 buffer

epoll 的 EPOLLOUT = 现在可以写，但应用还要调用 send/write
io_uring 的 WRITE CQE = 写操作已结束，cqe->res 表示实际写出的字节数

因此，二者虽然都有“注册/提交 → 等待 → 处理事件”的循环，但事件的含义完全不同：

epoll 返回的是就绪事件。
io_uring 返回的是完成事件。

2. “异步”与“异步 I/O”不是一回事

2.1 一般意义上的异步

发起任务后，不原地等待它结束，当前执行流可以继续做别的事；任务完成后再通过回调、消息、事件或协程恢复等方式取得结果。

例如：把日志写盘任务放入线程池。业务线程只投递任务，工作线程实际调用同步 write()。从业务流程看它是异步的，但底层 write() 本身仍可能是同步 I/O。

2.2 同步 I/O

普通的：

read(fd, buffer, length);
write(fd, buffer, length);
recv(fd, buffer, length, 0);
send(fd, buffer, length, 0);

一次函数调用既发起操作，也返回该次操作的结果。即使 fd 被设为非阻塞，调用者仍然要亲自执行 recv/send；“非阻塞”不自动等于“异步 I/O”。

2.3 epoll 做到的是什么

epoll_wait() 可以高效等待大量 fd 的就绪状态，避免逐个 fd 轮询。它通常与非阻塞 socket 配合，构成 Reactor。

但 epoll 不替应用搬运数据：收到 EPOLLIN 后，代码仍要调用 recv()；收到 EPOLLOUT 后，仍要调用 send()。

2.4 io_uring 做到的是什么

应用把“请替我执行 accept/read/write……”描述成 SQE，提交给内核；操作完成后，内核写入 CQE。应用处理 CQE 时，看到的是操作结果，而不只是“可以开始操作”。

3. io_uring 的两个环

应用准备 SQE → SQ（Submission Queue）→ 内核执行 I/O
 ↓
应用处理结果 ← CQ（Completion Queue）← 内核生成 CQE

SQ / SQE

SQ：提交队列。
SQE：一次待执行 I/O 的描述，例如操作类型、fd、buffer、长度和用户数据。
io_uring_get_sqe()：取得一个可填写的 SQE。
io_uring_prep_accept/read/write(...)：只是在填写 SQE，不会立刻执行 I/O。
io_uring_submit()：把准备好的请求提交给内核。

CQ / CQE

CQ：完成队列。
CQE：一个已经完成的 I/O 结果。
cqe->res：操作结果。成功时通常是新 fd 或字节数；失败时是负的 errno 值。
cqe->user_data：应用提交时附带的标识，用来判断这是哪个连接、哪类操作。
io_uring_cq_advance()：告诉 ring，这批 CQE 已处理，可以回收。

为什么使用环形队列和 mmap

环形队列可以复用固定槽位，减少频繁分配；SQ/CQ 通过 mmap 在用户态和内核态之间共享队列元数据，减少提交、取结果时的额外系统调用和元数据复制。

但要注意：这不代表所有 I/O 数据都天然“零拷贝”。例如普通 socket 接收的数据通常仍需进入应用提供的 buffer。

4. io_uring 三个底层系统调用

io_uring_setup：创建并配置 ring，建立 SQ/CQ 所需资源。
io_uring_enter：提交请求和/或等待完成事件。
io_uring_register：预注册文件、buffer、事件等资源，减少热路径开销；它不是每个普通请求都必须调用。

课堂代码使用的是 liburing 封装：

io_uring_queue_init_params(ENTRIES_LENGTH, &ring, &params);
io_uring_get_sqe(&ring);
io_uring_prep_accept(...);
io_uring_submit(&ring);
io_uring_wait_cqe(&ring, &cqe);

可近似理解为：初始化 ring → 取得请求槽位 → 描述操作 → 提交 → 等结果。

5. 你的 io_uring Echo Server 怎么走

关键入口：

set_event_accept(&ring,sockfd,(struct sockaddr*)&clientaddr,&len,0);

set_event_accept() 做两件事：

用 io_uring_get_sqe() 取得 SQE。
用 io_uring_prep_accept() 填写 accept 请求，并在 user_data 中记录 fd + EVENT_ACCEPT。

此时只是准备请求，并没有等待客户端。

主循环：

io_uring_submit
 ↓ 提交当前准备好的 accept/recv/send 请求
io_uring_wait_cqe
 ↓ 没有完成结果时在这里等待
io_uring_peek_batch_cqe
 ↓ 批量取得已完成操作
根据 user_data 判断 EVENT_ACCEPT
 ↓
再次 set_event_accept，同时为新 clientfd 提交 recv
 ↓
io_uring_cq_advance

你测试时发现程序阻塞在 io_uring_wait_cqe()，这是合理的：

io_uring_prep_accept() 只准备请求，很快返回。
io_uring_submit() 提交请求。
在客户端真正连接前，accept 尚未完成，CQ 中没有结果，所以 wait_cqe() 等待。
客户端连接后，CQE 到达，cqe->res 应是新连接的 client fd（失败则为负数）。

5.1 三种事件不是“就绪事件”，而是操作身份

#define EVENT_ACCEPT 0
#define EVENT_READ 1
#define EVENT_WRITE 2

这里的 EVENT_* 是应用自己定义的标签。准备 SQE 时，代码把 fd + event 写入 sqe->user_data；操作完成后，再从 CQE 的 user_data 还原标签，据此判断完成的是 accept、recv 还是 send。

三种 SQE 的含义：

函数	提交给内核的操作	CQE 到达时 `entries->res` 的含义
`set_event_accept`	接收一个新连接	新连接 fd；负数表示失败
`set_event_recv`	把数据读进指定 buffer	实际读取字节数；0 表示对端关闭；负数表示失败
`set_event_send`	发送指定 buffer 中的数据	实际发送字节数；负数表示失败

5.2 完整状态循环

启动：准备 ACCEPT SQE
 ↓ submit
 ACCEPT 完成
 ├─ entries->res 得到 connfd
 ├─ 再准备一个 ACCEPT，继续接收其他客户端
 └─ 为 connfd 准备 RECV
 ↓ submit
 READ 完成
 ├─ res == 0：对端断开，close(fd)
 └─ res > 0：buffer 中已有数据，准备 SEND
 ↓ submit
 WRITE 完成
 ↓
 再为该 fd 准备 RECV

对单个连接而言，核心循环就是：

RECV 完成 → SEND 完成 → 再次 RECV

这份代码没有额外解析数据，而是把收到的 buffer 原样发送回去，因此它是一个 io_uring Echo Server。

5.3 为什么循环开头的 submit 能提交刚刚准备的操作

在处理 CQE 时调用的 set_event_accept/recv/send() 都只是取得并填写新的 SQE。它们不会立刻执行；本轮处理结束并 cq_advance 后，程序回到 while 开头，由下一次 io_uring_submit() 统一提交。

因此时间顺序是：

本轮处理 CQE → 准备下一批 SQE → advance → 下一轮 submit

这种批量准备、批量提交正是 io_uring 的重要思路。

为什么处理后要再次设置 accept

普通的 io_uring_prep_accept() 描述的是一次 accept 操作。完成一次就消费掉一次请求；若想继续接收连接，需要再准备并提交新的 accept。

这与 epoll 的常规 LT 模式不同：监听 fd 注册 EPOLLIN 后，只要仍处于可读状态，epoll 可以继续报告就绪，无需每完成一次 accept 就重新 EPOLL_CTL_ADD。

为什么必须 advance

CQE 被读取不等于被消费：

io_uring_cq_advance(&ring,nready);

这一步更新 CQ 的消费位置。漏掉它，旧 CQE 会一直被当成尚未处理，表现为循环反复看到同一结果。

6. 你的 Reactor 代码怎么走

6.1 初始化

epoll_create
 ↓
创建 20 个监听 socket（端口 2000～2019）
 ↓
把监听 fd 以 EPOLLIN 加入 epoll
 ↓
进入 epoll_wait 主循环

监听 fd 的回调被设置为 accept_cb：

conn_list[sockfd].r_action.recv_callback = accept_cb;

6.2 建立连接

监听 fd 出现 EPOLLIN
 ↓
主循环调用 accept_cb
 ↓
accept_cb 主动执行 accept()
 ↓
event_register(clientfd, EPOLLIN)

关键点：EPOLLIN 只表示监听 socket 可以执行 accept；真正建立并取出 client fd 的动作仍由 accept() 完成。

6.3 接收数据

clientfd 出现 EPOLLIN
 ↓
调用 recv_cb
 ↓
recv() 把数据读进 rbuffer
 ↓
ws_request() 处理请求
 ↓
把关注事件修改为 EPOLLOUT

如果 recv() 返回 0，说明对端正常断开；返回负数则表示错误。当前代码随后关闭 fd 并从 epoll 删除。

6.4 发送数据

clientfd 出现 EPOLLOUT
 ↓
调用 send_cb
 ↓
ws_response() 生成响应
 ↓
send() 主动发送 wbuffer
 ↓
把关注事件改回 EPOLLIN

整个连接状态近似为：

等待读 EPOLLIN → recv + 处理请求 → 等待写 EPOLLOUT
 ↑ ↓
 └──────── send + 改回读 ──────────┘

7. 逐段对照：Reactor 与 io_uring

阶段	epoll / Reactor	io_uring / Proactor 思路
接收连接	注册监听 fd 的 `EPOLLIN`	提交一个 accept SQE
通知到达	“监听 fd 可以 accept”	“accept 已完成”
新连接 fd	应用调用 `accept()` 得到	从 accept CQE 的 `res` 得到
接收数据	`EPOLLIN` 后应用调用 `recv()`	预先提交 recv/read SQE，完成后 buffer 已有数据
发送数据	`EPOLLOUT` 后应用调用 `send()`	预先提交 send/write SQE，完成后得到实际写入量
事件身份	`events[i].data.fd` + 回调表	`cqe->user_data` 标识 fd/事件/上下文
一次操作结束	修改下一次关注的就绪事件	消费 CQE，再准备下一次 I/O SQE
批量处理	`epoll_wait(..., events, 1024, ...)`	`io_uring_peek_batch_cqe(..., cqes, 128)`

代码上的一一对应：

epoll_ctl ADD/MOD ↔ io_uring_get_sqe + prep_xxx
epoll_wait ↔ io_uring_wait_cqe / peek_batch_cqe
events[i].data.fd ↔ cqe->user_data
EPOLLIN 后 recv ↔ READ CQE 到达时数据已读完
EPOLLOUT 后 send ↔ WRITE CQE 到达时写操作已完成
下一轮 set_event ↔ 下一轮重新准备 SQE
 ↔ io_uring_cq_advance 消费完成项

8. 对学习笔记中三个说法的校正

① “SQE 与 CQE 是同一个节点，共用一块内存”——不准确

SQE 和 CQE 是不同队列中的不同结构：SQE 描述请求，CQE 描述结果。它们通过 user_data 关联。共享内存指的是这些 ring 能被用户态与内核态共同访问，不是 SQE 原地变成 CQE。

② “io_uring_prep_accept 底层调用 register”——不准确

io_uring_prep_accept() 主要是填写 SQE。io_uring_register 是独立的资源注册系统调用，普通 accept 请求不要求每次 register。

③ “mmap 后就没有 copy”——范围过大

mmap 主要减少 SQ/CQ 控制信息在用户态和内核态之间的复制及系统调用开销；普通网络 I/O 的 payload 是否复制，是另一层问题。

9. 最小记忆框架

只背下面四句话：

epoll 给我的是就绪，我还要自己 accept/recv/send。
io_uring 给我的是完成，结果看 cqe->res，身份看 cqe->user_data。
io_uring 的路径是：取 SQE → prep → submit → 等 CQE → 处理 → advance。
普通 io_uring 请求通常是一次性的：完成一次，消费一次，再提交下一次。

DPDK 用户态 TCP 协议栈（四）：并发与自实现 epoll

Tue, 18 Aug 2026 00:00:00 +0800

本篇只围绕一个问题展开：用户态 TCP 协议栈怎样让一个应用线程并发管理多条 TCP 连接？

前三篇已经反复讲过 DPDK 收发、mbuf、Ethernet/IPv4/TCP 解析、三次握手、SEQ/ACK、TCP 状态机和 POSIX Socket。本篇只在它们影响 epoll 逻辑时简要回顾，不再重新逐层讲包头和握手细节。

一、先给出整篇的核心答案

TCP 并发 epoll 的实现可以浓缩成一个闭环：

1. 每条 TCP 连接拥有独立的 stream/TCB 和用户态 fd
2. 应用通过 epoll_ctl 注册“我关心哪些 fd 的哪些事件”
3. 协议栈处理报文时发现某个 fd 已经可读或可写
4. 协议栈调用 epoll 回调，把该 fd 放入就绪队列
5. 回调唤醒阻塞在 epoll_wait 的应用线程
6. epoll_wait 返回就绪 fd，应用执行 accept/recv/send/close
7. 应用重新进入 epoll_wait，继续管理所有连接

epoll 没有让 TCP 报文并行到达，也没有替协议栈处理握手。它解决的是：

当许多连接都可能产生数据时，应用怎样只处理当前已经就绪的连接，而不是为每条连接创建一个长期阻塞的线程。

理解本篇时始终抓住三种对象：

对象	解决的问题
`ng_tcp_stream`	这是谁的连接，当前 TCP 状态和数据是什么
`epitem`	应用是否关注这个 fd，它现在是否就绪
`eventpoll`	一个 epoll 实例管理的整集、就绪集和等待线程

二、只保留必要的旧知识：数据最终从哪里来到哪里去

完整程序有三个长期运行的执行流：

main/lcore：网卡 RX/TX
 ↕ 全局 in/out ring
pkt_process/lcore：Ethernet/IP/TCP 解析、TCP 输出封包
 ↕ 每连接 rcvbuf/sndbuf
tcp_server_entry/lcore：accept、recv、send、epoll_wait

两层 ring 不要混淆：

全局 ring->in/out 传递 rte_mbuf *，用于网卡线程与协议处理线程之间传包。
每个 ng_tcp_stream 的 rcvbuf/sndbuf 传递 TCP fragment，用于协议栈与应用之间传数据。

一段客户端数据的最短路径是：

网卡 RX
→ 全局 in ring
→ ng_tcp_process()
→ 按四元组找到 stream
→ payload 放入 stream->rcvbuf
→ 触发 EPOLLIN
→ nepoll_wait() 返回 connfd
→ 应用 nrecv(connfd)

应用响应的路径相反：

nsend(connfd)
→ fragment 放入 stream->sndbuf
→ ng_tcp_out() 取出并封装 TCP 报文
→ 全局 out ring
→ 网卡 TX

这些收发与报文构造细节在前几篇已有完整说明。本篇真正关心的是中间这一步：

stream 的状态发生变化
→ 怎样让正在等待的应用知道？

三、支持并发的第一前提：连接必须彼此独立

1. 一条连接对应一个 `ng_tcp_stream`

struct ng_tcp_stream {
 int fd;

 uint32_t sip, dip;
 uint16_t sport, dport;
 uint8_t protocol;

 uint32_t snd_nxt;
 uint32_t rcv_nxt;
 NG_TCP_STATUS status;

 struct rte_ring *sndbuf;
 struct rte_ring *rcvbuf;

 pthread_cond_t cond;
 pthread_mutex_t mutex;
};

它是本代码中的简化 TCB。每个客户端都必须拥有独立的：

地址与端口；
TCP 状态；
SEQ/ACK；
接收和发送缓冲区；
用户态 fd；
阻塞与唤醒状态。

因此，TCP 并发的根基不是 epoll，而是连接级状态隔离。如果两条连接共用序列号或接收缓冲区，换成 epoll 也不能让协议栈正确并发。

2. 报文怎样找到自己的 stream

if (iter->sip == sip && iter->dip == dip &&
 iter->sport == sport && iter->dport == dport) {
 return iter;
}

一般网络流用五元组标识；这里已经确定是 TCP，所以搜索时比较四元组。两个客户端连接同一个服务端地址和端口时，客户端 IP 或源端口不同，因此能找到不同的 stream。

3. 监听 stream 和连接 stream

服务端只有一个监听 stream，但可以有许多已连接 stream：

listenfd / LISTEN stream
 ├── connfd A / ESTABLISHED stream A
 ├── connfd B / ESTABLISHED stream B
 └── connfd C / ESTABLISHED stream C

收到 SYN 时，协议栈保留监听 stream，并创建一个新的连接 stream 处理该客户端：

struct ng_tcp_stream *syn = ng_tcp_stream_create(
 iphdr->src_addr, iphdr->dst_addr,
 tcphdr->src_port, tcphdr->dst_port);

LL_ADD(syn, table->tcb_set);
syn->status = NG_TCP_STATUS_SYN_RCVD;

监听对象负责“还能不能接新连接”，连接对象负责“这个客户端的数据和状态”。epoll 后面会分别监听这两类 fd。

四、一连接一线程为什么能工作，又为什么需要 epoll

1. 一连接一线程

最直观的并发方式是：

主线程：不断 naccept()
连接 A：线程 A 阻塞在 nrecv(A)
连接 B：线程 B 阻塞在 nrecv(B)
连接 C：线程 C 阻塞在 nrecv(C)

它适合验证连接表、stream 隔离和收发缓冲区是否支持多个客户端。问题是大部分连接经常没有数据，线程却仍占用栈空间和调度资源。连接数增长时，线程数也同步增长。

2. epoll 的改变

epoll 模型下，应用线程不阻塞在某一个 nrecv(connfd) 上，而是阻塞在“所有已注册 fd 的就绪集合”上：

应用线程：nepoll_wait(A, B, C, ...)

只有 B 有数据
→ nepoll_wait 只返回 B
→ 应用处理 B
→ 再次等待所有连接

所以两种模型的区别不是 TCP 连接数，而是等待位置：

一连接一线程：每个线程等待一个 fd
epoll：一个线程等待一组 fd

五、为什么不能直接调用 Linux 原生 epoll

代码中的 listenfd、connfd 和 epfd 由自己的位图分配：

static int get_fd_frombitmap(void) {
 for (int fd = DEFAULT_FD_NUM; fd < MAX_FD_COUNT; fd++) {
 if (fd_table 中该位空闲) {
 标记为已用;
 return fd;
 }
 }
 return -1;
}

这些整数只在用户态协议栈内部有意义：

用户态 fd
→ get_hostinfo_fromfd(fd)
→ ng_tcp_stream / localhost / eventpoll

Linux 内核没有创建对应的 socket 对象，也不知道 stream->rcvbuf 是否有数据。因此把这种 connfd 传给内核 epoll_ctl()，内核无法监听它。

既然 Socket API 是用户态自己实现的，事件机制也要自己补齐：

nsocket / nbind / nlisten / naccept / nrecv / nsend
 +
nepoll_create / nepoll_ctl / nepoll_wait

六、理解 epoll 的关键：就绪是一种状态

应用关注的不是“是否来过一个包”，而是“现在执行某个操作会不会阻塞”。

1. 监听 fd 可读

监听 fd 的 EPOLLIN 表示：

至少有一条已完成握手的连接可以被 naccept() 取出

它不是说监听 socket 收到了应用 payload，而是说 accept 现在不会阻塞。

2. 连接 fd 可读

连接 fd 的 EPOLLIN 表示：

nrecv() 现在可以取得 payload，或者取得 EOF/关闭信息

因此，收到 FIN 也可以触发 EPOLLIN。应用随后调用 nrecv() 得到 0，知道对端已关闭。

3. 连接 fd 可写

EPOLLOUT 的一般含义是：发送缓冲区有空间，send 不会因为缓冲区已满而阻塞。它不等于“一个数据包已经从网卡发完”。

本节代码重点实现的是 EPOLLIN 链路；要完整支持 EPOLLOUT，还需要定义 sndbuf 从满变为可用时怎样产生通知。

这一点非常重要：

epoll 事件是 Socket 操作条件的变化，不是对每个网络包做一次简单转发。

七、epoll 的两个集合

一个 epoll 实例内部有两份不同用途的集合。

1. 整集：我关注谁

整集保存所有通过 EPOLL_CTL_ADD 注册的 fd。代码用红黑树组织，以 sockfd 为 key：

整集 = {listenfd, connfd_A, connfd_B, connfd_C, ...}

它回答：

这个 fd 是否被注册？
应用对它关心 EPOLLIN 还是 EPOLLOUT？
ADD/DEL/MOD 应该操作哪个节点？

红黑树提供稳定的 O(log n) 查找、插入和删除，并能随注册数量按节点增长。哈希的平均查找更快，但要额外处理桶容量、冲突和扩容。这里选择红黑树的重点是动态集合与稳定性能，并不是红黑树在所有场景都绝对更快。

2. 就绪集：现在谁能处理

就绪集是链表，只保存当前已经产生事件的节点：

整集：{listenfd, A, B, C, D}
就绪集：{B, D}

nepoll_wait() 无须扫描整棵红黑树，只需从就绪链表取出 B、D。

3. 同一个节点同时属于两份集合

struct epitem {
 RB_ENTRY(epitem) rbn;
 LIST_ENTRY(epitem) rdlink;

 int rdy;
 int sockfd;
 struct epoll_event event;
};

一个 epitem 中同时有红黑树节点和链表节点：

rbn：长期挂在整集，表示注册关系
rdlink：就绪时临时挂在就绪链表
rdy：防止同一节点被重复插入就绪链表

节点进入就绪链表后仍保留在红黑树里。应用消费一次就绪事件，不等于取消对这个 fd 的关注；只有 EPOLL_CTL_DEL 才删除注册关系。

4. `eventpoll` 管理整个 epoll 实例

struct eventpoll {
 int fd;

 ep_rb_tree rbr;
 int rbcnt;

 LIST_HEAD(, epitem) rdlist;
 int rdnum;

 pthread_mutex_t mtx;
 pthread_spinlock_t lock;
 pthread_cond_t cond;
 pthread_mutex_t cdmtx;
};

关系可以画成：

epfd
└── eventpoll
 ├── rbr：全部已注册 epitem
 ├── rdlist：当前就绪 epitem
 └── cond：没有就绪事件时，让 nepoll_wait 睡眠

八、三个外部接口怎样组成应用侧逻辑

1. `nepoll_create()`：创建事件管理器

它做的事情不是创建 TCP 连接，而是创建一个 eventpoll：

分配 epfd
→ 分配 eventpoll
→ 初始化红黑树
→ 初始化就绪链表
→ 初始化锁与条件变量
→ 建立 epfd 到 eventpoll 的映射

应用以后通过 epfd 找到这一整套事件管理状态。

2. `nepoll_ctl()`：维护整集

ADD：树中不存在 → 分配 epitem → 插入红黑树
DEL：树中存在 → 从红黑树移除 → 释放 epitem
MOD：树中存在 → 修改关注的事件

因此，nepoll_ctl() 只是在表达应用的兴趣：

“如果这个 fd 以后出现我关心的状态，请通知我。”

注册本身不会凭空制造事件。

3. `nepoll_wait()`：没有事件就睡，有事件就返回

while (ep->rdnum == 0 && timeout != 0) {
 if (timeout > 0)
 pthread_cond_timedwait(&ep->cond, &ep->cdmtx, ...);
 else if (timeout < 0)
 pthread_cond_wait(&ep->cond, &ep->cdmtx);
}

超时语义：

timeout < 0：一直等待；
timeout == 0：立即检查并返回；
timeout > 0：最多等待指定时长。

醒来后，它从就绪链表取出最多 maxevents 个节点，把其中的 epoll_event 复制给应用：

rdlist 中的 epitem
→ events[0...n-1]
→ 返回 nready

至此，epoll 只告诉应用“哪些 fd 可以处理”。真正的 accept/recv/send 仍由应用自己调用。

九、最关键的内部接口：协议栈怎样触发事件

三个 nepoll_* 接口面向应用；epoll_event_callback() 面向协议栈：

int epoll_event_callback(struct eventpoll *ep,
 int sockid, uint32_t event) {
 struct epitem *epi = RB_FIND(..., sockid);
 if (!epi)
 return -1;

 if (epi->rdy) {
 epi->event.events |= event;
 return 1;
 }

 pthread_spin_lock(&ep->lock);
 epi->rdy = 1;
 LIST_INSERT_HEAD(&ep->rdlist, epi, rdlink);
 ep->rdnum++;
 pthread_spin_unlock(&ep->lock);

 pthread_mutex_lock(&ep->cdmtx);
 pthread_cond_signal(&ep->cond);
 pthread_mutex_unlock(&ep->cdmtx);
}

它完成四步：

按 sockid 查整集
→ 把事件记录到对应 epitem
→ 把 epitem 加入就绪链表
→ signal 唤醒 nepoll_wait

如果节点已经在就绪链表中，就不重复插入，只合并事件位：

epi->event.events |= event;

这避免同一个 fd 连续收到多个通知时，在 rdlist 中出现多个相同节点。

epoll 模块在整体架构中的位置

协议栈 epoll 应用

握手完成 ─┐
收到数据 ─┼→ event_callback → rdlist → cond_signal → nepoll_wait
收到 FIN ─┘ ↓
 accept/recv/close

所以 epoll 不是协议栈之外的独立轮询器。它必须由协议栈在状态真正改变的地方主动通知。

十、用三条时间线彻底串起实现

时间线一：新客户端完成连接

① 客户端发送 SYN
② ng_tcp_process 找到 LISTEN stream
③ 为客户端创建新的 stream，进入 SYN_RCVD
④ 协议栈发送 SYN+ACK
⑤ 收到客户端 ACK，新 stream 进入 ESTABLISHED
⑥ 协议栈触发 listenfd 的 EPOLLIN
⑦ nepoll_wait 返回 listenfd
⑧ 应用调用 naccept(listenfd)
⑨ naccept 取出已建立 stream，为它分配 connfd
⑩ 应用用 EPOLL_CTL_ADD 把 connfd 加入 epoll

对应代码的关键通知：

stream->status = NG_TCP_STATUS_ESTABLISHED;

struct ng_tcp_stream *listener =
 ng_tcp_stream_search(0, 0, 0, stream->dport);

epoll_event_callback(table->ep, listener->fd, EPOLLIN);

为什么通知 listener->fd，而不是新连接的 fd？

因为此时应用还没有执行 naccept()，新 stream 还没有分配给应用使用的 connfd。对应用来说，当前可执行的动作是 accept(listenfd)，所以就绪的是监听 fd。

时间线二：已连接客户端发送 payload

① 报文按四元组找到 established stream
② 协议栈复制 payload，构造 fragment
③ fragment 进入 stream->rcvbuf
④ 协议栈触发 stream->fd 的 EPOLLIN
⑤ callback 找到 connfd 对应的 epitem
⑥ epitem 进入 rdlist，唤醒 nepoll_wait
⑦ 应用得到 connfd
⑧ 应用调用 nrecv(connfd)，从该 stream 的 rcvbuf 取数据

关键顺序必须是：

先让数据真正可读
→ 再发布 EPOLLIN

否则应用被唤醒后可能发现 rcvbuf 仍为空。

时间线三：客户端发送 FIN

① 协议栈收到 FIN
② stream 进入 CLOSE_WAIT
③ rcvbuf 中放入长度为 0 的 fragment，表示 EOF
④ 触发 connfd 的 EPOLLIN
⑤ nepoll_wait 返回 connfd
⑥ nrecv(connfd) 返回 0
⑦ 应用 EPOLL_CTL_DEL，然后 nclose(connfd)

这条时间线解释了为什么“关闭”也能通过可读事件交给应用：读取操作已经不会阻塞，只是结果为 EOF。

十一、epoll 服务器循环现在应该怎样读

int epfd = nepoll_create(1);

ev.events = EPOLLIN;
ev.data.fd = listenfd;
nepoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);

while (1) {
 int nready = nepoll_wait(epfd, events, 128, 5);

 for (int i = 0; i < nready; i++) {
 if (events[i].data.fd == listenfd) {
 int connfd = naccept(listenfd, ...);

 ev.events = EPOLLIN;
 ev.data.fd = connfd;
 nepoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);
 } else {
 int connfd = events[i].data.fd;
 int n = nrecv(connfd, buff, BUFFER_SIZE, 0);

 if (n > 0) {
 nsend(connfd, buff, n, 0);
 } else {
 nepoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
 nclose(connfd);
 }
 }
 }
}

不要只把它看成一个 API 调用顺序。这个循环其实在处理两类状态机入口：

listenfd 就绪
→ 连接管理路径
→ accept 新连接并将 connfd 注册进 epoll

connfd 就绪
→ 数据路径或关闭路径
→ recv 数据，或者识别 EOF 后移除连接

多个客户端的并发体现在：所有 connfd 都在同一棵红黑树中，但某一时刻只有真正就绪的连接进入 rdlist。

十二、薄弱但非常重要：LT、ET 与“消费事件”

理解整集和就绪集后，还必须区分两种事件语义。

1. LT：Level Triggered，水平触发

只要可读条件仍然成立，就应该继续报告：

rcvbuf 里还有数据
→ fd 仍然可读
→ 下一次 epoll_wait 仍应返回它

应用可以一次只读一部分，剩余数据会让 fd 继续保持就绪。

2. ET：Edge Triggered，边沿触发

只在状态从“不可读”变为“可读”的边沿通知一次：

rcvbuf：空 → 非空
→ 触发一次 EPOLLIN

如果应用没有把数据一直读到 EAGAIN，而 rcvbuf 始终保持非空，就可能没有新的空→非空边沿，因此也不会再次收到通知。

3. 当前学习代码的核心行为

epoll_event_callback() 把节点加入 rdlist；nepoll_wait() 返回后将其移出并清除 rdy。以后再次发生协议栈回调时，节点才能重新加入。

这更接近“协议栈事件通知队列”的实现骨架。要形成严格的 LT 或 ET，还需要把就绪谓词定义清楚：

监听 fd 可读：accept 队列非空
连接 fd 可读：rcvbuf 非空，或存在 EOF/错误
连接 fd 可写：sndbuf 有可用空间

然后选择策略：

LT：epoll_wait 返回事件后，如果谓词仍为真，应保留或重新加入就绪集。
ET：只有谓词从假变真时才入就绪集，应用必须把资源处理到再次变为假。

这部分是自实现 epoll 最容易遗漏的核心：就绪链表只是结果，真正决定事件语义的是状态谓词和重新入队规则。

十三、线程同步：为什么需要三种同步手段

代码中不同锁保护不同对象：

同步对象	主要保护内容
`ep->mtx`	红黑树的 ADD/DEL/MOD
`ep->lock` 自旋锁	短时间修改 `rdlist`、`rdnum`、`rdy`
`ep->cdmtx + cond`	`nepoll_wait` 睡眠与协议栈唤醒

1. 为什么等待必须检查条件

正确思路不是“收到 signal 就相信一定有事件”，而是：

while (ep->rdnum == 0)
 pthread_cond_wait(...);

条件变量可能虚假唤醒，也可能多个等待者竞争同一批事件。醒来后必须重新检查 rdnum。

同理，nrecv() 等待数据时也使用循环检查 rcvbuf，而不是单次 if。

2. 为什么先入就绪集，再 signal

发布顺序是：

修改受保护状态：epitem 进入 rdlist，rdnum++
→ 再 signal

signal 的作用只是提醒等待线程重新检查条件；真正可信的是受锁保护的 rdlist/rdnum。

3. `DEL` 与回调之间的关系

应用关闭连接时会删除 epitem，协议栈线程则可能正在为同一 fd 触发回调。完整实现必须让红黑树查找、节点删除和就绪链表访问遵守一致的生命周期规则，避免回调继续访问已经释放的节点。

这里不展开代码审查，只需记住：并发数据结构除了“查得快”，还要保证节点从注册、就绪到删除期间始终有效。

十四、单 epoll 与多个 epoll

当前代码在创建时执行：

struct ng_tcp_table *table = tcpInstance();
table->ep = ep;

协议栈触发事件时也直接使用：

epoll_event_callback(table->ep, stream->fd, EPOLLIN);

这意味着当前教学实现默认整个 TCP table 只有一个 epoll。它足以展示完整通知链路，但还不能表达：

同一进程创建多个 epoll 实例；
不同 epoll 注册不同连接；
同一个 fd 同时被多个 epoll 关注。

扩展为多个 epoll 时，不能只保留一个 table->ep。需要建立：

epfd → eventpoll

以及

sockfd → 所有注册了该 sockfd 的 epitem/eventpoll

协议栈产生事件后，要找到所有相关订阅者并分别更新它们的就绪集。这实际上把单指针通知扩展成一对多的观察者关系。

十五、多连接 core dump 在本篇中的位置

多连接时暴露 core dump，说明“单连接路径成立”并不等于“所有连接级资源都已正确隔离”。本节笔记直接涉及的一点是：每条 stream 都会创建自己的 DPDK ring，而 DPDK 命名对象需要可区分的名称。

sprintf(sbufname, "sndbuf%x%d", sip, sport);
stream->sndbuf = rte_ring_create(sbufname, ...);

sprintf(rbufname, "bufname%x%d", sip, sport);
stream->rcvbuf = rte_ring_create(rbufname, ...);

这里用客户端 IP 和源端口区分连接 ring。要记住三层不同的身份：

四/五元组：让协议栈把报文分给正确 stream
DPDK ring 名称：让每条 stream 获得独立缓冲对象
用户态 fd：让应用和 epoll 找到正确 stream

本篇不继续展开具体崩溃排查，因为重点是 epoll 的事件闭环。

十六、把全部实现压缩成一张图

 应用线程
 │
 nepoll_ctl ADD │ 注册兴趣
 ▼
 ┌───────────────┐
 │ eventpoll │
 │ │
 │ 红黑树 rbr │ ← 全部注册 fd
 │ 就绪表 rdlist │ ← 当前就绪 fd
 │ cond │ ← 没事件时睡眠
 └───────┬───────┘
 │ nepoll_wait 返回
 ▼
 accept / recv / send / close
 ▲
 │ 用户态 fd → stream
 ┌───────┴────────┐
 │ ng_tcp_stream │
 │ 状态/SEQ/ACK │
 │ rcvbuf/sndbuf │
 └───────▲────────┘
 │
 ng_tcp_process 按四元组定位
 │
 握手完成 / payload 到达 / FIN 到达
 │
 epoll_event_callback
 │
 加入 rdlist + signal

从这张图可以看到，TCP 并发 epoll 不是单独一个数据结构，而是四套映射协作：

报文四元组 → stream
用户态 fd → stream
epfd → eventpoll
eventpoll 中 sockfd → epitem

缺少任何一层，事件都无法从报文准确传递到应用。

十七、最终应掌握的实现逻辑

多连接首先要求每条连接拥有独立 TCB、状态、序列号和收发缓冲区。
报文通过四元组找到 stream，应用通过用户态 fd 找到同一个 stream。
一连接一线程让每个线程阻塞等一个 fd；epoll 让一个线程等待一组 fd。
用户态 fd 不属于内核，因此必须自实现 epoll，不能直接交给 Linux epoll。
红黑树保存“关注谁”，就绪链表保存“现在谁能处理”。
nepoll_ctl() 建立兴趣关系，epoll_event_callback() 发布事件，nepoll_wait() 消费事件。
握手完成触发监听 fd 的 EPOLLIN，因为此时 accept 不再阻塞。
payload 或 FIN 到达触发连接 fd 的 EPOLLIN，因为此时 recv 能返回数据或 EOF。
必须先改变真实就绪状态，再把事件加入就绪集并唤醒等待线程。
LT/ET 的本质不在链表名字，而在就绪谓词以及事件消费后的重新入队规则。
单 epoll 可以用 tcp_table->ep；多个 epoll 需要 fd 到多个订阅者的映射。
epoll 解决应用调度问题，不替代 TCP 状态机，也不能弥补连接状态未隔离的问题。

十八、反刍题

为什么三次握手完成时触发 listenfd，而不是新连接 fd？
为什么 FIN 可以通过 EPOLLIN 通知？
红黑树和就绪链表各自回答什么问题？
为什么一个 epitem 要同时包含 RB_ENTRY 和 LIST_ENTRY？
nepoll_ctl() 注册了一个 fd 后，为什么它不一定立刻出现在就绪链表？
从 payload 到达到 nepoll_wait() 返回，中间依次发生了什么？
如果 rcvbuf 仍有未读数据，LT 和 ET 下一步分别应该怎样表现？
为什么条件变量的等待必须放在 while 中？
为什么发布事件时要先更新 rdlist/rdnum，再调用 signal？
当前的 tcp_table->ep 为什么只能自然表达单 epoll？
如果一个 connfd 被两个 epoll 实例注册，协议栈该怎样分发一次 EPOLLIN？
epoll 已经实现正确，但不同连接仍共用 rcvbuf，并发为什么仍然会失败？

协程运行时：IO Hook、调度器与汇编上下文切换

Tue, 11 Aug 2026 00:00:00 +0800

本篇承接 yield、resume、ucontext 和简单轮询调度，重点理解阻塞式 I/O 的 Hook、协程状态管理、调度器与 epoll 的协作，以及 x86-64 汇编上下文切换。

一、从上下文切换走向完整协程运行时

已经掌握的两个方向：

main → ctx ：resume
ctx → main ：yield

它们底层都依赖一次 context switch：

保存当前执行现场
 ↓
恢复目标执行现场
 ↓
目标协程从上次暂停位置继续

但只有 switch、resume 和 yield 还不够。真正处理网络 I/O 还需要回答：

1. 普通read/recv没有数据时，怎样自动yield？
2. fd就绪以后，怎样找到并resume对应协程？
3. 十万个协程如何保存和组织？
4. READY、WAITING、SLEEPING、EXITED如何管理？
5. 定时器和I/O超时如何处理？
6. 上下文切换怎样用汇编实现？
7. 多核机器上怎样运行多个调度器？

最终需要形成：

POSIX I/O调用
 ↓
Hook层
 ↓
非阻塞I/O + epoll
 ↓
yield / resume
 ↓
协程状态和调度器
 ↓
ucontext或汇编context switch

二、为什么需要 Hook I/O

一个协程中的业务代码希望保持顺序结构：

while(1){
recv();
parser();
send();
}

阅读时仍然是：

接收数据
 ↓
解析数据
 ↓
发送响应

但如果这里直接调用阻塞式 recv()，没有数据时会阻塞整个线程，线程内其他协程也无法运行。

协程库希望在不大改业务流程的情况下，把调用替换为自己的实现：

业务调用recv/read
 ↓
进入协程库Hook函数
 ↓
先尝试非阻塞I/O
 ├── 已就绪：调用真实系统函数并返回
 └── 未就绪：注册epoll事件并yield
 ↓
 fd就绪
 ↓
 resume协程
 ↓
 再调用真实系统函数

这就是：

上层保持同步代码结构，底层通过 epoll 和协程实现异步等待。

三、Hook 的概念流程

笔记中的伪代码：

recv（fd,buffer,length）{
struct pollfd fds[1]={0};
fds[0].fd=fd;
if(0<poll(fd,1,0)){//io可读
recv_f(fd,buffer,length);
}else{
epoll_ctl(epfd,EPOLL_CTL_ADD,fd,&ev);
swapcontext();

}
}

它表达了四步。

3.1 检查 fd 是否就绪

poll(fd,1,0)

timeout 为 0，表示立即检查，不在 poll() 中等待。

返回值 > 0 → 当前fd有事件
返回值 = 0 → 当前没有事件
返回值 < 0 → 调用发生错误

3.2 已就绪时调用真实函数

recv_f(fd,buffer,length);

recv_f 指向真正的系统 recv，而不是 Hook 后的同名函数。

3.3 未就绪时注册 epoll

epoll_ctl(epfd,EPOLL_CTL_ADD,fd,&ev);

同时记录：

哪个fd
等待什么事件
哪个协程正在等待它
是否存在超时时间

3.4 当前协程 yield

swapcontext();

这里代表概念上的 yield。实际实现需要明确传入当前协程上下文和调度器上下文。

当前协程WAITING
 ↓
yield回调度器
 ↓
调度器运行其他READY协程

四、使用 dlsym 拦截 read 和 write

以下是提供的 Hook 代码：

#define _GNU_SOURCE

#include <dlfcn.h>

#include <stdio.h>
#include <ucontext.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>

#include <sys/socket.h>
#include <errno.h>
#include <netinet/in.h>


#include <pthread.h>
#include <sys/poll.h>
#include <sys/epoll.h>

4.1 为什么需要 _GNU_SOURCE

#define _GNU_SOURCE

它在包含系统头文件前启用 GNU 扩展声明，使 dlsym()、RTLD_NEXT 等接口在相应环境中可见。

4.2 函数指针类型

原代码：

typedef ssize_t (*read_t)(int fd, void *buf, size_t count);
read_t read_f = NULL;

typedef ssize_t (*write_t)(int fd, const void *buf, size_t count);
write_t write_f = NULL;

read_t 描述真实 read() 的函数类型：

参数1：fd
参数2：接收缓冲区
参数3：最大读取长度
返回值：实际读取长度或错误

write_t 对应真实 write()。

read_f → 保存原始read地址
write_f → 保存原始write地址

五、init_hook() 如何取得真实函数

原代码：

void init_hook(void) {

	if (!read_f) {
		read_f = dlsym(RTLD_NEXT, "read");
	}

	
	if (!write_f) {
		write_f = dlsym(RTLD_NEXT, "write");
	}

}

dlsym() 根据符号名查找函数地址：

dlsym(RTLD_NEXT, "read");

RTLD_NEXT 的含义可以理解为：

从当前 Hook 定义之后继续寻找下一个名为 read 的实现。

因此调用关系是：

业务代码调用read()
 ↓
进入当前文件定义的Hook read()
 ↓
Hook内部调用read_f()
 ↓
进入真正的系统read()

如果 Hook 内部再次直接调用 read()：

Hook read()
 ↓
又进入Hook read()
 ↓
无限递归

所以必须使用 read_f 调用真实函数。

使用 dlsym() 时通常需要链接动态加载库：

gcc ... -ldl

六、read() Hook 的执行过程

原代码：

ssize_t read(int fd, void *buf, size_t count) {

	struct pollfd fds[1] = {0};

	fds[0].fd = fd;
	fds[0].events = POLLIN;

	int res = poll(fds, 1, 0);
	if (res <= 0) { //不可读


		// fd --> epoll_ctl();

		swapcontext(); // fd --> ctx fd与context一对一
		
	}
	// io

	
	ssize_t ret = read_f(fd, buf, count);
	printf("read: %s\n", (char *)buf);
	return ret;

	
	
}

6.1 构造 pollfd

struct pollfd fds[1] = {0};

fds[0].fd = fd;
fds[0].events = POLLIN;

表示只检查一个 fd 的可读事件。

6.2 立即检查

int res = poll(fds, 1, 0);

第三个参数为 0：

不等待
立即返回当前状态

6.3 不可读时暂停协程

if (res <= 0) {
 // fd --> epoll_ctl();
 swapcontext();
}

完整运行时还需要在 yield 前完成：

将fd设置为非阻塞
将fd注册到epoll
记录fd等待POLLIN/EPOLLIN
记录当前等待协程
设置可选超时时间
当前协程状态改为WAITING
yield到scheduler

fd 就绪后：

epoll_wait返回fd
 ↓
找到等待它的协程
 ↓
协程进入READY队列
 ↓
scheduler resume协程
 ↓
从swapcontext()之后继续
 ↓
read_f()真正读取数据

6.4 调用真实 read

ssize_t ret = read_f(fd, buf, count);

这一步才真正从内核读取数据。

poll 告诉程序“当前可能可读”，read_f 才完成实际读取。就绪状态可能在检查和读取之间变化，因此 fd 仍然应该是非阻塞的，并正确处理 EAGAIN。

七、write() Hook

原代码：

ssize_t write(int fd, const void *buf, size_t count) {

	printf("write: %s\n", (const char *)buf);

	return write_f(fd, buf, count);
}

当前实现主要展示：

业务调用write
 ↓
进入Hook write
 ↓
调用write_f进入真实write

完整协程版 write() 也需要处理：

真实write成功一部分
 → 记录已写偏移，继续写剩余数据

真实write返回EAGAIN
 → 注册EPOLLOUT
 → 当前协程yield
 → fd可写后resume

Hook write() 内部使用 printf() 记录日志时要特别小心，因为 printf() 最终也可能调用 write()，从而再次进入 Hook。实际实现通常使用不会再次触发该 Hook 的日志路径，或者直接调用保存下来的真实 write_f。

八、Hook 示例怎样接入普通服务端

原代码：

int main() {

	init_hook();

	int sockfd = socket(AF_INET, SOCK_STREAM, 0);

	struct sockaddr_in serveraddr;
	memset(&serveraddr, 0, sizeof(struct sockaddr_in));

	serveraddr.sin_family = AF_INET;
	serveraddr.sin_addr.s_addr = htonl(INADDR_ANY);
	serveraddr.sin_port = htons(2048);

	if (-1 == bind(sockfd, (struct sockaddr*)&serveraddr, sizeof(struct sockaddr))) {
		perror("bind");
		return -1;
	}

	listen(sockfd, 10);

	struct sockaddr_in clientaddr;
	socklen_t len = sizeof(clientaddr);
	int clientfd = accept(sockfd, (struct sockaddr*)&clientaddr, &len);
	printf("accept\n");

	while (1) {

		char buffer[128] = {0};
		int count = read(clientfd, buffer, 128);
		if (count == 0) {
			break;
		}
		write(clientfd, buffer, count);
		printf("sockfd: %d, clientfd: %d, count: %d, buffer: %s\n", sockfd, clientfd, count, buffer);

	}

	return 0;

}

业务代码仍然调用：

read(clientfd, buffer, 128);
write(clientfd, buffer, count);

但由于程序中定义了同名 read() 和 write()，符号解析会先进入 Hook。

这正是 Hook 的价值：

业务代码结构保持不变
 ↓
read/write调用被协程库接管
 ↓
等待I/O时自动yield
 ↓
就绪后自动resume

当前示例只接收一个 clientfd，重点是展示 Hook 链路。与真正协程服务器结合时，还需要 accept Hook、多连接协程、epoll mainloop 和 scheduler。

九、为什么第三方库也可以受益

例如本地程序使用 hiredis 连接 Redis。hiredis 内部会调用 read/write 或 send/recv 完成网络操作。

不修改 hiredis 源码时：

业务调用hiredis
 ↓
hiredis内部调用read/write
 ↓
进入协程库Hook
 ↓
没有数据时yield
 ↓
Redis响应到达后resume

因此原本按照阻塞式 POSIX API 编写的库，有机会直接运行在协程调度环境中。

前提是 Hook 覆盖了它实际调用的 API，并正确处理：

阻塞标志
超时
EINTR
EAGAIN
部分读写
close和fd复用
线程安全

十、如何定义一个协程

笔记中的初始设计：

struct coroutinue{
int fd;
ucontext_t ctx;//stack ，stack_size,func包含在里面
void *arg

};

一个协程需要保存两类信息。

10.1 执行现场

ctx → 寄存器、栈指针、执行位置等上下文
stack → 协程自己的栈
stack_size → 栈大小
entry → 协程入口函数
arg → 入口参数

10.2 调度状态

id → 协程标识
state → READY、RUNNING、WAITING等
fd → 当前等待的I/O对象
events → 等待EPOLLIN或EPOLLOUT
expire_at → 超时时间或唤醒时间
scheduler → 所属调度器

概念上的完整结构：

struct coroutine
 ├── id
 ├── state
 ├── context
 ├── stack / stack_size
 ├── entry / arg
 ├── waiting_fd / events
 ├── expire_at
 ├── ready_node
 ├── wait_node
 ├── sleep_node
 └── scheduler

本篇沿用原笔记中的 coroutinue 拼写来对应代码，实际项目中可以统一为 coroutine。

十一、协程入口与创建

原始设计：

void func(void){

}


typedef void *(*coroutinue_entry)(void *)
int create_coroutinue(co_id id,coroutinue_entry entry,void *arg){
struct coroutinue *co =malloc(sizeof(struct coroutinue));
co.ss_sp=
makecontext(co->ctx,func,0);
}

创建协程需要完成：

1. 分配struct coroutine
2. 分配或绑定独立栈
3. 保存entry和arg
4. 初始化context
5. 设置入口包装函数
6. 设置协程退出后的返回目标
7. state设为READY
8. 加入ready_queue

为什么通常需要一个入口包装函数：

scheduler resume新协程
 ↓
进入wrapper
 ↓
wrapper调用entry(arg)
 ↓
entry返回
 ↓
wrapper把协程状态设为EXITED
 ↓
yield回scheduler
 ↓
scheduler回收资源

如果直接让入口函数随意 return，而没有统一退出路径，调度器很难正确修改状态和释放栈。

十二、十万个协程如何组织

假设采用“一连接一协程”：

10万个fd
 ↓
10万个coroutine对象

但它们不会全部同时运行。

例如：

10万个协程
 ├── 2万个READY
 ├── 5万个WAITING
 ├── 2万个SLEEPING
 └── 1万个已结束或待回收

调度器必须按状态组织它们，不能每轮扫描全部十万个对象。

十三、READY 为什么使用队列

笔记中的设计：

queue_node (corountine,)ready_queue

READY 协程表示现在就可以运行。

常见操作：

协程变为READY → 从队尾加入
scheduler取任务 → 从队头取出
协程yield但仍可运行 → 再放回队尾

因此队列适合：

O(1)入队
O(1)出队
天然支持轮询公平调度

如果有 2 万个 READY 协程：

ready_head
 → co1 → co2 → co3 → ... → co20000

scheduler 每次取队头协程 resume。

十四、WAITING 与 SLEEPING 为什么需要有序结构

笔记中的设计：

rbtree_node(coroutinue,)wait_rb;
rbtree_node(coroutinue,)sleep_rb;

等待 I/O 的协程可能还设置超时：

协程A等待fd=4，100ms后超时
协程B等待fd=5，500ms后超时
协程C等待fd=6，50ms后超时

睡眠协程也有不同唤醒时间：

协程D睡眠到10:00:00.100
协程E睡眠到10:00:00.800

如果以 expire_at 为 key 放入有序结构，调度器可以快速找到最早到期节点：

最小expire_at
 ↓
与当前时间比较
 ↓
已经到期就移出
 ↓
状态改为READY
 ↓
加入ready_queue

红黑树、最小堆、跳表、时间轮都可以实现定时管理，具体选择取决于插入、删除、精度和规模要求。

I/O fd 到协程的查找，还可以另外使用：

epoll_event.data.ptr
哈希表 fd → coroutine
数组 fd → coroutine

时间树解决“谁先超时”，fd 映射解决“哪个事件唤醒谁”，它们是两个不同查找维度。

十五、一个协程为什么可以同时拥有多个节点

笔记中的思路是把数据结构节点直接放进 coroutine：

ready_node
wait_node
sleep_node

这种方式称为侵入式数据结构：

coroutine对象本身包含链表节点或树节点
 ↓
不需要额外分配包装节点
 ↓
从节点可以找回所属coroutine

但协程状态必须保持一致：

READY → 位于ready_queue
WAITING → 位于I/O等待集合，可能同时位于超时树
SLEEPING → 位于sleep定时结构
RUNNING → 当前正在执行，通常不在ready_queue
EXITED → 位于回收集合或等待立即回收

协程从一个状态切到另一个状态时，需要从旧集合移除，再加入新集合，避免同一个节点被重复挂载。

十六、scheduler 如何定义

笔记中的设计：

scheduler
struct scheduler{
int epfd
struct epoll_event events[];

queue_node (corountine,)ready_head
rbtree_root(coroutinue,)wait_rb;
rbtree_root(coroutinue,)sleep_rb;

};

各字段含义：

epfd → epoll实例
events[] → epoll_wait返回的就绪事件
ready_head → 当前可以运行的协程
wait_rb → 等待I/O并带超时的协程
sleep_rb → 主动睡眠的协程

完整调度器还会需要：

main_context → scheduler自己的上下文
current → 当前正在运行的协程
all_coroutines → 所有协程的所有权集合
exited_queue → 等待回收的协程
stop → 退出标志
thread_id → 所属线程

十七、哪些操作由协程执行，哪些由调度器执行

17.1 协程主动执行

调用read/recv/send/write
发现需要等待后yield
主动sleep
业务处理
入口函数返回并exit

17.2 调度器执行

维护ready_queue
计算最近超时时间
调用epoll_wait
处理fd就绪事件
处理wait/sleep超时
把协程转为READY
选择下一个协程resume
回收EXITED协程

核心边界：

协程表达“我要等待什么”，调度器决定“等待期间运行谁，以及何时唤醒我”。

十八、调度循环的完整流程

一个合理的 scheduler mainloop 可以概括为：

while没有停止：

 1. 处理已经到期的sleep节点
 2. 处理已经超时的I/O等待节点
 3. 处理ready_queue中的协程
 4. 根据最近定时器计算epoll_wait超时
 5. 调用epoll_wait
 6. 根据events找到等待协程
 7. 将就绪协程加入ready_queue
 8. 回收已经退出的协程

如果 ready_queue 非空：

可以先继续运行READY协程
epoll_wait使用timeout=0避免阻塞

如果 ready_queue 为空：

根据最近timer计算等待时间
 ↓
epoll_wait可以阻塞到I/O到达或定时器到期

这样线程不会忙等。

十九、协程状态怎样流转

典型状态：

NEW
 ↓ create
READY
 ↓ scheduler resume
RUNNING
 ├── 等待I/O → WAITING
 ├── sleep → SLEEPING
 ├── 主动yield且仍可运行 → READY
 └── entry返回 → EXITED

WAITING
 ├── fd就绪 → READY
 └── 超时 → READY，并携带timeout结果

SLEEPING
 └── 时间到 → READY

EXITED
 ↓ scheduler回收
DESTROYED

状态与容器必须同步：

state = READY
 ↔ 在ready_queue中

state = WAITING
 ↔ 在I/O等待映射中

state = SLEEPING
 ↔ 在timer结构中

二十、setjmp、ucontext 和汇编怎样选择

三种方案：

setjmp / longjmp
ucontext
architecture-specific assembly

20.1 setjmp / longjmp

优点：

标准C接口
可移植性相对好
适合理解保存点和恢复点

限制：

不直接提供独立协程栈管理
构造完整栈式协程较复杂

20.2 ucontext

优点：

getcontext/makecontext/swapcontext语义清晰
可以直接指定独立栈和入口函数
教学和原型实现简单

限制：

已经不属于现代POSIX标准
不同平台支持情况不一致

20.3 汇编

优点：

直接控制保存和恢复的寄存器
切换路径短
适合性能敏感的运行时

限制：

与CPU架构、ABI和调用约定绑定
x86-64、ARM64等需要不同实现
测试和维护成本高

性能不能只靠固定排名判断，需要在相同编译器、架构和切换模型下基准测试。汇编通常能做得更精简，但正确性和可移植性同样重要。

二十一、x86-64 汇编上下文切换原代码

#elif defined(__x86_64__)

__asm__ (
" .text \n"
" .p2align 4,,15 \n"
".globl _switch \n"
".globl __switch \n"
"_switch: \n"
"__switch: \n"
" movq %rsp, 0(%rsi) # save stack_pointer \n"
" movq %rbp, 8(%rsi) # save frame_pointer \n"
" movq (%rsp), %rax # save insn_pointer \n"
" movq %rax, 16(%rsi) \n"
" movq %rbx, 24(%rsi) # save rbx,r12-r15 \n"
" movq %r12, 32(%rsi) \n"
" movq %r13, 40(%rsi) \n"
" movq %r14, 48(%rsi) \n"
" movq %r15, 56(%rsi) \n"
" movq 56(%rdi), %r15 \n"
" movq 48(%rdi), %r14 \n"
" movq 40(%rdi), %r13 # restore rbx,r12-r15 \n"
" movq 32(%rdi), %r12 \n"
" movq 24(%rdi), %rbx \n"
" movq 8(%rdi), %rbp # restore frame_pointer \n"
" movq 0(%rdi), %rsp # restore stack_pointer \n"
" movq 16(%rdi), %rax # restore insn_pointer \n"
" movq %rax, (%rsp) \n"
" ret \n"
);
#endif

对应的上下文结构：

typedef struct _nty_cpu_ctx {
	void *esp; //
	void *ebp;
	void *eip;
	void *edi;
	void *esi;
	void *ebx;
	void *r1;
	void *r2;
	void *r3;
	void *r4;
	void *r5;
} nty_cpu_ctx;



int _switch(nty_cpu_ctx *new_ctx, nty_cpu_ctx *cur_ctx);

函数语义：

new_ctx → 即将恢复的目标上下文
cur_ctx → 当前需要保存的上下文

在 System V AMD64 ABI 中，前两个整数或指针参数通常放在：

第一个参数new_ctx → RDI
第二个参数cur_ctx → RSI

因此：

RSI作为基地址 → 保存当前上下文
RDI作为基地址 → 加载目标上下文

二十二、汇编第一部分：保存当前上下文

22.1 保存栈指针

movq %rsp, 0(%rsi)

含义：

把当前RSP保存到cur_ctx偏移0的位置

RSP 指向当前线程正在使用的栈顶。恢复 RSP 才能回到该协程自己的栈。

22.2 保存帧指针

movq %rbp, 8(%rsi)

一个指针占 8 字节，所以第二个字段位于偏移 8。

22.3 保存返回地址

movq (%rsp), %rax
movq %rax, 16(%rsi)

调用 _switch 时，返回地址位于当前栈顶。先读到 RAX，再保存到 cur_ctx 偏移 16。

这个地址就是以后恢复协程时需要继续执行的位置。

22.4 保存被调用者保存寄存器

movq %rbx, 24(%rsi)
movq %r12, 32(%rsi)
movq %r13, 40(%rsi)
movq %r14, 48(%rsi)
movq %r15, 56(%rsi)

这些寄存器按照 x86-64 System V ABI 属于 callee-saved registers。函数返回后调用方有权期待它们保持不变，因此 context switch 必须保存和恢复。

偏移每次增加 8：

0 → rsp
8 → rbp
16 → rip/返回地址
24 → rbx
32 → r12
40 → r13
48 → r14
56 → r15

原结构中的 esp、ebp、eip 是 32 位风格名称；在这段 x86-64 汇编中实际保存的是 rsp、rbp 和返回地址。

二十三、汇编第二部分：恢复目标上下文

movq 56(%rdi), %r15
movq 48(%rdi), %r14
movq 40(%rdi), %r13
movq 32(%rdi), %r12
movq 24(%rdi), %rbx
movq 8(%rdi), %rbp
movq 0(%rdi), %rsp
movq 16(%rdi), %rax
movq %rax, (%rsp)
ret

这部分按相反方向加载 new_ctx：

恢复r15、r14、r13、r12、rbx
 ↓
恢复rbp
 ↓
恢复目标协程rsp
 ↓
把目标返回地址放到目标栈顶
 ↓
ret弹出返回地址
 ↓
从目标协程保存位置继续执行

最关键的一步：

movq 0(%rdi), %rsp

RSP 一旦切换，当前使用的栈就从旧协程栈变成了目标协程栈。

最后：

ret

从目标栈弹出保存的指令地址，于是代码看起来像目标协程之前调用的 _switch() 正常返回。

二十四、为什么不是保存所有寄存器

x86-64 有更多通用寄存器，但按照函数调用约定分为：

caller-saved → 调用方负责在需要时保存
callee-saved → 被调用函数必须保证返回后不变

_switch() 以普通函数调用形式进入，编译器会按照 ABI 处理 caller-saved 寄存器中的临时值，因此最小切换实现主要保存 callee-saved 寄存器、栈指针和返回位置。

这依赖：

明确的ABI
正确的函数声明
编译器遵循调用约定
汇编与结构体布局完全一致

System V AMD64 中，前六个整数或指针参数通常依次使用：

RDI、RSI、RDX、RCX、R8、R9

函数并不是不能超过六个参数。超过六个的参数会按照 ABI 放到栈上，只是调用方式不再全部使用参数寄存器。

二十五、从 Hook read 到调度器唤醒的完整链路

协程A调用read(fd)
 ↓
进入Hook read
 ↓
poll或真实read发现暂时不可读
 ↓
fd注册EPOLLIN
 ↓
记录fd → 协程A
 ↓
协程A状态RUNNING → WAITING
 ↓
_switch(scheduler_ctx, coA_ctx)
 ↓
scheduler运行其他READY协程
 ↓
epoll_wait返回fd
 ↓
根据event找到协程A
 ↓
从等待集合删除协程A
 ↓
协程A状态WAITING → READY
 ↓
加入ready_queue
 ↓
scheduler选择协程A
 ↓
_switch(coA_ctx, scheduler_ctx)
 ↓
协程A从Hook read中的yield位置继续
 ↓
调用read_f真正读取
 ↓
返回业务代码

这一整条链路把四个模块连接起来：

Hook层
epoll事件层
scheduler调度层
context switch底层

二十六、多线程与多进程模式

26.1 多线程模式

一种设计是多个线程各自运行调度器：

线程1 → scheduler1 → epoll1 → 一组协程
线程2 → scheduler2 → epoll2 → 一组协程
线程3 → scheduler3 → epoll3 → 一组协程

这通常比多个线程共同操作一个 scheduler 更容易控制，因为每个协程和上下文固定属于一个线程。

如果多个线程共享：

ready_queue
wait tree
sleep tree
coroutine对象

就需要考虑锁、并发状态迁移、跨线程唤醒和缓存竞争。

CPU affinity 可以让调度线程尽量固定在某个 CPU 核，减少迁移和缓存失效，但是否绑定需要通过测试决定。

26.2 多进程模式

进程1 → scheduler1 → 一组连接
进程2 → scheduler2 → 一组连接
进程3 → scheduler3 → 一组连接

每个进程拥有独立地址空间和调度器，协程数据天然隔离，减少共享锁。

需要额外考虑：

监听端口如何共享
连接如何负载均衡
进程间通信
共享状态
进程崩溃恢复

多线程和多进程都能利用多核。区别主要在共享内存、隔离性和通信成本。

二十七、怎样把协程能力用到实际项目

27.1 网络框架

以 ntyco 为基础理解：

coroutine
scheduler
epoll
Hook
timer
assembly switch

重点不是只复现 switch，而是打通：

I/O等待 → yield → epoll唤醒 → ready → resume

27.2 WebServer

一个连接或请求由一个协程处理
 ↓
协程recv HTTP请求
 ↓
解析协议
 ↓
查询Redis/MySQL
 ↓
发送HTTP响应

每个等待点都由 Hook 和 scheduler 自动让出。

27.3 KV 存储

例如 dkvstore：

连接协程
 ↓
接收命令
 ↓
解析SET/GET
 ↓
访问存储结构
 ↓
返回结果

27.4 图床

上传连接
 ↓
接收文件数据
 ↓
写磁盘或对象存储
 ↓
写数据库
 ↓
返回图片URL

这些项目能够体现的不是“使用了协程”一句话，而是：

怎样Hook阻塞API
怎样管理十万连接状态
怎样设计ready/wait/sleep结构
怎样处理超时和部分读写
怎样在多核上部署调度器
怎样测试切换和网络性能

二十八、核心总结

重点一：Hook 让同步代码接入异步调度

业务仍然调用read/write
 ↓
Hook判断I/O状态
 ↓
不可用时注册epoll并yield
 ↓
就绪后resume

重点二：协程对象既保存执行现场，也保存调度状态

context/stack → 回来后从哪里继续
state/fd/time → 什么时候可以回来
data nodes → 当前属于哪个调度集合

重点三：不同状态需要不同数据结构

READY → queue
I/O映射 → epoll data、数组或哈希
超时/睡眠 → 红黑树、最小堆或时间轮
EXITED → 回收队列

重点四：scheduler 是整个运行时的中心

处理epoll事件
处理定时器
维护协程状态
选择READY协程
执行resume
接收yield
回收退出协程

重点五：汇编 switch 只做保存和恢复

RSI → 保存当前上下文
RDI → 恢复目标上下文
RSP → 切换协程栈
ret → 跳回目标协程保存位置

最终可以把协程运行时理解成：

Hook 决定何时等待，epoll 决定何时就绪，scheduler 决定运行谁，context switch 决定怎样切过去。

Reactor 与 epoll：百万并发网络服务器

Sat, 08 Aug 2026 00:00:00 +0800

1. 本节课要解决什么问题

本节课不是直接实现完整 WebServer，而是先搭建一个能够承载大量网络连接的底层 I/O 框架。在这个框架之上，后续才能继续实现 HTTP 解析、路由、业务处理等功能。

核心目标有两个：

使用 Linux epoll 管理大量 socket。
使用 Reactor 思想，把不同 I/O 事件分发给不同回调函数。

当前代码实现的是一个简单的多端口 Echo Server：客户端发来什么，服务端就回写什么。

2. Reactor 的核心思想

Reactor 可以概括为：

I/O 对象（fd） → 发生事件（event） → 执行回调（callback）

本例中的映射关系如下：

I/O 对象	事件	含义	回调函数
`listenfd`	`EPOLLIN`	有新连接到达	`accept_cb()`
`clientfd`	`EPOLLIN`	客户端数据可读	`recv_cb()`
`clientfd`	`EPOLLOUT`	socket 当前可写	`send_cb()`

因此，主循环不需要判断“这个 fd 到底要做什么业务”，而只需要：

调用 epoll_wait() 等待事件。
从事件中取得 fd。
根据事件类型，调用该 fd 已经注册好的回调。

这就是“事件驱动”：没有事件时线程阻塞等待，有事件时才处理对应连接。

2.1 Reactor 的两个重点

建立 event 与 callback 的对应关系。
为每一个 I/O 保存独立的连接状态。

第二点非常重要。多个连接的数据不能共用一组读写缓冲区，否则连接之间会互相覆盖。因此每个 fd 都需要自己的：

读缓冲区 rbuffer
当前读取长度 rlength
写缓冲区 wbuffer
待发送长度 wlength
读事件回调
写事件回调

3. `epoll` 在 Reactor 中的职责

epoll 是 Linux 提供的 I/O 多路复用机制。一个线程可以通过一个 epoll 实例监听大量 fd，而不必给每条 TCP 连接创建一个线程。

三个最重要的接口是：

int epoll_create1(int flags);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events,
 int maxevents, int timeout);

其作用分别为：

epoll_create1()：创建一个 epoll 实例。
epoll_ctl()：添加、修改或删除所关注的 fd 和事件。
epoll_wait()：等待已经注册的 fd 产生事件。

当前代码使用的是默认的 LT（Level Triggered，水平触发）模式，因为没有设置 EPOLLET。

LT 模式下，只要 fd 仍处于可读或可写状态，epoll_wait() 就会继续报告它。若以后改成 ET（边沿触发），则 socket 必须设置成非阻塞，并且 accept()、recv() 等操作通常要循环执行，直到返回 EAGAIN。

4. 代码中的连接对象

struct conn {
 int fd;

 char rbuffer[BUFFER_LENGTH];
 int rlength;

 char wbuffer[BUFFER_LENGTH];
 int wlength;

 RCALLBACK send_callback;
 union {
 RCALLBACK recv_callback;
 RCALLBACK accept_callback;
 } r_action;
};

4.1 为什么需要 `struct conn`

TCP 是字节流协议，一次 recv() 不保证收到一个完整业务消息：

一个完整消息可能被拆成多次接收。
多个消息也可能在一次 recv() 中一起到达。
一次 send() 也不保证发送全部待发送数据。

所以 Reactor 不仅要保存回调，还必须保存每个连接的处理进度。严格来说，后续还应增加：

已读取但尚未解析的数据偏移量；
待发送数据的起始偏移量；
协议解析状态；
连接状态和超时信息；
动态扩容或链式缓冲区。

4.2 为什么 `accept_callback` 与 `recv_callback` 使用 `union`

监听 fd 的读事件表示“有连接可接受”，其回调是 accept_cb()；客户端 fd 的读事件表示“有数据可接收”，其回调是 recv_cb()。

同一个 fd 在这里不会同时既是监听 fd 又是客户端 fd，因此两个函数指针可以共用同一块存储空间。union 表达了二者“二选一”的关系。

不过，代码在赋值时使用了：

conn_list[sockfd].r_action.recv_callback = accept_cb;

语义上更清晰的写法是：

conn_list[sockfd].r_action.accept_callback = accept_cb;

调用时也应根据 fd 的角色使用对应成员，或者直接将二者合并成一个名称更通用的 read_callback。

4.3 为什么可以用 fd 作为数组下标

当前代码使用：

struct conn conn_list[CONNECTION_SIZE];

并直接通过 conn_list[fd] 找到连接。这种方法查找复杂度为 O(1)，非常直接。

但它有两个条件：

必须保证 0 <= fd < CONNECTION_SIZE，否则会越界。
数组内存非常大。

每个连接对象包含两个 1024 字节缓冲区，再加上长度、fd 和函数指针。100 多万个元素大约需要 2 GiB 以上的地址空间和可观的实际内存。因此“支持 100 万个 fd”不等于“采用这种结构后机器就一定能稳定承载 100 万连接”。生产实现通常会根据实际连接动态分配，或者按块分配连接对象与缓冲区。

5. 程序完整执行流程

5.1 初始化 epoll

代码中：

epfd = epoll_create(1);

参数在现代 Linux 中只要大于 0 即可，并不表示只能监听一个 fd。更推荐：

epfd = epoll_create1(EPOLL_CLOEXEC);

创建失败时必须检查返回值。

5.2 创建 20 个监听 socket

for (i = 0; i < MAX_PORTS; i++) {
 int sockfd = init_server(port + i);
 ...
}

程序监听 2000~2019 共 20 个端口。每个监听 fd 都注册 EPOLLIN，并对应 accept_cb()。

监听 fd 上的 EPOLLIN 不是普通业务数据可读，而是表示全连接队列中存在已经完成握手、可以由 accept() 取出的连接。

5.3 接受新连接

accept_cb() 的逻辑是：

调用 accept()，获得 clientfd。
检查 clientfd < 0。
初始化 conn_list[clientfd]。
给客户端 fd 注册 EPOLLIN。

这时事件映射从：

listenfd + EPOLLIN → accept_cb

变成新连接上的：

clientfd + EPOLLIN → recv_cb

5.4 接收数据

当客户端 fd 可读时执行 recv_cb()：

count = recv(fd, conn_list[fd].rbuffer, BUFFER_LENGTH, 0);

当前 Echo 逻辑把收到的数据复制到写缓冲区：

conn_list[fd].wlength = conn_list[fd].rlength;
memcpy(conn_list[fd].wbuffer,
 conn_list[fd].rbuffer,
 conn_list[fd].wlength);

随后把关注事件修改为 EPOLLOUT：

clientfd + EPOLLOUT → send_cb

5.5 发送数据

当 fd 可写时执行 send_cb()。数据发送结束后，再把关注事件切换回 EPOLLIN，等待客户端下一次发送。

完整状态流转如下：

监听 EPOLLIN
 ↓
accept_cb：建立 clientfd
 ↓
客户端 EPOLLIN
 ↓
recv_cb：接收并准备响应
 ↓
客户端 EPOLLOUT
 ↓
send_cb：发送响应
 ↓
重新监听客户端 EPOLLIN

6. `set_event()` 与事件注册

int set_event(int fd, int event, int flag)

当前约定：

flag == 1：使用 EPOLL_CTL_ADD。
flag == 0：使用 EPOLL_CTL_MOD。

功能上可行，但 flag 的含义不直观。更清晰的设计是直接传入 EPOLL_CTL_ADD、EPOLL_CTL_MOD，或者分别封装成 add_event() 和 mod_event()。

同时必须检查 epoll_ctl() 的返回值。例如：

if (epoll_ctl(epfd, op, fd, &ev) == -1) {
 perror("epoll_ctl");
 return -1;
}

set_event() 和 event_rigister() 声明为返回 int，但成功路径没有 return，这属于未定义行为。应补充 return 0。另外，rigister 应改为 register。

7. 主事件循环

while (1) {
 int nready = epoll_wait(epfd, events, 1024, -1);

 for (i = 0; i < nready; i++) {
 int connfd = events[i].data.fd;

 if (events[i].events & EPOLLIN)
 conn_list[connfd].r_action.recv_callback(connfd);

 if (events[i].events & EPOLLOUT)
 conn_list[connfd].send_callback(connfd);
 }
}

timeout == -1 表示没有事件时一直阻塞，避免空转消耗 CPU。

两个独立的 `if` 还是 `if ... else if`？

两个独立 if 理论上允许同一次返回同时处理读、写事件；else if 每轮只处理其中一种。

但不能简单认为两个 if 一定更好。若读回调发现连接已经断开并关闭了 fd，随后继续执行写回调就可能访问已经失效或被复用的 fd。稳妥做法是：

先处理 EPOLLERR、EPOLLHUP、EPOLLRDHUP。
回调返回关闭状态后，不再处理该 fd 的其他事件。
再依据连接状态处理读写事件。

8. 课堂代码补充

这份代码主要是为了演示 Reactor 的整体流程，所以有些细节课堂上只是带了一下。自己再写一遍时，可以顺手补上下面这些地方。

关于 send()

课上代码里有一句：

int count = send(fd, conn_list[fd].wbuffer, count, 0);

这里最后的 count 还没有赋值，应该写成 conn_list[fd].wlength。

另外，一次 send() 不一定能把 wlength 个字节全部发完。可以在连接对象里再记一个 woffset，每次发送后往后移动。数据还没发完就继续等 EPOLLOUT，全部发完后再切回 EPOLLIN。

关于 recv()

记住三个返回值：

大于 0：本次收到的字节数；
等于 0：对端关闭连接；
小于 0：要结合 errno 判断，非阻塞情况下可能只是暂时没有数据。

不能让 -1 继续参与后面的 memcpy()，否则长度转换后可能越界。EINTR 可以重试，EAGAIN/EWOULDBLOCK 表示这次先读到这里，其他情况再按真正的错误处理。

还有一点：recv() 收到的是一段字节，不会自动在末尾补 \0。要用 %s 打印时需要自己留位置并补结束符；如果处理二进制数据，就一直按长度来处理。

关于非阻塞

Reactor 一般要和非阻塞 socket 配合。监听 fd 和客户端 fd 都可以设置成 O_NONBLOCK，避免某一次 accept()、recv() 或 send() 卡住整个事件循环。

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_NONBLOCK);

如果以后从 LT 改成 ET，accept() 和 recv() 通常都要放在循环里，一直处理到返回 EAGAIN/EWOULDBLOCK。当前是 LT，一次只 accept() 一个连接也能继续触发，不过连接集中到来时，循环取完会更快一些。

关于 fd 和连接状态

当前写法直接用 fd 作为 conn_list 的下标，使用前要判断：

if (fd < 0 || fd >= CONNECTION_SIZE)
 return -1;

连接关闭时也不只是 close(fd)，对应的读写长度、偏移量和回调最好一起清空。因为 fd 的数字会被复用，下一个新连接有可能再次拿到同一个编号。

fd 也不能当作累计连接数。想每建立 1000 个连接打印一次，应该另外维护一个 accepted_count，不能用 clientfd % 1000 来判断。

其他随手记下的点

socket()、bind()、listen()、epoll_ctl()、epoll_wait() 等系统调用都要看返回值；
监听 socket 通常会设置 SO_REUSEADDR；
listen(sockfd, 10) 中的 10 是 backlog，不是服务器最多只能保持 10 条连接；
主循环除了 EPOLLIN、EPOLLOUT，还要留意 EPOLLERR、EPOLLHUP 和 EPOLLRDHUP；
对端关闭后继续发送可能触发 SIGPIPE，可以忽略该信号，或在 send() 时使用 MSG_NOSIGNAL；
TIME_SUB_MS(current, begin) 当前记录的是两次打印之间的间隔，不是从程序启动开始的总耗时。

9. 大包、拆包与粘包

代码中的读缓冲区只有 1024 字节。若客户端发送 2048 字节，一次 recv() 可能只收到其中一部分；即使缓冲区足够大，TCP 也不保证一次接收对应一次发送。

因此不能把：

一次 send = 一个业务消息 = 一次 recv

当成可靠规律。

业务协议需要定义消息边界，常见方法有：

固定长度消息。
特殊分隔符，例如文本协议中的换行。
消息头携带正文长度，例如“4 字节长度 + 消息体”。
HTTP 中使用请求行、首部、Content-Length 或分块传输规则。

Reactor 收到数据后应先追加到该连接自己的缓冲区，再交给协议解析器：

recv → 追加到连接缓冲区 → 判断是否形成完整消息
 → 未完整：保留并等待下次 EPOLLIN
 → 已完整：取出消息并处理，剩余数据继续保留

如果固定数组空间不足，可以使用动态缓冲区、环形缓冲区或链式缓冲区。

10. 为什么会出现 `Too many open files`

报错对应 errno == EMFILE（常见值为 24），表示当前进程已经达到可打开 fd 的上限。

一条 TCP 连接在客户端和服务端各自都占用一个 fd。百万连接测试至少要同时考虑：

10.1 进程级限制

查看当前 shell 的限制：

ulimit -n
ulimit -a

临时提高当前 shell 的 soft limit：

ulimit -n 1048576

程序必须从修改后的 shell 中启动，才能继承该限制。还要确保 hard limit 足够高。

10.2 系统级限制

cat /proc/sys/fs/file-max
cat /proc/sys/fs/file-nr

fs.file-max 是系统范围的文件句柄限制，ulimit -n 是单进程/会话限制，两者不是同一个概念。持久化设置还取决于系统的 PAM、systemd unit 和发行版配置，不能只改一个参数就假定生效。

10.3 程序自身限制

CONNECTION_SIZE 是否覆盖可能出现的 fd 值；
进程虚拟内存和实际物理内存是否足够；
每连接缓冲区是否过大；
是否存在 fd 泄漏；
epoll 实例和监听 socket 自己也会占 fd。

11. 为什么单个目标端口大约只能建立数万连接

一条 TCP 连接由五元组唯一标识：

源 IP、源端口、目的 IP、目的端口、传输层协议

在单台压测客户端连接单台服务器的单个端口时：

源 IP 固定；
目的 IP 固定；
目的端口固定；
协议固定为 TCP；
主要只能变化源端口。

当可用临时源端口耗尽时，客户端可能报：

Cannot assign requested address

11.1 一个需要校正的细节

客户端临时端口范围并非固定为 1024~65535。Linux 实际自动分配范围应通过下面的命令查看：

sysctl net.ipv4.ip_local_port_range

不同系统、不同配置的范围可能不同，部分端口还可能被占用、保留，或暂时处于 TIME_WAIT 等状态。因此可建立数量通常小于理论上的 65535。

11.2 为什么增加到 20 个服务端端口有效

将目标端口从一个增加到 2000~2019，改变了五元组中的“目的端口”。只要客户端把连接分散到这些端口，同一个源端口就可以与不同目的端口组成不同连接，理论连接空间随之扩大。

其他扩展方式还包括：

使用多个客户端源 IP；
使用多台压测机；
使用多个服务端 IP；
使用多个网络命名空间，但必须正确配置各自地址和路由。

不能仅用单台客户端的结果直接代表服务端的最大承载能力，因为压测端本身可能先耗尽端口、fd、CPU、内存或 conntrack 容量。

12. `nf_conntrack` 应该怎样理解

nf_conntrack 是 Linux Netfilter 的连接跟踪机制，防火墙、NAT 等功能会用到它。它不是 epoll 工作所必需的组成部分。

如果测试路径启用了连接跟踪，并且连接数达到表容量，才需要观察：

sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

旧资料中的 ip_conntrack 是较早的名称；现代内核通常使用 nf_conntrack。只有确实需要且模块尚未加载时，才考虑：

sudo modprobe nf_conntrack

不应看到连接问题就盲目加载模块或增大参数。应先确认机器是否启用了防火墙/NAT、模块是否存在、表是否真的已满。在服务端还是客户端调整，取决于哪台机器实际承担连接跟踪；中间的 NAT/防火墙设备也可能成为瓶颈。

13. 百万连接断开时为什么 CPU 会突然升高

如果一次性终止百万连接的一端，另一端会在短时间内集中处理大量 TCP 状态变化与关闭事件，例如 FIN/RST、epoll 唤醒、连接对象清理、定时器更新等。

这会形成“惊群式的业务处理洪峰”或资源回收洪峰，表现为 CPU 短时暴增。它不一定表示程序死循环，而可能是系统在集中处理积压事件。

优化方向包括：

分批建立和分批关闭连接；
减少关闭路径上的日志和同步操作；
将耗时清理异步化；
使用高效定时器结构，如时间轮；
避免每连接大量内存分配和释放；
做好背压和过载保护；
使用多 Reactor、多线程或多进程分摊事件处理；
用火焰图、perf、系统指标确认 CPU 真正消耗在哪里。

优化目标不是保证 CPU 永不升高，而是让峰值可控、持续时间缩短，并保证服务仍能继续响应。

14. “百万并发”不等于“百万 QPS”

性能测试至少要区分四个维度：

指标	含义
并发连接数	同一时刻保持的连接数量
QPS/吞吐量	单位时间完成的请求或消息数量
延迟	一次请求从发出到收到响应所需时间，通常关注 P50/P95/P99
测试用例	报文大小、收发频率、连接是否长连、业务是否计算或访问存储

保持 100 万条空闲 TCP 连接，和让 100 万条连接持续高速收发数据，是完全不同的负载。前者更考验 fd、内存和内核连接管理；后者还会迅速消耗 CPU、网络带宽、内存带宽以及业务依赖资源。

因此，一份可信的测试报告至少应说明：

客户端和服务端硬件配置；
内核和发行版版本；
所有相关内核参数与 fd 限制；
连接建立速率；
活跃连接与空闲连接比例；
请求/响应大小和频率；
QPS、吞吐量、错误率和延迟分位数；
CPU、内存、网络、fd、conntrack 使用率；
测试持续时间和连接关闭方式。

15. 本节课一句话总结

Reactor 的本质不是“用了 epoll 就很快”，而是把每个 fd 的状态独立保存起来，由事件循环将 I/O + event 精确分发给相应 callback；百万连接则是在这个正确模型之上，再共同解决 fd、内存、端口空间、内核网络栈和压测方法等系统性限制。