为什么三个测速站会给出三个不同的数字

三个答案，都说得通

在一分钟之内跑三个不同站点的测速，你可能看到 300 Mbps、180 Mbps 和 90 Mbps。直觉会告诉你其中两个是坏的。实际上它们各自回答的是略微不同的问题，而它们之间的差距，比任何一个单独的数字都更有信息量。

一个在量：当线路被刻意打满时，它能承载多少容量。一个在量：一次真实的下载能跑多快。还有一个可能在量：一条从未离开你运营商自己网络的路径。这是三个各自成立的量，各有各的用途。

并发连接数改变了天花板

单条 TCP 连接需要时间才能爬升到线路的满速。同时开八条或十六条，每条各自并行爬升，聚合值就能快得多地摸到天花板——在很短的测试时长内，这个差异非常大。所以多线程测试通常会给出更高的数字，而当问题是“我买到的容量给足了吗”时，它才是合适的工具。

单线程测试给出的数字更低，而当问题是“这一次下载到底能跑多快”时，它才是合适的工具。视频流、游戏下载、从 CDN 取文件、视频通话，实际使用中都只有一个流。两种方法之间的差距不是测量误差，而是“容量值”与“交付值”的差别。

延迟会放大这个效应：往返时间越高，单条连接爬升所需的时间越长。所以高延迟链路——卫星、部分固定无线、长距离国际路径——在单线程与多线程结果之间的差距最大。

服务器放在哪，决定了你量的是哪条路

不同工具使用不同的服务器网络。有的挑最近的可用节点，有的用某个特定服务的内容分发网络，还有的用托管在运营商自己网络里的服务器。每一种选择量的都是不同的路径。

对着运营商网内的服务器测，数据根本不经过互联点，所以它完全有理由给出你所能看到的最好数字——但它对流量如何到达该网络之外的服务不置一词。对着某家内容提供商的 CDN 测，告诉你的是这家提供商的表现，不是整个互联网的表现。拿两个使用不同端点的工具做比较，你比较的路径和连接一样多。

最大的误差通常来自本地环境

方法论的差异容易吸引注意力，但在日常测试中，最大的误差来自使用环境：

• 用 Wi-Fi 而不是网线。 无线会引入延迟、抖动和不确定性，而且随距离、墙体以及共享该频段的设备数量增长。在高速率套餐上，同一房间里的有线测试和无线测试可能相差很大一截。
• 后台流量。 云同步、系统更新、游戏补丁，或者别人正在看的 4K 视频，都会在测试窗口内吃掉容量。
• 浏览器插件和 VPN。 两者都处在数据路径上，可能给测试流量限速或改道。
• 时段。 在共享介质的连接上，上午 10 点和晚上 9 点做的是同一条线上的两次不同网络。

带着上下文去读一个数字

一次测速量的是：某一瞬间、用一种传输方式、到某一台服务器、走的一条路径。它不能证明每个网站都会加载得很快，不能证明游戏服务器会跟手，不能证明家庭网络配置得当，也不能证明容量在晚高峰依然守得住。把结果当成一张诊断快照，把方法当成结果的一部分——脱离条件的数字不是测量。

还有一点值得分开看：吞吐量和响应性是两回事。一条容量极高的线路，如果到最近 CDN 的延迟是 200 ms，在交互类工作上的体验会不如一条只有 10 ms 的普通线路。如果抱怨是“感觉慢”，屏幕上那个 Mbps 数字往往是最没用的一个。

一套可重复的测法

把条件标准化，比挑哪个工具更重要。

1. 尽量用网线。如果只能用 Wi-Fi，就待在接入点同一个房间，并使用 5 GHz 或 6 GHz 频段。
2. 关掉一切会搬运数据的东西——备份、同步客户端、更新、流媒体——包括测试设备上的，也包括共享这条连接的其它设备上的。
3. 用干净的浏览器配置文件测，不装插件，不开 VPN。
4. 跑三次取中间值，而不是取最好的那次。
5. 记下时段，并在你通常使用网络的最繁忙时段再测一次。两者之差，才是能预测你真实体验的那个数字。
6. 如果两个服务结论不一致，就让它们对着同一台就近的服务器各测一次，再判断是不是线路的问题。

上午晚些时候做一次，晚上做一次，你对这条连接的了解就会超过任何单个头条数字。