UDP 探测为什么容易误读
UDP 没有重传机制，丢一个样本就是一次超时，所以它对探测频率与超时阈值特别敏感。一次超时说明不了任何问题，连续多次超时才是可疑的持续丢包。另外不少网络对 UDP 与 ICMP 有独立的限速策略，控制面的限速很容易被误读成数据面的丢包，这是这类探测最常见的坑。
基本信息
| 判读原则 | 单次超时不算故障，连续多次超时才值得怀疑 |
|---|---|
| 采样要求 | 多轮短间隔采样，看分布而不是看单次 |
| 干扰因素 | 网络对 UDP 与 ICMP 的单独限速 |
| 适用边界 | 业务本身走 TCP 时，应以 TCP 探测为准 |
典型使用场景
- 评估 UDP 业务（DNS、音视频、游戏）的链路质量
- 排除控制面限速带来的误报
- 对比探测包大小与实际业务报文的差异
- 为持续丢包设定合理的判定阈值
- 区分「偶发抖动」与「持续恶化」两类问题
采样与判定口径
采样与判定口径
# 判定口径：单次超时不等于链路坏，连续 M 次超时才可疑
# 采样要记录轮次、间隔与包大小，便于复现
ping -c 20 -i 0.2 -s 1200 203.0.113.10
# 结论只对当前包大小与发送频率成立，改变参数后必须重测
# 业务走 TCP 时改用 TCP 握手探针，结论更贴近真实体验现象判读
| 现象 | 可能解释 | 下一步 |
|---|---|---|
| 偶发单次超时 | 瞬时抖动或被限速 | 增大样本量再判断 |
| 连续超时且业务受影响 | 路径确实丢包 | 两端抓包定位丢包点 |
| 探测丢包但 TCP 正常 | UDP 被单独限速 | 改用 TCP 探测为准 |
| 小包正常大包超时 | MTU 或分片问题 | 检查路径 MTU 与分片 |
部分网络对 UDP 与 ICMP 有单独的限速策略。业务本身就是 TCP 时，用 TCP 握手做探针更贴近真实体验；直接拿 UDP 探测结果解释 TCP 业务体验，结论往往偏悲观。
探测包大小与业务报文不一致时，结论只对探测包成立。小包测出「链路很好」，不代表业务的大报文走的路径同样健康，尤其是隧道与 VPN 环境。
排查顺序
- 先确认业务实际使用的协议，决定用哪种探针才合适
- 统计多轮采样结果，算出丢包比例而不是记录单次超时
- 对照包大小做多组测试，确认结论是否与报文尺寸相关
- 怀疑限速时同时观察 ICMP 与 TCP 表现，交叉验证
- 把采样参数与结论一起记录，便于他人复核与复现