Linux 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 用户态协议栈设计与实现

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

学习目标：理解网卡、网卡驱动、TCP/IP 协议栈、POSIX Socket API 与应用程序之间的关系；搭建 DPDK 环境；使用 DPDK 收取以太网帧；逐步解析 Ethernet、IPv4、UDP、TCP；最终理解用户态协议栈需要补齐哪些能力。

一、先建立完整的网络数据路径

可以把网络程序拆成五个逻辑模块：

1. 网卡 NIC
 ↕
2. 网卡驱动 Driver
 ↕
3. TCP/IP 协议栈
 ↕
4. POSIX Socket API：socket / bind / listen / accept / recv / send
 ↕
5. Application：Redis / Nginx / 自己编写的服务器

接收数据时，数据总体从左向右、从上向下流动；发送数据时方向相反。

不过，必须区分下面两条不同的数据路径。

1. Linux 内核协议栈路径

物理网络
 → 网卡
 → Linux 内核网卡驱动
 → sk_buff
 → 内核 Ethernet/IP/TCP/UDP 协议栈
 → Socket 接收缓冲区
 → recv()/read()
 → 应用程序

应用程序使用的是 Linux 已经实现好的协议栈。Redis、Nginx 默认走的就是这条路径。

2. DPDK 用户态路径

物理网络
 → 网卡
 → VFIO/UIO + DPDK PMD 用户态驱动
 → RX Descriptor Ring
 → rte_mbuf
 → 自己实现或引入的用户态协议栈
 → 自己实现的 Socket/POSIX 兼容层
 → 应用程序

网卡绑定给 DPDK 使用的驱动后，该端口的普通数据收发路径通常绕过 Linux 内核网卡驱动和内核 TCP/IP 协议栈。DPDK 负责高速收发原始数据包，但 DPDK 本身不是 TCP/IP 协议栈。

重要纠错：不能把 DPDK 主路径理解成“网卡 → DPDK → 内核驱动 → 内核 TCP/IP”。正常的 DPDK 用户态收包路径绕过内核协议栈。只有主动使用 KNI、TAP、virtio-user 等机制时，才会把选定的数据包重新送入内核。

二、网卡是什么

1. 网卡的基本职责

网卡（NIC，Network Interface Card）连接计算机和网络介质，主要完成：

接收和发送物理信号；
完成物理层编码、解码、时钟恢复等工作；
识别和生成以太网帧；
校验帧的 FCS；
按配置进行 MAC 地址过滤、VLAN 处理；
通过 DMA 在网卡和主机内存之间搬运数据；
一些网卡还能完成 checksum、TSO、LRO、RSS 等硬件卸载。

“网卡把模拟信号通过 AD/DA 转换为 0 和 1”可以帮助入门理解，但并不完全准确。现代以太网 PHY 会进行复杂的线路编码、调制、均衡和信号恢复，不能简单等同于普通 ADC/DAC。

2. 网卡属于哪一层

网卡不是完全独立于分层模型之外。通常可以这样理解：

PHY 部分主要工作在物理层；
MAC 部分主要工作在数据链路层；
checksum、TSO、RSS 等卸载能力会辅助更高层处理。

因此，说网卡“主要横跨物理层和数据链路层”更准确。

3. DMA：网卡如何把数据交给内存

网卡不会要求 CPU 一个字节一个字节地读取数据。典型过程如下：

驱动在内存中准备一组 RX 描述符和数据缓冲区；
驱动把这些内存地址告诉网卡；
网卡收到数据后，通过 DMA 直接把数据写入内存缓冲区；
网卡更新 RX 描述符，标记该数据包已经完成；
CPU 再处理描述符所指向的数据。

这里的 RX 描述符通常按环形结构组织，所以常称为 RX Ring 或 Descriptor Ring。

三、网卡驱动做什么

网卡驱动是操作系统或 DPDK 与具体网卡硬件之间的适配层。它通常负责：

根据 PCI Vendor ID / Device ID 识别硬件；
初始化网卡寄存器；
配置 MAC、MTU、收发队列和硬件卸载；
分配 RX/TX Descriptor Ring；
建立 DMA 映射；
启停网卡；
处理链路状态和错误；
在中断模式或轮询模式下回收、提交数据包。

Linux 内核中有统一的网络设备框架，e1000、ixgbe、i40e、mlx5、vmxnet3 等具体驱动在这个框架下实现。DPDK 则提供 PMD（Poll Mode Driver），让用户态程序通过轮询直接与网卡队列交互。

1. 中断模式与轮询模式

传统内核路径通常结合中断和 NAPI 轮询：

流量较低时，网卡通过中断通知 CPU；
流量较高时，NAPI 暂时关闭频繁中断，改用批量轮询；
这样可以避免“中断风暴”。

DPDK 的典型方式是 Poll Mode：

rte_eth_rx_burst(port_id, queue_id, mbufs, BURST_SIZE);

线程不断轮询指定的端口和队列，避免中断、调度和上下文切换开销。代价是即使没有数据，轮询线程也可能持续占用一个 CPU 核。

2. 多队列网卡

多队列网卡拥有多个 RX/TX 队列。其价值在于：

不同队列可以由不同 CPU 核或线程独立处理；
减少多个核心竞争同一个队列锁；
利用 RSS 把不同网络流分散到多个 RX 队列；
提升并行处理能力和总体吞吐量。

常见绑定关系是：

RX Queue 0 → lcore 1
RX Queue 1 → lcore 2
RX Queue 2 → lcore 3
RX Queue 3 → lcore 4

RSS 通常根据源/目的 IP、源/目的端口、协议号计算哈希，将同一个流稳定地送到同一队列，避免同一 TCP 流的数据包在多个核心间乱序处理。

重要纠错：多队列能显著提高并行性，但“不是多队列网卡就一定无法绑定 DPDK”并不准确。单队列设备也可能被支持，只是扩展能力差。能否绑定和运行取决于设备、PMD、IOMMU、VFIO/UIO 以及虚拟化环境等条件。

3. 虚拟机中的 vmxnet3

VMware 中可以在 .vmx 文件中指定：

ethernet0.virtualDev = "vmxnet3"
ethernet0.wakeOnPcktRcv = "TRUE"

vmxnet3 是 VMware 的半虚拟化高性能网卡，通常比模拟的 e1000 拥有更好的性能和多队列能力。修改配置前应关闭虚拟机，并确认实际使用的 ethernet0、ethernet1 与目标 MAC 地址相匹配。

四、sk_buff、rte_mbuf 与 Ring

1. Linux 的 sk_buff

Linux 内核用 struct sk_buff 描述网络包。它不是简单地把所有协议头复制一遍，而是保存：

数据缓冲区的位置；
当前数据起点和末尾；
MAC、网络层和传输层头的位置；
数据包长度；
所属设备；
checksum、VLAN、路由等元数据；
链表等组织信息。

协议层之间传递的通常是 sk_buff 指针。各层通过移动或记录头部位置来解析数据，而不是每经过一层就复制整个包。

2. 海量 sk_buff 如何组织

“每包一个 sk_buff，海量包如何组织”不能只用一种数据结构回答。不同阶段使用不同结构：

网卡收发描述符：环形队列 Ring；
NAPI 待处理对象：调度列表；
Socket 接收队列：链表/队列形式的 skb queue；
TCP 乱序数据：红黑树等结构；
TCP 重传数据：按发送顺序管理的队列/树；
内存对象分配：slab/slub 缓存。

所以，常用答案是“以 Ring 和各种队列为主，根据查找、排序、重传等需求再使用树结构”。

3. DPDK 的 rte_mbuf

rte_mbuf 与 sk_buff 的定位相似：都用来描述一个数据包及其元数据。DPDK 通常从预先创建的 mempool 中分配 mbuf，以减少频繁动态分配的开销。

mempool
 ├── rte_mbuf + data buffer
 ├── rte_mbuf + data buffer
 ├── rte_mbuf + data buffer
 └── ...

网卡通过 DMA 把数据写入 mbuf 对应的数据缓冲区。rte_eth_rx_burst() 返回的是已经装有数据的 mbuf 指针数组，因此 CPU 不需要再把整个数据包从内核复制到用户态。

这通常称为零拷贝或少拷贝设计，但严格来说仍然可能发生 DMA、缓存行传输、跨 NUMA 访问以及应用层复制，不能把“零拷贝”理解成整个系统完全没有任何数据移动。

五、协议栈是什么

协议栈是一组按层协作的协议实现。接收一个 UDP/IPv4 以太网帧时，可依次解析：

Ethernet Header
 → IPv4 Header
 → UDP Header
 → Application Payload

接收 TCP 时则是：

Ethernet Header
 → IPv4 Header
 → TCP Header
 → TCP Segment Payload

解析协议头只是用户态协议栈的第一步。一个真正可用的协议栈还需要实现 ARP、路由、校验和、分片重组、TCP 状态机、重传、拥塞控制、Socket 缓冲区等功能。

六、以太网帧解析

不考虑 VLAN 标签时，Ethernet II 头部固定为 14 字节：

0 5 6 11 12 13
+----------------+----------------+--------+
| 目的 MAC 6字节 | 源 MAC 6字节 | 类型 2 |
+----------------+----------------+--------+

常见 EtherType：

0x0800：IPv4；
0x0806：ARP；
0x86DD：IPv6；
0x8100：802.1Q VLAN。

DPDK 中对应：

struct rte_ether_hdr *ethhdr =
 rte_pktmbuf_mtod(mbufs[i], struct rte_ether_hdr *);

rte_pktmbuf_mtod() 的作用是把 mbuf 中的数据起始地址转换成指定类型的指针。它并没有复制以太网头，只是在同一段内存上按 struct rte_ether_hdr 的布局解释字节。

判断是否为 IPv4：

if (ethhdr->ether_type != rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)) {
 continue;
}

网络协议字段通常采用大端字节序，所以要进行主机字节序与网络字节序转换。

VLAN 注意事项

代码直接把以太网头后的数据当作 IPv4，只适用于没有 VLAN 标签的帧。若 EtherType 为 0x8100，还要解析 4 字节 VLAN Header，然后才能找到真正的上层 EtherType。

七、IPv4 解析

IPv4 基础头部最少 20 字节，结构包括：

+---------+---------+-------------------+
|Version | IHL | DSCP/ECN | Length |
+---------+---------+-------------------+
| Identification | Flags/Fragment Offset|
+---------------------------------------+
| TTL | Protocol | Header Checksum |
+---------------------------------------+
| Source IPv4 Address |
+---------------------------------------+
| Destination IPv4 Address |
+---------------------------------------+
| Options（可选，IHL > 5 时存在） |
+---------------------------------------+

关键字段：

Version：IPv4 时为 4；
IHL：头部长度，以 4 字节为单位；最小值为 5，即 20 字节；
Total Length：整个 IPv4 数据报长度；
Fragment Offset / Flags：分片相关；
TTL：每经过一个路由器通常减 1；
Protocol：上层协议，UDP=17，TCP=6，ICMP=1；
Header Checksum：只校验 IPv4 头；
Source/Destination Address：源和目的 IPv4 地址。

原代码通过固定的 14 字节 Ethernet Header 偏移找到 IPv4 头：

struct rte_ipv4_hdr *iphdr = rte_pktmbuf_mtod_offset(
 mbufs[i], struct rte_ipv4_hdr *, sizeof(struct rte_ether_hdr));

判断 UDP：

