性能测试 on JasperSao的博客

KV 存储项目：客户端测试、压力测试与多引擎扩展

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

阅读目标：沿着“建立可重复的测试—用压力测试暴露状态问题—在现有协议后接入第二种 KV 引擎”这条主线，回顾项目从数组存储继续向多引擎结构演进的过程。

本文承接 KV 存储项目网络层：统一接入 Reactor、Proactor 与协程和 KV 存储项目：协议层与数组存储。网络层的 Reactor、Proactor、ntyco，以及 kvs_protocol()、token 切分、数组五种操作等内容，前文已经完整讲过，这里只保留理解本阶段所需的连接点。

本文以学习笔记和当前代码为准，重点解释实现过程、测试现象与架构关系，不展开红黑树算法本身。

1. 这一阶段解决什么问题

前一阶段已经形成了一条可以工作的请求链路：

客户端发送文本命令
 ↓
网络层接收数据
 ↓
kvs_protocol() 切分 token
 ↓
kvs_filter_protocol() 识别命令
 ↓
数组引擎执行 SET / GET / DEL / MOD / EXIST
 ↓
协议层生成 OK / EXIST / NO EXIST / value
 ↓
网络层把响应发回客户端

项目能处理命令以后，下一步不只是继续添加代码，而是先回答三个问题：

已有功能能否被稳定、重复地验证？
测试次数增加后，内部状态是否仍然正确？
协议层能否在数组之外接入新的存储引擎？

所以本阶段的主线是：

Makefile 统一构建
 ↓
TCP 客户端实现自动化功能测试
 ↓
重复执行测试并粗测 QPS
 ↓
通过高次数测试定位数组状态问题
 ↓
保留原有数组引擎，接入红黑树引擎
 ↓
用同一组语义测试第二种引擎

这里体现了一种项目迭代思路：先观察当前代码已经处于什么形态，再决定下一项功能应该接入哪一层。

2. 用 Makefile 固定构建过程

随着源文件增加，手工重复输入完整的 gcc 命令会越来越不方便。最初可以直接把编译过程写进 all：

all:
	gcc -o kvstore kvstore.c reactor.c proactor.c kvs_array.c ntyco.c \
		-I ./NtyCo/core/ -L ./NtyCo/ -luring -lntyco

clean:
	rm -rf kvstore

这条命令由四部分组成：

部分	当前内容	作用
编译器	`gcc`	编译并链接 C 程序
target	`kvstore`	最终生成的程序
sources	`kvstore.c` 等	参加编译的源文件
flags	`-I`、`-L`、`-l`	指定头文件、库目录和链接库

把这些部分提取成变量后，Makefile 中各项职责更清楚：

CC=gcc
TARGET = kvstore
SRCS = kvstore.c reactor.c proactor.c kvs_array.c ntyco.c kvs_rbtree.c
INC = -I ./NtyCo/core/
LIBS = -L ./NtyCo/ -luring -lntyco

all:
	$(CC) -o $(TARGET) $(SRCS) $(INC) $(LIBS)

clean:
	rm -rf kvstore

当前阶段加入红黑树后，构建层面的变化很小：在 SRCS 中加入 kvs_rbtree.c。也就是说，存储引擎虽然增加了，但整个项目仍由同一个 target 统一构建。

2.1 NtyCo 是项目的外部依赖

INC 和 LIBS 都引用了 ./NtyCo/：

INC → ./NtyCo/core/ 中的头文件
LIBS → ./NtyCo/ 中的 libntyco

因此，Makefile 描述的是“依赖已经存在时怎样编译”。如果本地没有 NtyCo 目录，还要先完成依赖准备，也就是把对应代码下载到项目约定的位置，再进行编译。

这可以把构建理解成两个阶段：

准备第三方依赖
 ↓
编译当前项目

Makefile 的价值不只在于少输入一条命令，更重要的是把当前项目由哪些文件、头文件路径和库组成固定下来。

3. 客户端测试用例：把人工验证变成固定流程

测试客户端的基本流程很直接：

1. 建立 TCP 连接
2. 发送一条协议命令
3. 接收服务端响应
4. 将实际响应与预期响应比较
5. 一致则 PASS，不一致则 FAILED

测试代码把这五步拆成几个职责单一的函数：

