你的 speed-test 在撒谎,请改测 responsiveness

大数字的谎言

每一个 speed-test 网站都以一个仪表盘开场。指针转起来,定格在一个亮眼的数字上(下行 480、510,光纤的话甚至 940),这个数字就成了故事。这故事几乎总是错的。不是不诚实,只是答错了问题,而且答得很精确。

吞吐是一种容量测量:管道在没有别的事情发生时能搬多少水。问题在于,真实的网络几乎从不是「没别的事情发生」。真实的网络是家庭视频通话、云备份、Slack 同步、软件更新和小孩看动画片同时进行。在那个场景里,你关心的并不是每分钟一共多少加仑,你关心的是你的语音包能不能插队、能不能准时到达。

第二个问题就是 responsiveness,而过去二十年我们几乎没办法在浏览器里测量它。现在有了。它就在 macOS 里。只是从没人告诉你。

一段话讲清 bufferbloat

笔记本与互联网之间的每一台路由器和调制解调器都有一个缓冲区:一小块用来让数据包排队等候的内存。当缓冲区前面的链路比缓冲区后面的链路慢(比如你的 40 Mbps 上行接在千兆 LAN 之后),缓冲区就开始装满。厂商把这些缓冲区做得离谱地大,因为丢包看起来像 bug。但是太大的缓冲区会把你 Zoom 的语音包压在所有早一毫秒到达的包后面。管道里搬动了大量字节。只是真正重要的字节在排队。这种延迟(在负载下以几百毫秒计)就是 bufferbloat。这就是 speed-test 通过、通话却散架的原因。

认识 RPM:Round-trips Per Minute

2021 年,Apple 的网络团队提出了一个直白的指标:RPM,即每分钟的往返次数。想法简单到几乎让人不好意思。在管道被压满时(你正在全速下载和上传),数一数一分钟内你能完成多少次完整的「请求/响应」往返。一张响应良好的网络能跑到几千。一张臃肿的网络只能掉到几百。两边都是同一根 500-Mbps 的管道。

Apple 在 macOS Monterey 中发布了对应工具,叫 networkQuality,位于 /usr/bin/networkQuality。打开 Terminal 运行它,你会看到类似这样的输出:

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

仔细读这个输出。管道很粗,接近半个千兆下行。响应性是 medium。每分钟 540 次往返,大约每秒九次:在满载网络上你的语音包等待大约 111 毫秒,空闲时只等 18 毫秒。这个差距就是为什么家里没人时通话清清楚楚,而全家人都在追剧时一切都散架。

High、Medium、Low 各自意味着什么?

Apple 把 RPM 分成三档可读的类别:

High,2,000 RPM 及以上。网络响应良好。无论后台还有什么在跑,实时工作(通话、游戏、协作编辑)都会感觉干脆利落。
Medium,大约 600–2,000 RPM。网络仍可用,但负载下交互式应用会发卡。多数家庭网络在黄金时间就停在这里,投诉也大多来自这里。
Low,低于 600 RPM。缓冲区已满。语音通话会掉线,视频会冻住,SSH 会话里的按键会成批到达。除非缓冲区清空,加再多带宽都救不了。

为什么 speed-test 看不到这件事

speed-test 只测问题的简单一半:idle throughput(空闲吞吐),通常是一段短促的爆发,通常走在你 ISP 学会优先对待的那条连接上。它告诉你管道在轻载时能干什么,而从不接着问负载下的延迟。Bufferbloat 在定义上对这个测试就是不可见的:测试本身就是负载,后面没有别的流量在排队。

用户那一头的症状很熟悉。ISP 的技术员上门,跑一次 speed-test,通过了,就告诉你连接没问题。下一次视频通话依然卡。技术员没撒谎。他只是测错了东西。

RPM 测试在实战中的样子