if (iphdr->next_proto_id == IPPROTO_UDP) {

IPv4 解析必须检查的内容

健壮的实现至少应检查：

mbuf 中是否有完整的 Ethernet 和 IPv4 基础头；
IPv4 Version 是否为 4；
IHL 是否至少为 5；
包长度是否覆盖 IHL * 4；
Total Length 是否合理；
IPv4 Header Checksum 是否正确，或确认硬件已校验；
是否为分片；
再根据 Protocol 分发给 ICMP、UDP 或 TCP。

原代码使用 (iphdr + 1) 寻找 UDP 头，相当于默认 IPv4 头固定为 20 字节。若 IPv4 带 Options，IHL 会大于 5，UDP 头的真实起点应为 IP Header 起点 + IHL * 4。

八、UDP 解析

UDP 头固定为 8 字节：

+-------------------+-------------------+
| Source Port | Destination Port |
+-------------------+-------------------+
| UDP Length | UDP Checksum |
+-------------------+-------------------+
| Payload ... |
+---------------------------------------+

关键字段：

Source Port：源端口；
Destination Port：目的端口；
Length：UDP 头加 Payload 的总长度，最小为 8；
Checksum：覆盖伪首部、UDP 头和 UDP 数据。

原代码：

struct rte_udp_hdr *udphdr = (struct rte_udp_hdr *)(iphdr + 1);
printf("udp:%s\n ", (char *)(udphdr + 1));

第一行把 IPv4 基础头后的地址解释为 UDP Header；第二行把 UDP Header 后的数据解释为 C 字符串并打印。

为什么 `%s` 只适合当前演示

网络 Payload 不保证以 \0 结尾，而 %s 会持续读取，直到遇到 \0。因此实际代码必须：

根据 UDP Length 计算 Payload 长度；
确认长度没有超过 mbuf/IPv4 数据长度；
使用带长度的输出方式，例如 %.*s；
对二进制协议应使用十六进制打印，而不是字符串打印。

当前 Packet Sender 发送的是短 ASCII 文本，并且内存后面恰好出现零字节，所以演示中可能正常输出，但这不是安全的通用处理方法。

九、TCP 解析

TCP 头最少为 20 字节，可带 Options，最长可达 60 字节。

+-------------------+-------------------+
| Source Port | Destination Port |
+---------------------------------------+
| Sequence Number |
+---------------------------------------+
| Acknowledgment Number |
+------+----------+---------------------+
|Offset| Flags | Window |
+-----------------+---------------------+
| Checksum | Urgent Pointer |
+---------------------------------------+
| Options（可选） |
+---------------------------------------+
| Payload ... |
+---------------------------------------+

关键字段：

Sequence Number：本段第一个字节的序号；
Acknowledgment Number：期望收到的下一个序号；
Data Offset：TCP Header 长度，以 4 字节为单位；
Flags：SYN、ACK、FIN、RST、PSH、URG 等；
Window：接收窗口，参与流量控制；
Checksum：覆盖 IPv4/IPv6 伪首部、TCP 头和 TCP 数据。

只把 TCP Header 拆出来还不能叫“实现 TCP”。至少还需要：

四元组查找连接：源 IP、源端口、目的 IP、目的端口；
TCP 状态机；
三次握手和四次挥手；
序列号和 ACK；
乱序重组；
超时重传；
RTT/RTO 估计；
滑动窗口和流量控制；
拥塞控制；
TIME_WAIT 等定时器管理。

TCP 状态机简图

服务器：CLOSED → LISTEN → SYN_RECEIVED → ESTABLISHED
客户端：CLOSED → SYN_SENT → ESTABLISHED

主动关闭的一方：ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED
被动关闭的一方：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

十、POSIX Socket API 与用户态协议栈

POSIX API 是应用程序看到的接口：

socket()：创建 Socket；
bind()：绑定本地 IP 和端口；
listen()：把 TCP Socket 设为监听状态；
accept()：取出一个已经建立的 TCP 连接；
connect()：主动发起 TCP 连接；
recv()/read()：读取接收数据；
send()/write()：发送数据；
close()：关闭 Socket。

1. 内核中的关系

在 Linux 内核协议栈中，文件描述符 fd 会关联到内核 Socket 对象。TCP 连接还对应一个传输控制块，可广义称为 TCB，其中保存：

四元组；
TCP 状态；
序列号；
收发窗口；
重传队列；
接收队列；
定时器等。

recv(fd, ...) 不是简单地“直接读取 TCB 某个位置”，而是通过 fd 找到 Socket，再从该 Socket 的接收缓冲区读取已经按序整理好的字节。如果没有数据，调用可能阻塞，或者在非阻塞模式下返回 EAGAIN。

2. 用户态协议栈怎样提供 POSIX API

如果应用完全绕过内核协议栈，Linux 原生 recv() 不会自动读取 DPDK mbuf。需要增加适配层，常见方法包括：

修改应用，让它调用用户态协议栈自己的 API；
使用库替换或 LD_PRELOAD 截获 Socket 调用；
提供兼容 POSIX 的用户态 Socket 库；
通过事件通知机制实现类似 epoll 的接口。

用户态需要自己维护：

fd/table
 → socket object
 → UDP endpoint 或 TCP TCB
 → receive queue / send queue

对于 UDP，recvfrom() 通常从对应端口的报文队列取出一个 Datagram；对于 TCP，recv() 从已经重排并确认连续的字节流中读取数据。

十一、DPDK 是什么，以及为什么快

DPDK（Data Plane Development Kit）是一组用于高速数据包处理的库、驱动和工具。它的核心思想包括：

用户态 PMD 轮询网卡；
批量收发 Burst；
预分配 mempool/mbuf；
Hugepage；
CPU 亲和性和独占核心；
NUMA 感知；
无锁 Ring；
硬件多队列与 RSS；
Prefetch 和缓存友好布局；
减少中断、系统调用、上下文切换和数据复制。

DPDK 优化的核心指标

DPDK 不只是“处理大包、提高吞吐量”。更准确地说，它常用于提高：

每秒处理的数据包数 PPS，尤其是大量小包；
总吞吐量；
延迟的可预测性和尾延迟；
多核心扩展能力。

是否能提升 Redis/Nginx 性能，取决于瓶颈：

如果瓶颈在业务逻辑、锁、存储或单线程执行，只有 DPDK 不会神奇地提高 QPS；
如果瓶颈在内核网络路径、软中断、系统调用或数据复制，用户态网络方案可能改善 QPS 或延迟；
把现有 Redis/Nginx 接到 DPDK 上需要完整协议栈和兼容层，并非简单绑定网卡即可。

常见使用场景

防火墙、ACL、DPI；
路由器、交换机、网关；
负载均衡器；
5G/电信数据面；
虚拟交换机；
流媒体或报文转发；
流量采集与监控；
高性能存储网络的数据面。

数据备份和 RDMA 可能使用类似的大页、DMA、零拷贝、用户态驱动思想，但 DPDK 与 RDMA 是不同的技术体系，不能简单说“底层一定用 DPDK，应用层用 RDMA”。

可研究的用户态协议栈/数据面项目包括 mTCP、lwIP、F-Stack、VPP、Seastar networking、基于 BSD 协议栈移植的实现等。项目是否仍活跃、DPDK 版本是否兼容，需要按实际版本确认。

十二、VFIO、UIO、PCI、KNI 与 NUMA

1. PCI 地址

网卡通常是 PCIe 设备。可以使用：

lspci
lspci -nn
lspci -k

PCI 地址形如：

0000:1a:00.0

含义是：

domain:bus:device.function

2. VFIO 与 UIO

它们帮助用户态程序访问 PCI 设备资源：

UIO：较简单的通用用户态 I/O 框架；
VFIO：通常配合 IOMMU，隔离性和安全性更好，现代环境一般优先使用；
DPDK PMD：真正理解并操作具体网卡寄存器和队列的用户态驱动。

不能简单理解为 VFIO/UIO“截获 PCI 地址”；更准确地说，它们把设备资源安全地映射或暴露给用户态驱动，并管理中断、DMA/IOMMU 等能力。

3. KNI

KNI 曾用于在 DPDK 应用与 Linux 内核网络栈之间交换数据包。例如，把控制面流量送回内核处理。但它不是 DPDK 收包必须经过的组件，而且在较新的 DPDK 方案中通常会考虑 TAP、virtio-user 等替代路径。

4. NUMA

NUMA 是 Non-Uniform Memory Access，即非一致内存访问。多路 CPU 服务器中，每个 CPU Socket 通常拥有本地内存：

CPU Socket 0 ↔ Local Memory 0
CPU Socket 1 ↔ Local Memory 1

CPU 访问本地内存比跨 Socket 访问远端内存更快。因此应尽量做到：

网卡所在 NUMA Node；
轮询该网卡的 CPU 核；
mbuf mempool 所在内存；

三者位于同一个 NUMA Node。

代码中的 rte_eth_dev_socket_id() 用于查询设备所在 NUMA Socket，rte_socket_id() 返回当前 lcore 所在 Socket。二者不一定总是相同。

十三、Hugepage 大页

普通页通常为 4 KiB。Hugepage 常见规格为：

2 MiB；
1 GiB。

DPDK 使用大页主要是为了：

减少页表项数量；
降低 TLB Miss；
便于大块、稳定、可用于 DMA 的内存管理；
减少运行时内存分配的不确定性。

1. 示例 GRUB 配置

GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=2M hugepagesz=2M hugepages=1024"

这表示默认大页为 2 MiB，共预留 1024 页，即约 2 GiB 内存。虚拟机内存有限时，需要根据虚拟机总内存调整，不能机械照抄。

通常修改后还需要更新 GRUB 并重启，例如 Ubuntu/Debian：

sudo update-grub
sudo reboot

重启后验证：

grep -i huge /proc/meminfo

具体命令因发行版和 DPDK 版本而异。现代 DPDK 可能自动处理 hugetlbfs，也可以手动挂载。1 GiB 大页还依赖 CPU 支持，并通常需要在启动参数中预留。

2. Hugepage 不直接提升网卡物理转换速度

Hugepage 优化的是主机内存管理、TLB 和 DMA 缓冲区访问，并不会让网卡的光电信号转换本身更快。它提升的是数据包在 CPU/内存数据面中的处理效率和稳定性。

十四、VMware 三种网络模式

1. Bridged（桥接）

虚拟机像局域网中的独立主机：

物理局域网
 ├── Windows/macOS 宿主机：172.26.185.5
 └── 虚拟机：172.26.185.250

虚拟机通常与宿主机处于同一二层网络，可从局域网 DHCP 获取地址，或配置同网段静态地址。桥接绑定到某个宿主机物理接口时，该接口断开可能影响虚拟机网络。

“复制物理网络连接状态”之类的选项，通常让虚拟网卡随宿主机物理接口的连接/断开状态变化，适合笔记本在 Wi-Fi、有线网络之间切换的场景。不同 VMware 产品中的名称和细节会略有不同。

2. NAT

VMware 在宿主机上创建虚拟子网，虚拟机通过宿主机做 NAT 访问外网：

虚拟机 → VMware 虚拟网关/NAT → 宿主机 → 外网

外部设备通常不能直接主动访问虚拟机，除非做端口映射或额外配置。

3. Host-only（仅主机）

虚拟机主要与宿主机及同一 Host-only 网络中的虚拟机通信，默认不能直接访问外网。它适合隔离实验环境。

“Host-only 一定可以 ping 通公网”是不对的；默认情况下它不能上网，除非宿主机另行开启路由/NAT。

十五、macOS Packet Sender 测试链路

已知 DPDK 端口信息：

MAC：00:0c:29:aa:5b:f0
PCI：0000:1a:00.0
PMD：net_vmxnet3
Link：up

宿主机：

IP：172.26.185.5
Mask：255.255.0.0
Interface：en0

ustack 测试地址：

172.26.185.250

1. 为什么需要静态 ARP

应用把 UDP 发往 172.26.185.250:8888 时，操作系统需要构造以太网帧。因为目标 IP 在同一子网，macOS 必须知道目标 IP 对应的 MAC 地址。

正常情况是：

macOS 广播 ARP Request：谁是 172.26.185.250？
ustack 单播 ARP Reply：172.26.185.250 是 00:0c:29:aa:5b:f0

当前 ustack 没有实现 ARP Reply，所以手工建立：

sudo arp -s 172.26.185.250 00:0c:29:aa:5b:f0
sudo arp -s 172.26.185.250 00:0c:29:aa:5b:f0 ifscope en0

验证：

arp -n 172.26.185.250

2. Packet Sender 配置

Address：172.26.185.250
Port：8888
Protocol：UDP
ASCII：hello dpdk

完整路径：

Packet Sender
 → macOS UDP/IP 处理
 → 静态 ARP 表查到目标 MAC
 → macOS en0
 → VMware Fusion 桥接
 → vmxnet3 虚拟网卡
 → DPDK port 0 / RX queue 0
 → rte_eth_rx_burst()
 → Ethernet / IPv4 / UDP 解析
 → 打印 hello dpdk

看到：

udp:hello dpdk

说明至少以下环节已经连通：

macOS 到 Fusion 桥接网络；
目标 MAC 投递；
vmxnet3 链路；
DPDK 端口初始化；
RX Queue 0 收包；
当前测试报文的 Ethernet/IPv4/UDP 基础解析。

但它还不能单独证明 checksum、分片、VLAN、IP Options、异常长度处理等已经正确实现。

十六、DPDK 环境搭建思路

老版本 DPDK 常使用 dpdk-setup.sh、RTE_SDK 和 RTE_TARGET。典型含义是：

export RTE_SDK=/home/.../dpdk
export RTE_TARGET=...

RTE_SDK：DPDK 源码/SDK 根目录；
RTE_TARGET：旧版构建系统生成的目标目录名称。

native 一般表示按当前机器架构优化；linuxapp 是旧版目标名称的一部分；具体选项需要以所使用的旧版 DPDK 文档和脚本为准。

现代 DPDK 已主要使用 Meson + Ninja 构建，不再依赖旧式 make config、RTE_TARGET 流程：

meson setup build
ninja -C build

因此必须先确认教程使用的 DPDK 版本。不要把老教程里的菜单选项直接套到新版本。

通用搭建检查表

确认 CPU 架构、Linux 发行版和 DPDK 版本；
确认 vmxnet3/物理网卡被当前 DPDK PMD 支持；
配置 Hugepage；
若使用 VFIO，确认 IOMMU/VFIO 条件；
查看 PCI 地址和当前驱动；
将实验网卡绑定到合适驱动；
保留管理网卡，避免把 SSH 所依赖的唯一网卡绑定走；
用 testpmd 检查端口、队列、Link 和收包计数；
再运行自己的程序。

安全提示：绑定网卡前一定确认 PCI 地址。将正在承载 SSH 或默认路由的网卡绑定给 DPDK，会立即让普通 Linux 网络连接中断。

十七、原始代码（保持不变）

下面代码完全按原内容保留，没有修改：

#include<stdio.h>
#include<rte_eal.h>
#include<rte_ethdev.h>
#include<arpa/inet.h>

int global_portid=0;//网卡绑定id从0开始 发数据和收数据知道id就好
#define NUM_MBUFS 4096
#define BURST_SIZE 128
static const struct rte_eth_conf port_conf_default={
 .rxmode={.max_rx_pkt_len=RTE_ETHER_MAX_LEN}
};
static int ustack_init_port(struct rte_mempool *mbuf_pool){

 uint16_t nb_sys_ports=rte_eth_dev_count_avail();
 if(nb_sys_ports==0){
 rte_exit(EXIT_FAILURE,"No Supported eth found/n");
 } 
 //struct rte_eth_dev_info dev_info;
 //rte_eth_dev_info_get(global_portid，&dev_info);
 //绑定的网卡
 //现在有八个 队列 弄1 2 4 8 
 const int num_rx_queues =1;
 const int num_tx_queues =0;
 rte_eth_dev_configure(global_portid,num_rx_queues,num_tx_queues,&port_conf_default);
 
 if(rte_eth_rx_queue_setup(global_portid,0,128,rte_eth_dev_socket_id(global_portid),NULL,mbuf_pool)<0){
 //在0号网卡的0号队列开辟了RX队列 准备了128个mbuffer
 rte_exit(EXIT_FAILURE," Could not setup RX queue/n"); 
 }

 if (rte_eth_dev_start(global_portid)<0){//启动
 rte_exit(EXIT_FAILURE,"Could not start"); 
 }
 return 0;
}

int main(int argc,char *argv[]){

 if(rte_eal_init(argc,argv)<0){//初始化 检查网卡信息 配置 是否绑定
 rte_exit(EXIT_FAILURE,"Error with EAL init\n");
 }
 struct rte_mempool *mbuf_pool= rte_pktmbuf_pool_create("mbuf pool",NUM_MBUFS,0,0,RTE_MBUF_DEFAULT_BUF_SIZE,rte_socket_id());
 //接收数据放在mbuff
 //mbuffer分配在内存上的 rte_socket_id 就是当前使用哪块内存卡槽ID分配的
 if(mbuf_pool==NULL){
 rte_exit(EXIT_FAILURE,"Could not create mbuf pool\n");
 }

 ustack_init_port(mbuf_pool);

 //接收数据
 while(1){
 struct rte_mbuf *mbufs[BURST_SIZE]={0};
 uint16_t num_recvd= rte_eth_rx_burst(global_portid,0,mbufs,BURST_SIZE);
 if (num_recvd>BURST_SIZE){
 rte_exit(EXIT_FAILURE,"Error receiving from eth\n");
 }

 int i=0;
 for(i=0;i<num_recvd;i++){
 struct rte_ether_hdr *ethhdr=rte_pktmbuf_mtod(mbufs[i],struct rte_ether_hdr *);
 if(ethhdr->ether_type != rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)){
 continue;
 }
 struct rte_ipv4_hdr *iphdr =rte_pktmbuf_mtod_offset(mbufs[i],struct rte_ipv4_hdr *,sizeof(struct rte_ether_hdr));
 if (iphdr->next_proto_id==IPPROTO_UDP){//两个以上都转
 struct rte_udp_hdr *udphdr =(struct rte_udp_hdr *)(iphdr+1);
 printf("udp:%s\n ",(char*)(udphdr+1));
 }
 }

 }
 printf("Hello dpdk\n");


}

十八、代码逐行对照理解

1. 头文件

#include<stdio.h>

引入标准输入输出声明，本程序用它调用 printf()。

#include<rte_eal.h>

引入 DPDK EAL 接口。EAL 是 Environment Abstraction Layer，负责 Hugepage、lcore、内存、PCI 设备等基础环境初始化，也声明了 rte_eal_init()、rte_exit() 等接口。

#include<rte_ethdev.h>

引入以太网设备抽象接口，包括端口配置、RX Queue 设置、设备启动和 Burst 收包。

#include<arpa/inet.h>

提供网络字节序、IP 地址转换等常用声明。当前代码中没有直接调用 htons()、ntohs() 等函数，但 IPPROTO_UDP 等定义可能通过相关系统头可见。实际项目通常还会显式包含 DPDK Ethernet/IP/UDP 头文件，具体取决于 DPDK 版本的包含关系。

2. 全局端口与常量

int global_portid=0;

选择 DPDK 逻辑端口 0。这里的 port id 是 DPDK 枚举后的端口编号，不等于 PCI 地址，也不一定等于 Linux 的 eth0。

#define NUM_MBUFS 4096

准备在 mempool 中创建 4096 个 mbuf。它们不仅供 128 个 RX 描述符使用，还要留给收包后尚未释放、缓存以及其他内部需求。

#define BURST_SIZE 128

每次调用 rte_eth_rx_burst()，最多希望取回 128 个包。实际返回值可以是 0 到 128。

3. 默认端口配置

static const struct rte_eth_conf port_conf_default={
 .rxmode={.max_rx_pkt_len=RTE_ETHER_MAX_LEN}
};

创建端口配置结构，把最大接收包长设为标准以太网最大长度对应的 DPDK 常量。

注意：DPDK 的结构体字段会随版本变化。某些新版本中 max_rx_pkt_len 的位置或用法已变化。如果发生编译错误，应首先对照当前版本 API，而不是认为网络原理有问题。

4. 端口初始化函数