函数	作用
`connect_tcpserver()`	创建 socket，并连接指定 IP 和端口
`send_msg()`	发送一条测试命令
`recv_msg()`	接收服务端返回值
`testcase()`	完成一次“发送—接收—比较”
`array_testcase()`	组织数组引擎的一组功能场景
`rbtree_testcase()`	组织红黑树引擎的一组功能场景

代码中的注释“一个函数只做一件事”在这里得到了体现：网络连接、一次断言和一组业务场景分别由不同函数承担。

3.1 一个测试用例包含什么

testcase() 接收四项信息：

void testcase(int connfd, char *msg, char *pattern, char *casename)

它们分别表示：

参数	含义	示例
`connfd`	已连接的 TCP socket	与 KV 服务端的连接
`msg`	发给服务端的命令	`SET Dad Jasper`
`pattern`	期望得到的响应	`OK\r\n`
`casename`	用于输出的测试名称	`SET-Dad`

测试执行过程可以压缩为：

msg ──send──> KV 服务端
 │
 └── response ──recv──> result
 │
 strcmp(result, pattern)
 │ │
 相同 不同
 │ │
 PASS FAILED

因此，测试用例并不需要知道数组或红黑树内部怎样保存数据。它只站在客户端角度检查协议行为，这正好覆盖了完整链路：

TCP 收发 + 协议解析 + 引擎操作 + 响应生成

4. 一组完整场景不只是“五条命令”

项目一共有五种基础操作：

SET / GET / DEL / MOD / EXIST

但“覆盖五个命令”不等于每个命令只执行一次。当前 array_testcase() 实际组织了九个连续步骤：

顺序	请求	预期响应	验证的状态
1	`SET Dad Jasper`	`OK`	新键可以写入
2	`GET Dad`	`Jasper`	写入后的值可以读出
3	`MOD Dad Sao`	`OK`	已存在的键可以修改
4	`GET Dad`	`Sao`	修改结果已经生效
5	`EXIST Dad`	`EXIST`	已存在的键能被识别
6	`DEL Dad`	`OK`	已存在的键可以删除
7	`GET Dad`	`NO EXIST`	删除后无法再读取
8	`MOD Dad Jasper`	`NO EXIST`	删除后无法再修改
9	`EXIST Dad`	`NO EXIST`	删除后状态确实不存在

这九步不是彼此独立的命令，而是一条状态变化链：

不存在
 │ SET
 ▼
Dad = Jasper
 │ MOD
 ▼
Dad = Sao
 │ DEL
 ▼
不存在

测试在每个关键状态后使用 GET 或 EXIST 进行确认。这样不仅验证命令返回了什么，还验证前一条命令是否真正改变了存储状态。

4.1 测试覆盖的两个方向

当前场景同时覆盖：

正向结果：写入成功、读取成功、修改成功、存在、删除成功；
反向结果：删除后读取、修改和判断存在均返回 NO EXIST。

“尽量覆盖项目所有结果，目标达到 90% 以上”可以理解为：不仅让每个函数运行一次，还要让函数中的主要结果分支都被执行到。对于协议层而言，要关注的结果包括：

OK
EXIST
NO EXIST
ERROR
具体 value

测试用例会贯穿后续项目：新增命令、新增引擎或调整内部结构以后，都可以重复运行同一套预期，确认原有行为仍然成立。这就是回归测试的作用。

5. 从功能测试扩展到压力测试

功能测试回答的是：

一组操作的结果是否正确？

压力测试进一步回答：

同一组操作重复很多次以后，结果是否仍然正确？大约能处理多少请求？

array_testcase_10w() 将九条命令循环执行：

int count = 10000;

for (i = 0; i < count; i++) {
 /* 每轮执行 9 条请求 */
}

所以请求总数为：

10000 轮 × 9 条/轮 = 90000 条请求

计时使用 gettimeofday()：

tv_begin：循环开始时间
tv_end：循环结束时间
time_used：两者相差的毫秒数

宏 TIME_SUB_MS 把秒和微秒的差值统一换算为毫秒：

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

QPS 的基本计算关系是：

QPS = 请求总数 ÷ 耗时秒数
 = 请求总数 × 1000 ÷ 耗时毫秒数

这里的“请求总数”应按实际循环次数和每轮命令数计算。数组测试中是 90000；红黑树测试同样是 10000 × 9 = 90000。阅读输出时先统一这个口径，两个引擎的数据才可以放在一起比较。

5.1 三次粗测说明了什么

笔记记录了 9000 次请求附近的三次结果：

