Io_uring 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 协议入口保持一致。

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 请求通常是一次性的：完成一次，消费一次，再提交下一次。