文章目录
- 用途
- 发展
- 使用手册
- 常用参数
- 问题及相关分析
- control socket has closed unexpectedly / select failed: Bad file descriptor
- 问题描述
- 定量模式 VS 定时模式
用途
测试网络吞吐量性能的工具。
发展
iperf2和iperf3是完全独立的两个工具，二者不兼容。
| iperf2 | iperf3 | |
|---|---|---|
| 来源 | 原始iperf基础上的开源社区维护版 | ESNET团队的重写版 |
| 维护 | SourceForge | GitHub |
| 协议 | 支持TCP、UCP | 支持TCP、UCP、SCTP（3.1新增） |
| 安装 | 包名iperf | 包名iperf3 |
使用手册
iperf3官网: http://software.es.net/iperf/
变更参考：https://iperf.fr/iperf-doc.php
常用参数
通用: -p, --port # 服务端监听的端口/客户端连接的端口，默认是5201 -f, --format [kmgKMG] 打印吞吐量单位：Kbits, Mbits, KBytes, MBytes -i, --interval # 周期吞吐量、抖动、丢包报告的间隔时间，默认是1s -F, --file name 客户端传输/服务端接收指定本地文件 -B, --bind <host> 绑定特定端口 -V, --verbose 更详细的输出 -J, --json 以JSON格式输出 --logfile f 将输出内容发送到日志文件 -d, --debug 输出调试信息 -v, --version 显示版本信息并退出 -h, --help 显示本信息（帮助手册）并退出 服务端: -s, --server 以服务端运行 -D, --daemon 将服务端作为守护进程运行 -I, --pidfile file 写PID文件 -1, --one-off 处理一个客户端连接然后退出 客户端: -c, --client <host> 以客户端运行, 指定连接服务端的主机 -u, --udp 使用UDP协议 -b, --bandwidth #[KMG][/#] 目标带宽，单位bits/s (0表示无限制) (UDP默认1 Mbit/s, TCP无限制) (突发模式时可在带宽后添加/和包数量，将不间断发送指定数量的数据包，即便超出了指定带宽限制) -t, --time # 传输所需时间 (默认10s) -n, --bytes #[KMG] 传输字节数量 (instead of -t) -k, --blockcount #[KMG] 传输数据块/包数量 (instead of -t or -n) -l, --len #[KMG] 缓冲区读写长度 (TCP默认128KB，UDP默认8KB) --cport <port> 绑定指定的客户端端口 (TCP and UDP, 默认临时端口) -P, --parallel # 并行运行的客户端流数量 -R, --reverse 以反转模式运行 (服务端发送，客户端接收) -w, --window #[KMG] 设置窗口大小/套接字缓冲区大小 -M, --set-mss # 设置TCP/SCTP最大分段大小 (MTU - 40 bytes) -N, --no-delay 设置TCP/SCTP无延迟，禁用Nagle算法 -4, --version4 仅使用IPv4 -6, --version6 仅使用IPv6 -S, --tos N 设置IP服务类型 -Z, --zerocopy 使用“零拷贝”发送数据 -O, --omit N 省略前n秒 -T, --title str 在每个输出前加上的字符串 --get-server-output 从服务端获取结果 --udp-counters-64bit 在UDP测试数据包中使用64位计数器问题及相关分析
control socket has closed unexpectedly / select failed: Bad file descriptor
问题描述
-n 1G定量传输频繁触发control socket has closed unexpectedly / select failed: Bad file descriptor，换成-t 60就稳定不崩溃。
定量模式 VS 定时模式
-n <大小>定量模式（Number）
- 运行规则：客户端强制传输指定总数据量（如-n 1G= 必须完整发送 1GB payload），无论耗时多久，凑够总量才会停止。
1、发包逻辑：链路正常时匀速发包；一旦出现丢包、速率下跌，iperf 会瞬时拉高发包速率疯狂重传补流量，形成报文脉冲冲击；
2、重传逻辑：丢包后无节流，持续超额发包填补缺失的数据，WiFi 驱动、SDIO 总线、系统 socket 队列极易瞬间打满溢出；
3、资源释放：必须等全部数据传输完成后，才一次性回收所有 FD、缓冲区、连接句柄；单次会话内海量报文持续占用资源，嵌入式精简 iperf，极易出现内存 / 句柄泄漏；
4、控制通道：补流量阶段 100% 带宽被数据报文占满，iperf 用来同步状态的小 TCP 控制包会被系统丢弃，两端心跳失联，直接抛出control socket closed / Bad file descriptor。
- 数据流特点：总传输字节严格固定，测试耗时随链路质量浮动，链路越差，测试持续时间越长、报文冲击越剧烈。
-t <秒>定时模式（Time）
- 运行规则：客户端持续发送流量，严格跑满设定时长（如-t 60= 连续打流 60 秒），到时间立刻主动停止发包，完成一次测试会话。
1、发包逻辑：按-b设定带宽匀速平稳输出，不会主动超额补包；
2、重传逻辑：出现丢包只会在当前时间窗口内轻微补偿，不会为了凑总量无限制猛发；
3、资源释放：每一秒 iperf 都会执行一次套接字状态同步、缓冲区刷新、文件描述符回收，资源周期性释放，不会持续堆积；
4、控制通道：每秒都有空闲时隙收发控制信令（带宽同步、心跳报文），TCP 控制 socket 不会被 UDP/TCP 数据洪流完全淹没。
- 数据流特点：时长固定，传输总数据量随链路质量浮动，链路差则总流量变少。
| :—: | :— | :— |
| 对比维度 | -t | -n |
|---|---|---|
| 核心停止逻辑 | 到达设定时长立刻停止发包，总传输流量随链路质量浮动 | 必须发完指定总字节才停止，测试耗时随链路质量浮动 |
| 发包速率策略 | 严格按-b设定带宽匀速输出，无超速补包行为 | 链路出现丢包/速率下跌时，自动瞬时拉高发包速度，疯狂补发缺失流量，形成脉冲洪流 |
| 资源回收机制 | 每秒执行一次缓冲区刷新、套接字状态同步、文件描述符周期性释放，资源无长期堆积 | 全程持续占用所有网络资源，仅在全部数据传输完成后一次性回收，嵌入式易发生FD/内存泄漏 |
| 控制心跳可靠性 | 高；流量平稳，队列不会持续满载，每秒有空闲时隙收发心跳小包，控制通道不易失联 | 极低；补流量阶段带宽被数据报文占满，内核/无线驱动优先丢弃低优先级心跳小包，极易心跳失联 |
| 链路波动耐受能力 | 强；丢包仅减少该周期总传输量，不会反向加重发包压力，无恶性循环 | 弱；丢包→超速补发→队列溢出→更多丢包，形成负载恶性循环 |
| 嵌入式Linux兼容性 | 极好，长时间、多轮批量测试极少出现socket崩溃报错 | 较差，裁剪版iperf3长会话高频触发control socket closed/Bad file descriptor |
| 核心输出指标 | 固定时间窗口内：平均吞吐量、实时抖动、逐秒速率波动、丢包率 | 固定数据量下：完整传输耗时、全程平均吞吐量 |
| 批量自动化测试适配 | 完美适配，搭配iperf3 -s -1可循环连续跑多轮无崩溃 | 不适合自动化批量循环，单次手动短流量测试尚可 |
| UDP大带宽压测适配 | 稳定，不会因丢包引发瞬时超大报文冲击 | 风险高，极易打满WiFi/SDIO驱动队列，射频链路卡死 |
| 典型适用场景 | 1. WiFi长时间稳定性压力测试 2. 多信道/多天线方案横向对比 3. UDP实时业务（音视频）抖动测试 4. 嵌入式自动化批量复测 | 1. 模拟固定大小文件完整上传/下载耗时测试 2. WiFi+本地存储联动读写带宽测试 3. 产品流量限额、计费逻辑验证 |
| 明显缺陷 | 无法精准控制总传输字节，仅能控制测试时长 | 1. 丢包会放大网络负载 2. 长会话极易断控制心跳 3. 嵌入式设备易进程卡死报错 |