测试环境	耗时	粗测 QPS
客户端输出每次 PASS，服务端也打印	477 ms	18867
屏蔽客户端 PASS 输出	415 ms	21686
继续去掉服务端打印	285 ms	31578

三组数据的重点不是得到一个绝对性能结论，而是观察到：

测试总耗时
 = 网络收发耗时
 + 协议处理耗时
 + 引擎操作耗时
 + 客户端打印耗时
 + 服务端打印耗时

当 printf() 位于高频路径中，它也属于被计时的工作。逐步屏蔽打印后，QPS 上升，说明这次粗测测到的是整个端到端过程，而不只是 KV 引擎本身。

5.2 当前 QPS 的准确含义

当前压力客户端只有一个进程、一条 TCP 连接，并且每次都按下面的顺序执行：

send 一条请求
 ↓
等待 recv 一条响应
 ↓
比较结果
 ↓
发送下一条请求

因此当前结果更准确地说是：

单客户端、单连接、串行请求、包含协议校验的端到端吞吐量。

它适合观察同一环境下的相对变化，例如开关日志前后的差异，以及数组与红黑树在相同测试场景下的差异。

6. 为什么小次数正常，高次数却失败

压力测试增加到 90000 次请求后，出现了：

FAILED-> SET-Dad,ERROR!=OK

从客户端场景看，每轮都执行：

SET Dad Jasper
...
DEL Dad

一轮结束时，Dad 已经删除，所以下一轮的 SET Dad Jasper 应该仍然能够成功。实际数据量始终只在 0 和 1 之间变化：

SET 后：1 个元素
DEL 后：0 个元素
SET 后：1 个元素
DEL 后：0 个元素

但是数组实例使用 total 记录有效元素数量。如果插入成功执行 total++，删除成功却没有对应地维护数量，就会形成两套不同的状态：

实际元素数量：0 → 1 → 0 → 1 → 0 ...
total： 0 → 1 → 1 → 2 → 2 ...

循环次数少时，total 还没有触及 KVS_ARRAY_SIZE，现象不明显；循环次数持续增加后，最终会到达容量判断：

if (inst->total >= KVS_ARRAY_SIZE)

于是后续 SET 返回错误。与此同时，查找范围由 total 决定，total 不断增大也会使遍历范围越来越长，所以压力测试还能观察到性能逐渐变化。

6.1 `total` 的核心约定

数组引擎需要维持一个清楚的不变量：

table[0] 到 table[total - 1]：有效元素
table[total] 以及后面的位置：空闲空间
total：当前有效元素数量

按照这个约定：

插入成功 → total++
删除成功 → total--

如果删除数组中间的元素，可以用最后一个有效元素补到删除位置，从而继续保持有效区间连续：

删除前：[Dad, Mom, Son] total = 3
删除 Mom 后出现空位：[Dad, 空, Son]
把最后一个元素移到空位：[Dad, Son, 空]
最终：total = 2

这个问题说明，容量字段不是只在创建时赋值、插入时递增的计数器，而是数据结构状态的一部分。每一种改变元素数量的操作都必须共同维护它。

7. 压力测试进一步暴露的几个语义问题

高次数运行不仅检查容量，还会不断经过删除、查询不存在和修改不存在等分支，因此能把返回值、内存和状态维护问题一起暴露出来。

7.1 删除 value 时的内存顺序

下面这个表达式先执行赋值：

kvs_free(inst->table[i].value = NULL);

它的实际求值顺序是：

inst->table[i].value = NULL
 ↓
kvs_free(NULL)

原来保存在 value 中的地址因此没有被交给 kvs_free()。正确理解“释放后置空”的顺序是：

先把原地址交给 kvs_free
 ↓
再把保存该地址的指针设为 NULL

也就是：

kvs_free(inst->table[i].key);
inst->table[i].key = NULL;

kvs_free(inst->table[i].value);
inst->table[i].value = NULL;

这里要记住的不是某一行写法，而是指针生命周期：地址仍然可达时释放内存，释放完成后再清除悬空指针。

7.2 循环下标与业务状态不是同一种含义

如果同时存在：

int i = 0;

for (int i = 0; i < inst->total; i++) {
 ...
}

for 中的 i 属于内层作用域，会遮蔽外层的 i。循环结束后，外层 i 仍是初始值 0。

更关键的是，即使只保留一个 i，return i 仍然混合了两种概念：

