Reactor on JasperSao的博客

KV 存储项目网络层：统一接入 Reactor、Proactor 与协程

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

阅读目标：先恢复项目的整体认识，再通过带注释的代码块回忆具体实现。

本文只解析现有成品代码，不讨论修改方案。ntyco 只讲如何作为 KV 项目的网络层使用。

1. 先恢复项目的整体画面

这个项目的核心不是分别写了三个独立服务器，而是让三个网络服务器共同使用同一个 KV 协议入口：

 kvstore.c
 main + kvs_protocol
 │
 msg_handler 回调
 │
 ┌──────────────┼──────────────┐
 │ │ │
 reactor.c ntyco.c proactor.c
 epoll 协程 io_uring
 │ │ │
 └──────────────┼──────────────┘
 │
 TCP

三种网络层只负责连接和收发，kvs_protocol() 负责处理消息：

客户端请求
 ↓
网络层收到 msg 和 length
 ↓
kvs_protocol(msg, length, response)
 ↓
返回 response 的长度
 ↓
网络层发送 response

项目目前的 kvs_protocol() 是 echo 协议：把请求复制成响应。这一实现展示的重点，是三种网络模型如何接入同一个 KV 协议回调。

六份文件分成三组：

公共入口与接口
 ├─ kvstore.c
 └─ kvstore.h

Reactor 公共连接定义
 └─ server.h

三种网络层
 ├─ reactor.c
 ├─ proactor.c
 └─ ntyco.c

2. 公共入口：`kvstore.h` 与 `kvstore.c`

2.1 `kvstore.h`：把三种网络层统一成一种调用方式

#ifndef KV_STORE_H
#define KV_STORE_H

/* 三种网络实现的编号，供 NETWORK_SELECT 选择 */
#define NETWORK_REACTOR 0
#define NETWORK_PROACTOR 1
#define NET_WORK_NTYCO 2

/* 当前编译使用 io_uring Proactor 网络层 */
#define NETWORK_SELECT NETWORK_PROACTOR

/*
 * KV 协议回调类型：
 * msg 网络层收到的请求
 * length 请求的实际长度
 * response 协议层写入响应的位置
 * 返回值 网络层需要发送的响应长度
 */
typedef int (*msg_handler)(char *msg, int length, char *response);

/* 三种网络层向 kvstore.c 暴露相同形式的启动函数 */
extern int reactor_start(unsigned short port, msg_handler handler);
extern int ntyco_start(unsigned short port, msg_handler handler);
extern int proactor_start(unsigned short port, msg_handler handler);

/* KV 项目支持的命令名称 */
const char *command[] = {
 "SET", "GET", "DEL", "MOD", "EXIST"
};

/* 响应字符串表，目前未填充 */
const char *response[] = {
};

#endif

这一文件的整体作用可以概括为：

NETWORK_SELECT 决定使用谁
msg_handler 规定协议函数长什么样
三个 start 规定网络层怎样启动
command 列出 KV 命令集合

2.2 `kvstore.c`：选择网络层，并把协议函数交给它

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "kvstore.h"

/*
 * 当前是 echo 形式的 KV 协议入口。
 * 网络层把请求传进来，本函数把请求复制成响应。
 */
int kvs_protocol(char *msg, int length, char *response) {
 /* 输出本次请求长度与内容 */
 printf("recv: %d: %s\n", length, msg);

 /* 将收到的 length 个字节复制到响应缓冲区 */
 memcpy(response, msg, length);

 /* 把响应长度交还给网络层 */
 return strlen(response);
}

int main(int argc, char *argv[]) {
 /* 启动形式要求为：./kvstore <port> */
 if (argc != 2) return -1;

 /* 将命令行中的端口字符串转换成整数 */
 int port = atoi(argv[1]);

 /*
 * 编译期选择网络模型。
 * 三个分支都把同一个 kvs_protocol 作为 handler 传入。
 */
#if (NETWORK_SELECT == NETWORK_REACTOR)
 reactor_start(port, kvs_protocol);
#elif (NETWORK_SELECT == NETWORK_NTYCO)
 ntyco_start(port, kvs_protocol);
#elif (NETWORK_SELECT == NETWORK_PROACTOR)
 proactor_start(port, kvs_protocol);
#endif
}

