当前位置：首页 > news >正文

iperf2 vs iperf3：UDP 发包逻辑差异与常见问题

news 2025/8/25 9:27:11

1. 问题引入

在日常网络测试中，大家经常会遇到这样的情况：iperf3 -u -c -b 1000M

结果显示：实际带宽只有 600~800 Mbps，远低于我们设置的 1000 Mbps。

于是问题来了：

是链路本身达不到 1Gbps？
还是 iperf3 没有按指令发足够多的 UDP 报文？

很多人会因此怀疑测试结果不准确。其实这并不是链路坏了，而是 iperf3 UDP 模式的设计决定了它不会“强行灌包”。

2. 根本原因

造成这种现象的核心原因在于 iperf2 与 iperf3 的 UDP 发包逻辑不同：

iperf2：强调“尽量贴合目标速率”。如果系统调度落后，会突发补发欠账的包，看起来速率接近 -b，但链路抖动大，丢包率可能高。
iperf3：强调“真实统计”。如果系统调度落后，就直接跳过“欠账”，只统计实际发出的字节数。结果可能低于 -b，但数值更真实，能反映链路的实际可用带宽。

换句话说：

iperf2 更像“压测工具” → 灌满链路，测试设备极限。
iperf3 更像“测量工具” → 精确统计，反映真实可用速率。

3. 发包逻辑对比

3.1 关键变量与基本公式

目标带宽：B_target（bit/s），由 -b 指定
UDP 载荷长度：L_payload（Byte），由 -l 指定
每包比特数：P_bits = L_payload * 8
期望包速率：pps = B_target / P_bits（包/秒）
理想包间隔：Δt = 1 / pps = P_bits / B_target（秒）

注意：iperf 的带宽统计通常以应用层负载为准（即 payload 大小），不含 UDP/IP/L2 头部；但链路“线速”会受实际报文总大小（含各层头部、IFG 等）影响。

示例（-b 1,000,000,000，-l 1470）：

P_bits = 1470 * 8 = 11760
pps ≈ 1e9 / 11760 ≈ 85,034 包/秒
Δt ≈ 11.76 μs/包这意味着：用户态要在 每 11.76 μs 精准触发一次 sendto()，对普通 OS 调度精度是非常苛刻的。

3.2 iperf2：允许“追赶”的节奏（更像压测）

思路

以累计目标字节数为节拍参考：target_bytes(now) = B_target * elapsed
如果当前已发送字节 sent_bytes < target_bytes(now)，则立即、连续多次 sendto() 直到追上进度
这样会出现突发补发（burst），让统计值更贴近 -b，但链路侧抖动与丢包风险更高

流程

周期性计算“理论上应该发出的累积字节数”
如果“欠账”，就循环 sendto() 补发到“应发进度”
否则按节拍 sleep_until()
统计以“发送成功的字节数/窗口时间”为准（更接近目标，但存在突发）

伪代码

// iperf2-style UDP pacing (pseudo)
init_clock();
uint64_t sent_bytes = 0;
const uint64_t pkt_bytes = L_payload;
const double   Bps = B_target / 8.0;while (running) {double elapsed = now_seconds_since_start();double should_send_bytes = Bps * elapsed;// 欠账就追赶：可能一次性 send 多包while (sent_bytes + pkt_bytes <= should_send_bytes) {int rc = sendto(sock, buf, L_payload, 0, ...);if (rc < 0) {if (errno == EAGAIN || errno == EWOULDBLOCK) break; // socket 滑窗/队列满// 其它错误按需处理break;}sent_bytes += rc;}// 适度小睡，避免忙等sleep_until(elapsed + small_delta);
}

效果与代价

更容易“报表接近 -b”
可能把欠账一次性灌入内核/NIC 队列 → 链路侧看到 burst、抖动、甚至丢包上升

3.3 iperf3：不追赶的“到点发一包”（更像测量）

思路

以下一次发送的绝对时间戳为节拍：next_send_time
到点就发一包；如果因调度/阻塞落后了，不会补发欠账，而是顺延到新的节拍
统计“实际成功发出的字节数/真实时间”，因此当系统跟不上节拍时，显示带宽会低于 -b

流程

预先计算 Δt，设置 next_send_time = start + Δt
若 now < next_send_time → 睡到点；到点后只发一包
若 now >= next_send_time（落后）→ 不补发欠账，直接把 next_send_time 顺延（常见做法是 next_send_time = now + Δt 或者按步进递增，落后太多时会跳过若干节拍）
统计“实际发出去的字节/时间窗口”，更接近真实可用能力

伪代码

// iperf3-style UDP pacing (pseudo)
struct timespec next = start_time + Δt;
uint64_t sent_bytes = 0;while (running) {struct timespec now = clock_gettime(CLOCK_MONOTONIC);if (now < next) {sleep_until(next);               // 到点再发}// 到点只发一包，不追赶int rc = sendto(sock, buf, L_payload, 0, ...);if (rc > 0) {sent_bytes += rc;} else {if (errno == EAGAIN || errno == EWOULDBLOCK) {// socket 满了，说明系统跟不上节拍，不补发，直接顺延} else {// 其它错误按需处理}}// 计算下一个节拍；若落后较多，常见做法是直接“与 now 对齐”：now = clock_gettime(CLOCK_MONOTONIC);if (now > next + Δt) {// 说明错过多个节拍，直接对齐，避免累积补发next = now + Δt;} else {next = next + Δt;}
}
// 统计：实际成功发出的字节 / 真实窗口时间（不会“强行贴合 -b”）

效果与代价

更真实地反映“系统+内核+NIC”整体可用发包能力
当节拍跟不上目标时，显示带宽显著低于 -b（这是特性，不是 bug）

3.4 行为差异：一个“欠账”场景

设定 Δt = 11.76 μs，next_send_time = t0 + Δt
某次调度抖动导致 now = t0 + 100 μs 才醒来
- iperf2：计算“应发 N 包”，立即循环 sendto() 补发到应发进度（burst）
- iperf3：只发一包，然后把 next_send_time 挪到 now + Δt（或按步进顺延），不补发落下的 N−1 包

3.5 时序图

4. 伪代码对比

// iperf2 (简化示意)
for (;;) {target += pkt_bytes;while (sent < target) sendto(pkt);  // 允许“追赶”补发（可能突发）sleep_until(next_time);next_time += Δt;
}// iperf3 (简化示意)
for (;;) {if (now < next_time) sleep_until(next_time);sendto(pkt);                         // 到点才发，不补发“欠账”next_time += Δt;                     // 落后就顺延，不追赶
}
// 统计= 实际成功发送字节 / 时间窗口（不强行贴合 -b）