Benchmark Methodology

English · 简体中文

性能评估方法

评估对象是 rust-raknet 实现。10 月 12 日结果含 623 次已校验横向测量，构建源码为公开提交 1199ac7。原始 send 的专项稀疏 RTT 复测在结果页单独注明。

评估对象是 rust-raknet 的实现，不是所有 RakNet 实现。最近一次 README 测量使用传输回显负载，与 Minecraft 玩家数量或游戏负载无关。

先定义交付语义

所有吞吐对比采用可靠有序消息：rust-raknet ReliableOrdered、C KCP message mode、每个 QUIC 连接一条双向流、TCP 长度前缀记录。对端核验完整有效载荷及消息顺序后回显。不能拿不可靠 UDP 裸发送速率对比可靠交付速率。

实现	版本或固定提交	关键配置
rust-raknet	1.0.0 + 发送策略变更，本地 8c06cf4	普通 send 与显式 batch 分开，Tokio 1.53.1
TCP	Linux 7.0.11-76070011-generic，仓库驱动 0.1.0	TCP_NODELAY，4 B 小端长度前缀，整记录写入
官方 C KCP	b1a7a2101dcbb96017681a500d6b82bbe5a88766	未改动 ikcp.c/h，非 Rust KCP
quic-go	v0.63.0，Go 1.27.2	TLS 1.3、拥塞控制、流量控制开启

C KCP：ikcp_nodelay(kcp, 1, 10, 2, 1)，写入/输入后立即 flush；单连接窗口 64/64，高并发 64/128，无 FEC、无加密。QUIC 保留了安全及控制机制，功能成本与未加密的 rust-raknet / C KCP 不同。

分开测四种负载

负载	要回答的问题	方法
单连接吞吐	一条连接能持续交付多少数据	64 条消息应用窗口；64 / 800 / 4,096 B；丢包及延时组合
高并发吞吐	大量活跃连接如何利用 CPU	64 / 256 / 1,024 / 2,048 连接；每连接窗口 16
持续负载交付延迟	系统忙时消息要等多久	单独运行 --loaded-rtt，每条消息发出前到完整回显的时间
稀疏消息延迟	没有持续大负载时的往返成本	顺序请求/回显，独立 CPU 亲和性，充分采样

高并发总计 1,048,576 条测量消息；每连接先预热 20 次，所有连接通过 barrier 后才开始计时，直至全部完成才关闭。持续负载延迟每次测量 262,144 条消息，预热样本清空。它不是单向网络延迟，也不是仅服务端处理时间。

指标与单位

• 吞吐：已核验的单方向应用有效载荷字节 / 秒 / 1,048,576，单位 MiB/s。不计协议头、ACK，不把两个方向相加。
• RTT：客户端发出消息到完整核验回显的往返时间，包含两端处理、排队及网络。
• 中位延迟：半数消息不超过这个值。95% / 99% 延迟：相应比例消息不超过这个值，用来观察较慢消息。
• 内存：Linux wait4 的 ru_maxrss，KiB 除以 1,024 得到 MiB；C/S 分别表示客户端/服务端进程峰值 RSS。

RSS 覆盖启动、预热、测量和退出，包含运行时、分配器和应用缓冲。它不包含内核 socket 缓冲，不能代表每连接内存，也不能将 C/S 峰值之和当成同时峰值。TCP 有较多内核状态，因此 RSS 不能用来比较网络的完整系统内存成本。

RTT 测量存储样本、读时钟和排序会影响 CPU/内存，所以持续负载延迟必须与纯吞吐分开运行，使用该轮自身 RSS。

丢包要测对

netem 的概率针对网络包，数据和 ACK 都受影响，不是应用消息。合并后的数据报丢失可能影响多条消息，TCP 分段也可能包含多个记录。不同运行的随机丢包轨迹不相同。

“0% 注入丢包”不保证绝对无丢包：UDP 接收缓冲仍可能溢出。每轮记录命名空间内 UdpRcvbufErrors、其他 UDP 错误及 qdisc 统计。批量接口遇到有效丢包反馈会关闭合并，所以还要说明 warmup 的影响。

所有丢包配置仅在私有网络命名空间中执行，禁止使用主机接口或主机 loopback。

公平性与重复性

最近环境：i7-9700F，8 个逻辑 CPU；Rust 1.98.1 / GCC 13.3.0 / Go 1.27.2，优化构建。回环 MTU 1,500 B，GSO/GRO 限制单包，netem 队列 100,000，nice 10。

单连接 Rust/Go 各四个 worker，C 单个事件循环，未固定 CPU；不是相同 CPU 预算下的实现极限。高并发四个 worker 和四个服务端 socket，服务端/客户端各使用不重叠的四个 CPU。稀疏延迟分别固定到两个 CPU，但亲和性不等于独占核心。

单连接 rust-raknet 名义 MTU 1,428 B，与 C KCP / QUIC 的 UDP 1,400 B 对齐。高并发 rust-raknet 名义 MTU 1,400 B，QUIC UDP 1,372 B，C KCP UDP 1,400 B；C KCP 的 IPv4 包预算多 28 B，不能外推为相同分片条件。

每个吞吐/负载延迟组合重复三次，稀疏延迟五次。轮换协议顺序、每轮新建服务端和连接。报告中位数与最小–最大范围；延迟百分位是各轮百分位的中位数，不是合并样本计算。

如何得出结论

同时比较中位数、范围、较慢消息延迟和 RSS。普通 send 与显式批量接口属于不同应用负载，策略是本地选项；一个条件更快不代表所有场景获胜。当前结果页记录源码、工具链及独立的 73.1 µs 复测。

可靠有序回环回显不证明混合模式公平性、自适应拥塞控制、WAN 竞争、突发丢包/抖动或 NAT 穿透表现。公开七列 runner现已包含两个策略变体；默认/策略构建应保持库源码和解析依赖相同。