static int ustack_init_port(struct rte_mempool *mbuf_pool){

定义只在本源文件使用的函数，参数是已经创建好的 mbuf 内存池。

uint16_t nb_sys_ports=rte_eth_dev_count_avail();

查询当前 EAL 环境中可用的 DPDK Ethernet 设备数量。nb 是 number 的常用缩写。它不是固定表示“绑定网口数量”，更准确地说是当前可用的 ethdev 数量。

if(nb_sys_ports==0){
 rte_exit(EXIT_FAILURE,"No Supported eth found/n");
}

如果没有设备，打印错误并退出。字符串中的 /n 是普通字符，不是换行符；真正的换行符写法是 \n。本笔记遵守要求，不修改原代码，只指出区别。

//struct rte_eth_dev_info dev_info;
//rte_eth_dev_info_get(global_portid，&dev_info);

这两行被注释，不会执行。设计意图是读取端口能力，比如最大队列数、RSS、offload 能力。第二行参数之间使用了中文逗号 ，，若取消注释需要注意它不能作为 C 语言逗号使用。

const int num_rx_queues =1;
const int num_tx_queues =0;

配置 1 个接收队列、0 个发送队列。此程序只收不发，所以 TX Queue 设为 0。若以后要回复 ARP、UDP 或 TCP，就必须配置 TX Queue。

rte_eth_dev_configure(global_portid,num_rx_queues,num_tx_queues,&port_conf_default);

配置端口的 RX/TX 队列数量和总体参数。函数有返回值，当前代码没有检查；健壮程序应检查是否小于 0。

if(rte_eth_rx_queue_setup(global_portid,0,128,
 rte_eth_dev_socket_id(global_portid),NULL,mbuf_pool)<0){

配置 RX Queue：

global_portid：端口 0；
0：RX Queue 0；
128：描述符数量；
rte_eth_dev_socket_id(...)：在网卡所在 NUMA Socket 分配队列资源；
NULL：使用默认 RX Queue 配置；
mbuf_pool：网卡收到的数据放入这个池提供的 mbuf。

注释“准备了 128 个 mbuffer”是便于理解的近似说法。准确说是请求建立 128 个 RX descriptors；描述符与 mbuf 的补充、占用和回收由 PMD 管理，mempool 总大小仍为 4096。

rte_exit(EXIT_FAILURE," Could not setup RX queue/n");

配置失败就退出。同样，/n 不会产生换行。

if (rte_eth_dev_start(global_portid)<0){
 rte_exit(EXIT_FAILURE,"Could not start");
}

启动端口。配置端口和队列只是准备工作，start 后网卡才进入正式收发状态。

return 0;

表示初始化成功。

5. main 与 EAL 初始化

int main(int argc,char *argv[]){

程序入口。DPDK 会先解析命令行中的 EAL 参数，应用自己的参数通常放在 -- 后面并根据 rte_eal_init() 的返回值调整。

if(rte_eal_init(argc,argv)<0){
 rte_exit(EXIT_FAILURE,"Error with EAL init\n");
}

初始化 DPDK 运行环境，涉及：

解析 EAL 参数；
发现 CPU lcore；
初始化 Hugepage 内存；
初始化内存管理；
探测并初始化设备和总线；
建立主从 lcore 等运行环境。

它不等于“自动保证所有网卡已经正确绑定”。绑定通常要在运行程序之前完成，EAL 负责发现当前可使用的设备。

6. 创建 mbuf pool

struct rte_mempool *mbuf_pool=
 rte_pktmbuf_pool_create("mbuf pool",NUM_MBUFS,0,0,
 RTE_MBUF_DEFAULT_BUF_SIZE,rte_socket_id());

参数逐个理解：

"mbuf pool"：内存池名称；
NUM_MBUFS：4096 个 mbuf；
第一个 0：每个 lcore 的 cache 数量为 0；
第二个 0：每个对象额外私有区域大小为 0；
RTE_MBUF_DEFAULT_BUF_SIZE：每个 mbuf 默认数据缓冲区大小；
rte_socket_id()：在当前运行核心所在 NUMA Socket 分配。

这里 rte_socket_id() 指 NUMA 节点编号，不是物理“内存卡槽 ID”。服务器硬件的 DIMM 插槽和 NUMA Node 不是同一个概念。

if(mbuf_pool==NULL){
 rte_exit(EXIT_FAILURE,"Could not create mbuf pool\n");
}

创建失败立即退出。可能原因包括 Hugepage 不足、名称冲突、socket 内存不够或参数不合法。

ustack_init_port(mbuf_pool);

用刚创建的内存池配置并启动端口。

7. 轮询收包

while(1){

进入无限循环。这是 PMD 轮询模型的核心，线程会持续询问 RX Queue 是否有包。

struct rte_mbuf *mbufs[BURST_SIZE]={0};

创建一个长度为 128 的指针数组。数组保存 rte_mbuf *，并不在栈上创建 128 个完整 mbuf。

uint16_t num_recvd=
 rte_eth_rx_burst(global_portid,0,mbufs,BURST_SIZE);

从端口 0、队列 0 最多取 128 个已经收到的包：

返回 0：当前没有包；
返回 1～128：实际取到的包数；
mbuf 指针写入 mbufs[0 ... num_recvd-1]。

rte_eth_rx_burst() 通常通过检查 RX descriptors 批量完成工作，不是每次都触发系统调用。

if (num_recvd>BURST_SIZE){
 rte_exit(EXIT_FAILURE,"Error receiving from eth\n");
}

按 API 契约，返回值不会大于传入的 BURST_SIZE，所以这个判断正常情况下不会成立。它也不能检测一般收包错误，因为该 API 的返回值语义主要是“本次收到多少包”。

8. 遍历每一个包

int i=0;
for(i=0;i<num_recvd;i++){

依次处理本轮收到的所有 mbuf。

struct rte_ether_hdr *ethhdr=
 rte_pktmbuf_mtod(mbufs[i],struct rte_ether_hdr *);

取得包数据起点，把它解释成 Ethernet Header。

if(ethhdr->ether_type != rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)){
 continue;
}

如果 EtherType 不是 IPv4，就跳过后续解析。ARP、IPv6、VLAN 等都会走 continue。

这里有一个重要的生命周期问题：跳过不等于释放。当前程序没有调用 rte_pktmbuf_free(mbufs[i])，因此收到的 mbuf 不会归还 mempool。运行一段时间后，RX Queue 可能因为拿不到空闲 mbuf 而停止继续收包。

struct rte_ipv4_hdr *iphdr =rte_pktmbuf_mtod_offset(
 mbufs[i],struct rte_ipv4_hdr *,sizeof(struct rte_ether_hdr));

从数据起点向后移动一个 Ethernet Header 的长度，即 14 字节，再把地址解释成 IPv4 Header。

当前代码在解引用前没有检查包的实际长度；遇到截断帧或异常帧时可能越界读取。

if (iphdr->next_proto_id==IPPROTO_UDP){

检查 IPv4 Protocol 字段是否等于 UDP 的协议号 17。

struct rte_udp_hdr *udphdr =(struct rte_udp_hdr *)(iphdr+1);

iphdr + 1 会跳过一个 struct rte_ipv4_hdr，也就是按 20 字节基础 IPv4 头定位 UDP Header。它没有考虑 IHL 大于 5的 IPv4 Options。

printf("udp:%s\n ",(char*)(udphdr+1));

udphdr + 1 跳过 8 字节 UDP Header，将后续 Payload 当作字符串打印。它没有依据 UDP Length 限制读取长度，也没有保证 Payload 以 \0 结尾，因此只适合受控的入门测试。

9. 循环之后的代码

printf("Hello dpdk\n");

由于前面是无限循环，并且没有 break，正常情况下这一行不可达。

十九、今天内容的核心总结

网卡把网络介质上的信号变成帧，并通过 DMA 把数据放入主机内存；它主要涉及物理层和数据链路层。
驱动负责初始化网卡、配置队列和 DMA，并让软件能够操作具体硬件。
Linux 使用 sk_buff 描述数据包；DPDK 使用 rte_mbuf，两者都不只是数据本身，还包含元数据。
多队列让多个 CPU 核并行处理流量，RSS 负责把流分配到不同队列；多队列很重要，但不是所有 DPDK 绑定的绝对前提。
DPDK 用用户态轮询、Burst、Hugepage、mempool、多队列和 NUMA 优化高速包处理。
网卡绑定给 DPDK 后，常规数据路径绕过内核 TCP/IP；因此要么引入现有用户态协议栈，要么自己实现。
Ethernet 普通头为 14 字节，IPv4 最少 20 字节，UDP 固定 8 字节，TCP 最少 20 字节。
“能找到协议头并打印 Payload”只是解析器原型，不等于完整协议栈。
完整 UDP 还需要 ARP、IP、校验和、端口分发、队列和 API；完整 TCP 还需要状态机、序列号、重传、窗口、定时器等。
POSIX recv() 读取的是 Socket 接收缓冲区；用户态协议栈必须自己建立 fd、Socket、TCB 和收发队列之间的关系。
当前测试通过静态 ARP 绕过了尚未实现的 ARP Reply，成功证明了 macOS、Fusion 桥接、vmxnet3、DPDK RX 和基础 UDP 解析链路已打通。
下一步最重要的不是立即写 TCP，而是先补齐 mbuf 释放、长度校验、ARP Reply、TX 和 UDP Echo。

二十、版本说明与官方参考

你的学习材料明显包含旧版 DPDK 构建流程，因此本笔记保留了 dpdk-setup.sh、RTE_SDK、RTE_TARGET 的历史解释，同时把现代版本单独说明。实际执行命令时，必须先运行 dpdk-testpmd -v、查看源码目录中的 release 信息或构建文件，确认本机 DPDK 版本。

DPDK Linux Getting Started Guide：现代 Linux 环境、编译、驱动和运行入口；
DPDK Poll Mode Driver：PMD 绕过传统内核网络栈、直接轮询 RX/TX Descriptor 的官方说明；
DPDK Linux Drivers：VFIO、UIO、设备绑定和安全性说明；
DPDK VMXNET3 PMD：vmxnet3 收发环、多队列/RSS、功能与限制；
DPDK Hugepage Tool：查看、预留和挂载大页；
DPDK 22.11 KNI 文档：KNI 的用途、弃用状态及 virtio-user 替代说明。

协程运行时：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 决定怎样切过去。

POSIX API 与 TCP 连接生命周期

Mon, 10 Aug 2026 00:00:00 +0800

本篇承接已有的《网络IO》《IO 多路复用与 Reactor》《Reactor 与 epoll：百万并发网络服务器课后笔记》。
socket、fd、服务端基础代码、select/poll/epoll 和 Reactor 不再重复；

一、为什么网络代码可以跨 Linux、Unix 和 macOS

Linux 受到 Unix 设计影响，不同厂商和社区又形成了不同发行版。它们的内核、工具和扩展功能可能不同，但应用程序仍然可以使用一组相似的接口：

socket();
bind();
listen();
accept();
connect();
send();
recv();
close();

重要原因是这些系统广泛支持 POSIX 和 BSD Socket 风格的接口规范。

标准接口主要约定：

函数叫什么
函数接收什么参数
返回值如何表达成功和失败
错误通过什么方式报告
应用程序可以依赖哪些行为

不同系统的内核实现可以不同，但只要对应用程序提供兼容接口，使用标准接口编写的代码就比较容易迁移：

应用程序
 ↓
POSIX / Socket API
 ↓
不同操作系统的内核实现

代码可以直接迁移还要求它没有依赖某个系统的专有能力。例如 socket、bind、listen 是通用 Socket API；epoll 是 Linux 专用机制，迁移到 macOS 时通常要换成 kqueue。

二、客户端和服务端使用的 API

2.1 TCP 客户端

课堂中的客户端调用顺序：

socket();
bind();//optional
connect();
send();
recv();
close();

对应作用：

socket() → 创建 socket 和 fd
bind() → 可选，指定本地 IP 和本地端口
connect() → 指定对端并发起 TCP 连接
send() → 把应用数据交给内核
recv() → 从内核取出收到的数据
close() → 关闭 fd，并推动 TCP 关闭过程

客户端通常不主动调用 bind()。如果直接 connect()，内核会选择合适的本地 IP 和临时端口。

临时端口范围由系统配置决定，不固定为 1024～65535。Linux 上可以查看：

cat /proc/sys/net/ipv4/ip_local_port_range

客户端需要固定源 IP 或源端口时，才会在 connect() 前显式调用 bind()。

2.2 TCP 服务端

课堂中的服务端调用顺序：

socket();
bind();
listen();
accept();
recv();
send();
close();

与 Reactor 结合后还会使用：

epoll_create();
epoll_ctl();
epoll_wait();
fcntl();

这两组 API 位于不同层次：

socket/bind/listen/accept/connect/send/recv/close
 → 管理 TCP socket 和数据传输

epoll_create/epoll_ctl/epoll_wait
 → 管理大量 fd 的就绪事件

fcntl() 常用于把 fd 设置为非阻塞。

三、一次 TCP 连接的三个阶段

1. 建立连接：三次握手
2. 数据传输：序号、确认、流量控制、拥塞控制和重传
3. 断开连接：FIN/ACK 与 TCP 状态迁移

应用程序看到的是：

connect() / accept()
send() / recv()
close()

内核真正执行的是 TCP 协议状态机。

四、socket() 在应用层与内核之间建立了什么

课堂代码：

fd=socket();

socket 的英文含义是插座。可以用“插头和插座”帮助理解应用层 fd 与内核 socket 对象的关系：

应用层
 fd：应用程序使用的整数句柄
 ↓
内核
 socket/TCP相关对象：保存协议、地址、状态、缓冲区等

socket() 成功后主要完成两类事情。

4.1 分配 fd

fd 是当前进程文件描述符表中的一个位置。内核找到可用位置，将它标记为正在使用，然后返回对应整数。

进程fd表
0 → 标准输入
1 → 标准输出
2 → 标准错误
3 → 新创建的socket

调用 close(fd) 后，该 fd 位置会被释放，之后可能被其他文件或 socket 再次使用。

4.2 创建并关联内核 socket 状态

应用程序用 fd 查找内核中的 socket 对象。TCP 相关对象会逐步保存：

本地IP
本地端口
远端IP
远端端口
协议类型
TCP状态
发送缓冲区
接收缓冲区
序号和确认号
窗口及重传信息

课堂中把这组 TCP 连接状态概括为 TCB（Transmission Control Block，传输控制块）。

五元组是：

源IP
源端口
目的IP
目的端口
传输层协议

例如：

192.168.1.10:52000
 → 192.168.1.20:2000
 → TCP

同一个服务端端口可以同时拥有大量连接，因为每条连接的五元组不同。

五、bind()：把本地地址写入 socket

课堂代码：

bind(fd,);

bind() 的作用是给 socket 指定本地 IP 和本地端口：

通过fd找到内核socket对象
 ↓
设置本地IP
 ↓
设置本地端口

服务端必须有稳定的监听地址，所以通常显式绑定：

0.0.0.0:2000

客户端通常直接调用 connect()；如果之前没有 bind()，内核会自动选择本地地址和临时端口。

六、listen()：让 socket 进入监听状态

课堂代码：

listen(fd,backlog);

listen() 将 socket 变成监听 socket：

普通TCP socket
 ↓ listen()
LISTEN状态

如果服务端只完成 bind() 而没有 listen()，对应端口没有处于 TCP 监听状态，客户端连接通常会被拒绝。

6.1 两类连接队列

监听 socket 的连接可以从两个阶段理解：

收到客户端SYN
 ↓
SYN队列：握手尚未完成
 ↓
收到第三次握手ACK
 ↓
已完成连接队列：等待应用accept()

常见名称：

SYN queue / 半连接队列
accept queue / 已完成连接队列

“半连接”不是只能传一半数据，而是三次握手还没有完成。

6.2 backlog

现代 Linux 中，listen(fd, backlog) 的 backlog 主要限制等待 accept() 的已完成连接队列长度：

listen(fd,backlog);

可以理解成：

应用程序暂时没来得及 accept 时，内核允许多少条已经建立完成的连接排队等待。

SYN 队列还有独立内核配置：

cat /proc/sys/net/ipv4/tcp_max_syn_backlog

实际队列长度还受内核上限、系统配置和 SYN cookies 等机制影响。

七、TCP 三次握手

三次握手由内核 TCP 协议栈完成。应用程序通过 connect() 发起；服务端 listen() 后由内核接收握手；accept() 取出的是已经完成握手的连接。

假设双方初始序号分别是：

客户端初始序号：1234
服务端初始序号：5647

7.1 第一次：客户端发送 SYN

client → server

SYN = 1
SEQ = 1234

含义：

客户端希望建立连接，自己的初始发送序号从 1234 开始。

客户端状态：

CLOSED → SYN_SENT

SYN 会占用一个序号，所以服务端确认时使用 1234 + 1。

7.2 第二次：服务端返回 SYN + ACK

server → client

SYN = 1
ACK = 1
SEQ = 5647
ACK number = 1235

ACK number = 1235 表示客户端序号 1234 的 SYN 已经收到，下一次期望从 1235 开始。

同时，服务端告诉客户端自己的初始发送序号是 5647。

服务端相关连接状态：

LISTEN → SYN_RECEIVED

7.3 第三次：客户端返回 ACK

client → server

ACK = 1
ACK number = 5648

5648 = 5647 + 1，表示服务端的 SYN 已经收到。随后双方进入：

ESTABLISHED

完整过程：

客户端 服务端

SYN, SEQ=1234
 ───────────────────────────────→

 SYN+ACK,
 SEQ=5647, ACK=1235
 ←───────────────────────────────

ACK, ACK=5648
 ───────────────────────────────→

双方进入ESTABLISHED

7.4 为什么要交换序号

双方分别告诉对方自己的初始序号，后续 TCP 才能利用序号和确认号实现：

识别数据顺序
发现数据缺失
排除重复数据
确认已经收到的字节范围
进行超时重传

初始序号不是固定从 0 开始，而是由内核生成。这样可以减少旧连接延迟报文的干扰，也提高序号的不可预测性。

八、connect()、握手和 accept() 的关系

客户端：

connect();

connect() 让内核发起 TCP 三次握手。阻塞 socket 上，connect() 通常要等待连接成功或失败后才返回，因此服务端不可达时可能等待较长时间。

服务端：

listen();
accept();

三次握手不是由 accept() 执行的。握手由服务端内核协议栈在监听状态下完成：

内核完成三次握手
 ↓
连接进入已完成连接队列
 ↓
listenfd出现可读事件
 ↓
应用调用accept()

accept() 主要完成：

从已完成连接队列取出一条连接
 ↓
为它分配新的clientfd
 ↓
让clientfd关联这条已连接socket

因此：

listenfd → 继续监听新连接
clientfd → 与某个客户端收发数据

8.1 Reactor 中的对应关系

listenfd出现EPOLLIN
 ↓
accept_cb()
 ↓
accept()
 ↓
得到clientfd
 ↓
把clientfd注册到epoll

LT 下，如果队列中还有连接，监听 fd 会继续报告可读。

ET 下应循环 accept()，直到当前队列已经取空。课堂代码：

while（1）{
fd =accept();
if(fd==-1){
break

}
}

这段代码表达的核心是：

一次EPOLLIN通知
 ↓
连续accept
 ↓
把当前已经完成的连接全部取出

实际使用非阻塞 fd 时，accept() 返回 -1 且 errno 为 EAGAIN/EWOULDBLOCK，表示本轮队列已经取空。

九、SYN 队列如何匹配第三次握手

收到第三次握手报文后，内核需要找到它属于哪一条正在建立的连接。

IP 头和 TCP 头能够提供：

源IP
目的IP
源端口
目的端口
协议类型TCP

内核结合五元组、序号和连接状态查找对应的半连接状态，验证 ACK 后，将连接推进到已建立状态并放入已完成连接队列。

连接状态的生命周期不是从 accept() 才开始。服务端收到 SYN 后，内核已经需要保存握手状态；accept() 只是把完成后的连接交给应用程序。

十、SYN Flood

SYN Flood 的基本过程：

攻击者发送大量SYN
 ↓
服务端为握手保存状态
 ↓
攻击者不完成第三次握手
 ↓
半连接状态和相关资源被持续占用

常见防护包括：

SYN cookies。
调整 SYN 队列和重试参数。
防火墙、负载均衡器和云安全组。
限速和异常源识别。
DDoS 清洗服务。

listen() 的 backlog 主要用于已完成连接队列，不能单独解决 SYN Flood。

十一、send() 和 recv() 到底做了什么

课堂中的数据路径：

发送方application
 ↓ send/write
发送方kernel TCP协议栈
 ↓
网络
 ↓
接收方kernel TCP协议栈
 ↓ recv/read
接收方application

11.1 send()

课堂例子：

send（fd,buffer,100,0）;
send（fd,buffer,200,0）;
send（fd,buffer,400,0）;

send() 返回正数，表示本次有多少字节被内核 socket 发送路径接受。它不表示对端应用已经读取这些数据。

后续什么时候组成 TCP 段、什么时候交给 IP 层、何时重传，由内核协议栈处理。

TCP 是字节流，不保留应用层每次 send() 的边界。上面三次调用总共交给 TCP 700 字节，接收端不一定按照 100、200、400 三次收到。

11.2 recv()

课堂例子：

recv（fd，buffer，50,0）
recv（fd，buffer，250,0）
recv（fd，buffer，250,0）
recv（fd，buffer，150,0）

接收端可以按照 50 + 250 + 250 + 150 取出相同的 700 字节。

recv() 把已经到达 socket 接收缓冲区的数据复制到应用层 buffer。一次返回多少字节取决于：

当前已经到达多少数据
应用提供的buffer有多大
socket是否阻塞
协议栈和调度时机

因此：

发送端三次send
不等于
接收端必须三次recv

这也是 TCP 半包、粘包问题的来源。应用层协议需要自己定义消息边界，例如固定长度、长度字段或分隔符。

11.3 一次接收 1000 与十次接收 100

课堂对比：

recv（fd,buffer,1000,0）;

与：

recv（fd,buffer,100,0）;
// 循环10次

复制总数据量可以相同，但十次 recv() 会产生更多系统调用、循环判断和状态处理开销，因此性能并非完全没有差异。

实际代码应以协议完整性和程序结构为主，选择合理缓冲区大小，不必把每次读取切得非常小。

十二、MTU、MSS 与 TCP 分段

MTU 是链路能够承载的最大 IP 包大小。常见以太网 MTU 是 1500 字节，但它包含 IP 头，不等于 TCP 应用数据长度。

TCP 常用 MSS 表示一个 TCP 段最多携带的 payload 大小：

MSS ≈ MTU - IP头 - TCP头

常见 IPv4、无额外选项时：

1500 - 20 - 20 = 1460字节

课堂例子：

send（fd,buffer,1700,0）;

应用一次交给内核 1700 字节，不代表网络上一定只有一个包。协议栈会根据 MSS、网卡卸载、路径 MTU 等条件分段。

接收端 recv() 的边界与网络分段也没有一一对应关系。网络上传输多个 TCP 段，接收端可能一次取出合并后的数据，也可能分多次取出。

十三、TCP 如何可靠并尽量快速地传输

这些机制主要运行在两端内核 TCP 协议栈之间，不由应用程序逐包控制。

13.1 序号与确认号

SEQ → 当前报文携带的数据从哪个字节序号开始
ACK → 下一次期望收到哪个字节序号

如果 ACK number = 1235，可以理解为序号 1235 之前的数据已经连续收到，下一次希望从 1235 开始。

13.2 接收窗口与滑动窗口

接收方通过窗口告诉发送方：

当前接收缓冲区还允许接收多少数据。

发送方可以在没有逐段等待 ACK 的情况下发送窗口范围内的多段数据。ACK 推进后，允许发送的范围继续向前滑动。

它解决：

既要连续发送提高吞吐
又不能超过接收方处理能力

13.3 慢启动

连接开始时，发送方不知道网络能承受多少在途数据，因此从较小的拥塞窗口开始。在慢启动阶段，拥塞窗口按每个 RTT 观察通常接近指数增长。

13.4 拥塞避免

拥塞窗口达到阈值后，增长转为更平缓的方式。检测到丢包或拥塞信号后，具体如何降低窗口取决于拥塞控制算法和丢包检测方式，不能把所有情况都理解为固定“减半重新开始”。

13.5 延迟确认

接收方可以短暂等待，把 ACK 与反向数据一起发送，或者用一个 ACK 确认更多数据，以减少纯 ACK 包数量。

延迟时间由协议实现和当前状态决定，不是所有系统都固定延迟 200 ms。

13.6 超时重传与快速重传

发送方在规定时间内没有收到确认，会认为数据可能丢失并触发重传。连续收到重复 ACK 时，也可能在超时前触发快速重传。

这些机制共同实现：

可靠传输
按序交付
避免重复
适应接收端能力
适应网络拥塞程度

十四、close() 与四次挥手

课堂代码：

close(fd);

close() 首先是通用的 fd 关闭接口。对 TCP socket 来说，当最后一个引用被关闭时，内核会根据 socket 状态和配置推进 TCP 关闭过程。

TCP 关闭使用 FIN 标志，不是 final。

14.1 为什么通常是四次

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

主动关闭方 被动关闭方

FIN
 ───────────────────────────────→

 ACK
 ←───────────────────────────────

 FIN
 ←───────────────────────────────

ACK
 ───────────────────────────────→

过程：

1. 主动方发送FIN：我没有更多数据要发送
2. 被动方返回ACK：我知道你不再发送
3. 被动方处理完自己的发送后，也发送FIN
4. 主动方返回ACK：确认对方也不再发送

第二步和第三步有时会合并在同一个报文中，所以抓包时不一定总能机械地看到四个独立数据包。

14.2 主动关闭方状态

ESTABLISHED
 ↓ close()，发送FIN
FIN_WAIT_1
 ↓ 收到对方对FIN的ACK
FIN_WAIT_2
 ↓ 收到对方FIN，返回ACK
TIME_WAIT
 ↓ 等待2MSL
CLOSED

14.3 被动关闭方状态

ESTABLISHED
 ↓ 收到FIN，返回ACK
CLOSE_WAIT
 ↓ 本地应用调用close()，发送FIN
LAST_ACK
 ↓ 收到对方ACK
CLOSED

14.4 为什么 recv() 返回 0

被动方收到 FIN 后，如果此前还有已到达的数据，应用应先读出这些数据。全部读完以后，再次调用：

recv(fd,buffer,size,0);

会返回：

它表示对方正常关闭了发送方向，后面不会再有数据。非阻塞 socket 暂时没有数据返回的是 -1/EAGAIN，不是 0。

14.5 数据与 FIN

应用先调用：

send（fd,buffer,100,0）

随后调用：

close(fd);

TCP 会保持字节流顺序：内核已经接受的待发送数据排在 FIN 之前。接收端先读到数据，数据全部读完后才观察到 EOF，即 recv() == 0。

14.6 shutdown()

shutdown() 可以只关闭 TCP 的一个方向：

SHUT_RD → 关闭读方向
SHUT_WR → 关闭写方向，向对端发送FIN
SHUT_RDWR → 关闭读写方向

它适合“我已经发送完，但还要继续接收对方响应”的半关闭协议。普通请求响应程序只使用 close() 也很常见，但 shutdown() 并不是没有用途。

十五、TIME_WAIT、CLOSING 与同时关闭

15.1 TIME_WAIT

通常由最终发送 ACK 的主动关闭方进入 TIME_WAIT。作用：

如果最后一个ACK丢失，可以重新确认对方重发的FIN
让旧连接的延迟报文在网络中消失

服务端出现大量 TIME_WAIT，通常说明服务端经常主动关闭连接，不等于双方一定同时调用了 close()。

15.2 同时关闭

如果双方几乎同时调用 close()：

双方都发送FIN
 ↓
双方都可能在FIN_WAIT_1时收到对方FIN
 ↓
进入CLOSING
 ↓
收到自己FIN对应的ACK
 ↓
进入TIME_WAIT

简化状态：

ESTABLISHED
 ↓ 本地发送FIN
FIN_WAIT_1
 ↓ 先收到对端FIN
CLOSING
 ↓ 收到ACK
TIME_WAIT

如果主动方先收到 ACK，再收到 FIN，则通常经过：

FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT

TCP 状态机用于处理这些不同的报文到达顺序。

十六、同时打开与 TCP P2P

常规应用使用客户端/服务端角色：

客户端调用connect()
服务端调用listen()/accept()

但 TCP 建立后，双方都是全双工通信端点。客户端和服务端主要描述谁主动连接、谁被动监听，以及应用协议中的角色。

TCP 还定义了“同时打开”：双方都主动发送 SYN，并在 SYN_SENT 状态收到对方 SYN。

双方CLOSED
 ↓ 同时主动打开
双方SYN_SENT
 ↓ 收到对方SYN并返回SYN+ACK
双方SYN_RECEIVED
 ↓ 收到ACK
双方ESTABLISHED

课堂中的 P2P 方向：

fd=socket（）
bind（）//optional
connect（）；

真正跨公网实现 P2P 还需要考虑 NAT、端口映射、防火墙和连接协调。单纯同时调用 connect() 不保证一定能穿透网络设备。

本节需要理解：

TCP 建立后没有“只能客户端发、只能服务端收”的限制，双方都可以 send 和 recv。

十七、把 API 与 TCP 状态对应起来

应用调用或事件	内核中的主要含义
socket()	创建 fd 和 socket 相关内核对象
bind()	设置本地 IP 和端口
listen()	进入 LISTEN，准备接收连接
connect()	主动发起三次握手
收到 SYN	创建或查找握手状态，进入 SYN_RECEIVED
握手完成	连接进入 ESTABLISHED，并等待 accept
accept()	从已完成连接队列取出连接，返回 clientfd
send()	把应用字节交给 socket 发送路径
recv()	把 socket 接收数据复制到应用缓冲区
收到 FIN	对端关闭发送方向，最终让 recv 返回 0
close()	释放 fd 引用，并推动 TCP 关闭过程

完整主线：

socket()
 ↓
bind()
 ↓
listen() / connect()
 ↓
三次握手
 ↓
accept()得到clientfd
 ↓
send()/recv()
 ↓
序号、确认、窗口、拥塞控制、重传
 ↓
close()
 ↓
FIN/ACK与四次挥手
 ↓
TIME_WAIT或CLOSED

十八、本节课需要真正掌握的内容

重点一：API 是入口，协议栈完成真正的 TCP 工作

connect()不是应用自己发送三个包
accept()不负责执行三次握手
send()不等于对端应用已经收到
recv()不对应某一次send()
close()会推动TCP关闭状态机

重点二：监听 fd 和客户端 fd 对应不同状态

listenfd
 → LISTEN状态
 → 管理握手和等待accept的连接

clientfd
 → 对应某条已建立TCP连接
 → 用于send和recv

重点三：TCP 是可靠字节流

没有应用消息边界
使用序号和ACK保证顺序与可靠性
使用接收窗口进行流量控制
使用拥塞窗口适应网络承载能力
使用重传恢复丢失数据

重点四：建立和关闭都是状态机

三次握手：
CLOSED → SYN_SENT/SYN_RECEIVED → ESTABLISHED

主动关闭：
ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT

被动关闭：
ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

课后实践

准备两台虚拟机，观察 TCP P2P：

1. 双方创建TCP socket
2. 根据实验设计绑定本地地址
3. 协调双方连接时机
4. 抓包观察SYN、SYN+ACK、ACK
5. 建立后让双方都执行send和recv
6. 同时或分别close，观察TCP状态

可以配合：

ss -ant
tcpdump -nn -i any tcp

协程设计原理：从异步回调到 ucontext 调度

Mon, 10 Aug 2026 00:00:00 +0800

本篇承接已有的网络 I/O、epoll 与 Reactor 笔记。这份笔记重点理解：为什么需要协程、协程怎样把异步 I/O 写成同步流程、上下文切换的三种实现方式，以及 yield、resume 和调度器之间的关系。

一、这份笔记要解决的问题

以开源协程库 ntyco 为参照，尝试逐步理解并实现一套用户态协程框架。

完整学习路线包括：

1. 为什么需要协程
2. 协程有哪些原语操作
3. 如何定义 struct coroutine
4. 如何定义 struct scheduler
5. 调度器采用什么策略
6. 如何兼容或封装 POSIX API
7. 协程从创建到退出的执行流程
8. 协程如何扩展到多核
9. 如何测试协程性能

当前真正落到代码上的内容主要是：

异步回调为什么难写
 ↓
协程如何保留同步代码结构
 ↓
上下文切换需要保存什么
 ↓
setjmp/longjmp
 ↓
ucontext
 ↓
yield / resume
 ↓
最简单的轮询调度器

后续的 struct coroutine、struct scheduler、I/O 调度、多核模式和性能测试，是建立在这些基础之上的下一阶段。

二、协程要解决什么问题

2.1 同步请求

同步代码通常按顺序执行：

func(){
send（）；
recv();
}

执行过程：

send()发起请求
 ↓
recv()等待结果
 ↓
结果返回以后继续执行

优点是代码符合人的思考顺序：

发请求 → 等结果 → 处理结果

缺点是等待 I/O 时，当前执行单元不能继续做其他工作。

2.2 异步回调

异步写法可以表示为：

callback(){
 recv();
 send(fd,cb);
 }
 func{
 send(fd,callback)
 }

执行过程：

func()发起请求
 ↓
立即返回，不阻塞当前流程
 ↓
fd就绪
 ↓
事件系统调用callback()
 ↓
callback()继续处理结果

异步的关键不是函数名字叫 async，而是：

发起操作和处理结果不在同一次连续调用栈中，中间通过事件和回调重新进入业务逻辑。

2.3 异步不等于并行

异步表示等待期间可以处理其他任务；并行表示多个任务在同一时刻由不同 CPU 核执行。

异步 → 关注等待关系
并行 → 关注是否同时执行

单线程 epoll 也可以实现异步，但它并没有同时使用多个 CPU 核。

2.4 协程的目标

回调的性能模型很好，但业务流程一复杂，就会出现多层嵌套：

请求A完成
 → 回调中发起请求B
 → B的回调中发起请求C
 → C的回调继续业务

协程希望实现：

底层：仍然使用异步事件和非阻塞I/O
上层：代码看起来像同步顺序执行

即：

底层异步，上层同步写法。

三、线程池异步与单线程同步的对比

线程池任务示例：

client_t *rClient = (client_t*)malloc(sizeof(client_t));
					memset(rClient, 0, sizeof(client_t));				
					rClient->fd = clientfd;
					
					job_t *job = malloc(sizeof(job_t));
					job->job_function = client_job;
					job->user_data = rClient;
					workqueue_add_job(&workqueue, job);

这里把 clientfd 封装进任务：

rClient->fd = clientfd
 ↓
job->job_function = client_job
 ↓
job->user_data = rClient
 ↓
workqueue_add_job()
 ↓
工作线程取出任务并执行

两种结构如下。

3.1 同一个线程检测和处理 I/O

while(1){
int nready =epll_wait();
for(int i=0;i<nready;i++){
recv(event[i].data.fd,buffer)
send(event[i]data.fd,buffer)
}
}
}
//单线程

流程：

epoll_wait()
 ↓
遍历就绪fd
 ↓
当前线程执行recv/send
 ↓
处理完成后才能继续下一个事件

3.2 epoll 线程只分发任务

void *task_callback(void *arg){
	recv(event[i].data.fd,buffer)
send(event[i]data.fd,buffer)
}
while(1){
int nready =epll_wait();
for(int i=0;i<nready;i++){
task.fd=event[i].fd
task.callback=task_callback
push_task_to_threadpool(&task);
}//多线程

流程：

epoll_wait()检测就绪
 ↓
把fd包装成task
 ↓
推入线程池
 ↓
工作线程执行recv/send

一次示例测试得到：

线程池方式：每1000连接约1500ms
直接处理：每1000连接约7300ms

这个结果只能说明当前代码、机器和负载下，任务并行处理改善了吞吐。它不能直接推导出“所有异步程序一定比同步程序快六倍”。

性能差异还可能来自：

任务中是否有阻塞操作
CPU核心数量
连接和请求模型
锁与队列开销
日志输出
测试方法
数据大小

协程与线程池也不是同一种实现：

线程池 → 内核线程并行执行任务
协程 → 通常在线程内由用户态调度器协作切换

四、为什么互联网业务需要并发等待

一个网页可能需要同时请求多个动态接口：

用户信息
文章列表
消息数量
推荐内容
广告数据
权限信息

如果完全串行：

请求1完成
 ↓
请求2完成
 ↓
请求3完成

总等待时间会累积。

如果这些请求相互独立，可以在等待某个请求时推进其他请求：

发起请求1 ─┐
发起请求2 ─┼→ 分别等待 → 谁先完成先处理谁
发起请求3 ─┘

同样的模型也会出现在：

DNS查询
HTTP请求
数据库查询
Redis请求
Kafka或MongoDB访问
文件I/O
多个客户端连接

如果请求之间存在依赖：

A的结果决定B的参数
B的结果决定C的参数

业务顺序仍然必须是 A → B → C。协程不能消除真实依赖，但可以在 A 等待期间调度其他不相关协程。

五、从回调流程演化到协程流程

5.1 回调写法

三个请求流程可以写成：

请求流程1
callback(){
 recv();
 send(fd,cb);
 }
 func{
 send_http(fd,callback)
switch(1,2)
 }

请求流程2
callback(){
 recv();
 send(fd,cb);
 }
 func{
 switch(2,3)
 send(fd,callback)
 }

请求流程3
callback(){
 recv();
 send(fd,cb);
 }
 func{
 send(fd,callback)
 switch(3,1)
 }

业务被拆散到多个 callback 中，切换关系也混在业务代码里。

5.2 协程期望的写法

希望得到的目标形式：

请求流程1

 func{
 setjmp();
asyn_send(fd,callback)

asyn_recv(fd,buffer)
 }

其他请求也保持相同的顺序结构：

请求流程2

 func{
asyn_send(fd,callback)

asyn_recv(fd,buffer)
 }

请求流程3

 func{
asyn_send(fd,callback)

asyn_recv(fd,buffer)
 }

表面看起来仍然是：

发送
 ↓
接收
 ↓
处理

但 asyn_recv() 发现 fd 尚未就绪时，不阻塞整个线程，而是让出当前协程：

async_xxx(){
if(1==poll(fd,0)){
switch();
}
}

它表达的思想是：

I/O已经就绪
 → 当前协程继续执行

I/O尚未就绪
 → 保存当前协程上下文
 → yield到调度器
 → 调度其他协程
 → fd就绪后resume回来

所以协程不是把阻塞 I/O 变快，而是在等待发生时切走。

六、协程必须具备哪些原语

最基础的协程原语可以概括为：

create → 创建协程
resume → 从调度器进入协程
yield → 协程主动让出执行权
exit → 协程执行结束
switch → 保存一个上下文并恢复另一个上下文

与 I/O 调度结合后还需要：

wait_io(fd, event) → 当前协程等待某个fd事件
wakeup(coroutine) → fd就绪后把协程变为可运行
schedule() → 选择下一个可运行协程

三者之间的关系：

resume和yield → 面向协程业务语义
switch → 底层上下文切换动作
schedule → 决定下一次resume谁

七、上下文到底是什么

协程执行到一半切走，之后还要从原位置继续，因此必须保存执行现场。

上下文通常包括：

程序计数器/指令位置
栈指针
通用寄存器
部分调用约定要求保存的寄存器
协程自己的栈
协程状态

如果只记住“执行到了哪一行”，但没有保存栈和寄存器，函数局部变量、返回地址和调用关系就无法恢复。

栈式协程通常需要：

每个协程一个独立栈
每个协程一份上下文
一个调度器上下文

I/O 模型中常见的是：

fd就绪事件
 → 找到等待这个fd的协程
 → 将协程加入ready队列

并不是 fd 本身天然等于协程；实现可以选择“一连接一协程”“一请求一协程”，也可以让一个协程等待多个事件。

八、实现上下文切换的三种方式

常见的实现方式：

1. setjmp / longjmp
2. ucontext
3. 汇编保存和恢复寄存器，例如 ntyco

8.1 setjmp / longjmp

setjmp() 保存可以恢复的执行环境，longjmp() 跳回该位置。

它适合帮助理解“保存位置并跳回来”，但它本身不自动为每个协程创建独立栈。要实现完整栈式协程，还要管理协程栈和更完整的上下文。

8.2 ucontext

ucontext 提供：

getcontext() → 获取当前上下文
makecontext() → 为上下文指定入口函数
swapcontext() → 保存当前上下文并切换到目标上下文
setcontext() → 直接恢复某个上下文

它非常适合教学，因为能够明确看到栈、入口函数和上下文切换。

ucontext 已从 POSIX.1-2008 中移除，不适合作为现代跨平台库的统一标准接口，但很多 Unix/Linux 环境仍然提供它。

8.3 汇编切换

汇编实现会按照目标架构和调用约定，直接保存、恢复必要寄存器和栈指针。

优点：

可控制保存哪些寄存器
切换路径短
适合高性能协程库

代价：

与CPU架构相关
与ABI和调用约定相关
移植成本更高
实现错误容易破坏栈

ntyco 采用汇编方式实现底层上下文切换。

九、setjmp / longjmp 原代码

setjmp / longjmp 示例代码：

#include<setjmp.h>
#include<stdio.h>
jmp_buf env;//上下文环境
void func(int arg){
 printf("func: %d\n",arg);
 longjmp(env,++arg);
}
int main(){
 
 int ret=setjmp(env);
 if(ret==0){
 func(ret);
 }else if(ret==1){
 func(ret);
 }else if(ret==2){
 func(ret);
 }else if(ret==3){
 func(ret);
 }


 return 0; 

}

9.1 jmp_buf

jmp_buf env;//上下文环境

env 用来保存 setjmp() 所需的执行环境。

9.2 第一次 setjmp()

int ret=setjmp(env);

直接调用 setjmp() 时返回 0：

ret = 0
 ↓
进入if(ret==0)
 ↓
func(0)

9.3 longjmp()

longjmp(env,++arg);

func(0) 中 arg 先变成 1，再跳回 setjmp() 保存的位置。

这一次 setjmp() 看起来像重新返回，并得到：

ret = 1

于是进入：

}else if(ret==1){
 func(ret);
}

执行过程：

setjmp首次返回0
 ↓
func(0)打印func: 0
 ↓ longjmp(...,1)
setjmp恢复后返回1
 ↓
func(1)打印func: 1
 ↓ longjmp(...,2)
setjmp恢复后返回2
 ↓
func(2)打印func: 2
 ↓ longjmp(...,3)
setjmp恢复后返回3
 ↓
func(3)打印func: 3
 ↓ longjmp(...,4)
setjmp恢复后返回4
 ↓
没有匹配分支，main结束

预期打印：

func: 0
func: 1
func: 2
func: 3

这段代码展示的是控制流跳转，还不是完整的多协程调度器。

十、ucontext 原代码：三个协程和 main 上下文

ucontext 示例代码：

#include<stdio.h>
#include<ucontext.h>

ucontext_t ctx[3];
ucontext_t main_ctx;
int count=0;
//coroutine1
void func1(void){
 while(count++<30){
 printf("1\n");
 //swapcontext(&ctx[0],&ctx[1]);
 swapcontext(&ctx[0],&main_ctx);
 printf("4\n");
 }

}
//coroutine2
void func2(void){
 while(count++<30){
 printf("2\n");
 //swapcontext(&ctx[1],&ctx[2]);
 swapcontext(&ctx[1],&main_ctx);
 printf("5\n");
 }



}
//coroutine3
void func3(void){
 while(count++<30){
 printf("3\n");
	//swapcontext(&ctx[2],&ctx[0]);
	swapcontext(&ctx[2],&main_ctx);
 printf("6\n");
 }



}
//schedule
int main(){

 char stack1[2048]={0};
 char stack2[2048]={0};
 char stack3[2048]={0}; 
 getcontext(&ctx[0]);
 ctx[0].uc_stack.ss_sp=stack1;
 ctx[0].uc_stack.ss_size=sizeof(stack1);
 ctx[0].uc_link=&main_ctx;
 makecontext(&ctx[0],func1,0);

 
 getcontext(&ctx[1]);
 ctx[1].uc_stack.ss_sp=stack2;
 ctx[1].uc_stack.ss_size=sizeof(stack2);
 ctx[1].uc_link=&main_ctx;
 makecontext(&ctx[1],func2,0); 

 getcontext(&ctx[1]);
 ctx[2].uc_stack.ss_sp=stack3;
 ctx[2].uc_stack.ss_size=sizeof(stack3);
 ctx[2].uc_link=&main_ctx;
 makecontext(&ctx[1],func3,0); 

 printf("swapcontext\n");
 swapcontext(&main_ctx,&ctx[0]);
 int i=30;
 while(count<30){
 swapcontext(&main_ctx,&ctx[count%3]);
 }
 printf("\n");






 return 0;
}

这段代码希望建立：

main_ctx → 调度器上下文
ctx[0] → func1协程
ctx[1] → func2协程
ctx[2] → func3协程

阅读第三个协程的初始化时，要按照这个对应关系理解：

ctx[2]使用stack3
ctx[2]的入口函数是func3

十一、如何创建一个 ucontext 协程

以第一个协程为例。

11.1 保存初始上下文

getcontext(&ctx[0]);

ctx[0] 获得一份可继续配置的上下文。

11.2 指定独立栈

ctx[0].uc_stack.ss_sp=stack1;
ctx[0].uc_stack.ss_size=sizeof(stack1);

含义：

stack1 → 栈起始地址
sizeof(stack1) → 栈大小
ctx[0].uc_stack → ctx[0]使用的协程栈

三个协程分别使用：

ctx[0] → stack1
ctx[1] → stack2
ctx[2] → stack3

独立栈让不同协程能够保存自己的函数调用关系和局部变量。

11.3 指定返回去向

ctx[0].uc_link=&main_ctx;

如果 func1 正常执行完并返回，运行时会转到 main_ctx。

uc_link 处理的是入口函数正常返回后的去向；func1 中主动调用 swapcontext() 则是显式 yield。

11.4 指定入口函数

makecontext(&ctx[0],func1,0);

含义：

ctx[0]第一次被resume时
 ↓
从func1开始执行
 ↓
func1没有参数

最后一个 0 表示传给 func1 的参数数量为 0。

十二、swapcontext()：保存当前上下文并恢复另一个

函数形式：

swapcontext(&from,&to);

可以理解成：

把当前执行现场保存到from
 ↓
恢复to中的执行现场
 ↓
开始运行to

12.1 main resume 第一个协程

swapcontext(&main_ctx,&ctx[0]);

含义：

保存main当前执行位置到main_ctx
 ↓
恢复ctx[0]
 ↓
第一次进入func1

func1 打印：

printf("1\n");

12.2 func1 yield 回 main

swapcontext(&ctx[0],&main_ctx);

含义：

保存func1当前执行位置到ctx[0]
 ↓
恢复main_ctx
 ↓
main从刚才swapcontext之后继续

func1 的执行位置停在：

swapcontext(&ctx[0],&main_ctx);

下一次 main 再 resume ctx[0] 时，swapcontext() 返回，继续执行：

printf("4\n");

这就是协程能够“从上次让出的位置继续”的原因。

十三、yield、resume 和 switch

三者的对应关系：

main → ctx[0] → resume协程
ctx[0] → main → yield协程
swapcontext() → 底层switch动作

13.1 resume

调度器选择一个协程
 ↓
从main_ctx切到该协程ctx
 ↓
协程开始或继续运行

13.2 yield

协程遇到I/O等待或主动让出
 ↓
保存自己的ctx
 ↓
切回main_ctx
 ↓
调度器选择其他协程

13.3 switch

switch 不关心为什么切换，只负责：

保存from
恢复to

resume 和 yield 是对 switch 在不同业务方向上的命名。

十四、当前调度器如何工作

原代码：

while(count<30){
 swapcontext(&main_ctx,&ctx[count%3]);
}

count % 3 的结果不断在 0、1、2 之间变化：

count % 3 == 0 → resume ctx[0]
count % 3 == 1 → resume ctx[1]
count % 3 == 2 → resume ctx[2]

因此它相当于一个简单轮询调度器：

main
 ↓
ctx[0]运行一段后yield
 ↓
main
 ↓
ctx[1]运行一段后yield
 ↓
main
 ↓
ctx[2]运行一段后yield
 ↓
main继续轮询

这些上下文的栈关系可以画成：

ctx3独立栈
ctx2独立栈
ctx1独立栈
main栈

这些栈并不是垂直嵌套成一条普通函数调用链，而是各自保存执行现场，由 swapcontext() 在它们之间切换。

十五、为什么当前轮询还不是 I/O 调度器

当前策略只根据：

ctx[count%3]

选择协程，它不知道：

哪个协程正在等待fd
哪个fd已经就绪
哪个协程已经结束
哪个协程可以立即运行

真正的 I/O 协程调度需要至少维护：

ready队列 → 当前可以运行的协程
waiting集合 → 等待I/O、定时器或条件的协程
epoll → 检测fd就绪
协程状态 → NEW、READY、RUNNING、WAITING、DEAD

典型过程：

协程调用异步recv
 ↓
数据尚未就绪
 ↓
把“fd → 当前协程”注册给调度器
 ↓
当前协程状态变成WAITING
 ↓
yield回调度器
 ↓
调度器resume其他READY协程
 ↓
epoll报告fd可读
 ↓
对应协程进入READY队列
 ↓
调度器再次resume它
 ↓
recv继续执行

这个过程才真正实现：

代码看起来在等待 recv，但线程没有被这个协程阻塞。

十六、协程结构体需要保存什么

进一步实现时需要定义 struct coroutine。根据前面的执行过程，它至少需要表达：

协程ID
协程状态
上下文
独立栈和栈大小
入口函数
入口参数
所属调度器
等待的fd和事件
退出结果或错误

概念结构：

struct coroutine
 ├── id
 ├── state
 ├── context
 ├── stack
 ├── function
 ├── argument
 ├── waiting_fd
 └── scheduler

这里先理解字段为什么存在，不需要脱离后续 ntyco 代码自行发明另一套结构。

十七、调度器需要保存什么

调度器负责管理所有协程并决定下一次运行谁。

概念结构：

struct scheduler
 ├── main_context
 ├── current_coroutine
 ├── ready_queue
 ├── waiting_coroutines
 ├── epoll_fd
 ├── timer
 └── all_coroutines

调度器要回答：

当前运行的是谁
哪些协程可以运行
哪些协程在等待I/O
哪些协程等待超时
fd就绪后应该唤醒谁
协程退出后怎样回收

十八、如何封装 POSIX API

一个重要设计目标，是让协程网络库尽量保持熟悉的 POSIX 调用方式。

期望上层仍然写：

connect
accept
recv
send
close

但协程封装后的行为是：

调用recv
 ↓
先尝试非阻塞recv
 ├── 已就绪：直接返回结果
 └── EAGAIN：注册EPOLLIN并yield
 ↓
 fd就绪
 ↓
 resume协程
 ↓
 再次尝试recv

这样业务代码保留同步风格，但底层仍然由 epoll 和协程调度实现异步等待。

“接口一致”不代表直接调用阻塞版本的 POSIX API，而是协程库提供行为兼容的包装层或 hook。

十九、协程怎样用于 WebServer

已有 Reactor WebServer 的逻辑：

epoll_wait
 ↓
recv_cb
 ↓
http_request
 ↓
send_cb
 ↓
http_response

协程模型可以把一个连接或一个请求组织成顺序流程：

协程开始
 ↓
等待并接收HTTP请求
 ↓
解析HTTP
 ↓
查询数据库或缓存
 ↓
构造HTTP响应
 ↓
发送响应
 ↓
等待下一次请求或退出

遇到 fd 尚未就绪时：

当前协程yield
 ↓
线程继续处理其他连接协程
 ↓
fd就绪后resume

Reactor 与协程不是互斥关系：

Reactor/epoll → 检测事件
协程调度器 → 把事件转换成协程唤醒
协程 → 承载顺序业务流程

二十、微信群聊场景应该怎样思考

思考这个场景时，不必急着寻找固定答案，先建立分析框架。

面对“微信群聊如何使用协程”时，可以依次问：

1. 一个协程对应一个连接、一个用户，还是一次消息处理？
2. 连接没有消息时，协程处于什么状态？
3. fd可读后，谁把对应协程唤醒？
4. 一条消息需要广播给多人时，哪些步骤能够并发？
5. 慢客户端发送不出去时，是否会阻塞其他用户？
6. 每个连接的发送队列放在哪里？
7. 用户断开以后，协程、fd和缓冲区如何回收？
8. 心跳和超时由谁管理？
9. 群消息顺序如何保证？
10. 多核模式下，同一个连接能否跨调度器迁移？

可以先画：

用户A连接协程
 ↓ 收到群消息
服务端业务处理
 ↓
找到群成员
 ↓
把消息加入B/C/D的发送队列
 ↓
对应连接可写时唤醒发送流程

重点不是简单回答“一个用户一个协程”，而是明确：

协程在哪里等待
什么事件唤醒
状态保存在哪里
慢连接如何隔离

二十一、协程的多核模式

单个调度器通常运行在一个线程中，同一时刻只能使用一个 CPU 核。

多核模式常见思路：

一个线程一个调度器
 ↓
每个调度器拥有自己的epoll和ready队列
 ↓
多个线程并行运行

这形成 M:N 模型：

M个协程
 ↓ 用户态调度
N个内核线程
 ↓
多个CPU核

需要处理：

连接如何分配到各调度器
协程是否允许跨线程迁移
跨线程唤醒
共享队列和锁
负载均衡
work stealing
线程局部状态

上下文通常只能在它所属的线程和栈环境中安全切换，不能随意把 setjmp/ucontext 保存的上下文拿到另一个线程恢复。

二十二、协程性能如何测试

不能只看一个“每 1000 连接耗时”。协程性能至少分成四层。

22.1 原语性能

创建一个协程的耗时
一次yield/resume的耗时
每秒可以上下文切换多少次
销毁协程的耗时

22.2 内存

每个协程结构体大小
每个协程栈大小
一万或百万协程的总内存
栈是否按需增长

22.3 I/O 服务性能

并发连接数
QPS
吞吐量
P50/P95/P99延迟
超时和错误率
CPU使用率
上下文切换次数

22.4 对比基线

应在相同业务和负载下比较：

单线程Reactor
Reactor + 线程池
Reactor + 协程
一连接一线程

只有测试业务、连接数、响应大小和日志配置相同，结果才有可比性。

二十三、核心总结

重点一：协程不是为了创造真正并行

单线程协程仍然只使用一个CPU核
协程的主要价值是等待I/O时切换任务
多核需要多个调度线程配合

重点二：协程结合了两种优点

上层：同步顺序代码，容易理解
底层：异步事件等待，不阻塞整个线程

重点三：上下文和独立栈是恢复执行的基础

上下文 → 记录执行现场
协程栈 → 保存函数调用和局部变量
switch → 保存一个上下文，恢复另一个

重点四：yield、resume 与调度器

resume → 调度器进入协程
yield → 协程返回调度器
switch → 完成底层上下文切换
scheduler → 决定下一个运行谁

重点五：真正的 I/O 协程需要 epoll

recv遇到EAGAIN
 ↓
协程注册等待EPOLLIN
 ↓
yield
 ↓
epoll报告fd可读
 ↓
协程进入ready队列
 ↓
resume
 ↓
继续recv和后续业务

最终理解：

协程不是替代 epoll，而是建立在事件驱动之上，把回调式异步流程重新组织成可顺序阅读的业务代码。

Reactor 在 WebServer 与 WebSocket 中的应用

Sun, 09 Aug 2026 00:00:00 +0800

本篇是《网络IO》《IO 多路复用与 Reactor》《Reactor 与 epoll：百万并发网络服务器》的后续实践。
socket、fd、select、poll、epoll 接口、连接对象和 Reactor 基础不再重复；本篇只整理这节课新增的 LT/ET、HTTP WebServer、文件发送状态机和 WebSocket。

一、本节课做了什么

前一节已经搭好了 Reactor 网络层，本节在它上面接入两种协议业务：

reactor.c：网络 I/O 层
 ├── recv_cb()
 └── send_cb()

webserver.c：HTTP 协议层
 ├── http_request()
 └── http_response()

websocket.c：WebSocket 协议层
 ├── ws_request()
 └── ws_response()

本节最重要的调用链：

clientfd 出现 EPOLLIN
 ↓
recv_cb() 调用 recv()
 ↓
http_request() / ws_request()
 ↓
set_event(fd, EPOLLOUT, 0)
 ↓
clientfd 出现 EPOLLOUT
 ↓
send_cb()
 ↓
http_response() / ws_response()
 ↓
send()
 ↓
set_event(fd, EPOLLIN, 0)

因此，Reactor 与协议层的分工是：

reactor.c → 关心 fd 是否可读、可写，以及 recv/send
webserver.c → 关心 HTTP 请求和 HTTP 响应
websocket.c → 关心握手、帧解码和帧编码

二、LT 与 ET

2.1 LT：水平触发

只要内核接收缓冲区中还有数据，LT 就会继续报告可读事件。

例如客户端发送 32 字节，服务端一次只接收 10 字节：

第一次 recv：10 字节，剩余 22
第二次 recv：10 字节，剩余 12
第三次 recv：10 字节，剩余 2
第四次 recv：2 字节，接收完成

2.2 ET：边沿触发

ET 主要关注从“没有数据”到“有数据”的状态变化。收到一次通知后，应在当前回调中尽量把数据处理完。

当前代码在 accept_cb() 中这样注册客户端：

event_rigister(clientfd,EPOLLIN|EPOLLET);//|EPOLLET

这表示 clientfd 使用 ET，并且先关注可读事件。

ET 的处理思路：

accept_cb() → 持续 accept，直到当前没有新连接
recv_cb() → 持续 recv，直到当前数据读完
send_cb() → 持续推进发送，直到发完或暂时不可写

循环读取时要配合非阻塞 fd。当前没有更多数据时，recv() 返回 -1，并且 errno 为 EAGAIN 或 EWOULDBLOCK，这表示本轮读取结束，应回到事件循环。

LT 和 ET 都不能决定 HTTP 请求或 WebSocket 帧是否完整。TCP 是字节流，协议层仍然需要根据协议格式判断消息边界。

三、`recv_cb()`：从网络层进入协议层

本节使用你提交的原代码：

int recv_cb(int fd){
 memset(conn_list[fd].rbuffer,0,BUFFER_LENGTH);
	int count = recv(fd, conn_list[fd].rbuffer, BUFFER_LENGTH, 0);
	if (count == 0) { // disconnect
		printf("client disconnect: %d\n", fd);
		close(fd);

 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);//unfinished

		return -1;

				}else if(count<0){
 printf("count:%d,errno:%d ,%s\n", count,errno,strerror(errno));
		 close(fd);
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);//unfinished
 return 0;
 }
 conn_list[fd].rlength=count;
 // printf("RECV: %s\n", conn_list[fd].rbuffer);
#if 0//echo
 conn_list[fd].wlength=conn_list[fd].rlength;
 memcpy(conn_list[fd].wbuffer,conn_list[fd].rbuffer,conn_list[fd].wlength);
 printf("[%d]RECV: %s\n",conn_list[fd].rlength,conn_list[fd].rbuffer);
#elif0
 http_request(&conn_list[fd]);
#else 
 ws_request(&conn_list[fd]);
#endif

 set_event(fd,EPOLLOUT,0);
 return count;
}

3.1 接收数据

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

数据从内核 socket 接收缓冲区复制到当前连接的 rbuffer，实际接收长度保存到：

conn_list[fd].rlength=count;

3.2 三种业务切换

Echo 分支把收到的数据复制到写缓冲区：

#if 0//echo
 conn_list[fd].wlength=conn_list[fd].rlength;
 memcpy(conn_list[fd].wbuffer,conn_list[fd].rbuffer,conn_list[fd].wlength);
 printf("[%d]RECV: %s\n",conn_list[fd].rlength,conn_list[fd].rbuffer);

HTTP 分支把连接对象交给 `http_request()`：

```c
#elif0
 http_request(&conn_list[fd]);
```

WebSocket 分支把连接对象交给 `ws_request()`：

```c
#else 
 ws_request(&conn_list[fd]);
```

三种业务共用同一个 `recv_cb()`，只替换上层协议处理函数。这正是 Reactor 与业务分层后的好处。

3.3 从读事件切换到写事件

set_event(fd,EPOLLOUT,0);

http_request() 或 ws_request() 处理完输入后，当前 fd 改为关注 EPOLLOUT。等 socket 可写时，Reactor 会调用 send_cb()。

四、HTTP 请求：`http_request()`

浏览器访问服务器时，会发送类似内容：

GET / HTTP/1.1
Host: 172.16.145.129:2000
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: text/html,application/xhtml+xml,application/xml
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

请求由请求行、请求头、空行和可选 body 组成：

GET / HTTP/1.1 → 请求行
Host → 请求头
Connection → 请求头
User-Agent → 请求头
空行 → 请求头结束

原代码：

int http_request(struct conn *c){
 //printf("request: %s\n",c->rbuffer);
 memset(c->wbuffer,0,BUFFER_LENGTH);
 c->wlength=0;
 c->status=0;
}

当前 http_request() 主要完成一次新响应的状态初始化：

c->rbuffer → 当前 HTTP 请求
c->wbuffer → 清空，准备写响应
c->wlength → 置 0
c->status → 置 0，从响应状态机起点开始

它位于：

recv_cb() 之后
send_cb() 之前

五、HTTP 响应：直接返回 HTML

原代码：

int http_response(struct conn *c){
#if 1
 c->wlength=sprintf(c->wbuffer,"HTTP/1.1 200 OK\r\n"
 "Content-Type: text/html\r\n"
 "Accept-Ranges: bytes\r\n"
 "Content-Length: 82\r\n"
 "Date: Tue,30 Apr 2024 13:16:46 GMT\r\n\r\n"
 "<html><head><title>0voice.king</title></head><body><h1>King</h1></body></html>\r\n\r\n");
 return 0;

其中：

HTTP/1.1 200 OK
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 82
Date: Tue,30 Apr 2024 13:16:46 GMT

是 HTTP 状态行和响应头。它们告诉浏览器响应是否成功、body 是什么类型、长度是多少。

下面是 HTTP body：

<html><head><title>0voice.king</title></head><body><h1>King</h1></body></html>

浏览器看到 Content-Type: text/html 后，会把 body 当作 HTML 渲染，页面中显示 King。

这一分支中，HTTP 头和 body 一起写入：

c->wbuffer

总长度由 sprintf() 的返回值保存到：

c->wlength

调用链：

recv_cb()
 ↓
http_request()
 ↓
设置 EPOLLOUT
 ↓
send_cb()
 ↓
http_response()
 ↓
HTTP 头和 HTML 写入 wbuffer
 ↓
send()

六、返回 `index.html`

原代码：

#elif 0
 int filefd =open("index.html",O_RDONLY);
 struct stat stat_buf;
 fstat(filefd,&stat_buf);
 c->wlength=sprintf(c->wbuffer,"HTTP/1.1 200 OK\r\n"
 "Content-Type: text/html\r\n"
 "Accept-Ranges: bytes\r\n"
 "Content-Length: %ld\r\n"
 "Date: Tue,30 Apr 2024 13:16:46 GMT\r\n\r\n",
 stat_buf.st_size);

 int count=read(filefd,c->wbuffer+c->wlength,BUFFER_LENGTH-c->wlength);
 c->wlength +=count;

 close(filefd);

执行过程：

open("index.html")
 ↓
fstat() 得到文件大小
 ↓
HTTP 响应头写入 wbuffer
 ↓
read() 把 index.html 追加在 HTTP 头后面
 ↓
wlength = HTTP 头长度 + 本次文件读取长度
 ↓
send_cb() 发送整个 wbuffer

stat_buf.st_size 被写入：

Content-Length: 文件大小

这个分支的特点是：HTTP 头和文件内容都先进入应用层 wbuffer，然后统一调用 send()。

七、状态机与 `sendfile()`

当一个响应需要多个发送阶段时，课程使用 status 保存当前进度：

status = 0 → 构造并发送 HTTP 头
status = 1 → 持续发送文件
status = 2 → 文件发送结束，清理状态

原代码：

#elif 0
 int filefd =open("index.html",O_RDONLY);
 struct stat stat_buf;
 fstat(filefd,&stat_buf);
 if(c->status==0){
 c->wlength=sprintf(c->wbuffer,"HTTP/1.1 200 OK\r\n"
 "Content-Type: text/html\r\n"
 "Accept-Ranges: bytes\r\n"
 "Content-Length: %ld\r\n"
 "Date: Tue,30 Apr 2024 13:16:46 GMT\r\n\r\n",
 stat_buf.st_size);
 c->status=1;
 }else if (c->status==1){
 int ret=sendfile(c->fd,filefd,NULL,stat_buf.st_size);
 if(ret==-1){
 printf("error:%d\n",errno);
 }
 //c->wlength=0;
 memset(c->wbuffer,0,BUFFER_LENGTH);
 c->status=2;
 }else if(c->status==2){

 c->wlength=0;
 memset(c->wbuffer,0,BUFFER_LENGTH);
 c->status=0;
 }
 close(filefd);

状态流转：

第一次进入 http_response()
 ↓ status == 0
构造 HTTP 响应头
 ↓ status = 1
send_cb() 发送 wbuffer，并继续关注 EPOLLOUT
 ↓
第二次进入 http_response()
 ↓ status == 1
sendfile() 发送 index.html
 ↓ status = 2
继续关注 EPOLLOUT
 ↓
第三次进入 http_response()
 ↓ status == 2
清理 wbuffer 和 wlength
 ↓ status = 0
重新关注 EPOLLIN

sendfile() 直接建立文件 fd 到 socket fd 的发送路径：

int ret=sendfile(c->fd,filefd,NULL,stat_buf.st_size);

协议层仍然负责构造 HTTP 头，sendfile() 负责发送文件内容。状态机把两个阶段连接起来。

八、返回图片

图片与 HTML 在网络层都是字节数据，主要区别是 HTTP 的 Content-Type。

原代码：

#else
int filefd =open("vip.png",O_RDONLY);
 struct stat stat_buf;
 fstat(filefd,&stat_buf);
 if(c->status==0){
 c->wlength=sprintf(c->wbuffer,"HTTP/1.1 200 OK\r\n"
 "Content-Type: image/png\r\n"
 "Accept-Ranges: bytes\r\n"
 "Content-Length: %ld\r\n"
 "Date: Tue,30 Apr 2024 13:16:46 GMT\r\n\r\n",
 stat_buf.st_size);
 c->status=1;
 }else if (c->status==1){
 int ret=sendfile(c->fd,filefd,NULL,stat_buf.st_size);
 if(ret==-1){
 printf("error:%d\n",errno);
 }
 //c->wlength=0;
 memset(c->wbuffer,0,BUFFER_LENGTH);
 c->status=2;
 }else if(c->status==2){

 c->wlength=0;
 memset(c->wbuffer,0,BUFFER_LENGTH);
 c->status=0;
 }
 close(filefd);

与 HTML 文件的区别：

响应内容	打开的文件	Content-Type
网页	`index.html`	`text/html`
PNG 图片	`vip.png`	`image/png`

Reactor 的 recv_cb()、send_cb() 不需要知道 body 是网页还是图片。WebServer 协议层设置正确的响应头即可。

九、`send_cb()` 如何驱动多阶段发送

原代码：

int send_cb(int fd){
#if 0

 http_response(&conn_list[fd]);

#else
 ws_response(&conn_list[fd]);

#endif
 int count=0;
 if(conn_list[fd].status==1){
 //printf("SEND:%s\n",conn_list[fd].wbuffer);
 count = send(fd, conn_list[fd].wbuffer,conn_list[fd].wlength, 0);
 set_event(fd,EPOLLOUT,0);
}else if(conn_list[fd].status==2){
 set_event(fd,EPOLLOUT,0);
}else if(conn_list[fd].status==0){
 if(conn_list[fd].wlength !=0){
 count = send(fd, conn_list[fd].wbuffer,conn_list[fd].wlength, 0); 
 }
 set_event(fd,EPOLLIN,0);
}
 //set_event(fd,EPOLLOUT,0);
 return count;
}

9.1 选择协议响应

学习 HTTP 时，让写回调进入：

#if 0

 http_response(&conn_list[fd]);

学习 WebSocket 时，让写回调进入：

#else
 ws_response(&conn_list[fd]);

9.2 状态与事件切换

status == 1
 → send() 发送当前 wbuffer
 → 继续设置 EPOLLOUT
 → 等待下一阶段

status == 2
 → 继续设置 EPOLLOUT
 → 进入状态机清理阶段

status == 0
 → 如果 wlength 不为 0，就发送当前数据
 → 设置 EPOLLIN
 → 等待下一次请求

这就是“需要发送多次时怎么办”的答案：

保存当前发送状态，再通过后续的 EPOLLOUT 事件继续推进，而不是把整个过程强行塞进一次回调。

十、WebSocket 握手

WebSocket 用于浏览器与服务器之间的长连接和双向通信。

建立 WebSocket 连接时，浏览器先发送 HTTP Upgrade 请求，其中包括：

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: T29c4Rys861qGqbGGNdkwA==
Sec-WebSocket-Version: 13

你提交的 WebSocket 代码：

#include"server.h"
#include<stdio.h>
#define GUID "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
/*
Key："T29c4Rys861qGqbGGNdkwA=="
T29c4Rys861qGqbGGNdkwA==258EAFA5-E914-47DA-95CA-C5AB0DC85B11
SHA-1

20 bytes
base64

handshake

transmission
decode
encode

*/

服务端计算 Sec-WebSocket-Accept 的过程：

客户端 Sec-WebSocket-Key
 +
固定 GUID
 ↓
SHA-1
 ↓
160 bit = 20 bytes
 ↓
Base64
 ↓
Sec-WebSocket-Accept

固定 GUID：

#define GUID "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"

客户端 Key 放在前面，GUID 放在后面。

服务端响应格式：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 计算结果

返回 101 后，同一个 TCP 连接不再传输普通 HTTP 消息，而是进入 WebSocket 帧传输阶段。

十一、WebSocket 在 Reactor 中的位置

原代码：

int ws_request(struct conn *c){
 printf("request: %s",c->rbuffer);
}

int ws_response(struct conn *c){
 
}

当前两个函数是课程为后续实现预留的协议接口。

ws_request() 后续负责：

握手阶段 → 解析 HTTP Upgrade 请求和 Sec-WebSocket-Key
传输阶段 → 解析 WebSocket frame，完成 decode

ws_response() 后续负责：

握手阶段 → 构造 101 和 Sec-WebSocket-Accept
传输阶段 → 把文本或二进制业务数据 encode 成 WebSocket frame

在 Reactor 中的调用位置：

EPOLLIN
 ↓
recv_cb()
 ↓
ws_request()
 ↓
设置 EPOLLOUT
 ↓
send_cb()
 ↓
ws_response()
 ↓
send()

WebSocket 是应用层协议，底层仍然是普通 TCP clientfd。Reactor 不需要为 WebSocket 创建一种新 fd。

十二、使用 wrk 测试 WebServer

测试命令：

wrk -t10 -c50 -d10s http://172.16.145.129:2000/

课程中的测试现象：

打印每次 request 和 Host 数据时：QPS 约 1.5 万
关闭逐请求打印后：QPS 约 4.5 万

逐请求打印会产生格式化、终端输出和系统调用开销，因此会明显降低服务器吞吐量。

wrk 结果中主要关注：

Requests/sec → 每秒请求数，即 QPS
Latency → 请求延迟
timeout → 超时数量
read/write → 读写错误
Transfer/sec → 每秒传输数据量

局域网延迟较小；公网还会受到网络时延、丢包、带宽和中间设备影响。

十三、Connection reset by peer

Connection reset by peer 表示连接被对端通过 TCP RST 重置。

常见情况：

客户端提前关闭连接
压测工具结束请求
服务器准备发送时客户端已经退出
网络设备重置连接

服务器应识别错误并清理当前连接，不要让单个客户端断开导致整个进程退出。

十四、本节课的三个重点

重点一：事件与协议函数的对应关系

clientfd + EPOLLIN
 → recv_cb()
 → http_request() / ws_request()

clientfd + EPOLLOUT
 → send_cb()
 → http_response() / ws_response()

重点二：网络层与协议层分离

reactor.c
 → 管理 fd、事件、recv、send

webserver.c
 → 处理 HTTP request 和 response

websocket.c
 → 处理 handshake、decode 和 encode

重点三：多次发送使用状态机

一次发送即可完成
 → wbuffer + wlength

需要多个发送阶段
 → status 保存进度
 → 多次 EPOLLOUT 推进

发送静态文件
 → HTTP 头放入 wbuffer
 → 文件内容交给 sendfile()

最终理解：

Reactor 提供统一的事件驱动网络层；HTTP 和 WebSocket 负责协议，业务数据何时读取、何时发送，由 fd 的事件和回调共同驱动。

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、内存、端口空间、内核网络栈和压测方法等系统性限制。

IO 多路复用与 Reactor

Fri, 07 Aug 2026 00:00:00 +0800

1. 为什么需要 IO 多路复用

网络服务器主要管理两类 socket：

监听 socket（listenfd / 代码中的 sockfd） 它出现可读事件，通常表示已经完成 TCP 握手的连接正在等待 accept()。
已连接 socket（clientfd / connfd） 它出现可读事件，可能表示收到了数据，也可能表示对端关闭连接；随后由 recv() 判断具体情况。它也可能出现可写、错误、挂断等事件。

最直接的服务器模型是“一连接一线程”：主线程执行 accept()，每建立一个连接便创建一个线程，由该线程阻塞在 recv() 上。

int clientfd = accept(sockfd, ...);
pthread_create(&thid, NULL, client_thread, &clientfd);

这种模型的优点是代码直观，一个线程可以按顺序处理一个连接的收、发逻辑。缺点是连接数增加时，需要大量线程；线程会占用栈空间和内核资源，还会产生调度及上下文切换成本。许多长连接大部分时间并没有数据，线程却仍然存在，因此不适合大量空闲连接并发存在的场景。

IO 多路复用的核心思想：让一个线程同时等待多个 fd。线程不再阻塞于某一个 recv()，而是阻塞在 select()、poll() 或 epoll_wait() 上；哪些 fd 已经就绪，线程就处理哪些 fd。

“多路”指多个 IO/fd，“复用”指复用同一个线程进行等待和处理。它复用的是等待能力，并不会自动并行执行业务代码。

2. “IO 就绪”与“完成 IO”

select、poll、epoll 提供的是就绪通知机制：

监听 fd 可读：通常可以调用 accept()。
客户端 fd 可读：可以调用 recv()；也可能是对端关闭或发生错误。
客户端 fd 可写：内核发送缓冲区当前有空间，并不等于全部数据已经发送完成。

它们只告诉应用程序“现在适合尝试某项 IO 操作”，不会替应用程序完成请求解析、业务计算和响应组装。

一个长连接的生命周期会经历许多次事件，而不是“连接一次只触发一个事件”：

建立连接 → 收到请求 → 发送响应 → 再次收到请求 → …… → 断开连接

因此，用户在线数或 TCP 连接数并不等于同一时刻的活跃请求数。例如服务器可能维护 100 万个连接，但某一时刻只有 1 万个连接真正产生事件。高并发服务器真正希望快速取得并处理的是这 1 万个就绪 fd。

3. select

3.1 接口

int select(int nfds,
 fd_set *readfds,
 fd_set *writefds,
 fd_set *exceptfds,
 struct timeval *timeout);

五类参数的含义：

nfds：三个集合中最大 fd 值加 1，而不是 fd 的数量。
readfds：关注可读事件的 fd 集合。
writefds：关注可写事件的 fd 集合。
exceptfds：关注异常条件的 fd 集合；它并不是所有网络错误的统一集合。
timeout：最长等待时间。
- NULL：一直阻塞，直到出现事件或被信号中断。
- {0, 0}：立即返回，成为轮询。
- 指定时间：超时后返回 0，可让事件循环顺便检查定时任务，但精确定时器通常还需要专门的数据结构。

返回值：

> 0：返回集合中就绪项的数量。
= 0：超时。
= -1：调用失败，例如被信号中断时 errno == EINTR。

3.2 如何理解 fd_set

fd_set 可以理解成一个位图集合：fd 是非负整数，位图中编号为 fd 的那一位表示该 fd 是否属于集合。

fd 编号： 0 1 2 3 4 5 6 7 8
位图值： 0 0 0 1 1 1 1 0 0
 ↑
 关注 3、4、5、6

常用宏：

FD_ZERO(&set); // 清空集合
FD_SET(fd, &set); // 加入 fd
FD_CLR(fd, &set); // 移除 fd
FD_ISSET(fd, &set); // 判断 fd 是否位于集合中

在典型 Linux/glibc 环境中，FD_SETSIZE 为 1024，fd_set 可表示编号 0～1023 的 fd，通常占 1024 bit，即 128 byte。但应以当前平台的 FD_SETSIZE 和 sizeof(fd_set) 为准。

需要注意：在 Linux 上，仅仅尝试修改 FD_SETSIZE 并不能可靠地突破 select() 的 1024 fd 限制；处理大量 fd 应改用 poll 或 epoll。此外，“最多 1024 个 fd”并不完全等于“最多 1024 个客户端”，因为进程还会占用标准输入输出、监听 socket、文件等其他 fd，而且 fd 编号必须小于 FD_SETSIZE。

3.3 为什么代码需要 rfds 和 rset 两份集合

附件代码中：

fd_set rfds, rset;
FD_ZERO(&rfds);
FD_SET(sockfd, &rfds);

while (1) {
 rset = rfds;
 int nready = select(maxfd + 1, &rset, NULL, NULL, NULL);
 ...
}

原因是 select() 的 fd 集合是传入兼传出参数：

调用前，集合表示“应用程序关注哪些 fd”。
返回后，集合被改写，只保留本次已经就绪的 fd。

因此：

rfds 保存长期关注的完整集合（整集）。
rset 是每次调用时复制出的工作集合，返回后用于判断本轮哪些 fd 就绪。

代码先判断监听 fd：

if (FD_ISSET(sockfd, &rset)) {
 int clientfd = accept(sockfd, ...);
 FD_SET(clientfd, &rfds);
}

然后从较小 fd 一直扫描到 maxfd，找出就绪客户端并执行 recv()：

for (int i = sockfd + 1; i <= maxfd; i++) {
 if (FD_ISSET(i, &rset)) {
 recv(i, ...);
 }
}

3.4 优缺点

优点：

一个线程可以等待多个 fd。
跨 Unix 类系统的可移植性较好。
fd 数量较少时足够简单实用。

缺点：

每次调用都要把集合从用户态复制到内核态，返回时还要复制回来。
内核需要检查关注集合；应用层也要扫描到 maxfd 才知道谁就绪。
集合会被改写，调用前必须重新准备。
Linux 上受 FD_SETSIZE 限制。
参数和集合管理较烦琐。

4. poll

4.1 数据结构与接口

poll 使用结构体数组描述关注对象：

struct pollfd {
 int fd; // 被监控的 fd
 short events; // 输入：关注的事件
 short revents; // 输出：实际发生的事件
};

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

常见事件包括：

POLLIN：可读。
POLLOUT：可写。
POLLERR：发生错误。
POLLHUP：挂断。
POLLNVAL：fd 无效。

timeout 的单位是毫秒：

-1：一直阻塞。
0：立即返回。
> 0：最多等待指定毫秒数。

与 select 相比，pollfd 把“关注的事件”和“实际发生的事件”分开，因此不必在每轮调用前重建整个关注集合。它也没有 FD_SETSIZE 这种固定位图上限；实际容量仍受进程 fd 限额和内存限制。

4.2 poll 是否从根本上解决了性能问题

没有。每次调用 poll() 时，仍需把 pollfd 数组交给内核；内核和应用层仍需要在数组中检查事件。因此大量 fd 中只有少量就绪时，工作量仍与整个关注集合的规模相关。

poll 的主要价值是接口更统一、没有 select 的固定 fd 编号限制，而不是在大量连接场景中获得 epoll 那种只返回就绪项的机制。

适合场景通常包括：

需要比 select 更方便的事件表达方式。
fd 数量不特别大。
需要较好的 Unix 平台可移植性，而不能使用 Linux 专有的 epoll。

4.3 附件 poll 代码中的两个重要问题

原代码连续调用了两次 poll()：

poll(fds, maxfd + 1, -1);
int nready = poll(fds, maxfd + 1, -1);

第一次调用已经取得事件，第二次又重新阻塞；应删除第一次，只保留：

int nready = poll(fds, maxfd + 1, -1);

此外，代码用 fd 值作为数组下标，但数组被 {0} 初始化。未使用位置的 fd 因而是 0，会意外重复监控标准输入。poll 约定 fd < 0 的项会被忽略，因此所有空槽应初始化为 -1。更常见的写法是紧凑地保存有效 pollfd 项，而不是把 fd 直接当数组下标。

5. epoll

epoll 是 Linux 专用的 IO 事件通知机制。它将“维护关注集合”和“等待就绪事件”拆开，尤其适合大量连接、少量活跃的服务器场景。

5.1 三个核心接口

1. 创建 epoll 实例

int epfd = epoll_create(1);

返回的 epfd 本身也是一个 fd，代表一个内核中的 epoll 实例。较新的代码通常使用：

int epfd = epoll_create1(EPOLL_CLOEXEC);

epoll_create(size) 的 size 在现代 Linux 中已被忽略，但必须大于 0；保留它是为了兼容旧接口。它不是“单次最多返回多少个就绪事件”。单次最多返回多少项由 epoll_wait() 的 maxevents 决定。

2. 增删改关注对象

int epoll_ctl(int epfd, int op, int fd,
 struct epoll_event *event);

三种操作：

EPOLL_CTL_ADD：加入一个 fd。
EPOLL_CTL_DEL：删除一个 fd。
EPOLL_CTL_MOD：修改该 fd 关注的事件或关联数据。

事件结构体：

struct epoll_event {
 uint32_t events; // EPOLLIN、EPOLLOUT 等
 epoll_data_t data; // 可保存 fd、指针等用户数据
};

附件先注册监听 fd：

ev.events = EPOLLIN;
ev.data.fd = sockfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);

accept() 得到新客户端后，再单独将 clientfd 加入关注集合。

3. 等待就绪事件

int nready = epoll_wait(epfd, events, maxevents, timeout);

events：用户提供的结果数组，用来接收本次就绪项。
maxevents：结果数组最多能装多少项，必须大于 0；它不是 epoll 能管理的 fd 总数。
timeout：-1 一直等待，0 立即返回，正数表示最多等待的毫秒数。
返回值：本轮写入 events 数组的就绪项数，超时返回 0，失败返回 -1。

应用只需遍历 events[0..nready-1]：

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

5.2 “整集”和“就绪集”

从概念上看，epoll 实例在内核中维护两个重要集合：

关注集合（interest list）：应用通过 epoll_ctl() 增、删、改的所有 fd。
就绪集合（ready list）：其中当前有事件需要应用处理的 fd。

传统实现说明中常把关注集合描述为红黑树、就绪集合描述为链表。但这些属于 Linux 内核实现细节，理解接口时更重要的是“长期关注集合”和“当前就绪集合”的分离，不应让业务代码依赖具体内部数据结构。

5.3 为什么 epoll 更适合大并发

以 100 万个连接、当前 1 万个连接活跃为例：

select/poll：每轮等待都需要提交并检查规模接近 100 万的关注集合，应用还要从大集合里寻找就绪项。
epoll：连接建立或状态变化时，通过 epoll_ctl() 增量维护关注集合；epoll_wait() 主要把当前就绪项返回给应用，应用遍历约 1 万个结果。

因此，epoll 的优势不应简单概括成“完全没有遍历或拷贝”，而应表述为：

不必在每次等待时重新提交整个关注集合。
应用遍历的是本轮返回的就绪项，而不是从 0 扫描至最大 fd。
连接管理是增量进行的，适合大量长连接中只有少量活跃的情形。

不过，epoll 不会消除业务处理、数据复制、系统调用等全部成本；当绝大部分连接始终活跃时，它相对 poll 的优势也会缩小。

5.4 LT 与 ET

epoll 有两种常见触发方式：

LT（Level Triggered，水平触发）：默认方式。只要 fd 仍处于就绪状态，后续 epoll_wait() 还会继续报告，较容易编写。
ET（Edge Triggered，边沿触发）：只有状态发生变化时重点通知。通常必须配合非阻塞 fd，并持续 accept() / recv() / send()，直到返回 -1 且 errno 为 EAGAIN 或 EWOULDBLOCK，否则可能遗漏尚未处理完的数据。

附件只设置了 EPOLLIN，没有设置 EPOLLET，因此使用的是 LT。

6. 从 IO 多路复用到 Reactor

select、poll、epoll 解决的是：

哪些 fd 上发生了应用关心的 IO 事件？

但实际服务器还需要解决：

某类事件发生以后，应当执行哪段业务逻辑？

Reactor 是一种事件驱动的程序组织模式。应用先把“事件”和“处理函数”注册起来；事件循环等待事件，事件发生后再把它分派给对应处理函数。

注册 fd + 关注事件 + 回调函数
 ↓
 select / poll / epoll 等待
 ↓
 得到就绪事件
 ↓
 Reactor 分派事件
 ↓
 accept_cb / recv_cb / send_cb

例如：

listenfd + READ -> accept_cb()
clientfd + READ -> recv_cb()
clientfd + WRITE -> send_cb()

因此，可以把两者的关系概括为：

select/poll/epoll 是底层的事件检测或事件分离机制。
Reactor 是上层的事件注册、循环等待和回调分派模式。
Reactor 关注的中心从“对某个 fd 写一段固定流程”转为“某个 fd 的某种事件应该调用哪个 handler”。

它和路由有相似之处：路由根据请求路径找到处理器，Reactor 根据 fd 上发生的事件找到处理器。但 Reactor 还负责事件监听、生命周期管理和持续循环，因此不能简单等同于路由。

典型 Reactor 由以下部分组成：

事件源：监听 socket、客户端 socket、定时器等。
事件多路分离器：select、poll 或 epoll。
Reactor / Dispatcher：事件循环与分派器。
Handler / Callback：处理连接、读取、写入、关闭等事件的函数。

Reactor 只是组织 IO 事件处理的模式，并不意味着业务一定只使用一个线程。常见结构包括：

单 Reactor、单线程。
单 Reactor + 工作线程池。
主 Reactor 负责接收连接，多个从 Reactor 负责已连接 socket，再配合工作线程池。

耗时业务不能长期阻塞事件循环，否则一个回调会拖延其他连接；CPU 密集型或阻塞型任务通常交给工作线程池。

7. 三种工具对比

特性	select	poll	epoll
平台	多种 Unix 类系统	多种 Unix 类系统	Linux
关注集合表示	`fd_set` 位图	`pollfd` 数组	内核维护的 epoll 关注集合
每轮是否重新提交整个关注集合	是	是	否，使用 `epoll_ctl` 增量维护
应用如何找就绪项	扫描到 `maxfd`	扫描数组	遍历 `epoll_wait` 返回的就绪数组
固定 1024 fd 编号限制	Linux 上通常有	无此固定限制	无此固定限制
主要适用情况	fd 较少、重视可移植性	fd 中等、重视可移植性和统一事件接口	Linux 大量连接、少量活跃

不能笼统地说谁在所有场景下一定最快。fd 很少时差别可能很小；平台兼容性、接口复杂度、连接活跃比例和业务负载都应纳入选择。

8. 附件代码的演进关系

代码使用条件编译展示了四个阶段：

单连接阻塞处理
 ↓
循环 accept，但一个连接的 recv 会阻塞后续连接
 ↓
一连接一线程，逻辑简单但线程成本随连接数增长
 ↓
select / poll / epoll，一个线程等待多个 fd
 ↓
进一步封装事件、状态与回调，即 Reactor

当前真正编译的是最后的 #else，即 epoll 版本；前面的分支因为使用 #if 0 / #elif 0 而不会参与编译。

9. 先记住三套代码共同的骨架

学习这三个接口时，不要一开始背所有参数。先固定服务器永远重复的四步：

1. 注册：告诉系统要关注哪些 fd、哪些事件
2. 等待：阻塞到至少一个事件发生
3. 分发：判断是监听 fd，还是客户端 fd
4. 更新：新连接加入，断开的连接删除，需要时修改关注事件

把三种接口代入同一骨架：

阶段	select	poll	epoll
保存关注对象	`fd_set rfds`	`struct pollfd fds[]`	内核中的 epoll 关注集合
注册新客户端	`FD_SET(clientfd, &rfds)`	添加一个 `pollfd`	`epoll_ctl(...ADD...)`
等待事件	`select(...)`	`poll(...)`	`epoll_wait(...)`
找出就绪对象	扫描并调用 `FD_ISSET`	扫描并检查 `revents`	直接遍历返回的 `events`
删除客户端	`FD_CLR(fd, &rfds)`	删除数组项或设为 `-1`	`epoll_ctl(...DEL...)`

下面三段代码都实现同一个核心功能：

监听 fd 可读 → accept 新连接 → 注册 clientfd
clientfd 可读 → recv 数据 → send 回显
连接关闭/出错 → 删除 clientfd → close

为了突出多路复用主干，示例省略了非阻塞设置、完整发送缓冲区、信号处理等生产级细节。

10. select 核心代码逐段对照

10.1 初始化：建立长期关注集合

fd_set rfds, rset; // 完整关注集合、本轮就绪集合
FD_ZERO(&rfds); // 初始为空
FD_SET(sockfd, &rfds); // 首先关注监听 fd

int maxfd = sockfd; // select 要知道最大的 fd

此时可以想象：

rfds = { sockfd }

10.2 每轮复制并等待

while (1) {
 rset = rfds;
 int nready = select(maxfd + 1, &rset, NULL, NULL, NULL);

这里两个集合的职责一定要分清：

调用前：rfds = 长期关注的完整集合
 rset = 复制品，也包含完整集合

返回后：rfds = 保持不变，供下一轮继续使用
 rset = 被 select 改写，只保留本轮就绪 fd

maxfd + 1 中的 +1 是因为 nfds 表示检查区间的右边界：内核检查 fd 0 到 maxfd，即 [0, maxfd + 1)。

10.3 监听 fd 就绪：接收并注册新连接

 if (FD_ISSET(sockfd, &rset)) {
 // sockfd 可读不是有业务数据，而是有连接可以取出
 int clientfd = accept(sockfd,
 (struct sockaddr *)&clientaddr,
 &len);

 // accept 不会删除 sockfd；它返回一个新的 clientfd
 FD_SET(clientfd, &rfds);

 if (clientfd > maxfd)
 maxfd = clientfd;
 }

要点：

检查的是返回集合 rset，因为要问“本轮谁就绪”。
新连接加入的是长期集合 rfds，因为要从下一轮开始持续关注它。
accept() 从已完成连接队列取出一个连接，但 sockfd 仍然继续监听。
新 clientfd 本轮不在 rset 中，从下一轮开始接受监控。

10.4 扫描客户端：处理并删除

 for (int fd = sockfd + 1; fd <= maxfd; ++fd) {
 if (!FD_ISSET(fd, &rset))
 continue; // 这个 fd 本轮不可读

 char buffer[1024] = {0};
 int count = recv(fd, buffer, sizeof(buffer), 0);

 if (count > 0) {
 send(fd, buffer, count, 0); // Echo：原样回发
 } else {
 // count == 0 表示对端关闭；教学代码也在出错时删除
 FD_CLR(fd, &rfds);
 close(fd);
 }
 }
}

这里的“可读”应理解为：现在调用读取类操作能够立即得到结果，而不会因为没有事件一直阻塞：

监听 fd 可读 → 调用 accept()，取出一个连接
客户端 fd 可读 → 调用 recv()，读取数据或得知对端关闭

maxfd = sockfd 也不是说监听 fd 永远最大，而是初始化时集合中只有 sockfd。加入新客户端以后，再通过比较更新 maxfd。

select 版最值得背下来的代码主干是：

rset = rfds;
nready = select(maxfd + 1, &rset, NULL, NULL, NULL);

if (FD_ISSET(sockfd, &rset)) {
 clientfd = accept(...);
 FD_SET(clientfd, &rfds);
}

for (fd = sockfd + 1; fd <= maxfd; fd++) {
 if (FD_ISSET(fd, &rset))
 recv(fd, ...);
}

记忆关键词：复制集合、maxfd + 1、扫描、FD_ISSET。

11. poll：对照附件代码理解

你的写法直接把 fd 当作 fds 数组下标：fd 3 放在 fds[3]，fd 4 放在 fds[4]。下面保留这种写法，方便和原代码逐行对应。

11.1 初始化数组

#define MAX_FDS 1024

struct pollfd fds[MAX_FDS];

// poll 会忽略 fd < 0 的项
for (int i = 0; i < MAX_FDS; ++i) {
 fds[i].fd = -1;
 fds[i].events = 0;
 fds[i].revents = 0;
}

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

int maxfd = sockfd;

此时：

假设 sockfd = 3：

fds[3].fd = 3
fds[3].events = POLLIN

events = POLLIN 表示“我希望观察可读”，revents 表示 poll() 返回时“本轮实际发生了什么”。

11.2 等待事件

while (1) {
 int nready = poll(fds, maxfd + 1, -1);

调用前后：

events = 输入：希望关注什么
revents = 输出：实际上发生了什么

与 select 不同，events 不会被替换成就绪集合，因此下一轮通常不必重建所有关注事件；但应把 revents 当作当轮结果使用。

附件原本连续调用了两次 poll()，应删掉第一次，否则第一次取得事件后，第二次又会重新阻塞。

11.3 监听 fd 就绪：注册新客户端

 if (fds[sockfd].revents & POLLIN) {
 // 监听 fd 可读：取出一个新连接
 int clientfd = accept(sockfd,
 (struct sockaddr *)&clientaddr,
 &len);

 // clientfd 直接作为数组下标
 fds[clientfd].fd = clientfd;
 fds[clientfd].events = POLLIN;

 if (clientfd > maxfd)
 maxfd = clientfd;
 }

例如 sockfd = 3、accept() 返回 clientfd = 4：

fds[3] 管理监听 fd 3：可读时调用 accept()
fds[4] 管理客户端 fd 4：可读时调用 recv()

11.4 扫描客户端的 revents

 for (int fd = sockfd + 1; fd <= maxfd; ++fd) {
 if (!(fds[fd].revents & POLLIN))
 continue; // fd 本轮没有发生可读事件

 char buffer[1024] = {0};
 int count = recv(fd, buffer, sizeof(buffer), 0);

 if (count > 0) {
 send(fd, buffer, count, 0);
 } else {
 close(fd);
 fds[fd].fd = -1; // 让 poll 忽略这个位置
 fds[fd].events = 0;
 }
 }
}

poll 版最值得背下来的代码主干是：

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

nready = poll(fds, maxfd + 1, -1);

for (fd = sockfd + 1; fd <= maxfd; ++fd) {
 if (fds[fd].revents & POLLIN)
 recv(fd, ...);
}

记忆关键词：events 是我想观察什么，revents 是本轮实际发生了什么。

12. epoll 核心代码逐段对照

epoll 的明显区别是：应用不再把完整关注数组传给每一次等待，而是提前通过 epoll_ctl() 增量维护关注集合。

12.1 创建实例并注册监听 fd

int epfd = epoll_create(1);

struct epoll_event ev;
ev.events = EPOLLIN;
ev.data.fd = sockfd;

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

此处可以理解为：

epoll_create：创建一个事件管理器
epoll_ctl ADD：向管理器登记“关注 sockfd 的可读事件”

其中 ev.data.fd = sockfd 可以看成给这次登记贴上“sockfd 身份标签”。内核会保存这个标签，等该 fd 就绪时再原样放进返回结果中。

12.2 等待并直接遍历就绪数组

while (1) {
 struct epoll_event events[1024] = {0};
 int nready = epoll_wait(epfd, events, 1024, -1);

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

这里两个变量要严格分开：

ev ：调用 epoll_ctl() 时送进去的登记卡
events[] ：调用 epoll_wait() 时拿回来的结果数组

例如注册时写入：

ev.data.fd = 3;
epoll_ctl(epfd, EPOLL_CTL_ADD, 3, &ev);

当 fd 3 可读时，epoll_wait() 可能返回：

nready = 1
events[0].data.fd = 3
events[0].events = EPOLLIN

所以 events[i].data.fd 不是凭空出现的，它就是注册时 ev.data.fd 中保存的身份标签。

12.3 监听 fd 就绪：ADD 新客户端

 if (fd == sockfd) {
 // 监听 fd 可读：从连接队列中取出一个连接
 int clientfd = accept(sockfd,
 (struct sockaddr *)&clientaddr,
 &len);

 // 给新客户端准备新的登记信息
 ev.events = EPOLLIN;
 ev.data.fd = clientfd;

 epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
 continue;
 }

accept() 不会删除监听 fd。假设 sockfd = 3、它返回 clientfd = 5，注册完成后可以这样理解：

fd 3 → 可读时返回标签 3 → 调用 accept()
fd 5 → 可读时返回标签 5 → 调用 recv()

12.4 客户端就绪：读取或 DEL

 if (events[i].events & EPOLLIN) {
 char buffer[1024] = {0};
 int count = recv(fd, buffer, sizeof(buffer), 0);

 if (count > 0) {
 send(fd, buffer, count, 0);
 } else {
 // 客户端断开：先从 epoll 删除，再关闭 fd
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 close(fd);
 }
 }
 }
}

epoll 版最值得背下来的代码主干是：

epfd = epoll_create(1);

ev.events = EPOLLIN;
ev.data.fd = sockfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);

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