i：遍历到了哪个数组下标
返回值：本次 KV 操作是什么结果

数组为空时尤其容易看清这个区别：

i = 0
total = 0
循环一次都不执行
return i 得到 0

这里的 0 只是下标初始值，并不能说明修改或删除成功。

因此，学习时应把业务状态单独记忆：

返回值	协议层理解
`< 0`	参数或执行错误，生成 `ERROR`
`0`	操作成功，或 `EXIST` 查询确认存在
`> 0`	SET 时表示已存在；DEL/MOD/EXIST 时表示不存在

7.3 两种失败现象来自同一套返回值约定

删除成功后如果返回 1，协议层会按照既定规则生成：

DEL 返回 1 → NO EXIST

于是客户端看到：

FAILED-> DEL-Dad,NO EXIST!=OK

删除以后再执行 MOD，如果数组为空、循环未执行，最后又通过 return i 返回初始值 0，协议层会生成：

MOD 返回 0 → OK

于是客户端看到：

FAILED-> MOD-Dad,OK!=NO EXIST

这两种现象虽然出现在不同命令中，核心都是同一件事：引擎函数的返回值属于内部业务协议，协议层会严格按照该约定翻译成文本响应。

可以把这条关系记成：

引擎内部状态
 ↓
固定返回值
 ↓
kvs_filter_protocol()
 ↓
客户端可见响应
 ↓
testcase() 与预期比较

测试失败信息最终帮助定位到的，不一定是 TCP 层，也可能是更深处的状态维护或返回值语义。

8. 从单一数组引擎扩展为多引擎

前一阶段的协议层只连接数组：

SET / GET / DEL / MOD / EXIST
 ↓
 global_array

本阶段保留已经成型的数组实现，并通过宏加入红黑树：

#define ENABLE_ARRAY 1
#define ENABLE_RBTREE 1

这两个开关控制相关类型、接口、全局实例、协议分支、初始化和销毁代码是否参与编译。这样可以在接入期间让两种引擎同时存在，并分别运行测试。

项目结构由此变成：

 kvs_protocol
 ↓
 kvs_filter_protocol
 ↓
 根据命令选择对应的引擎
 ↙ ↘
 SET/GET/DEL/MOD/EXIST RSET/RGET/RDEL/RMOD/REXIST
 ↓ ↓
 global_array global_rbtree

这里没有改变底层网络。无论使用 Reactor、Proactor 还是 ntyco，网络层仍然只调用同一个 kvs_protocol()。增加的是协议层后面的存储选择。

9. 为什么给红黑树命令增加 `R` 前缀

一条普通的 SET Dad Jasper 只表达了“设置键值”，没有说明数据应该存进数组还是红黑树。

当前阶段采用最直接的区分方法：在协议命令中加入引擎标识。

数组命令	红黑树命令	语义
`SET`	`RSET`	新增 key-value
`GET`	`RGET`	查询 value
`DEL`	`RDEL`	删除 key-value
`MOD`	`RMOD`	修改 value
`EXIST`	`REXIST`	判断 key 是否存在

命令字符串表因此扩展为十项：

const char *command[] = {
 "SET", "GET", "DEL", "MOD", "EXIST",
 "RSET", "RGET", "RDEL", "RMOD", "REXIST"
};

枚举与字符串表保持相同顺序，kvs_filter_protocol() 找到命令编号后，通过 switch 进入对应分支：

RSET
 ↓
KVS_CMD_RSET
 ↓
kvs_rbtree_set(&global_rbtree, key, value)
 ↓
按照返回值生成 OK / EXIST / ERROR

因此，R 前缀在当前阶段承担的是一个简单的路由信息：让协议层知道应该调用哪种引擎。

10. 每种数据结构都遵守“5 + 2”接口

数组引擎已经形成七个接口：

create
destory
set
get
del
mod
exist

可以压缩为：

2 个生命周期操作 + 5 个 KV 操作 = 5 + 2

红黑树接入时也提供相同形态：

int kvs_rbtree_create(kvs_rbtree_t *inst);
void kvs_rbtree_destory(kvs_rbtree_t *inst);
int kvs_rbtree_set(kvs_rbtree_t *inst, char *key, char *value);
char *kvs_rbtree_get(kvs_rbtree_t *inst, char *key);
int kvs_rbtree_del(kvs_rbtree_t *inst, char *key);
int kvs_rbtree_mod(kvs_rbtree_t *inst, char *key, char *value);
int kvs_rbtree_exist(kvs_rbtree_t *inst, char *key);

