三要素是什么
网络质量再花哨，量化下来只有三件事：能塞多少（带宽）、要跑多久（时延）、掉了多少（丢包）。三者的关系不是并列的：丢包会触发重传，重传直接把有效吞吐压下来；时延决定单个连接在确认窗口内最多能发出多少数据；带宽不足又会制造排队时延，让时延随负载漂移。所以三要素的判读最终要落到同一个指标上——业务实际拿到的有效吞吐，而不是链路标称值或某一个漂亮的平均值。
基本信息
| 三要素 | 带宽（有效吞吐）、时延（往返时延与抖动）、丢包（比例与方向） |
|---|---|
| 常见误区 | 把链路标称带宽当成实际能跑到的速度，忽略协议开销与窗口限制 |
| 常用工具 | ping 测时延与丢包、mtr 逐跳定位、curl 分段计时看应用层、iperf3 测吞吐与 UDP 质量 |
| 采样要求 | 时延与丢包至少百次采样，吞吐测试建议持续十秒以上 |
| 判读顺序 | 先确认有没有丢包与抖动，再看时延由哪一段构成，最后用吞吐收口 |
典型使用场景
- 验收与选型：新开通的专线或云网络，需要用一组数字证明它达到承诺水平
- 故障定级：业务方只报「网络慢」，量化后才能判断要不要升级处理
- 带宽扩容决策：区分瓶颈是带宽不足还是时延窗口限制，避免白买带宽
- 跨地域服务评估：判断异地访问慢是物理距离造成的传播时延，还是中间环节拥塞
- 整改效果验证：调优或换线路后用同一组测试重跑，用数字说明改善幅度
三要素一条龙
三要素一条龙
ping -c 100 -i 0.2 <目标> | tail -3 # 时延与丢包：至少百次采样再下结论
mtr -r -c 100 -n <目标> # 逐跳丢包与时延，看从哪一跳开始变差
mtr -T -P 443 -r -c 100 -n <目标> # 改 TCP 443 探测，绕开被限制的 ICMP
iperf3 -c <目标> -t 20 -P 4 # TCP 有效吞吐：多流更接近链路能力
iperf3 -c <目标> -u -b 200M -t 20 # UDP 质量：丢包率与抖动
curl -o /dev/null -s -w '%{time_total} %{speed_download}\n' <URL> # 应用层实测
ping -M do -s 1472 -c 5 <目标> # 确认路径 MTU，排除分片造成的隐性丢包要素与工具判读
| 要素 | 常用工具 | 要看什么 | 异常特征 |
|---|---|---|---|
| 带宽 | iperf3 多流、curl 下载计时 | 有效吞吐与链路标称的差距 | 链路千兆而单流只有几十兆，多为时延×窗口限制 |
| 时延 | ping 的 RTT、mtr 的 Avg 与 StDev | 除平均值外还要看最大值与抖动 | 平均值正常但峰值高，实时业务会明显卡顿 |
| 丢包 | mtr 大轮数、iperf3 UDP | 丢包率、丢包方向、是否与业务量相关 | 偶发丢包即触发重传，吞吐出现断崖式下跌 |
| 抖动 | mtr 的 StDev、iperf3 UDP 抖动列 | 时延波动范围是否超过业务容忍度 | 抖动偏大时语音与游戏体验先崩，网页却看不出问题 |
单流跑不满链路未必是故障：跨地域链路的带宽时延积限制了单连接的窗口上限，需要并发多流才能逼近链路能力，这正是吞吐测试要用多流的原因。判读时先把「标称带宽」「单流吞吐」「多流吞吐」三个数分开写。
只在服务器侧测一次就下结论风险很高：回程路径可能与去程完全不同，不同时段的拥塞程度也差异明显。至少做到双向、跨时段各采样一次，再对结论负责。