这里最需要记住的不是条件编译本身，而是下面三个调用具有完全相同的含义：

reactor_start(port, kvs_protocol);
ntyco_start(port, kvs_protocol);
proactor_start(port, kvs_protocol);

可以统一读作：

在指定端口启动某个网络后端；以后收到消息时，请调用 kvs_protocol()。

3. Reactor 的连接结构：`server.h`

Reactor 是事件驱动的。一次读事件和下一次写事件不是在同一个函数中连续完成，因此需要 struct conn 保存跨事件存在的连接信息。

#ifndef SERVER_H
#define SERVER_H

/* 每个连接的读、写缓冲区都是 1024 字节 */
#define BUFFER_LENGTH 1024

/* 当前 Reactor 上层启用 KVSTORE 协议 */
#define ENABLE_HTTP 0
#define ENABLE_WEBSOCKET 0
#define ENABLE_KVSTORE 1

/* epoll 事件回调：传入发生事件的 fd */
typedef int (*RCALLBACK)(int fd);

struct conn {
 int fd; // 当前连接的 socket fd

 char rbuffer[BUFFER_LENGTH]; // recv 接收到的请求
 int rlength; // 请求的实际长度

 char wbuffer[BUFFER_LENGTH]; // KV 协议生成的响应
 int wlength; // 响应的实际长度

 RCALLBACK send_callback; // EPOLLOUT 时调用 send_cb

 union {
 RCALLBACK recv_callback; // 客户端 fd 可读时调用 recv_cb
 RCALLBACK accept_callback; // 监听 fd 可读时调用 accept_cb
 } r_action;

 int status; // 连接/协议状态字段

#if 1 // websocket
 char *payload; // WebSocket 数据字段
 char mask[4]; // WebSocket 掩码字段
#endif
};

/* 同一套 Reactor 曾为不同上层协议保留入口 */
#if ENABLE_HTTP
int http_request(struct conn *c);
int http_response(struct conn *c);
#endif

#if ENABLE_WEBSOCKET
int ws_request(struct conn *c);
int ws_response(struct conn *c);
#endif

#if ENABLE_KVSTORE
int kvs_request(struct conn *c);
int kvs_response(struct conn *c);
#endif

#endif

struct conn 可以用一条数据流来理解：

recv(fd)
 ↓
rbuffer + rlength
 ↓ kvs_handler
wbuffer + wlength
 ↓
send(fd)

两个函数指针则决定 epoll 返回事件时执行什么：

监听 fd 的 EPOLLIN → accept_cb
连接 fd的 EPOLLIN → recv_cb
连接 fd的 EPOLLOUT → send_cb

4. Reactor 网络层：`reactor.c`

4.1 Reactor 总体流程

创建 epoll
 ↓
创建 20 个监听 socket，并注册 EPOLLIN
 ↓
epoll_wait
 ├─ 监听 fd 可读 → accept_cb
 ├─ 客户端 fd 可读 → recv_cb → kvs_protocol
 └─ 客户端 fd 可写 → send_cb

4.2 KV 回调和连接表

#define CONNECTION_SIZE 1048576 // 连接表容量
#define MAX_PORTS 20 // 连续监听 20 个端口

/* 计算两次 timeval 之间的毫秒差，用于 accept 统计 */
#define TIME_SUB_MS(tv1, tv2) \
 ((tv1.tv_sec - tv2.tv_sec) * 1000 + \
 (tv1.tv_usec - tv2.tv_usec) / 1000)

#if ENABLE_KVSTORE
/* reactor_start 会把 kvs_protocol 保存到这里 */
static msg_handler kvs_handler;

int kvs_request(struct conn *c) {
 /*
 * 将连接的接收缓冲区交给 KV 层；
 * KV 层把响应写入同一连接的发送缓冲区；
 * 返回值记录到 wlength。
 */
 c->wlength = kvs_handler(
 c->rbuffer,
 c->rlength,
 c->wbuffer
 );
}

int kvs_response(struct conn *c) {
 /* 当前 KV 响应不再进行二次处理 */
}
#endif

