下载很快，可为什么每次点击都显得慢？

快速下载一个大文件，随后却觉得每次点击都慢，这并不矛盾。容量说的是每秒能搬运多少数据；往返时间说的是在出现任何有用结果之前，一次往返要等多久。改善前者对后者毫无帮助，而人打字、点击或通话时注意到的恰恰是后者。要测的是抱怨，不是连接。

文件快，点击慢：两个不同的数字

批量传输让数据持续在途，所以即使每个单独请求都在等待，它也能报出一个漂亮的速率。许多基准测试还会同时打开多条连接，这会在单条请求依旧很慢时抬高合计数字。两个结果并不冲突，而把这个更高的数字拿给抱怨卡顿的用户看，正是失去信任的方式。

页面加载是一连串小交换：域名解析、建立连接、一次请求、一次响应，然后是依赖请求。每一步都要再付一次往返时间，所以延迟高的路径即使容量充足也会显得慢。

隧道会加上自己的行程和处理，而路线比地图上的标签更重要。同一个国家的两个出口，通往同一目的地的路径可能差别很大。二十毫秒的差异就足以改变页面的手感，尽管它几乎不动吞吐量数字。所以出口选择应当依据延迟采样，而不是旗帜图标。

测抱怨，别测连接

选择与用户说的那句话相匹配的测量。下载慢需要正确方向上的持续速率；通话卡顿需要该应用自身的统计；页面启动慢需要解析和建立连接的时间。

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

第一条命令给出到响应可预期的主机的往返采样，第二条报告首字节时间和单条连接的持续速率，第三条用四条并行流测合计吞吐。在同一天的同一时间、对同一目的地运行它们，因为拿早上的采样和晚上的采样相比，得到的只是故事，不是测量。

比较出口时要固定目的地。同时更换服务器和隧道会把一个变量变成两个，结果无法告诉你哪个才关键。每个出口至少运行三次，因为单次采样常常落在路由变化或噪声很大的一分钟里。中位数比最好情况更有用。

把 ICMP 当作线索，而不是答案。响应回声请求的主机可能走与应用不同的路径，丢一次回复并不能证明所有应用都在丢包。

负载下的延迟是排队问题

最让人困惑的情形，是空闲时感觉良好、备份时却无法使用的连接。那是排队，不是容量。饱和的上行链路会在每个其他数据包前面堆起缓冲，于是一次按键就排在某个上传分片的后面。

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

第一条命令在后台采样延迟，第二条把反方向打满。如果传输期间 ping 时间跳升、之后又恢复，你复现的是缓冲膨胀，而不是发现了路由故障。修复通常是队列管理设置、更低的后台速率，或把大文件传输移出交互路径。

减少可选的后台流量，往往比更换出口国家更有帮助。它还更便宜、可逆，并且一分钟内就能验证。如果队列无法管理，就把大上传安排在非工作时间；如果必须在白天运行，就限制它们的速率。路由器支持时，队列管理设置是更好的修复。

只改一件事，拿同类和同类比

空闲延迟高时，固定目的地比较各个出口，再为最佳候选比较路线。稳定吞吐低时，则要看容量、服务器负载和客户端处理，因为那是不同的限制。

记下你测了什么、对哪个目的地、在什么时间、用什么设置。没有这四个事实，比较就无法复现，下一个人只能从零开始。

然后让工具对得上工单里的说法。“网速慢”不是测量；“到这个主机首字节用了 900 ms，而吞吐正常”才是测量，它直接指向延迟而不是容量。