说到用iperf3做网络性能测试，很多人可能都尝试过基本的TCP带宽测量，就像原文里展示的那样。但你真的试过UDP测试吗？我最初接触时，觉得这两种测试方式大概就是“测个网速”的区别，后来实际操作了几次才发现，背后的门道还真不少。TCP测试像是在验证一条高速公路的理论最大通车能力，而UDP测试则更像是在这条路上模拟实际的车流，看看在丢包和延迟的现实条件下，你的应用到底能跑多快、多稳。
测试目标：稳定传输 vs. 极限压力
这可能是最核心的区别了。你用iperf3 -c ... -b 100M做TCP测试时，它默认会尝试去“填满”这条100M的管道，但TCP自己有拥塞控制机制（比如大家熟悉的“慢启动”），它会根据网络状况动态调整发送窗口。所以，TCP测试结果反映的是在保证数据可靠、有序到达的前提下，当前网络能承受的“可持续吞吐量”。换句话说，它测的是一种“绅士”的、不把网络搞垮的传输能力。
UDP测试就“野”多了。它本身是无连接的，不管对端收没收到，只管发。在iperf3里，如果你用-u参数启用UDP测试，并同样指定-b 100M，那么客户端就会以恒定的100Mbps速率拼命发送UDP数据包。这个测试的目的，是人为制造网络压力，看在这种饱和攻击下，究竟有多少包能成功抵达（吞吐量），又有多少包被丢弃了（丢包率），以及数据包的延迟（抖动）有多大。这对于测试VoIP、视频流、在线游戏这类对延迟敏感、能容忍少量丢包的应用场景至关重要。
结果解读：一个数字 vs. 一组指标
看测试报告时感受也很不同。TCP测试的结果通常很“干净”，最终你主要关注那个带宽数字，比如“90.2 Mbits/sec”，它代表了端到端的有效传输速率。整个传输过程是受控的，报告里的“Retr”字段（重传次数）如果很高，才说明网络质量可能有问题。
但UDP测试的报告就丰富（或者说复杂）多了。除了带宽，你必须重点关注两个指标：丢包率和抖动。报告里会明确告诉你发送了多少包，接收了多少包，一算就知道丢包率。比如我上次在一个不太稳定的链路上测，得到了“0.5%”的丢包率，对于普通上网可能没事，但对于实时语音通话，用户可能就会听到“咔咔”的杂音了。抖动则是延迟的变化范围，单位通常是毫秒，这个值越小越好，大的抖动会导致视频卡顿或游戏角色“瞬移”。
所以，你可以这么理解：TCP测试告诉你“这条路最多能安全地开多快的车”；而UDP测试则告诉你“如果你非要开这么快，有多少车会出事（丢包），以及车速有多不稳定（抖动）”。两者结合起来，才能对网络质量有一个立体的评估。
实际应用场景：该选哪一个？
那到底什么时候该用哪种呢？根据我的经验，可以这么粗略地划分：
如果你在评估网络的基础带宽，比如家里新装了一条千兆宽带，想看看运营商有没有“缺斤短两”，那么用TCP测试就够了。它简单直接，结果也容易理解。
但如果你是一个网络管理员，或者正在部署一个视频会议系统、一个实时金融交易程序，那么UDP测试就不可或缺。你需要知道在网络最繁忙的时候，你的关键应用会受到多大影响。有时候，TCP测试显示带宽很充足，但UDP一测，发现抖动高达几十毫秒，这对于实时应用来说可能就是灾难性的。
对了，还有个小技巧：iperf3的UDP测试默认数据包大小是1470字节（配合以太网MTU）。你还可以用-l参数调整包大小，来模拟不同应用的流量特征，比如测试小数据包（如DNS查询）或大数据包（如文件块传输）的传输效果，这又是另一个维度的信息了。
总之，别再把iperf3当成一个简单的测速工具了。TCP和UDP这两把“尺子”，量的是网络不同层面的“身材”。下次做测试前，先问问自己：我到底关心的是什么？是这条路的绝对宽度，还是车在上面跑起来的实际平稳度？想清楚了这个问题，你自然就知道该拿起哪把尺子了。