int epfd = 0; // epoll 实例 fd
struct timeval begin; // accept 统计起点
struct conn conn_list[CONNECTION_SIZE]; // 用 fd 直接索引连接

4.3 添加和切换 epoll 事件

int set_event(int fd, int event, int flag) {
 struct epoll_event ev;
 ev.events = event; // EPOLLIN 或 EPOLLOUT
 ev.data.fd = fd; // epoll 返回事件时带回这个 fd

 if (flag) {
 /* 新 fd 第一次进入 epoll */
 epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);
 } else {
 /* 已登记 fd 在读、写关注之间切换 */
 epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);
 }
}

这份 Reactor 的主要节奏，就是不断切换同一个客户端的事件：

刚建立连接 → EPOLLIN
收到并处理请求 → EPOLLOUT
发送完响应 → EPOLLIN

4.4 初始化一个客户端连接

int event_register(int fd, int event) {
 if (fd < 0) return -1;

 /* fd 同时也是 conn_list 的下标 */
 conn_list[fd].fd = fd;

 /* 客户端可读和可写时对应的处理函数 */
 conn_list[fd].r_action.recv_callback = recv_cb;
 conn_list[fd].send_callback = send_cb;

 /* 初始化这个连接的输入区域 */
 memset(conn_list[fd].rbuffer, 0, BUFFER_LENGTH);
 conn_list[fd].rlength = 0;

 /* 初始化这个连接的输出区域 */
 memset(conn_list[fd].wbuffer, 0, BUFFER_LENGTH);
 conn_list[fd].wlength = 0;

 /* 新连接加入 epoll，调用处传入的是 EPOLLIN */
 set_event(fd, event, 1);
}

4.5 创建监听 socket

int r_init_server(unsigned short port) {
 /* 创建 IPv4 TCP socket */
 int sockfd = socket(AF_INET, SOCK_STREAM, 0);

 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(port); // 监听端口

 /* 把 socket 绑定到本机端口 */
 if (bind(sockfd,
 (struct sockaddr *)&servaddr,
 sizeof(struct sockaddr)) == -1) {
 printf("bind failed: %s\n", strerror(errno));
 }

 /* 将 socket 变为监听 socket */
 listen(sockfd, 10);

 return sockfd;
}

4.6 接受客户端

int accept_cb(int fd) {
 struct sockaddr_in clientaddr;
 socklen_t len = sizeof(clientaddr);

 /*
 * fd 是监听 socket；
 * clientfd 是新建立的客户端连接。
 */
 int clientfd = accept(
 fd,
 (struct sockaddr *)&clientaddr,
 &len
 );

 printf("accept finshed: %d,fd:%d\n", clientfd, fd);

 if (clientfd < 0) {
 printf("accept errno: %d --> %s\n",
 errno, strerror(errno));
 return -1;
 }

 /* 新客户端从等待读事件开始 */
 event_register(clientfd, EPOLLIN);

 /* 每当 fd 到达 1000 的整数倍，打印一次时间间隔 */
 if ((clientfd % 1000) == 0) {
 struct timeval current;
 gettimeofday(&current, NULL);

 int time_used = TIME_SUB_MS(current, begin);
 memcpy(&begin, &current, sizeof(struct timeval));

 printf("accept finshed: %d, time_used: %d\n",
 clientfd, time_used);
 }

 return 0;
}

4.7 接收请求并进入 KV 协议

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) {
 /* recv 返回 0：客户端断开 */
 printf("client disconnect: %d\n", fd);
 close(fd);
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 return 0;
 } else if (count < 0) {
 /* recv 返回负数：打印错误并结束连接 */
 printf("count: %d, errno: %d, %s\n",
 count, errno, strerror(errno));
 close(fd);
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 return 0;
 }

 /* 保存这次实际收到的请求长度 */
 conn_list[fd].rlength = count;

#if 0
 /* echo 分支：直接把读缓冲复制到写缓冲 */
 conn_list[fd].wlength = conn_list[fd].rlength;
 memcpy(conn_list[fd].wbuffer,
 conn_list[fd].rbuffer,
 conn_list[fd].wlength);
#elif ENABLE_HTTP
 http_request(&conn_list[fd]);