for (i = 0; i < nready; i++) {
 fd = events[i].data.fd;
 if (fd == sockfd) {
 clientfd = accept(...);
 ev.events = EPOLLIN;
 ev.data.fd = clientfd;
 epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
 } else if (events[i].events & EPOLLIN) {
 recv(fd, ...);
 }
}

记忆关键词：create 创建、ctl 管理、wait 等待、只遍历就绪项。

13. 把三段代码放在一起看

13.1 注册客户端

// select：修改用户态位图
FD_SET(clientfd, &rfds);

// poll：修改用户态结构体数组
fds[clientfd].fd = clientfd;
fds[clientfd].events = POLLIN;

// epoll：通过系统调用修改内核关注集合
ev.events = EPOLLIN;
ev.data.fd = clientfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);

13.2 等待事件

// select：集合会被改写，所以先复制
rset = rfds;
nready = select(maxfd + 1, &rset, NULL, NULL, NULL);

// poll：传入完整 pollfd 数组
nready = poll(fds, maxfd + 1, -1);

// epoll：关注集合已在内核，只传结果数组
nready = epoll_wait(epfd, events, 1024, -1);

13.3 寻找就绪客户端

// select：监听 fd 已单独处理，这里遍历客户端 fd
for (fd = sockfd + 1; fd <= maxfd; ++fd)
 if (FD_ISSET(fd, &rset)) { ... }