协议层因此不需要理解旋转、着色、后继节点等红黑树内部细节。它只关心：

用哪个实例
调用哪个 KV 操作
如何解释返回值

这正是本次“加入红黑树”最值得回顾的部分：不是从零推导红黑树算法，而是把已有数据结构包装成项目已经形成的 KV 引擎接口。

同样的思路也可以用于后续哈希引擎：哈希表内部怎样定位 key 属于数据结构实现；接入项目时，仍围绕生命周期和五种 KV 语义组织接口。

11. 红黑树在项目中的最小理解范围

为了理解本项目中的接入，只需要掌握下面几层关系。

11.1 树实例和节点

红黑树实例保存：

typedef struct _rbtree {
 rbtree_node *root;
 rbtree_node *nil;
} rbtree;

其中：

root 指向根节点；
nil 是哨兵节点，用于表示空孩子和空树边界；
nil 初始化为黑色；
创建完成时，root 指向 nil，表示树中还没有 KV 节点。

节点中与 KV 项目直接相关的是：

key → 用于比较和查找
value → 与 key 对应的数据

父节点、左右孩子和颜色则服务于红黑树结构本身。

11.2 五种 KV 操作如何映射到底层树操作

KV 接口	在红黑树中的主要过程
`kvs_rbtree_set()`	为 key/value 分配空间，构造节点并插入树
`kvs_rbtree_get()`	按 key 搜索节点，返回节点的 value
`kvs_rbtree_del()`	搜索节点，删除节点并释放相关空间
`kvs_rbtree_mod()`	搜索节点，替换已有 value
`kvs_rbtree_exist()`	搜索节点，通过是否到达 `nil` 判断存在性

这些包装函数把“树节点操作”转换成与数组引擎一致的“KV 操作”。

11.3 生命周期怎样进入程序主流程

程序启动时，两种引擎分别初始化：

init_kvengine()
 ├─ kvs_array_create(&global_array)
 └─ kvs_rbtree_create(&global_rbtree)

网络服务结束后，再进入统一销毁阶段：

dest_kvengine()
 ├─ kvs_array_destory(&global_array)
 └─ kvs_rbtree_destory(&global_rbtree)

红黑树销毁时需要逐步删除树中的节点，最后处理树实例的哨兵节点。具体采用最小节点、最大节点或其他顺序，是树内部的销毁策略；对项目主线而言，重要的是 destory 与 create 共同构成完整生命周期。

12. 用同一套语义验证红黑树引擎

rbtree_testcase() 与 array_testcase() 的业务顺序保持一致，只是命令增加了 R 前缀：

数组： SET → GET → MOD → GET → EXIST → DEL → GET → MOD → EXIST
红黑树：RSET → RGET → RMOD → RGET → REXIST → RDEL → RGET → RMOD → REXIST

这使测试具有两个层次：

单独验证每个引擎是否满足五种 KV 操作；
验证两种引擎在相同业务场景下是否表现出相同语义。

可以把两组用例看成一份“行为契约”：

初始状态和操作	数组响应	红黑树响应
不存在时 SET	`OK`	`OK`
SET 后 GET	对应 value	对应 value
已存在时 MOD	`OK`	`OK`
已存在时 EXIST	`EXIST`	`EXIST`
已存在时 DEL	`OK`	`OK`
DEL 后 GET/MOD/EXIST	`NO EXIST`	`NO EXIST`

只要对外行为一致，客户端就不需要了解底层究竟使用数组还是红黑树。当前协议用命令前缀显式选择引擎，但测试验证的是二者共同的 KV 语义。

13. 数组与红黑树在当前项目中的角色

本阶段不是简单地用红黑树替换数组，而是让两种实现同时存在：

维度	数组引擎	红黑树引擎
协议命令	五种普通命令	五种 `R` 前缀命令
全局实例	`global_array`	`global_rbtree`
生命周期	`create/destory`	`create/destory`
KV 接口	`set/get/del/mod/exist`	`set/get/del/mod/exist`
内部组织	连续数组区间	根节点、哨兵和树节点
查找方式	在有效区间中遍历	按 key 在树中搜索

真正稳定下来的不是某一种数据结构，而是数据结构外面的项目边界：

协议命令
 ↓
统一的 KV 语义
 ↓