#elif ENABLE_WEBSOCKET
 ws_request(&conn_list[fd]);
#elif ENABLE_KVSTORE
 /* 当前启用的分支：通过 handler 生成 KV 响应 */
 kvs_request(&conn_list[fd]);
#endif

 /* 请求处理完成，下一阶段等待发送 */
 set_event(fd, EPOLLOUT, 0);
 return count;
}

这里完成了项目中最重要的一次跨层调用：

recv_cb
 → kvs_request(&conn_list[fd])
 → kvs_handler(rbuffer, rlength, wbuffer)
 → kvs_protocol

4.8 发送响应

int send_cb(int fd) {
#if ENABLE_HTTP
 http_response(&conn_list[fd]);
#elif ENABLE_WEBSOCKET
 ws_response(&conn_list[fd]);
#elif ENABLE_KVSTORE
 /* KV 分支当前不对 wbuffer 做额外处理 */
 kvs_response(&conn_list[fd]);
#endif

 int count = 0;

 /* wlength 非零时，把 KV 响应发给客户端 */
 if (conn_list[fd].wlength != 0) {
 count = send(
 fd,
 conn_list[fd].wbuffer,
 conn_list[fd].wlength,
 0
 );
 }

 /* 响应阶段结束，再次等待客户端请求 */
 set_event(fd, EPOLLIN, 0);
 return count;
}

4.9 启动 Reactor 主循环

int reactor_start(unsigned short port, msg_handler handler) {
 printf("reactor_entry %d\n", port);

 /* 保存由 main 传入的 kvs_protocol */
 kvs_handler = handler;

 /* 创建 epoll 实例 */
 epfd = epoll_create(1);

 /* 从 port 开始连续建立 20 个监听端口 */
 for (int i = 0; i < MAX_PORTS; i++) {
 int sockfd = r_init_server(port + i);

 /* 监听 fd 可读时执行 accept_cb */
 conn_list[sockfd].fd = sockfd;
 conn_list[sockfd].r_action.recv_callback = accept_cb;

 /* 将监听 fd 加入 epoll */
 set_event(sockfd, EPOLLIN, 1);
 }

 /* accept 性能统计的起始时间 */
 gettimeofday(&begin, NULL);

 while (1) {
 struct epoll_event events[1024] = {0};

 /* 阻塞等待，最多取得 1024 个就绪事件 */
 int nready = epoll_wait(epfd, events, 1024, -1);

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

 /*
 * 监听 fd：read callback 是 accept_cb；
 * 客户端 fd：read callback 是 recv_cb。
 */
 if (events[i].events & EPOLLIN) {
 conn_list[connfd]
 .r_action.recv_callback(connfd);
 }

 /* 客户端可写时调用 send_cb */
 if (events[i].events & EPOLLOUT) {
 conn_list[connfd]
 .send_callback(connfd);
 }
 }
 }
}

把整份 Reactor 压缩成一句话：

epoll 主循环根据 fd 和事件找到回调；读回调接收请求并调用 KV handler，写回调发送 handler 生成的响应。

5. io_uring Proactor 网络层：`proactor.c`

5.1 Proactor 总体流程

准备 ACCEPT 操作
 ↓ submit
等待完成队列 CQ
 ↓
ACCEPT 完成 → 得到 connfd → 准备 RECV
 ↓
READ 完成 → 调 kvs_protocol → 准备 SEND
 ↓
WRITE 完成 → 再次准备 RECV

Reactor 是“事件就绪以后调用 I/O”，这份 io_uring 代码是“先提交具体 I/O，再处理完成结果”。

5.2 操作类型与操作标记

/* 用于区分 CQE 对应哪一种操作 */
#define EVENT_ACCEPT 0
#define EVENT_READ 1
#define EVENT_WRITE 2

struct conn_info {
 int fd; // 操作所属的 socket
 int event; // ACCEPT / READ / WRITE
};

#define ENTRIES_LENGTH 1024 // io_uring 队列项参数
#define BUFFER_LENGTH 1024 // 网络缓冲区长度

/* proactor_start 保存 main 传入的 kvs_protocol */
static msg_handler kvs_handler;