// poll：遍历完整 pollfd 数组
for (fd = sockfd + 1; fd <= maxfd; ++fd)
 if (fds[fd].revents & POLLIN) { ... }

// epoll：遍历本轮就绪数组
for (i = 0; i < nready; ++i)
 if (events[i].events & EPOLLIN) { ... }

13.4 删除客户端

// select
FD_CLR(fd, &rfds);
close(fd);

// poll
close(fd);
fds[fd].fd = -1;
fds[fd].events = 0;

// epoll
epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
close(fd);

最核心的差别就体现在“完整集合放在哪里、每轮遍历谁”：

select：应用保存位图 → 每轮复制 → 扫描 0..maxfd
poll： 应用保存数组 → 每轮提交 → 扫描完整数组
epoll： 内核保存关注集合 → 每轮只取出并遍历就绪数组

总结

一连接一线程用线程等待每个连接；IO 多路复用让一个线程等待多个 fd；select 和 poll 每轮仍需处理整个关注集合，而 epoll 将关注集合长期维护在内核中并返回当前就绪项；Reactor再进一步把这些就绪事件分派给预先注册的回调函数，使服务器从“管理 fd”上升为“管理事件及其处理逻辑”。

网络 I/O 与 I/O 多路复用

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

一、网络 I/O 的使用场景

