以前的记录留下了几条 iperf3 命令：传一定大小的数据、连接 Windows 测试端口，以及用很多小 UDP 包压测网络。命令还在，但没有保存对应的测速输出，因此不能据此判断当时那条线路能跑到多少。
这里保留这些用法，并补上测试顺序。先建立一条容易解释的 TCP 基线，再改变方向、并发数或 UDP 速率；一次改一个条件，结果才方便比较。
先确定测的是哪条路径
需要两台相互可达、都装有 iperf3 的主机。本文用 HOST 代替服务端地址，运行前替换为实际地址。两端先记录版本：
iperf3 --versionUbuntu 上可以通过发行版软件包安装：
sudo apt update
sudo apt install iperf3测试记录至少写明两端系统、iperf3 版本、网卡连接速率，以及中间是否经过 Wi-Fi、VPN、代理或虚拟机。测试局域网时优先直接连接对方的内网地址，否则可能把公网绕行也测进去。
Windows 构建的来源和功能需要单独确认。iperf3 官方 FAQ说明 Windows 不在其官方支持平台之列，也说明 iperf2 与 iperf3 不能互通；不能只看程序名字相近就混用两端。
用 TCP 建立基线
在服务端终端运行：
iperf3 -s保持这个终端运行，再从客户端执行：
iperf3 -c HOST -t 30
iperf3 -c HOST -t 30 -R第一条由客户端发送，第二条反过来由服务端发送。根据 iperf3 参数手册，默认服务端端口为 TCP 5201，-R 改变数据方向，-t 指定测试秒数。服务端防火墙需要允许测试客户端访问这个端口；测完按 Ctrl+C 结束前台服务。
观察末尾的 sender 与 receiver 汇总，比较两个方向的速率。不要只截取中间一秒的峰值。如果相同条件下几次结果差异明显，先检查其他流量、Wi-Fi 信号和两端负载，再讨论线路上限。
原来按总量测试的写法可以继续用：
iperf3 -c HOST -n 100M这里的 -n 100M 是发送总字节量，传完即结束，不是限速为 100 Mbps。在快链路上它可能很快结束，观察稳态吞吐时用固定时长更方便。
Windows 上指定端口
旧记录使用 8090 端口。服务端也必须指定同一个端口：
iperf3 -s -p 8090Windows 客户端在程序所在目录执行：
.\iperf3.exe -c HOST -n 10000M -p 8090这个测试会传输较大的数据量。只想确认服务是否可连接，可以先把测试改成 -t 5。连接失败时，检查服务端是否还在运行、监听端口和防火墙规则是否一致；某个网页能打开，并不能证明 iperf3 端口可达。
UDP 先限速，再逐步增加
从较低速率开始，例如：
iperf3 -c HOST -u -b 10M -t 30
iperf3 -c HOST -u -b 50M -t 30UDP 结果需要同时记录接收速率、抖动和丢包比例。-b 是目标发送速率，不能把发送端要求的速率当作接收端已经获得的吞吐。UDP 测试仍需要 TCP 控制连接，同时需要允许对应的 UDP 测试流量，这一点在 iperf3 的连接过程说明中有明确区分。
我的旧记录还包含下面两条小包、高并发命令。它们适合留作压力测试的参数记录，不适合作为第一次测速的默认值：
iperf3 -c HOST -u -b 0 -l 128 -P 32 -t 60 --pacing-timer 0
iperf3 -c HOST -u -b 0 -l 64 -P 64 -t 30 -O 5 -w 2M --pacing-timer 0这里 -b 0 取消发送速率限制，-P 增加并行流，-l 控制缓冲区长度，-O 5 排除前五秒统计，-w 请求 socket 缓冲区大小。--pacing-timer 的单位是微秒，旧记录把它设为零；它的支持与接受范围应先用本机帮助和版本确认，不能假设换一个构建仍可照搬。
这些条件会同时改变包速率、CPU 压力和排队情况。旧记录没有保留运行结果，所以这里只保留命令含义，不给它附加“性能更高”的结论。做普通网络测速时回到单流、限速的例子即可。
怎样留下可比较的结果
可以保存 JSON，之后按相同条件比较：
iperf3 -c HOST -t 30 -J > iperf3-tcp-forward.json
iperf3 -c HOST -t 30 -R -J > iperf3-tcp-reverse.json连同版本、时间、路径和测试命令一起保留。iperf3 测的是两端应用经过这条路径传输数据的表现；网卡标称速率、文件复制速度和这次测试结果不是同一个指标。如果吞吐偏低，下一步应分别检查链路协商、丢包和两端资源占用，而不是立即叠加更多“优化参数”。