jperf 1.0.0 Linux 实战：从解压构建到 TCP/UDP 性能测试与自动化

简介jperf-1.0.0.zip 是一份面向 Linux 运维与网络性能测试人员的 Java 工具源码包对应 jperf 1.0.0 版本。它基于 Java 开发支持 TCP 与 UDP 协议可测量带宽、延迟、丢包率等关键指标并通过模拟大量并发连接评估网络在高负载下的表现适用于网络设备验证、服务器性能调优与数据中心网络优化等场景。压缩包共 49 个文件约 70KB以 20 个 java 源文件与 14 个 class 编译文件为主体另含 5 个 xml 配置、3 个 txt 说明、3 个 iml 与 1 个 ipr/iws 工程文件、1 个 jar 包及 properties 配置整体为可导入 IDE 的完整工程结构便于二次开发与源码研读。目前已有 106 人学习下载。读者可借此掌握 jperf 的工程组织方式、测试模式实现与参数配置逻辑为网络性能测试与调优提供可复用的参考。1. jperf-1.0.0.zip 在 Linux 上到底能干什么很多人第一次看到jperf-1.0.0.zip会以为它只是个带界面的 iperf 壳子实际上它是一套基于 Java 的图形化网络性能测试工具专门用来把 iperf 那堆命令行参数变成可视化操作。你在 Linux 服务器上跑 iperf 测带宽参数记错一个字母结果就完全不一样而 jperf 把 TCP_RR、TCP_CBR、UDP_RR 这些模式做成了下拉框连接数、传输速率、测试时长都能在界面上填。它适合谁网络运维、服务器性能调优、数据中心网络验证的从业者尤其是需要反复做对比测试又不想每次翻 man 手册的人。这个 1.0.0 版本解压后能看到pom.xml、build.xml、src、examples、target这些目录说明它同时支持 Maven 和 Ant 两种构建方式源码是完整的不是只给一个 jar 让你黑盒用。2. 解压后先别急着跑目录结构与构建方式选型2.1 从文件清单判断这个包能不能直接用拿到jperf-1.0.0.zip之后先unzip -l看一眼内容别直接解压到当前目录。这个包里有几个关键文件需要你提前认识文件/目录作用是否需要动pom.xmlMaven 构建配置管理依赖和打包需要检查 Java 版本build.xmlAnt 构建脚本老项目常见备用方案srcJava 源码目录需要编译examples示例配置或脚本参考用target编译输出目录可能已有 jar先看有没有现成的jperf-all.iml/.ipr/.iwsIntelliJ IDEA 工程文件用 IDEA 打开时用LICENSE.txt/README.txt许可和说明必读常见做法是先用unzip -l jperf-1.0.0.zip | head -50确认没有路径穿越问题再解压到/opt/jperf或~/tools/jperf这种独立目录。如果你看到target目录里已经有jperf-1.0.0.jar或类似文件那说明作者可能已经编译过你可以跳过构建直接运行但要注意这个 jar 是不是完整可执行。2.2 Maven 和 Ant 两条路怎么选这个包同时给了pom.xml和build.xml说明它经历过从 Ant 到 Maven 的迁移或者作者想兼容两种构建习惯。我一般优先走 Maven因为依赖管理更清晰。先确认 Java 环境# 检查 Java 版本jperf 1.0.0 通常需要 JDK 8 或以上 java -version javac -version # 如果没有 JavaUbuntu/Debian 系这样装 sudo apt-get update sudo apt-get install default-jdk # CentOS/RHEL 系这样装 sudo yum install java-1.8.0-openjdk-devel装完 JDK 后进入解压目录先试 Maven 构建cd /opt/jperf/jperf-1.0.0 # 用 Maven 编译并打包跳过测试可以加快速度 mvn clean package -DskipTests # 如果构建成功target 目录下会出现可执行 jar ls -lh target/*.jar这里-DskipTests不是必须的但如果你只是想把工具跑起来跳过测试能省几分钟。clean会清掉之前的编译产物避免旧 class 文件干扰。如果 Maven 报错说找不到依赖检查pom.xml里的 repository 配置有些老项目依赖的仓库已经下线需要手动换成中央仓库或阿里云镜像。如果 Maven 走不通比如pom.xml里的插件版本太老和当前 Maven 不兼容那就切 Ant# 确认 ant 已安装 ant -version # 如果没有Ubuntu/Debian 安装 sudo apt-get install ant # 在项目根目录执行默认构建目标 ant # 或者指定打包目标具体看 build.xml 里定义的 target 名 ant jarAnt 构建的好处是它对老 Java 项目兼容性更好坏处是依赖需要手动放到lib目录。你打开build.xml看classpath部分如果引用了lib/*.jar而解压包里没有lib目录那就得自己补依赖。常见做法是从 Maven 中央仓库下载对应 jar 放进lib再重新跑ant。提示不管走哪条路构建之前先看一眼README.txt里面通常会写清楚这个版本对应的 iperf 版本和 Java 版本要求能省掉很多试错时间。3. 启动 jperf 并跑通第一个 TCP 测试3.1 命令行启动与图形界面依赖jperf 是 Java Swing 写的图形工具在 Linux 上启动需要 X11 转发或者本地桌面环境。如果你在纯 SSH 终端里跑./jperf报HeadlessException说明没有图形显示。两种解法一是用ssh -X或ssh -Y连服务器把图形界面转发到本地二是在服务器上装 VNC 或者直接用带桌面的 Linux。启动脚本通常在项目根目录或target目录下名字可能是jperf.sh或直接jperf。如果没有启动脚本可以手动用 java 命令跑# 假设打包后的 jar 在 target 目录主类名从 README 或 MANIFEST 里找 java -jar target/jperf-1.0.0.jar # 如果 jar 没有指定 Main-Class需要显式指定主类 java -cp target/jperf-1.0.0.jar:lib/* com.example.jperf.Main-cp后面的lib/*是通配符表示把lib目录下所有 jar 都加入 classpath。冒号是 Linux 下的分隔符Windows 用分号。主类名不要猜用unzip -p target/jperf-1.0.0.jar META-INF/MANIFEST.MF看Main-Class字段或者翻README.txt。3.2 TCP_RR 模式参数怎么填jperf 界面上最常用的模式是 TCP_RRTCP Round Robin适合测服务器处理并发连接的能力。启动后你会看到几个关键输入框Server填 iperf 服务端的 IP如果本机同时跑服务端和客户端就填127.0.0.1Port默认 5001如果被占用改成 5002 或更高Connections并发连接数测并发能力时从 10 开始逐步加到 100、500Duration测试时长单位秒一般 10 到 30 秒足够看出趋势Transmit Size每次传输的字节数TCP_RR 模式下通常设小一点比如 1KB 到 8KB填完之后点 Runjperf 会调用底层的 iperf 命令。你可以在界面下方的命令预览里看到实际执行的命令类似iperf -c 127.0.0.1 -p 5001 -t 10 -P 10 -l 1K这里-c是客户端模式-p指定端口-t是时长-P是并发连接数-l是传输块大小。理解这些参数和界面的对应关系很重要因为界面偶尔会有 bug直接看命令预览能确认你到底在测什么。3.3 服务端怎么配合jperf 本身可以启动服务端但更常见的做法是在目标机器上用 iperf 命令行起服务端jperf 只做客户端。这样更稳定也方便在服务器上写脚本自动化# 在目标服务器上启动 iperf 服务端监听 5001 端口 iperf -s -p 5001 # 如果要同时支持多个客户端加 -i 1 每秒输出一次状态 iperf -s -p 5001 -i 1服务端起来之后你在 jperf 客户端填目标 IP 和端口点 Run 就能看到吞吐量、抖动、丢包率这些指标。如果连不上先在客户端用telnet 目标IP 5001或nc -zv 目标IP 5001确认端口通不通再检查服务端防火墙有没有放行。注意jperf 1.0.0 底层调用的 iperf 版本可能是 iperf 2.x不是 iperf 3.x。两者参数不兼容如果你系统里装的是 iperf3jperf 调它可能会报参数错误。用iperf -v确认版本必要时单独装 iperf 2.x。4. UDP 测试与结果解读丢包率、抖动怎么看4.1 UDP_RR 和 UDP_CBR 的区别UDP 模式下 jperf 提供两种常见模式UDP_RRRound Robin和 UDP_CBRConstant Bit Rate。UDP_RR 适合测低延迟、高数据速率的场景比如实时音视频传输UDP_CBR 适合模拟恒定码率的流比如 IPTV 或 VoIP。选错模式会导致测试结果和实际业务对不上。在 jperf 界面选 UDP 模式后关键参数多了一个Bandwidth单位是 Mbps 或 Kbps。这个值决定客户端往服务端打流的速度。测丢包率时一般从目标带宽的 80% 开始逐步加压看丢包率什么时候超过 1%。比如你测一条 1Gbps 的链路先设 800Mbps跑 30 秒看服务端报告的丢包率。# 对应的 iperf 命令大概是这样的 iperf -c 目标IP -p 5001 -u -b 800M -t 30 -i 1-u表示 UDP 模式-b 800M是带宽 800Mbps-i 1是每秒输出一次中间结果。jperf 界面上填完参数后命令预览里会显示类似内容你可以直接复制到终端里跑对比图形界面和命令行的结果是否一致。4.2 结果表格里哪些数字不能忽略jperf 跑完之后会显示一个结果面板里面有几个关键指标指标含义正常范围参考Transfer总传输数据量取决于时长和带宽Bandwidth平均吞吐量接近设定带宽的 90% 以上Jitter抖动UDP 模式才有小于 1ms 算好大于 5ms 要查Lost/Total丢包数/总包数丢包率小于 0.1% 可接受Lost Percent丢包率超过 1% 说明链路有问题抖动和丢包率是 UDP 测试的核心。如果抖动很大但丢包率很低可能是中间设备队列调度不均匀如果丢包率随带宽增加而飙升说明链路已经到瓶颈了。我一般会做三组对比50% 带宽、80% 带宽、100% 带宽看丢包率曲线的拐点在哪里那个拐点就是实际可用带宽的上限。4.3 导出结果做进一步分析jperf 支持把结果导出成文本或 CSV方便用 Excel 或 Python 画图。导出按钮通常在结果面板的右下角或者菜单里有 Export。如果找不到导出功能可以直接复制结果面板里的文本粘贴到文件里# 把 jperf 输出保存到文件方便后续处理 # 假设你把结果复制到了剪贴板用 xclip 保存 xclip -selection clipboard -o jperf_result.txt # 或者直接用 iperf 命令行输出到文件 iperf -c 目标IP -p 5001 -u -b 800M -t 30 -i 1 iperf_udp_result.txt 21拿到文本后用awk或 Python 提取每秒的带宽和丢包率画成折线图比看 jperf 界面上的汇总数字更直观。常见做法是用 pandas 读 CSVmatplotlib 画图几行代码就能看出趋势。5. 避坑与排查jperf 在 Linux 上最容易翻车的五个点5.1 启动报 NoClassDefFoundError现象运行java -jar jperf-1.0.0.jar时报NoClassDefFoundError或ClassNotFoundException提示某个类找不到。原因jar 包没有把依赖打进去或者pom.xml里配置的依赖在运行时缺失。jperf 依赖 iperf 命令行工具和一些 Java 库如果只拿了主 jar 没拿依赖 jar就会报这个错。解决用 Maven 的assembly或shade插件重新打包成 fat jar或者手动把lib目录下所有 jar 加到 classpath。命令是java -cp jperf-1.0.0.jar:lib/* 主类名。如果pom.xml里没有配 shade 插件可以临时加一个或者直接用mvn dependency:copy-dependencies把依赖复制到target/dependency再手动拼 classpath。5.2 图形界面乱码或按钮显示不全现象jperf 窗口打开后中文显示成方块或者按钮文字被截断。原因Java Swing 默认字体在 Linux 上可能没有安装中文字体或者字体配置不对。另外如果系统 DPI 设置和 Java 的 UI 缩放不匹配按钮布局会错位。解决安装中文字体比如sudo apt-get install fonts-wqy-zenhei然后在启动时指定字体# 指定 Java 使用文泉驿字体 java -Dswing.defaultlafcom.sun.java.swing.plaf.gtk.GTKLookAndFeel \ -Dswing.plaf.metal.controlFontWenQuanYiZenHei \ -jar jperf-1.0.0.jar如果按钮还是错位试试调整 Java 的 UI 缩放-Dsun.java2d.uiScale1.0或1.5看哪个合适。5.3 iperf 版本不匹配导致参数报错现象jperf 点 Run 之后命令预览里显示的命令带-P或-l参数但实际执行时报invalid option。原因系统里装的是 iperf 3.x而 jperf 1.0.0 是按 iperf 2.x 的参数设计的。iperf 3 把-P改成了-P但语义有变化-l也不完全一样有些参数直接移除了。解决确认 iperf 版本iperf -v。如果是 3.x要么装一个 iperf 2.x 的二进制放到 PATH 前面要么在 jperf 设置里指定 iperf 可执行文件的路径。常见做法是下载 iperf 2.0.9 的静态编译版本放到/usr/local/bin/iperf2然后在 jperf 里把 iperf 路径改成这个。5.4 测试结果波动大每次跑都不一样现象同样的参数跑三次带宽结果差 20% 以上丢包率也忽高忽低。原因可能是测试时长太短TCP 慢启动还没结束就停了也可能是服务端和客户端之间有其他流量干扰还可能是 jperf 界面刷新导致 CPU 占用高影响了测试进程。解决把测试时长加到 30 秒以上让 TCP 进入稳定状态。测试前用iftop或nload确认链路没有其他大流量。如果还不行直接用命令行 iperf 跑排除 jperf 图形界面的干扰。我一般会跑三次取中间值或者用-i 1看每秒波动如果波动集中在开始几秒那是慢启动正常现象。5.5 防火墙或 SELinux 挡住端口现象jperf 客户端显示连接超时服务端 iperf 没有任何输出。原因目标服务器的防火墙没放行 5001 端口或者 SELinux 限制了 iperf 绑定端口。解决先确认端口通不通nc -zv 目标IP 5001。不通就检查防火墙# 查看防火墙规则firewalld 系 sudo firewall-cmd --list-all # 临时放行 5001 端口 sudo firewall-cmd --add-port5001/tcp # iptables 系 sudo iptables -L -n | grep 5001 sudo iptables -I INPUT -p tcp --dport 5001 -j ACCEPT如果防火墙没问题检查 SELinuxgetenforce如果是 Enforcing临时设成 Permissive 测试sudo setenforce 0。测试完记得改回去或者给 iperf 加 SELinux 策略。6. 把 jperf 塞进自动化测试流程的一个技巧jperf 的图形界面适合手动调参和演示但如果你要把它集成到 CI/CD 或者日常巡检脚本里图形界面反而是累赘。我的做法是用 jperf 确定好参数组合然后把命令预览里的 iperf 命令抠出来写成一个 shell 脚本定时跑并记录结果。这样既保留了 jperf 帮你调参的价值又避开了图形界面在自动化场景下的不稳定。具体操作在 jperf 里配好一组参数点 Run 之前先复制命令预览里的完整命令粘贴到一个脚本文件里。比如你测出来 TCP_RR 模式下 100 并发、10 秒、1KB 块大小最合适脚本就写成#!/bin/bash # jperf_tcp_rr_test.sh # 用法./jperf_tcp_rr_test.sh 目标IP 端口 并发数 时长 TARGET_IP${1:-127.0.0.1} PORT${2:-5001} CONNECTIONS${3:-100} DURATION${4:-10} RESULT_DIR/var/log/jperf mkdir -p $RESULT_DIR TIMESTAMP$(date %Y%m%d_%H%M%S) RESULT_FILE$RESULT_DIR/tcp_rr_${TARGET_IP}_${TIMESTAMP}.txt # 先确认服务端可达 if ! nc -zv $TARGET_IP $PORT 2/dev/null; then echo ERROR: $TARGET_IP:$PORT 不可达 | tee -a $RESULT_FILE exit 1 fi # 执行 iperf 测试输出同时写文件和终端 iperf -c $TARGET_IP -p $PORT -t $DURATION -P $CONNECTIONS -l 1K \ -i 1 21 | tee -a $RESULT_FILE # 提取最后一行汇总的带宽值方便后续监控告警 BANDWIDTH$(grep -E SUM.*sender $RESULT_FILE | tail -1 | awk {print $(NF-2), $(NF-1)}) echo 汇总带宽: $BANDWIDTH | tee -a $RESULT_FILE这个脚本里nc -zv先做连通性检查避免 iperf 卡在连接超时上。-i 1每秒输出一次方便看波动。最后用grep和awk从结果里抠出汇总带宽你可以把这个值推到 Prometheus 或者写到日志里做趋势分析。参数说明$1到$4分别对应目标 IP、端口、并发数、时长都有默认值不传也能跑。跑一段时间后你会积累一批结果文件用awk做个简单统计# 统计最近 10 次测试的平均带宽 grep 汇总带宽 /var/log/jperf/tcp_rr_*.txt | tail -10 | awk {sum$2; count} END {if(count0) print 平均带宽:, sum/count, Mbps}这个习惯帮我省了很多事。有一次机房网络调整后巡检脚本发现 TCP_RR 的汇总带宽从 940Mbps 掉到了 620Mbps我顺着时间点查交换机日志发现是一个端口协商成了百兆全双工改回千兆后恢复正常。如果只靠手动跑 jperf 看界面这种渐进式的性能下降很难及时发现。从那以后我每次拿到新的网络性能测试工具都会先花十分钟把图形界面里的命令抠出来写成带时间戳和汇总提取的脚本再挂到 cron 里跑。jperf 1.0.0 这个包虽然老但源码完整、构建方式清晰把参数调明白之后底层还是 iperf 那套东西稳定可靠。希望帮到你。本文还有配套的精品资源点击获取