网络是后端服务开发中的重要环节。生活中大量功能都依赖客户端与服务端之间的网络通信。

1. 微信发送文字、语音和视频

当用户在微信发送消息时，大致过程是：

发送方微信
 ↓
通过网络将数据发送给微信服务器
 ↓
服务器找到接收方
 ↓
将数据转发给接收方微信

文字、语音、图片、视频在网络上传输时，最终都会被转换成字节数据。

网络 I/O 主要关心：

数据从哪里读取
数据向哪里发送
读取了多少字节
发送了多少字节

网络 I/O 本身并不关心这些字节具体表示文字、图片还是视频。

2. 刷抖音

刷视频时：

抖音 App 请求视频
 ↓
服务器返回视频信息和资源地址
 ↓
App 通过网络下载视频数据
 ↓
客户端解码并播放

通常视频会被切分成多个数据块，App 可以一边下载、一边播放。

3. 使用 `git clone`

执行：

git clone 仓库地址

大致过程是：

本地 Git 客户端连接 GitHub
 ↓
向 GitHub 请求仓库数据
 ↓
GitHub 通过网络发送 Git 对象
 ↓
本地接收、校验和解压
 ↓
形成本地仓库

代码能够到达本地，本质上也是客户端和 GitHub 服务端之间进行了网络 I/O。

