iperf 2.0.13源码级网络性能测试工具实战详解
简介：iperf是一款用于评估网络带宽、延迟和传输稳定性的核心测试工具。本文聚焦于iperf 2.0.13版本，深入解析其基于源码的编译、跨平台移植及在不同系统（包括嵌入式设备如手机）上的应用方法。该版本虽为早期发布，但具备完整的TCP/UDP带宽测试、多线程支持与参数自定义能力，适用于资源受限或需兼容旧系统的场景。通过配置、编译到实际测试的全流程实践，帮助用户掌握网络性能诊断关键技术，提升网络优化能力。
iperf 深度解析：从协议原理到实战调优的全链路技术指南
你有没有遇到过这样的场景？明明是千兆网络，传输大文件却只有100Mbps；视频会议总是卡顿，但ping延迟又很低；新部署的防火墙说支持万兆，实际压测连3G都跑不满……这些问题背后，往往藏着一个“看不见的瓶颈”。而要揪出它，我们手里最锋利的那把刀，就是 iperf 。
别被这个名字骗了——这可不是个简单的“网速测试小工具”。在资深网络工程师眼里， iperf 是一把能剖开TCP/IP协议栈、直视网络脉搏的手术刀。今天，咱们就来一次彻底的拆解，不光告诉你怎么用，更要带你看看它是如何工作的、为什么这么设计，以及如何在复杂环境中精准定位问题。
准备好了吗？让我们从一场真实的“网络断案”开始。
想象一下：某数据中心刚完成升级，核心交换机换成了40Gbps的设备。运维团队信心满满地宣布“带宽翻倍”，可业务部门反馈上传速度毫无提升。老板急了，项目组炸锅了。这时候，有人掏出 iperf ，三下五除二跑了个测试，结果让所有人傻眼——单连接吞吐量居然不到500Mbps！
问题出在哪？硬件坏了？配置错了？还是……工具没用对？
答案往往是最后一个。很多人用 iperf 就像用测速网站一样，敲一行命令等着看数字。可如果你不了解背后的机制，看到的结果可能完全是误导。比如上面这个案例，根本原因其实是： 单条TCP流受限于BDP（Bandwidth-Delay Product），无法填满高带宽长延迟链路 。
怎么破？加 -P 8 参数，并发8条流试试？哗——瞬间飙到3.8Gbps！真相大白：不是链路不行，是测试方法错了。
这就是我们为什么要深入理解 iperf 的真正原因。它不只是输出一个数字，而是帮你构建一套分析框架。
经典依旧：为何还在用 iperf-2.0.13？
说到版本，你可能会问：“现在都有 iperf3 了，干嘛还讲 2.0.13？” 这是个好问题。事实上，在很多嵌入式系统、工业网关甚至某些IoT设备中， iperf-2.0.13 依然是默认内置的测试工具。为啥？
因为它够轻！整个源码包才几百KB，编译后的二进制文件在静态链接下也不到100KB。相比之下，iperf3 虽然功能更强，但也更重，依赖更多，在资源受限的环境下反而成了负担。
更重要的是， 2.0.13 版本的设计非常干净 。没有复杂的JSON输出、没有REST API接口，就是一个纯粹的C语言命令行程序。这种“极简主义”让它成了学习网络编程的最佳范本之一。你想知道一个完整的TCP客户端/服务端是怎么搭建的？想了解多线程并发控制如何实现？看它的源码比读教科书还直观。
所以，即便它是“老古董”，只要还能跑得动，就有存在的价值。尤其是在一些老旧设备维护、跨平台移植或者教学演示中，它依然是首选。
源码里的秘密：这个工具有多“讲究”？
打开 iperf-2.0.13 的源码目录，你会看到典型的C项目结构：
├── client.c
├── server.c
├── net.c
├── tcp_window.c
├── reporter.c
└── include/
└── headers.h
别看文件不多，分工可一点不含糊。每个 .c 文件都专注做一件事，这种模块化设计简直是教科书级别的“关注点分离”。
比如 client.c ，里面有个关键函数叫 client_start() ，逻辑清晰得让人感动：
int client_start(struct iperf_test *test) {
connect_with_timeout(test->ctrl_sck, ...); // 带超时的连接，避免卡死
send_parameters(test); // 发送配置给服务端
receive_server_settings(test); // 等对方确认
create_streams(test); // 创建多条数据流（支持-P）
start_timer(test->duration, callback_reporter, test); // 启动定时器
join_threads(test); // 等所有线程结束
return 0;
}
每一行都在干一件具体的事，而且都有错误处理和日志反馈。比如那个 connect_with_timeout ，你知道为什么非得加超时吗？因为在不可靠网络里，一个无限制的 connect() 可能让整个进程挂住几十秒甚至几分钟。加上超时机制，才能保证工具本身不会成为“受害者”。
再看服务端 server.c ，它的 server_start() 函数像个尽职的门卫：
while ((s = accept(test->listener, NULL, NULL)) >= 0) {
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, &one, sizeof(one)); // 关闭Nagle算法
test->ctrl_sck = s;
negotiate_parameters(test); // 和客户端协商参数
run_tcp_server(test); // 开始干活
close(test->ctrl_sck);
}
注意这里设置了 TCP_NODELAY ，也就是禁用了 Nagle 算法。这是为了什么？就是为了减少小包延迟！如果你在测低延迟应用（比如金融交易系统），哪怕几毫秒的累积延迟都可能影响结果。这种细节上的考量，正是专业工具和玩具的区别。
还有那个 tcp_window.c ，负责调节TCP窗口大小。代码虽短，意义重大：
void tcp_adjust_windows(struct iperf_stream *sp) {
int newsize = sp->window;
if (sp->settings->mss > 0)
newsize = max(newsize, sp->settings->mss * 4);
setsockopt(sp->socket, SOL_SOCKET, SO_RCVBUF, &newsize, sizeof(newsize));
setsockopt(sp->socket, SOL_SOCKET, SO_SNDBUF, &newsize, sizeof(newsize));
}
这段代码试图确保接收缓冲区至少能容纳4个MSS（最大段长度）的数据。这样做的目的是最大化带宽利用率，特别是在高RTT链路上。否则，窗口太小，发送方就得频繁等待ACK，白白浪费带宽。
这些看似不起眼的细节，组合起来就是一套完整的高性能网络通信模型。而这，也正是我们可以从中汲取经验的地方。
| 文件名 | 核心职责 | 关键函数 |
|---|---|---|
client.c | 客户端主控逻辑 | client_start() , send_parameters() |
server.c | 服务端监听与会话管理 | server_start() , run_tcp_server() |
tcp_window.c | TCP缓冲区自适应 | tcp_adjust_windows() |
reporter.c | 统计收集与输出 | report_periodic() , report_final() |
threads.c | 多线程调度 | spawn_thread() , join_thread() |
🤓 小贴士：下次你自己写网络工具时，不妨照着这个结构来组织代码。清晰、易维护、好扩展。
下面这张流程图展示了整个控制流是如何流动的：
graph TD
A[main()] --> B{Is Server?}
B -->|Yes| C[server_start()]
B -->|No| D[client_start()]
C --> E[negotiate_parameters]
D --> F[send_parameters]
E --> G[create_streams]
F --> G
G --> H[start_timer]
H --> I[join_threads]
I --> J[report_final]
是不是很清爽？客户端和服务端通过统一的参数协商建立连接，然后各自创建数据流，启动计时器上报进度，最后汇总结果退出。整个过程就像一台精密的钟表，各部件协同运转，互不干扰。
编译的艺术：它怎么做到“到处都能跑”的？
你以为 ./configure && make 就完事了？其实背后有一整套复杂的环境探测机制在工作。
iperf-2.0.13 使用的是经典的 GNU Autotools 工具链（autoconf + automake）。当你运行 ./configure 时，它会自动检测当前系统的编译器、库函数、头文件是否存在，并据此生成合适的 Makefile。
举个例子，它会检查：
AC_CHECK_HEADERS([sys/select.h netinet/tcp.h])
AC_CHECK_FUNCS([gettimeofday memset])
AC_CHECK_LIB([pthread], [pthread_create])
AC_CHECK_LIB([ssl], [SSL_library_init])
如果发现系统有 pthread 库，就会启用多线程支持；如果有 OpenSSL，就允许编译 SSL 加密选项。如果没有呢？那就定义个宏，比如 NO_THREADS ，然后在代码里用 #ifdef 把相关部分跳过去。
这就叫做“条件编译”。它的妙处在于：同一份源码，可以在不同平台上自动裁剪功能，最终生成最适合目标环境的二进制文件。
比如你要往树莓派上交叉编译，只需要这样：
export CC=arm-linux-gnueabihf-gcc
./configure --host=arm-linux-gnueabihf --disable-shared --enable-static
make
搞定！生成的静态二进制可以直接扔进嵌入式设备运行，不用操心glibc版本兼容问题。
不过要注意，MSVC（Windows Visual Studio）是不支持的。因为 iperf 重度依赖 POSIX 接口，比如 fork() 、 select() 、 pthread_* 这些，在Windows上都得改写成 Win32 API 才行。虽然网上有些移植版，但稳定性和功能都有折扣。
所以建议： Linux/Unix 平台用原生编译，Windows 上要么用 Cygwin/WSL，要么直接上 iperf3 。
安全性考虑：要不要开启 SSL？
是的， iperf-2.0.13 支持通过 -Z 参数启用 SSL 加密传输。但它依赖的是 OpenSSL 0.9.8 到 1.0.2 这些老版本， 不支持 TLS 1.3 ，存在一定的安全风险。
握手流程大概是这样：
sequenceDiagram
participant Client
participant Server
Client->>Server: TCP SYN
Server->>Client: SYN-ACK
Client->>Server: ACK + ClientHello
Server->>Client: ServerHello + Certificate
Client->>Server: ClientKeyExchange
Server->>Client: ChangeCipherSpec
Client->>Server: Finished (encrypted)
一旦加密通道建立，所有流量都会被保护起来，防止中间人窃听。这对于金融、医疗等对合规要求高的行业来说是有意义的。
但强烈建议： 只在封闭可信网络中使用此功能 。公网或开放网络请勿启用，毕竟旧版OpenSSL已知漏洞不少。
如果你想验证证书，还可以配合 -C 参数指定CA文件，实现双向认证。不过说实话，拿 iperf 做身份验证有点“杀鸡用牛刀”了。真要搞安全测试，不如上 Wireshark + 自定义脚本组合拳。
移植实战：让它在 Android 和 iOS 上跑起来
Android：NDK 编译 native binary
Android 虽然是Linux内核，但用户空间完全不同。想让它运行 iperf ，得借助 NDK 编译成 native 二进制。
步骤如下：
# 创建独立工具链
$NDK_ROOT/build/tools/make_standalone_toolchain.py \
--arch arm --api 21 --install-dir /tmp/my-toolchain
# 设置编译器
export CC=/tmp/my-toolchain/bin/arm-linux-androideabi-gcc
# 配置并编译
./configure --host=arm-linux-androideabi --prefix=$PWD/output --disable-shared
make && make install
然后推送到手机：
adb push output/bin/iperf /data/local/tmp/
adb shell chmod +x /data/local/tmp/iperf
adb shell /data/local/tmp/iperf -s
成功！你现在有了一个运行在安卓设备上的 iperf 服务器。某些专业的网络诊断App（比如 Network Analyzer）就是这么干的。
iOS：签名限制下的“灰色操作”
iOS 就麻烦多了。苹果不允许随意执行命令行程序，除非越狱或者走企业证书分发。
常见做法是：把 iperf 编译成静态库，集成进一个App里，然后通过 system() 调用执行。但这需要企业级开发者账号，普通用户基本玩不了。
也有极客尝试用 jailbreak 设备刷进去，但这属于“非官方玩法”，稳定性没法保证。
✅ 结论：Android 上可行且实用；iOS 上难度大，仅限特定场景。
TCP vs UDP：两种模式的本质区别
这才是 iperf 最核心的知识点。很多人误以为“测网速就是跑个TCP”，其实完全不是一回事。
TCP：动态调整的“智能流”
TCP 是可靠的、有序的、基于连接的协议。它的带宽测量其实是一个 动态平衡过程 ，受两个关键因素制约：
- 滑动窗口（Flow Control Window） ：由接收方通告，表示还能收多少数据。
- 拥塞控制（Congestion Control） ：由发送方根据网络反馈自主调整速率。
它们共同决定了最大吞吐量，公式为：
$$
\text{Max Throughput} \approx \frac{\text{Receive Window Size}}{\text{Round-Trip Time (RTT)}}
$$
这个值也叫 BDP（Bandwidth-Delay Product） 。举个例子：
- 链路带宽：1Gbps
- RTT：50ms
- BDP = 1e9 bps × 0.05 s = 6.25 MB
也就是说，要想跑满这条链路，接收窗口至少得有6.25MB！可如果你的系统默认只有128KB，那理论最大吞吐也就：
$$
\frac{128\,\text{KB}}{50\,\text{ms}} \approx 20.97\,\text{Mbps}
$$
远远低于物理能力。这就是为什么你在高速专线或卫星链路上总感觉“带宽没跑满”的根本原因。
解决办法？调大接收缓冲区！
sysctl -w net.core.rmem_max=26214400
sysctl -w net.ipv4.tcp_rmem="4096 87380 26214400"
设置完成后，再用 iperf -w 32M 显式指定窗口大小，你会发现吞吐量突飞猛进！
另外，TCP 的发送行为高度依赖 ACK 反馈。可以用下面这个 Mermaid 图来看清交互过程：
sequenceDiagram
participant Client as iperf Client (Sender)
participant Server as iperf Server (Receiver)
participant Network as Network Path
Client->>Server: 发送批量 TCP 数据段 (Segment)
Note right of Client: 基于当前 cwnd 和 rwnd 允许的窗口
Server-->>Network: 缓冲接收数据
Network->>Client: 返回 ACK 确认报文
Note left of Client: ACK 携带新 rwnd 信息
opt 出现丢包或延迟
Server->>Client: 重复 ACK 或延迟 ACK
Client->>Client: 触发拥塞控制调整 (如快速重传)
end
Client->>Client: 更新 cwnd 和 ssthresh
Client->>Server: 调整发送速率并继续发送
看到没？这是一个闭环控制系统。任何环节出问题（比如ACK延迟、窗口停滞），都会导致吞吐下降。
所以，测TCP不仅仅是看“能跑多快”，更要观察过程是否平稳。推荐配合 tcpdump 抓包，导入Wireshark看Stevens图，分析数据段与ACK的时间对应关系。
UDP：裸奔的压力测试
UDP 不同。它无连接、不可靠，也不重传。你让它发多快，它就发多快（只要CPU跟得上）。
命令也很简单：
iperf -c 192.168.1.100 -u -b 100M -t 30
意思是：以100Mbps的恒定速率发送UDP流，持续30秒。
服务端会统计：
- 实际接收速率
- 丢包率
- Jitter（抖动）
丢包率计算公式：
$$
\text{Packet Loss Rate} = \left(1 - \frac{\text{Received Packets}}{\text{Sent Packets}}\right) \times 100\%
$$
iperf 在每个UDP包里嵌入序列号和时间戳，接收端靠这个判断有没有丢、哪几个丢了、什么时候到的。
伪代码长这样：
typedef struct {
uint32_t seq_num;
uint64_t timestamp_ns;
} udp_header;
void handle_udp_packet(char *packet, int len) {
udp_header *hdr = (udp_header*)packet;
static uint32_t expected_seq = 0;
if (hdr->seq_num != expected_seq) {
packet_loss_count += hdr->seq_num - expected_seq; // 统计跳跃丢失
}
// 计算抖动
if (last_time > 0) {
int64_t curr_interval = curr_time - last_time;
jitter_ns += abs(curr_interval - prev_interval);
}
expected_seq = hdr->seq_num + 1;
received_packet_count++;
}
Jitter 的计算依据是 RFC 1889，反映的是连续包到达间隔的变化程度。对于VoIP、视频会议这类实时业务，Jitter > 30ms 就可能导致卡顿。
下面是几种典型场景的测试结果对比：
| 测试条件 | 目标速率 | 平均接收速率 | 丢包率 | 平均抖动（ms） | 解释 |
|---|---|---|---|---|---|
| 局域网直连 | 100 Mbps | 99.8 Mbps | 0.01% | 0.05 | 链路优质，几乎无抖动 |
| WiFi 环境 | 50 Mbps | 47.2 Mbps | 2.1% | 4.3 | 信道竞争引起周期性丢包 |
| 跨公网隧道 | 10 Mbps | 8.6 Mbps | 8.5% | 12.7 | NAT设备缓冲导致突发延迟 |
| 饱和链路压测 | 1 Gbps | 720 Mbps | 28% | 31.5 | 队列溢出严重，不适合实时业务 |
📌 工程提示：对于敏感应用（如SIP电话），建议将平均抖动控制在 < 30ms，丢包率 < 1%，否则需考虑部署 QoS 优先级标记（DSCP/TOS）。
多线程并发测试：榨干每一滴带宽
前面提到，单条TCP流常常无法打满链路。怎么办？并发！
iperf 提供了 -P 参数来启动多个并行流：
iperf -c 192.168.1.100 -P 8 -t 60
这会在客户端创建8个独立的TCP连接，同时向服务端发起数据传输。服务端自动接受并分别统计每条流的性能，最后给出 [SUM] 总带宽。
输出示例：
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 1.25 GBytes 358 Mbits/sec
[ 4] 0.0-30.0 sec 1.23 GBytes 352 Mbits/sec
...
[SUM] 0.0-30.0 sec 4.99 GBytes 1.43 Gbits/sec
看到了吗？单流最高才364Mbps，但8条流加起来接近1.43Gbps！这就是并发的魅力。
底层是怎么实现的？其实就是标准的 pthread 多线程模型：
for (int i = 0; i < num_threads; i++) {
thread_args_t *args = malloc(sizeof(thread_args_t));
// 设置参数...
pthread_create(&threads[i], NULL, send_stream, args);
}
for (int i = 0; i < num_threads; i++) {
pthread_join(threads[i], NULL);
}
每个线程独立创建 socket、连接、发送数据，互不干扰。主线程最后汇总结果。
但要注意，线程太多也会带来副作用。我们在一台Xeon服务器上做了实测：
| 并发数 (-P) | 平均总带宽 | 用户态 CPU (%) | 内核态 CPU (%) | 上下文切换 (/sec) | RSS 内存增量 (MB) |
|---|---|---|---|---|---|
| 1 | 940 Mbps | 18 | 22 | 1,200 | +15 |
| 4 | 3.62 Gbps | 45 | 38 | 4,800 | +58 |
| 8 | 6.78 Gbps | 68 | 52 | 9,100 | +112 |
| 16 | 7.10 Gbps | 76 | 61 | 17,300 | +210 |
结论很明显：
- 带宽随并发数增长，接近线性；
- CPU 开销显著上升，尤其内核态处理中断变多；
- 上下文切换激增，可能成为瓶颈；
- 内存占用非线性增加，主要来自每个连接的 buffer 分配。
所以建议：并发数不是越多越好，一般4~8条足够。太多反而会让本地主机成为瓶颈。
此外，为了避免“雪崩效应”（所有线程同时启动造成瞬时冲击），iperf 还实现了微小延迟机制：
usleep(rand() % 10000); // 每个线程随机延迟0~10ms再开始
这一招很灵，能有效平滑初始流量，避免对服务端造成误判。
实战案例：数据中心里的“隐形杀手”
某公司新建了一个三层数据中心，Spine-Leaf 架构，宣称全线万兆互联。可业务上线后发现跨机房同步特别慢。
我们介入排查，搭建了如下拓扑：
graph LR
A[Server A] -- 10G --> B[Spine Switch]
C[Server B] -- 10G --> B
D[Server C] -- 10G --> B
E[Server D] -- 10G --> B
B -- 20G --> F[Core Router]
注意最后一跳：Spine 到 Core 是20G链路，而下面四个服务器每个都能跑满10G。理论上没问题，对吧？
错！当我们让三台服务器同时向外部发起大流量传输时：
# 在 Server A/B/C 上分别执行
iperf -c TARGET_IP -P 8
总需求带宽高达 3×8×1.2G ≈ 28.8Gbps，远超20G上行链路容量。结果可想而知——拥塞！
用 iftop 一看，上行端口利用率长期100%， tx_dropped 计数狂涨。iperf 输出的 [SUM] 带宽也被卡在19.8G左右，再也上不去。
问题定位了： 上行链路带宽不足 + 缺乏负载分担机制 。
解决方案：
- 升级为40G上行
- 启用 ECMP（Equal-Cost Multi-Path）实现多路径转发
- 或者优化路由策略，分流关键业务
这个案例告诉我们： 单点测试看不出的问题，并发压测一试就现形 。这也是为什么大型网络验收必须包含压力测试环节。
参数调优：打造你的专属测试方案
别再用默认参数瞎跑了！根据业务特征定制测试配置，才是专业做法。
报文大小（-l）：小包还是大包？
默认1470字节适合大多数场景，但如果你在测工业控制网络，可能需要64字节小包：
iperf -c 192.168.1.100 -l 64 # 模拟Modbus/TCP心跳包
或者数据中心内部批量传输，可以试试8KB大包：
iperf -c 192.168.1.100 -l 8192 # 接近RDMA风格的大块传输
不同尺寸的影响如下：
| 报文大小 (Bytes) | 吞吐量 (Mbps) | CPU 使用率 (%) | 场景 |
|---|---|---|---|
| 64 | 180 | 35 | 工业自动化信号 |
| 256 | 420 | 28 | 传感器数据上报 |
| 1470 | 940 | 15 | 视频流、文件同步 |
| 8192 | 950 | 14 | 跨机房备份任务 |
规律很明显：包越大，协议开销占比越低，效率越高。但别超过 MTU，否则会分片！
怎么判断是否分片？抓包看看：
tcpdump -i eth0 host 192.168.1.100 and port 5001 -w mtu_test.pcap
导入Wireshark，如果看到 IP 头里 “More Fragments” 被置位，说明已经分片了。这时候丢任何一个片段，整个包就算丢，可靠性大大降低。
流程图如下：
graph TD
A[用户设定-l参数] --> B{是否 > (MTU - IP头 - 传输层头)?}
B -->|是| C[IP层分片]
B -->|否| D[单包传输]
C --> E[接收端重组]
D --> F[直接交付应用]
E --> G[可能因丢失任一片段导致整体失败]
建议设置 -l 不超过 MTU - 20(IP) - 20(TCP) = 1460 字节，留点余量。
时间与间隔（-t 和 -i）：稳态才是真理
测试时间太短，还没进入稳定状态就结束了，结果不可靠。建议：
- 性能验收：至少60秒
- 拥塞观察：≥300秒
- 稳定性回归：多轮连续执行
用 -i 控制报告频率，观察瞬时波动：
iperf -c 192.168.1.100 -t 60 -i 5
输出类似：
[ 3] 0.0- 5.0 sec 56.2 MBytes 94.3 Mbits/sec
[ 3] 5.0-10.0 sec 58.1 MBytes 97.5 Mbits/sec
[ 3] 10.0-15.0 sec 42.0 MBytes 70.4 Mbits/sec <--- 出现抖动
看到第3个区间突然下降？可能是后台任务占用了CPU，或者是QoS策略切换了优先级。这种细节能帮你发现隐藏问题。
UDP速率控制（-b）：压测极限的正确姿势
TCP 是“尽力而为”，UDP 才是“硬压”。
iperf -c 192.168.1.100 -u -b 900M
逐步提高 -b 值，直到出现明显丢包，记录拐点：
| 目标速率 (Mbps) | 实际接收 (Mbps) | 丢包率 (%) | 判断结论 |
|---|---|---|---|
| 100 | 99.8 | 0.02 | 完全承载 |
| 500 | 498.5 | 0.3 | 接近上限 |
| 800 | 760.1 | 5.0 | 开始拥塞 |
| 950 | 820.3 | 13.7 | 明显瓶颈 |
| 1000 | 832.7 | 16.7 | 物理层已达极限 |
当丢包率突破5%，通常认为服务质量不可接受。这种方法非常适合评估防火墙、IPS、无线AP的实际吞吐能力。
自动化脚本：让测试变得科学
别再手动跑了！写个脚本，实现标准化、可复现的测试流程。
#!/bin/bash
# standard_iperf_test.sh - 标准化网络性能测试脚本
SERVER_IP="192.168.1.100"
DURATION=60
LOG_DIR="/var/log/iperf"
DATE_STAMP=$(date +%Y%m%d_%H%M%S)
OUTPUT_FILE="$LOG_DIR/result_$DATE_STAMP.txt"
mkdir -p $LOG_DIR
echo "[$(date)] Starting iperf test to $SERVER_IP" >> $LOG_DIR/test.log
for pkt_size in 64 256 1470 8192; do
for protocol in tcp udp; do
echo "Testing $protocol with packet size $pkt_size..." >> $LOG_DIR/test.log
if [ "$protocol" = "tcp" ]; then
iperf -c $SERVER_IP -l $pkt_size -t $DURATION -i 10 \
>> $OUTPUT_FILE 2>&1
else
iperf -c $SERVER_IP -u -l $pkt_size -b 900M -t $DURATION -i 10 \
>> $OUTPUT_FILE 2>&1
fi
done
done
echo "Test completed. Results saved to $OUTPUT_FILE"
跑起来：
chmod +x standard_iperf_test.sh
nohup ./standard_iperf_test.sh &
后期还能用Python解析日志，生成趋势图：
import re
import pandas as pd
import matplotlib.pyplot as plt
def parse_log(file_path):
records = []
pattern = r'(\d+\.\d+)-(\d+\.\d+) sec\s+([\d\.]+)\s+(M|K)Bytes\s+([\d\.]+)\s+Mbits/sec'
with open(file_path, 'r') as f:
for line in f:
match = re.search(pattern, line)
if match:
start, end, trans_val, unit, rate = match.groups()
records.append({
'interval': f"{start}-{end}",
'bandwidth_Mbps': float(rate)
})
return pd.DataFrame(records)
df = parse_log('result_20250405_100000.txt')
df.plot(x='interval', y='bandwidth_Mbps', kind='line', title='Bandwidth Trend')
plt.xticks(rotation=45)
plt.tight_layout()
plt.savefig('bandwidth_trend.png')
一键执行、自动记录、可视化分析，这才是现代运维该有的样子。💪
回过头看， iperf 不只是一个工具，它是一套思维方式。它教会我们：
不要相信单一指标，
不要忽略测试方法的影响，
更不要把“看起来正常”当作“真的没问题”。
真正的网络高手，不是最快修好故障的人，而是能在问题发生前就预见到它的人。而这一切，始于你对每一个参数的理解，每一次测试的设计，和每一份报告的深思。
所以，下次当你拿起 iperf 的时候，记得问自己一句：
“我这次测的，真的是我想知道的吗？”🤔
简介：iperf是一款用于评估网络带宽、延迟和传输稳定性的核心测试工具。本文聚焦于iperf 2.0.13版本，深入解析其基于源码的编译、跨平台移植及在不同系统（包括嵌入式设备如手机）上的应用方法。该版本虽为早期发布，但具备完整的TCP/UDP带宽测试、多线程支持与参数自定义能力，适用于资源受限或需兼容旧系统的场景。通过配置、编译到实际测试的全流程实践，帮助用户掌握网络性能诊断关键技术，提升网络优化能力。
更多推荐
4
0- 0
已为社区贡献8条内容
所有评论(0)