MakeUseOf 撰稿人 Gavin Phillips 为此做了一组对照测试：先跑 Ookla 测速，同时让 WinMTR 在后台记录，空闲状态跑五分钟，再在测速运行时跑一次，最后补上 Waveform 的缓冲膨胀（bufferbloat）测试。他那条线路的 Ookla 成绩是下行 617.5Mbps、上行 577.7Mbps，足够快，但这远不是全部真相。

第一步：先把测速页上最小的那行字看完

延迟是往返一次所需的时间，页面加载是否“秒开”、通话是否自然、游戏是否跟手，都由它决定，而吞吐量几乎管不着——1Gbps 的线路照样可能延迟高得难受。多数测速工具其实会给出延迟值，只是它被排版成结果页上最小的一行字。这个数字越低越好，超过 100ms 就会明显影响在线服务，尤其是网络游戏。

在上述测试中，Waveform 测得空闲延迟 34ms，WinMTR 显示每一跳约 9 到 11ms，属于不会拖累游戏的水平。

第二步：换一个会报抖动和丢包的测速工具

抖动指的是每次 ping 之间的波动幅度，而不是某一次 ping 的数值。平均延迟漂亮却抖动剧烈，正是视频通话忽然卡顿、对局中莫名掉帧的元凶。测试中 Waveform 记录的抖动只有 4.1ms，看着平平无奇；但最初那次 Ookla 上行延迟 10ms、抖动 11ms，峰值却冲到 298ms——平均值把问题抹平了，体感却是不稳定。

丢包则是干脆没送到、需要重传的数据，直接对应通话冻结和跳帧。麻烦的是，Ookla、谷歌自带测速、Netflix 的 Fast 等主流工具通常都不显示丢包。想看这两项，可以改用 Cloudflare 的测速页（speed.cloudflare.com），它会同时给出抖动、丢包等信息。

第三步：跑一次满载测试，看延迟涨多少

测速工具默认测的是单台设备的独享速度。一台设备在线时它相当准，可到了晚上八点、全家人同时看剧打游戏开语音，画面就完全不同了——这类网络拥塞，普通测速根本不衡量。

缓冲膨胀测试正是用来补这一课的：它在把带宽压满的同时观察延迟涨幅。测试中，负载一上来，Waveform 记录到下行延迟增加 29ms、上行增加 5ms，仍能拿到 A 级；WinMTR 的满载追踪也印证了这一点，每一跳的最差值都随之上升（其中一跳从 60ms 涨到 72ms），但各跳平均值几乎没变。

第四步：用 WinMTR 定位是哪一段出问题

WinMTR 是一款免费开源工具，相当于把 ping 和 traceroute 合成一个界面，能实时看到数据经过的每一跳，从而判断速度是在哪一段被拖慢的。用法是先在空闲状态跑上五分钟做基线，再一边跑测速一边记录，两份数据对照着看。

注意：某一跳 100% 丢包，未必是线路坏了

测试中每一次 WinMTR 追踪都会出现一跳显示 100% 丢包，单看那一行足以让人以为线路已经瘫痪，可测速全程顺利完成。原因在于 ping 和 traceroute 走的是 ICMP 协议，而许多路由器会限速甚至直接忽略发给自己的 ICMP 请求——因为回应这些请求会挤占它转发流量的本职资源——但真正的数据包仍会照常走另一条内部路径转发。只要追踪能跑到最后一跳且末跳有正常数据，中间这种“黑洞跳”就不必紧张。

拿到数据之后怎么办

重点看延迟和抖动两项。如果测速数字很大，但延迟和抖动同样很高，说明问题出在别处：可能是路由器设置需要调整，可能是无线环境下路由器摆放位置不合适，也可能是链路上某一跳出现拥塞，那就不是用户这端能解决的了。

另外一定要多测几次。同一条线路，这一次测出来像是着了火，下一次可能各项指标都平顺得很。测速给出的那个大数字并非毫无意义，只是当连接“感觉很黏”时，还得靠上面这些指标才能找到真正的原因。

来源：MakeUseOf