每个 SQE 都通过 user_data 带上 conn_info。CQE 返回以后，程序就知道完成的是谁的什么操作。

5.3 准备 send

int set_event_send(struct io_uring *ring,
 int sockfd,
 void *buf,
 size_t len,
 int flags) {
 /* 从提交队列取得一个 SQE */
 struct io_uring_sqe *sqe = io_uring_get_sqe(ring);

 /* 标记这是 sockfd 的写操作 */
 struct conn_info info = {
 .fd = sockfd,
 .event = EVENT_WRITE,
 };

 /* 将 SQE 填写为 send 请求 */
 io_uring_prep_send(sqe, sockfd, buf, len, flags);

 /* 操作完成时，通过 user_data 找回 fd 和事件类型 */
 memcpy(&sqe->user_data, &info, sizeof(struct conn_info));
}

5.4 准备 recv

int set_event_recv(struct io_uring *ring,
 int sockfd,
 void *buf,
 size_t len,
 int flags) {
 struct io_uring_sqe *sqe = io_uring_get_sqe(ring);

 /* 标记这是 sockfd 的读操作 */
 struct conn_info info = {
 .fd = sockfd,
 .event = EVENT_READ,
 };

 /* 将 SQE 填写为 recv 请求 */
 io_uring_prep_recv(sqe, sockfd, buf, len, flags);

 memcpy(&sqe->user_data, &info, sizeof(struct conn_info));
}

5.5 准备 accept

int set_event_accept(struct io_uring *ring,
 int sockfd,
 struct sockaddr *addr,
 socklen_t *addrlen,
 int flags) {
 struct io_uring_sqe *sqe = io_uring_get_sqe(ring);

 /* 标记这是监听 sockfd 的 accept 操作 */
 struct conn_info info = {
 .fd = sockfd,
 .event = EVENT_ACCEPT,
 };

 /* 将 SQE 填写为 accept 请求 */
 io_uring_prep_accept(sqe, sockfd, addr, addrlen, flags);

 memcpy(&sqe->user_data, &info, sizeof(struct conn_info));
}

三个函数的结构完全一致，只有 prep 函数和 event 类型不同：

准备函数	liburing prep	事件标记
`set_event_accept`	`io_uring_prep_accept`	`EVENT_ACCEPT`
`set_event_recv`	`io_uring_prep_recv`	`EVENT_READ`
`set_event_send`	`io_uring_prep_send`	`EVENT_WRITE`

5.6 创建监听 socket

int p_init_server(unsigned short port) {
 /* 创建 IPv4 TCP socket */
 int sockfd = socket(AF_INET, SOCK_STREAM, 0);

 struct sockaddr_in servaddr;
 servaddr.sin_family = AF_INET;
 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
 servaddr.sin_port = htons(port);

 /* 绑定端口 */
 if (bind(sockfd,
 (struct sockaddr *)&servaddr,
 sizeof(struct sockaddr)) == -1) {
 printf("bind failed: %s\n", strerror(errno));
 }

 /* 开始监听 */
 listen(sockfd, 10);
 return sockfd;
}

5.7 初始化 io_uring 并准备第一个 accept