这些场景都可以概括成：

客户端发起请求 → 服务端处理请求 → 服务端返回响应

二、什么是网络 I/O

网络 I/O 是建立在客户端和服务端之间的数据传输过程，类似二者之间连接的网络管道。例如十个客户端分别连接服务器，服务端通常会获得十个连接 fd：

客户端 A ←→ fd 4
客户端 B ←→ fd 5
客户端 C ←→ fd 6
...
客户端 J ←→ fd 13

随着客户端数量增加，fd 数量也会增加，于是就产生了一个重要问题：

服务端如何同时管理大量 fd？

这正是后面需要学习 select、poll 和 epoll 的原因。

三、socket 与 fd

在 Linux 中，Linux 通过 socket API 通信。创建 socket：

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

参数的含义：

AF_INET：IPv4
SOCK_STREAM：面向字节流，对应 TCP
0：使用该组合默认的 TCP 协议

fd 本质是进程中的非负整数（此处了解，记忆也没啥用）：

0：标准输入
1：标准输出
2：标准错误
3：监听 socket
4：客户端连接 A
5：客户端连接 B

在当前服务端进程中，一个已连接 socket 的 fd 通常对应一条 TCP 连接。（存在 ACCEPT 的情况）

四、TCP 服务端的简便理解

可以把 TCP 服务端理解成酒店：