Apple 的 networkQuality 优雅而粗暴。它对 CDN 端点开多条并行连接,在两个方向同时把它们灌满,然后在这种饱和之中测一对小小的 HTTP/2 请求和响应能多快完成。这就是 RPM 值。容量测量顺手就出来,所以工具一次运行同时给出三个数字。

测试约十五秒。它会狠狠拍打你的链路,所以不要在通话时跑。它也会暴露你的 ISP 不太想让你看到的事:与邻居互相干扰的 Wi-Fi 信道、固件 bug 把队列深度翻倍的路由器、给每次往返加 200 毫秒延迟的 VPN。你会非常频繁地发现:薄弱环节不在你的 ISP,而在你自己家里。

当 RPM 是 Low 时该怎么办

没有银弹,但清单是有限的:

先用有线测一下。给 Mac 接上以太网,再跑一次 networkQuality。如果 RPM 跳到 High,问题在 Wi-Fi:拥挤、信道冲突或距离,而不在 ISP。
开启 Smart Queue Management。支持 SQM、CAKE 或 fq_codel 的路由器能戏剧性地把 bufferbloat 压平。一台开了 fq_codel 的 $100 路由器会赢过没开的 $600 路由器。
限制上行。如果用不了 SQM,把 Mac 的上行限制在测得的上行容量的 90% 左右。仅此一项就能避免你自己的上传把缓冲区填满,从而让你的下载因为 ACK 回不来而饿死。
替换 ISP 的二合一调制路由。许多 ISP 配发的设备是为吞吐基准而调的,不是为响应性。把 ISP 的盒子改成桥接模式,在前面接你自己的路由器,通常是大多数人能看到的最大单步 RPM 提升。

三个顽固的迷思

「加更多带宽就能搞定」。 偶尔可以,大多数时候不行。如果你的上行已经被一个备份任务塞满,从 40 升到 100 Mbps 上行确实有用。但如果真凶是缓冲区,你只是会用两倍速度撞上同一个天花板,症状会回来。解决办法是清空队列,而不是把队列前面的管道做得更粗。

「我的 ping 是 12 毫秒,所以我没问题」。 Ping 测的是空闲延迟:没有别的事时一个包走多久。Bufferbloat 只在负载下才显形。一条 bloated 链路上 12 毫秒的空闲 ping,在负载下经常变成 350 毫秒。打开两个终端:一个跑 ping,一个跑大上传,你会实时看到这件事发生。

「ISP 已经为这一点做了优化」。 有的有,很多没有。工程上不难,但商业激励指向了相反的方向:为 speed-test 而调的网络在按吞吐数字买单的市场里赢。Responsiveness 几乎不出现在营销页上。

WiFi & IP Info 在哪儿合上拍

我们把 networkQuality 引擎放到了菜单栏一键之内。Pro 的 Network Quality 面板跑同一套 Apple 测试,把上行/下行容量呈现出来,报出 RPM 档位与基线 RTT,并且关键的是,保留历史。你可以一星期里每小时点一次「再跑一次」,看清规律:周末早上 High,晚饭时 Medium,孩子们放学回家时 Low。这张图才是让 ISP 真正去做点什么的图,因为 可重现性 才是把抱怨变成工单的东西。

把它和应用的 Latency History 图与 Connection Log 配在一起,你就能给运营商发一条 30 秒就能写完的工单:「RPM 在本地 18:00 至 21:00 之间从 2,400 掉到 410,与到你们自己网关的中位 RTT 升高三倍相关。CSV 已附。」这跟「我家网络慢」是完全不同的对话。

一句话版本

你的 speed-test 测的是容量。容量是真实的,偶尔它就是问题所在。但更多时候,问题在 responsiveness:在管道忙的时候,你的流量能不能及时进来又出去。RPM 是测这个的指标。Apple 做了一流的工具来测它。我们把这个工具放进了你的菜单栏,并且替你保留历史。

如果你只想从这一页带走一句话,那就是这一句:带宽是路有多宽;responsiveness 是你在红绿灯前等多久。 两者都重要。但 speed-test 页面上只有其中一个。