int proactor_start(unsigned short port, msg_handler handler) {
 /* 创建监听 socket */
 int sockfd = p_init_server(port);

 /* 保存 kvs_protocol */
 kvs_handler = handler;

 /* 初始化 io_uring 参数 */
 struct io_uring_params params;
 memset(&params, 0, sizeof(params));

 /* 创建提交队列和完成队列 */
 struct io_uring ring;
 io_uring_queue_init_params(
 ENTRIES_LENGTH,
 &ring,
 &params
 );

 /* accept 完成后，内核会填写客户端地址 */
 struct sockaddr_in clientaddr;
 socklen_t len = sizeof(clientaddr);

 /* 在进入循环之前，先准备第一个 accept SQE */
 set_event_accept(
 &ring,
 sockfd,
 (struct sockaddr *)&clientaddr,
 &len,
 0
 );

 /* READ 使用 buffer，KV 输出和 WRITE 使用 response */
 char buffer[BUFFER_LENGTH] = {0};
 char response[BUFFER_LENGTH] = {0};

5.8 提交和取得完成事件

 while (1) {
 /* 把当前已经准备好的 SQE 提交给 io_uring */
 io_uring_submit(&ring);

 /* 至少等待一个操作完成 */
 struct io_uring_cqe *cqe;
 io_uring_wait_cqe(&ring, &cqe);

 /* 一次批量取出最多 128 个完成项 */
 struct io_uring_cqe *cqes[128];
 int nready = io_uring_peek_batch_cqe(
 &ring,
 cqes,
 128
 );

 for (int i = 0; i < nready; i++) {
 struct io_uring_cqe *entry = cqes[i];

 /* 从 user_data 还原这个操作的 fd 和类型 */
 struct conn_info result;
 memcpy(&result,
 &entry->user_data,
 sizeof(struct conn_info));

这里的两个信息来源要分清：

result.fd / result.event
 提交 SQE 时由应用保存
 用来识别“谁的什么操作”

entry->res
 操作完成时由内核返回
 用来表示 accept 的新 fd、recv 长度或 send 结果

5.9 分发 ACCEPT、READ 和 WRITE 完成事件

 if (result.event == EVENT_ACCEPT) {
 /*
 * 当前 accept 已完成；
 * 先准备下一个 accept，保持继续接收新连接。
 */
 set_event_accept(
 &ring,
 sockfd,
 (struct sockaddr *)&clientaddr,
 &len,
 0
 );

 /* accept CQE 的 res 是新客户端 fd */
 int connfd = entry->res;

 /* 为新客户端准备第一次 recv */
 set_event_recv(
 &ring,
 connfd,
 buffer,
 BUFFER_LENGTH,
 0
 );

 } else if (result.event == EVENT_READ) {
 /* recv CQE 的 res 是本次收到的字节数 */
 int ret = entry->res;

 if (ret == 0) {
 /* 客户端关闭连接 */
 close(result.fd);
 } else if (ret > 0) {
 /*
 * buffer + ret 构成请求；
 * response 接收 KV 协议输出；
 * 返回值重新赋给 ret，作为响应长度。
 */
 ret = kvs_handler(buffer, ret, response);

 /* 准备把 KV 响应发送给原客户端 */
 set_event_send(
 &ring,
 result.fd,
 response,
 ret,
 0
 );
 }

 } else if (result.event == EVENT_WRITE) {
 /* send CQE 的 res 是写操作完成结果 */
 int ret = entry->res;

 /* 本轮响应结束，再次等待该客户端请求 */
 set_event_recv(
 &ring,
 result.fd,
 buffer,
 BUFFER_LENGTH,
 0
 );
 }
 }

 /* 告诉 ring：这一批 CQE 已经处理完 */
 io_uring_cq_advance(&ring, nready);
 }
}

把整份 Proactor 压缩成一句话：

每处理一个完成事件，就准备这个连接的下一项操作；READ 完成与 WRITE 准备之间插入一次 KV handler 调用。

6. ntyco 协程网络层：`ntyco.c`

6.1 ntyco 在项目中的结构

ntyco_start
 ↓ 创建
server 协程：socket → bind → listen → accept
 ↓ 每个客户端创建
server_reader 协程：recv → kvs_protocol → send

这里不展开 nty_coroutine_create 和 nty_schedule_run 的内部实现，只观察项目怎样调用框架。

6.2 客户端处理协程

/* ntyco_start 保存 main 传入的 kvs_protocol */
static msg_handler kvs_handler;

void server_reader(void *arg) {
 /* server 创建协程时传入的是 cli_fd 地址 */
 int fd = *(int *)arg;
 int ret = 0;

 while (1) {
 /* 每轮准备一个新的接收缓冲区 */
 char buf[1024] = {0};

 /* 接收这个客户端的请求 */
 ret = recv(fd, buf, 1024, 0);

 if (ret > 0) {
 /* 为本轮响应准备缓冲区 */
 char response[1024] = {0};

 /*
 * buf + ret 是请求；
 * response 是 KV 输出；
 * slength 是响应长度。
 */
 int slength = kvs_handler(buf, ret, response);

 /* 将 KV 响应发送给当前客户端 */
 ret = send(fd, response, slength, 0);

 if (ret == -1) {
 close(fd);
 break;
 }
 } else if (ret == 0) {
 /* 客户端正常关闭连接 */
 close(fd);
 break;
 }
 }
}