不同引擎各自实现

这也解释了“要什么需求、用什么技术方案实现”的关系：

需求是保存、查询、删除、修改和判断 key；
数组和红黑树是两种实现这些需求的技术方案；
协议层负责把客户端命令路由给具体方案；
测试用例负责确认不同方案满足相同的外部预期。

14. 关于多进程、多线程压力测试的课后思考

当前单连接测试中，每条请求都要等待上一条响应，无法同时给服务端制造多个在途请求。要观察并发场景，可以让多个执行单元各自建立连接并运行同一组测试。

14.1 多进程思路

父进程
 ├─ fork → 子进程 1 → 建立连接 → 重复测试
 ├─ fork → 子进程 2 → 建立连接 → 重复测试
 └─ fork → 子进程 N → 建立连接 → 重复测试

每个子进程拥有自己的客户端 socket 和测试循环。父进程等待所有子进程结束，再汇总：

总请求数 = 进程数 × 每个进程的请求数
整体 QPS = 总请求数 × 1000 ÷ 整体耗时毫秒数

14.2 多线程思路

一个客户端进程
 ├─ 线程 1 → 独立连接 → 重复测试
 ├─ 线程 2 → 独立连接 → 重复测试
 └─ 线程 N → 独立连接 → 重复测试

每个线程使用独立连接时，测试流程和当前代码最接近；主线程统一记录开始与结束时间，并统计所有线程完成的请求总数。

14.3 并发数增加后观察什么

并发测试不只是期待 QPS 一定上升，还要同时观察：

所有响应是否仍然符合预期；
总吞吐量怎样随客户端数量变化；
单次请求延迟是否增加；
服务端采用的网络模型是否能发挥并发处理能力；
打印、网络、协议或存储引擎中的哪一部分先成为主要耗时。

因此，多进程或多线程的意义是改变负载模型：从“一个客户端串行发请求”变成“多个客户端同时发请求”。

15. 这一阶段形成的完整项目画面

把前三个阶段放在一起，可以得到当前项目结构：

测试客户端
 ├─ 功能用例：检查每一步响应
 └─ 压力用例：重复场景、计时、计算 QPS
 │
 ▼
 TCP 网络
 │
 ▼
网络层：Reactor / Proactor / ntyco
 │
 ▼
kvs_protocol()：切分 token
 │
 ▼
kvs_filter_protocol()：识别命令并选择引擎
 ┌────┴────┐
 ▼ ▼
 数组引擎 红黑树引擎
 5 + 2 接口 5 + 2 接口
 │ │
 └────┬────┘
 ▼
 统一返回值与文本响应

Makefile 则从构建角度把这些模块放到一起：

kvstore.c
reactor.c / proactor.c / ntyco.c
kvs_array.c
kvs_rbtree.c
NtyCo 与 liburing
 ↓
 kvstore

16. 最后的复习提纲

16.1 测试主线

connect
 → send command
 → recv response
 → compare pattern
 → PASS / FAILED

16.2 压力测试主线

固定业务场景
 → 重复执行
 → 统计实际请求数
 → 记录总耗时
 → 计算 QPS
 → 从失败轮次和响应反查内部状态

16.3 数组问题定位主线

少量测试正常、增加次数后 SET 返回 ERROR
 → 检查容量条件
 → 检查 total 的增减
 → 发现实际元素已删除但 total 仍增长
 → 恢复“有效元素数量”的统一约定

同时记住：

释放内存：先 free 原地址，再把指针置 NULL
循环下标：只表示位置
函数返回值：表示业务结果
协议响应：由业务返回值翻译得到

16.4 多引擎扩展主线

保留数组成型代码
 → 用 ENABLE_ARRAY / ENABLE_RBTREE 控制编译
 → 为红黑树提供同样的 5 + 2 接口
 → 增加 RSET/RGET/RDEL/RMOD/REXIST
 → 协议层按命令选择实例
 → 用同一套业务场景验证两种引擎

16.5 本阶段最重要的认识

测试用例不是项目完成后的附属代码，而是项目继续迭代时用来确认行为的固定标准。

小次数测试验证基本功能，高次数测试还会验证状态能否长期保持一致。

total、节点数量和指针生命周期都属于数据结构必须维护的内部状态。

数组、红黑树以及后续哈希表可以采用不同内部实现，但都可以通过相同的 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 数量 / 邀面数量
→ 反映技术能力和面试表现