socket()：聘请迎宾员
bind()：安排迎宾员在哪个门口工作
listen()：正式开始迎宾
accept()：接待一位到达的客人
recv()：听客人提出需求
send()：将处理结果交给客人
close()：结束服务

说说两类重要 fd：

1. 监听 fd

定义完 sockfd 经过 bind、listen 后，sockfd 就成为监听 fd。主要职责是监听新连接，不负责收发数据。

2. 连接 fd

参考代码中的 int clientfd = accept(sockfd, ...);。accept() 成功后会返回一个新的 fd：

sockfd：负责监听新客户端
clientfd：负责和某个客户端通信

关系如下：

 ┌→ clientfd 4 ←→ 客户端 A
listenfd → accept() ─┼→ clientfd 5 ←→ 客户端 B
 └→ clientfd 6 ←→ 客户端 C

监听 fd 通常只有一个，但每建立一个客户端连接，服务端就会获得一个新的连接 fd。

五、服务端代码执行流程

1. 创建 socket

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

作用：

在内核中创建 socket 对象。
返回一个 fd。
当前还没有绑定 IP 和端口。
当前也没有开始监听。

更准确的变量名可以理解为：

int listenfd;

因为它后面会被设置为监听 socket。

2. 准备服务器地址

struct sockaddr_in servaddr;

servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(2000);

`sin_family`

servaddr.sin_family = AF_INET;

表示使用 IPv4。

`INADDR_ANY`

servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

INADDR_ANY 表示监听本机所有 IPv4 网络接口，对应：

0.0.0.0

假设服务器有多个 IP：

127.0.0.1
192.168.1.10
10.0.0.10

绑定 0.0.0.0，表示这些本机地址上的 2000 端口都可以接收连接。

`htons()`

servaddr.sin_port = htons(2000);

htons 表示：

host to network short

它把主机字节序的 16 位端口号转换成网络字节序。

同理：

htonl

表示把 32 位数据从主机字节序转换成网络字节序。

端口范围是：

0～65535

通常：

0：让操作系统自动分配端口。
1～1023：传统意义上的特权端口。
1024～65535：普通程序通常可以使用。

但 1024 以上的端口也可能已经被其他程序占用。

3. 绑定 IP 和端口

bind(sockfd,
 (struct sockaddr *)&servaddr,
 sizeof(struct sockaddr));

bind() 将 socket 与本地 IP、端口建立联系：

sockfd ←→ 0.0.0.0:2000

可以理解为：

给迎宾人员安排具体的工作地点。

如果端口已经被其他服务绑定，可能出现：

Address already in use

你的代码通过下面的方式查看错误：

printf("bind error:%s\n", strerror(errno));

不过如果 bind() 失败，程序理论上不应该继续执行 listen()。

4. 进入监听状态

listen(sockfd, 10);

执行成功后，socket 从普通 socket 变成监听 socket。

此时可以使用：

ss -lntp | grep ':2000'

查看监听状态。

可能看到：

LISTEN 0 10 0.0.0.0:2000

5. 接收客户端连接

int clientfd = accept(
 sockfd,
 (struct sockaddr *)&clientaddr,
 &len
);

如果当前没有已经建立完成的客户端连接，阻塞模式下的 accept() 会暂停程序：

程序阻塞在 accept()
 ↓
等待客户端连接
 ↓
客户端完成 TCP 三次握手
 ↓
accept() 返回 clientfd

accept() 不会把原来的 sockfd 变成客户端连接。

它会返回一个全新的 clientfd。

六、代码中的三个服务端版本（代码文末附）

第一阶段：只处理一个客户端的一次数据

#if 0
 int clientfd = accept(...);

 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0);

 printf("RECV:%s\n", buffer);

 count = send(clientfd, buffer, count, 0);
#endif

执行过程：

accept 一个客户端
 ↓
recv 一次
 ↓
send 一次
 ↓
后面不再 accept

这个版本只能：

接收一个客户端。
读取一次数据。
返回一次数据。

如果客户端想再次发送，服务端没有循环继续读取。

第二阶段：循环接收客户端，但串行处理

#elif 0
while (1) {
 int clientfd = accept(...);

 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0);

 printf("RECV:%s\n", buffer);

 count = send(clientfd, buffer, count, 0);
}
#endif

这里增加了：

while (1)

因此服务端可以不断接收新客户端。

但是它仍然是串行处理：

accept 客户端 A
 ↓
recv 等待 A 发送数据
 ↓
send 返回给 A
 ↓
重新 accept 客户端 B

关键问题在这里：

recv(clientfd, buffer, 1024, 0);

默认情况下，recv() 是阻塞的。

假设客户端 A 已经连接，但一直没有发送数据：

服务端阻塞在 A 的 recv()

此时即使客户端 B 已经发起连接，应用程序也暂时无法回到 accept() 处理 B。

第三阶段：一个客户端对应一个线程

当前实际编译的是 #else：

#else
while (1) {
 int clientfd = accept(...);

 pthread_t thid;
 pthread_create(
 &thid,
 NULL,
 client_thread,
 &clientfd
 );
}
#endif

每接收一个客户端，创建一个线程。

线程函数：

void *client_thread(void *arg)
{
 int clientfd = *(int *)arg;

 while (1) {
 char buffer[1024] = {0};

 int count = recv(
 clientfd,
 buffer,
 1024,
 0
 );

 printf("RECV:%s\n", buffer);

 count = send(
 clientfd,
 buffer,
 count,
 0
 );
 }
}

运行关系变成：

主线程
 │
 ├─ accept 客户端 A
 │ └─ 创建线程 1 → recv(A)
 │
 ├─ accept 客户端 B
 │ └─ 创建线程 2 → recv(B)
 │
 └─ accept 客户端 C
 └─ 创建线程 3 → recv(C)

主线程只负责：

不断执行 accept()

工作线程负责：

recv() → 处理数据 → send()

这样即使线程 1 阻塞在客户端 A 的 recv()，主线程仍然可以继续 accept() 客户端 B。

准确来说，这是：

一个连接对应一个线程。

不是严格的”一次请求对应一个线程”，因为一个连接线程内部可以通过 while 处理多次请求。

七、对于阶段三一个连接一个线程的问题

这种模型简单直观，但连接数量增大后会产生问题。

1. 线程需要内存

每创建一个线程，都需要线程栈及相关管理资源。连接越多，线程越多，百万并发的时候…

2. 上下文切换成本

CPU 核心数量有限。

假设服务器只有 8 个 CPU 核心，却创建了 5000 个线程，操作系统必须不停地：

保存线程 A 的状态
切换到线程 B
保存线程 B 的状态
切换到线程 C

线程太多时，大量 CPU 时间可能消耗在线程调度上。

3. 大部分线程可能只是在等待

很多网络连接并不是一直都有数据。

例如即时通信中的长连接：

客户端保持在线
但大部分时间没有发送消息

对应线程会长期阻塞在：

recv(clientfd, ...);

如果一个空闲连接占用一个线程，就会浪费大量线程资源。

代码

#include <stdio.h> // printf
#include <string.h> // memset
#include <sys/socket.h>
#include <arpa/inet.h> // htonl, htons
#include <errno.h> // errno
#include <netinet/in.h> // struct sockaddr_in
#include <unistd.h> // close
#include <pthread.h>

void *client_thread(void *arg) {
 int clientfd = *(int *)arg;
 while (1) {
 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0); // 全部阻塞在 recv 上
 printf("RECV:%s\n", buffer);
 count = send(clientfd, buffer, count, 0);
 printf("SEND:%s\n", count);
 }
}

int main() {
 int sockfd = socket(AF_INET, SOCK_STREAM, 0); // create socket 聘请迎宾者
 // 绑定本地端口
 struct sockaddr_in servaddr;
 servaddr.sin_family = AF_INET;
 servaddr.sin_addr.s_addr = htonl(INADDR_ANY); // 0.0.0.0
 servaddr.sin_port = htons(2000); // 0-1023 系统默认，1024 之后都可以用，不能与其他的冲突
 // 在哪个门迎宾，安排的位置
 if (-1 == bind(sockfd, (struct sockaddr *)&servaddr, sizeof(struct sockaddr))) {
 printf("bind error:%s\n", strerror(errno));
 }
 // 登记绑定
 listen(sockfd, 10); // 正式上榜
 printf("listen finished\n");
 struct sockaddr_in clientaddr;
 socklen_t len = sizeof(clientaddr);
#if 0
 printf("accept\n");
 int clientfd = accept(sockfd, (struct sockaddr *)&clientaddr, &len); // 建立链接
 printf("accept finished\n");
 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0);
 printf("RECV:%s\n", buffer);
 count = send(clientfd, buffer, count, 0);
 printf("SEND:%s\n", count);
#elif 0
 while (1) {
 printf("accept\n");
 int clientfd = accept(sockfd, (struct sockaddr *)&clientaddr, &len); // 建立链接
 printf("accept finished\n");
 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0); // 全部阻塞在 recv 上
 printf("RECV:%s\n", buffer);
 count = send(clientfd, buffer, count, 0);
 printf("SEND:%s\n", count);
 } // 多个 io 如何接收数据
#else
 while (1) {
 printf("accept\n");
 int clientfd = accept(sockfd, (struct sockaddr *)&clientaddr, &len); // 建立链接
 printf("accept finished\n");
 pthread_t thid;
 pthread_create(&thid, NULL, client_thread, &clientfd);
 }
#endif
 getchar();
 printf("exit\n");
 return 0;
}