与 Reactor、Proactor 相比，协程版本把同一个客户端的处理过程写在一个顺序循环里：

recv(...);
kvs_handler(...);
send(...);

6.3 监听协程

void server(void *arg) {
 /* 还原 ntyco_start 传入的端口 */
 unsigned short port = *(unsigned short *)arg;

 /* 创建 IPv4 TCP 监听 socket */
 int fd = socket(AF_INET, SOCK_STREAM, 0);
 if (fd < 0) return;

 /* 填写本地监听地址 */
 struct sockaddr_in local, remote;
 local.sin_family = AF_INET;
 local.sin_port = htons(port);
 local.sin_addr.s_addr = INADDR_ANY;

 /* 绑定并监听 */
 bind(fd,
 (struct sockaddr *)&local,
 sizeof(struct sockaddr_in));
 listen(fd, 20);

 printf("listen port : %d\n", port);

 while (1) {
 socklen_t len = sizeof(struct sockaddr_in);

 /* 接受一个客户端连接 */
 int cli_fd = accept(
 fd,
 (struct sockaddr *)&remote,
 &len
 );

 /*
 * 每个客户端创建一个 server_reader 协程；
 * 该协程负责此后的 recv、KV 处理和 send。
 */
 nty_coroutine *read_co;
 nty_coroutine_create(
 &read_co,
 server_reader,
 &cli_fd
 );
 }
}

6.4 ntyco 网络层入口

int ntyco_start(unsigned short port, msg_handler handler) {
 /* 保存 kvs_protocol */
 kvs_handler = handler;

 /* 创建负责监听和 accept 的 server 协程 */
 nty_coroutine *co = NULL;
 nty_coroutine_create(&co, server, &port);

 /* 启动 ntyco 调度器 */
 nty_schedule_run();
}

把 ntyco 版本压缩成一句话：

server 协程负责产生连接，每个连接再由一个 reader 协程按顺序完成接收、协议处理和发送。

7. 三种网络层放在一起回顾

7.1 同一阶段的代码对应关系

阶段	Reactor	io_uring Proactor	ntyco
保存 KV 函数	`kvs_handler = handler`	`kvs_handler = handler`	`kvs_handler = handler`
等待连接	监听 fd 的 `EPOLLIN`	提交 `ACCEPT` SQE	`server` 协程调用 `accept`
获得连接	`accept_cb()`	`EVENT_ACCEPT` CQE	`accept()` 返回
等待请求	客户端 fd 的 `EPOLLIN`	提交 `RECV` SQE	reader 协程调用 `recv`
KV 接入点	`kvs_request()`	`EVENT_READ` 分支	`server_reader()`
发送响应	`send_cb()`	提交 `SEND` SQE	reader 协程调用 `send`
继续循环	改回 `EPOLLIN`	WRITE 完成后再提交 RECV	while 回到 recv

7.2 一次请求的三条完整路径

Reactor

epoll_wait
 → EPOLLIN
 → recv_cb
 → conn.rbuffer / conn.rlength
 → kvs_request
 → kvs_protocol
 → conn.wbuffer / conn.wlength
 → EPOLLOUT
 → send_cb
 → EPOLLIN

Proactor

提交 RECV
 → READ CQE
 → buffer / entry->res
 → kvs_protocol
 → response / 响应长度
 → 提交 SEND
 → WRITE CQE
 → 再提交 RECV

ntyco

server_reader 协程
 → recv
 → buf / ret
 → kvs_protocol
 → response / slength
 → send
 → 下一轮 recv

7.3 两种回调不要混淆

/* Reactor 内部的网络事件回调 */
typedef int (*RCALLBACK)(int fd);

/* 三种网络层共同使用的 KV 协议回调 */
typedef int (*msg_handler)(char *msg,
 int length,
 char *response);

它们的层次是：

Reactor 中：
epoll → RCALLBACK → recv_cb → msg_handler → kvs_protocol

Proactor 中：
CQE → EVENT_READ 分支 → msg_handler → kvs_protocol

