第4章：UDP 带宽测试——丢包率、抖动与带宽上限分析
聊完 TCP，咱们得聊聊 UDP。说实话，UDP 在带宽测试里是个「硬骨头」。TCP 有拥塞控制，会自动降速，测出来的带宽其实是「协议友好」的结果。但 UDP 不一样——它只管发，不管收。你发多少，网络就扛多少，扛不住就丢包。
我个人习惯把 UDP 测试叫做「裸奔测试」。它能直接暴露网络的真实承载能力。今天咱们就把它扒干净，看看丢包率、抖动和带宽上限到底怎么测、怎么分析。
4.1 为什么需要单独测 UDP？
你想想看，视频通话、在线游戏、直播推流，这些场景用的都是 UDP。为什么？因为实时性要求高，不能等重传。丢几个包可以忍，但延迟高了就卡成 PPT。
所以，UDP 带宽测试的核心目标不是「跑满带宽」，而是：
- 找到不丢包的最大发送速率
- 评估抖动（Jitter）是否在可接受范围
- 判断网络瓶颈在哪（是带宽不够，还是设备处理能力不行）
核心观点：UDP 带宽上限 ≠ 链路带宽上限。它受限于发送端速率、中间设备转发能力、接收端处理能力。说白了，链路是 10Gbps，但你的网卡或者交换机可能只能扛住 5Gbps 的 UDP 流量。
4.2 丢包率测试——用 iperf3 打 UDP 流
工具还是 iperf3，但参数不一样。UDP 测试需要指定带宽，不然 iperf3 会默认用 TCP 的逻辑。
4.2.1 服务端启动
iperf3 -s -p 52014.2.2 客户端发送 UDP 流
iperf3 -c 192.168.1.100 -u -b 100M -t 30 -l 1470解释一下参数：
-u：启用 UDP 模式-b 100M：目标发送速率 100 Mbps-t 30：持续 30 秒-l 1470：数据包大小 1470 字节（避免 IP 分片）
输出结果里，你会看到类似这样的信息：
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 350 MBytes 98.0 Mbits/sec 0.123 ms 0/250000 (0%)关键字段：
- Lost/Total Datagrams：丢包数 / 总包数，括号里是丢包率
- Jitter：抖动，单位毫秒
我的经验：我曾经帮一个直播平台排查卡顿问题。他们用 100M 带宽推流，丢包率只有 0.1%，但用户就是卡。后来发现抖动高达 50ms，导致播放器缓冲区频繁溢出。记住：丢包率低不代表体验好，抖动才是隐形杀手。
4.3 抖动测试——为什么它比丢包更隐蔽？
抖动，说白了就是延迟的变化量。网络设备处理数据包时，队列深度、CPU 负载、链路质量都会导致延迟忽高忽低。
测试抖动，我推荐用 iperf3 的 UDP 模式，因为它会记录每个包的到达时间戳。你也可以用 mtr 或者 ping -f 做辅助验证。
4.3.1 抖动测试命令
iperf3 -c 192.168.1.100 -u -b 50M -t 60 -l 1470 --get-server-output加上 --get-server-output，服务端会返回更详细的统计信息，包括每个时间窗口的抖动值。
4.3.2 抖动阈值参考
| 应用场景 | 可接受抖动 | 备注 |
|---|---|---|
| 语音通话 | < 30 ms | 超过 50ms 会出现明显回声或断续 |
| 视频会议 | < 20 ms | 抖动大会导致画面撕裂或卡顿 |
| 在线游戏 | < 10 ms | FPS 游戏对抖动极其敏感 |
| 直播推流 | < 15 ms | 编码器需要稳定的时间戳 |
避坑指南：我曾经遇到过一台交换机，在 80% 负载下抖动正常，但超过 85% 负载后抖动直接飙到 200ms。原因是交换机的输出队列采用了 FIFO 调度，没有做 QoS。所以测试时一定要逐步增加负载，观察抖动拐点。
4.4 UDP 带宽上限分析——三步法
怎么找到 UDP 的带宽上限？我总结了一个三步法，屡试不爽。
4.4.1 第一步：线性增长测试
从 10M 开始，每次增加 10M，持续 30 秒，记录丢包率和抖动。
for rate in 10 20 30 40 50 60 70 80 90 100; do
iperf3 -c 192.168.1.100 -u -b ${rate}M -t 30 -l 1470
done4.4.2 第二步：找到丢包拐点
当丢包率从 0% 突然跳到 0.1% 甚至更高时，那个速率就是「临界带宽」。注意，不是丢包率超过 1% 才算问题。很多生产环境要求丢包率 < 0.01%。
4.4.3 第三步：验证瓶颈位置
如果丢包发生在发送端，说明发送速率超过了链路带宽。如果丢包发生在接收端，说明接收端处理能力不足。怎么判断？看 iperf3 服务端的输出：
- 服务端丢包 > 客户端丢包：接收端是瓶颈
- 客户端丢包 > 服务端丢包：网络中间设备是瓶颈
- 两端丢包率接近：链路带宽是瓶颈
实战案例：有一次我测一个 10Gbps 链路，UDP 跑到 8Gbps 时丢包率 0.5%。客户端和服务端丢包率几乎一样。我判断是链路带宽不够。后来发现中间有一台千兆交换机，被误接成了 1Gbps 端口。嗯，这种低级错误我也犯过。
4.5 知识体系图：UDP 带宽测试核心逻辑
4.6 实战：一次完整的 UDP 带宽测试
假设我们要测试一条 1Gbps 链路的 UDP 性能。我会这么做：
- 基线测试：用 100M 速率跑 60 秒，确认丢包率为 0%，抖动 < 1ms
- 压力测试：从 200M 开始，每次增加 200M，直到 1Gbps
- 记录数据：每个速率跑 30 秒，记录丢包率和抖动
- 分析结果：假设在 800M 时丢包率 0.05%，抖动 5ms；在 1Gbps 时丢包率 2%，抖动 20ms。那么安全带宽就是 800M
我的建议：生产环境中，UDP 带宽使用率建议控制在临界带宽的 80% 以内。比如临界带宽是 800M，那实际业务流量不要超过 640M。留出余量应对突发流量。
4.7 常见问题与排查思路
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 低速率就丢包 | 链路质量差、光模块故障 | 检查光功率、更换光模块 |
| 抖动随负载线性增长 | 设备队列调度问题 | 配置 QoS、启用 WFQ 或 LLQ |
| 接收端丢包远高于发送端 | 接收端 CPU 或网卡瓶颈 | 检查网卡中断亲和性、启用 RSS |
| 两端丢包率相同 | 链路带宽不足 | 升级链路或限速 |
最后提醒一句：UDP 测试时，一定要关闭防火墙的速率限制和连接跟踪。我曾经被 iptables 的 conntrack 模块坑过，UDP 流量一高就丢包，关了就好了。嗯，这种坑踩过一次就记住了。
好了，UDP 带宽测试的核心内容就这些。丢包率、抖动、带宽上限，这三个指标组合起来，就能给出一条链路的完整 UDP 性能画像。下次遇到视频卡顿或者游戏掉线，你知道该从哪里下手了吧？