ntyco 中：
server_reader → msg_handler → kvs_protocol

8. 最后的整体记忆

重新回顾这个项目时，只需要先恢复四个关键词：

NETWORK_SELECT
 决定使用 Reactor、Proactor 还是 ntyco

msg_handler
 把网络层与 KV 协议层连接起来

kvs_protocol
 接收请求、生成响应，当前实现为 echo

网络事件循环
 三种模型分别用 epoll、io_uring、协程完成连接和收发

整个程序的共同主干是：

/* main 把协议函数交给网络层 */
network_start(port, kvs_protocol);

/* 网络层保存函数地址 */
kvs_handler = handler;

/* 网络层收到请求后调用它 */
response_len = kvs_handler(
 request,
 request_len,
 response
);

/* 网络层按返回长度发送响应 */
send(clientfd, response, response_len, 0);

这四步就是六份代码共同围绕的核心。三种网络模型改变的是“请求怎样到达这四步、响应怎样离开这四步”，而 KV 协议入口保持一致。

协程设计原理：从异步回调到 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”上升为“管理事件及其处理逻辑”。

Reactor on JasperSao的博客

KV 存储项目网络层：统一接入 Reactor、Proactor 与协程

1. 先恢复项目的整体画面

2. 公共入口：kvstore.h 与 kvstore.c

2.1 kvstore.h：把三种网络层统一成一种调用方式

2.2 kvstore.c：选择网络层，并把协议函数交给它

3. Reactor 的连接结构：server.h

4. Reactor 网络层：reactor.c

4.1 Reactor 总体流程

4.2 KV 回调和连接表

4.3 添加和切换 epoll 事件

4.4 初始化一个客户端连接

4.5 创建监听 socket

4.6 接受客户端

4.7 接收请求并进入 KV 协议

4.8 发送响应

4.9 启动 Reactor 主循环

5. io_uring Proactor 网络层：proactor.c

5.1 Proactor 总体流程

5.2 操作类型与操作标记

5.3 准备 send

5.4 准备 recv

5.5 准备 accept

5.6 创建监听 socket

5.7 初始化 io_uring 并准备第一个 accept

5.8 提交和取得完成事件

5.9 分发 ACCEPT、READ 和 WRITE 完成事件

6. ntyco 协程网络层：ntyco.c

6.1 ntyco 在项目中的结构

6.2 客户端处理协程

6.3 监听协程

6.4 ntyco 网络层入口

7. 三种网络层放在一起回顾

7.1 同一阶段的代码对应关系

7.2 一次请求的三条完整路径

Reactor

Proactor

ntyco

7.3 两种回调不要混淆

8. 最后的整体记忆

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

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

二、协程要解决什么问题

2.1 同步请求

2.2 异步回调

2.3 异步不等于并行

2.4 协程的目标

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

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

3.2 epoll 线程只分发任务

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

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

5.1 回调写法

5.2 协程期望的写法

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

七、上下文到底是什么

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

8.1 setjmp / longjmp

8.2 ucontext

8.3 汇编切换

九、setjmp / longjmp 原代码

9.1 jmp_buf

9.2 第一次 setjmp()

9.3 longjmp()

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

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

11.1 保存初始上下文

11.2 指定独立栈

11.3 指定返回去向

11.4 指定入口函数

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

12.1 main resume 第一个协程

12.2 func1 yield 回 main

十三、yield、resume 和 switch

13.1 resume

13.2 yield

13.3 switch

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

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

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

2. 公共入口：`kvstore.h` 与 `kvstore.c`

2.1 `kvstore.h`：把三种网络层统一成一种调用方式

2.2 `kvstore.c`：选择网络层，并把协议函数交给它

3. Reactor 的连接结构：`server.h`

4. Reactor 网络层：`reactor.c`

5. io_uring Proactor 网络层：`proactor.c`

6. ntyco 协程网络层：`ntyco.c`

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

四、HTTP 请求：`http_request()`

六、返回 `index.html`

七、状态机与 `sendfile()`

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

3. `epoll` 在 Reactor 中的职责

4.1 为什么需要 `struct conn`

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

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

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

10. 为什么会出现 `Too many open files`

12. `nf_conntrack` 应该怎样理解