机场测速怎么看？延迟、单线程与多线程的区别

解释测速结果里每个指标的实际含义：延迟、抖动、丢包、TLS 握手耗时、下载速度，以及为什么多线程测速跑到很高的数字，单个视频或单个下载仍然可能很慢。

先分清两类指标

测速图上的数字可以分成两类，它们回答完全不同的问题：

响应类（延迟、抖动、丢包、握手耗时）——「一次交互要等多久，稳不稳」。网页打开速度、AI 对话的流畅度、游戏体验主要由它决定。

吞吐类（下载速度、上传速度、带宽）——「单位时间能搬多少数据」。大文件下载、高码率视频主要由它决定。

两类指标之间没有必然关系。 延迟很低但速度很慢，或者速度很快但延迟很高，都是常见且合理的组合。把它们混为一谈，是看不懂测速结果的主要原因。

响应类指标

Ping / 延迟（Latency）

数据从你的设备发出到收到回应所需的时间，单位是毫秒。它衡量的是连接的反应速度——请求发出去之后多久有动静。

延迟有物理下限：信号在光纤里的传播速度是有限的，跨洋链路上百毫秒是距离决定的，任何服务商都改变不了。当一条线路宣称跨洋延迟极低时，第一反应应该是怀疑测量方式，而不是相信线路神奇。

抖动（Jitter）

延迟的波动幅度。读文字时通常感觉不到，但在流媒体和游戏里，高抖动会造成缓冲和卡顿。

实际使用中，抖动往往比延迟绝对值更重要。一条稳定在 80ms 的链路，体验通常好过一条在 40ms 和 300ms 之间反复横跳的链路。

丢包（Packet Loss）

数据包没有送达或不完整的比例，用百分比表示。它多数时候是线路或信号质量差的结果。

丢包的影响远大于数字看起来的程度。因为 TCP 会把丢包当作拥塞信号并主动降速，1% 的丢包在长距离链路上就足以让单连接速度垮掉——这一点在下面单线程那一节还会再提到。

TLS RTT / 握手耗时

访问 HTTPS 网站时，除了建立 TCP 连接，还要完成一次加密握手来协商密钥。这个过程需要额外的往返。

按 TLS 1.3 的设计，完整握手需要一个往返即可建立连接，会话恢复的场景下还可以更少；更早的 TLS 1.2 需要更多往返。所以 TLS RTT 通常明显高于 Ping，它更接近「点开一个网站到开始加载内容」的真实感受。

在高延迟链路上这一项尤其值得看：每一次往返都要付出一整个 RTT，延迟的成本在握手阶段是被成倍放大的。

吞吐类指标

下载与上传速度

下载是从服务器拉数据到本地，上传是反过来。单位是 Mbps（兆比特每秒）。

一个必须记住的换算：Mbps 除以 8 才是 MB/s（兆字节每秒）。100 Mbps 的链路，理论上对应约 12.5 MB/s 的下载速度。很多「测速 100M 但下载只有 12M」的困惑就来自这里——那不是丢了 88%，而是单位不同。

带宽与吞吐

带宽是链路的理论容量上限，吞吐是你实际达到的速率。吞吐永远不会超过带宽，而且通常达不到——中间任何一段的限制、拥塞、丢包都会拉低它。

测速给出的是某次测量下的吞吐，不是带宽本身。

节点速率限制

很多套餐对单个节点或整个账号有速率上限。如果测速结果稳定地卡在某个整数附近（比如反复停在 50 Mbps 或 100 Mbps），那更可能是套餐限速而不是线路质量问题。这一项通常写在套餐说明里，值得先确认再折腾。

核心问题：单线程与多线程

这是整篇里最值得花时间的部分，也是最多人误解的地方。

两种测试在做什么

多线程测速同时建立多条并行连接一起传输数据，把它们的速率加总。这样做的目的很直接：尽可能逼近链路的总吞吐上限。主流测速工具的设计目标就是测出连接的最大潜力，所以默认采用这种方式。

单线程测速只用一条连接传输，测的是一条连接能跑多快。

同一条链路上，两个数字可能差好几倍。这不是任何一方在造假，而是它们本来就在测不同的东西。

为什么单条连接跑不满带宽

一条 TCP 连接的速度不是由带宽单独决定的，而是受几个因素共同限制：

往返延迟（RTT）。 TCP 一次只能发送「窗口」大小的数据，然后必须等待确认才能继续。所以单连接的速度大致等于窗口大小除以往返时间。窗口固定时，RTT 翻倍，单连接速度就减半。这也是为什么跨洋链路上单连接速度普遍不高——不是带宽不够，是距离太远。

丢包与拥塞控制。 TCP 把丢包解读为拥塞信号，检测到丢包就会主动降低发送速率，然后再慢慢爬回来。在长距离链路上，即使很低的丢包率也会让单连接反复降速，始终无法稳定在高速率。链路越长，恢复越慢，影响越明显。

中间环节的处理能力。 节点的 CPU、加密开销、并发连接数都会成为单条连接的天花板。节点负载高的时候，单连接往往最先受影响。

目标服务器。 对端也有自己的带宽、限速和负载。你的链路再好，对方限速 5 MB/s 就是 5 MB/s。

多条连接为什么能绕过去

关键在于上述限制是按连接生效的。

每条连接各自有自己的窗口、各自独立地响应丢包。一条连接因为丢包降速时，其他连接不受影响，仍在传输。把 8 条连接的速率加起来，总和自然比单条高得多，也更接近链路的真实容量。

这也解释了为什么多线程和单线程的差距在长距离、有丢包的链路上被放大：单连接受损越严重，并行带来的收益就越明显。

所以那个经典问题

测速跑到 1000 Mbps，为什么看 YouTube 还是卡？

至少有三个原因同时起作用：

1. 1000 Mbps 是多条连接加总的结果，视频播放依赖的是少数几条连接的稳定速率，对应的是单线程能力。
2. 测速服务器和视频服务器不是一台机器。 测速工具通常会自动挑选一台延迟低的近距离服务器来测出链路的最大潜力，而视频平台的内容可能托管在完全不同的位置。Ookla 自己在文档里就指出，很多站点和流媒体服务把内容放在离你较远的服务器上，从这些服务获得的速度和延迟会更差。
3. 测速是几十秒的短时冲刺，播放是持续几十分钟的长跑。 短时间内的峰值不代表长时间的稳定速率，晚高峰尤其如此。

不要走到另一个极端

「多线程测速没有意义」「Speedtest 都是假的」同样是错的。

多线程结果能回答几个单线程回答不了的问题：套餐是否在限速、链路总容量够不够、多任务并发时会不会互相挤占。评估一条链路的整体能力，它是必要的一项。

结论是两个都要看：多线程告诉你上限在哪，单线程告诉你单个应用能得到多少。只看一个都会得出片面的结论。

测速结果里还有谁的份

一次测速的数字，是整条链路上每一段共同作用的结果：

你的设备 → 本地网络 → 代理客户端 → 节点 → 出口线路 → 测速服务器

任何一段都可能是瓶颈：

• 测速服务器。 不同服务器的位置和负载不同，换一台结果就会变。厂商自己也建议测多台服务器来获得更完整的判断。
• 本地 ISP。 你的宽带上限和出口路径是整条链路的地基。
• Wi-Fi 还是网线。 无线的带宽、干扰与设备无线能力差异很大，同一个网络下手机和电脑测出不同结果非常常见。
• 设备本身。 CPU 与网卡能力有上限。加密和代理处理都要消耗 CPU，低性能设备在高速链路上会先撞到自己的天花板。
• 浏览器与客户端。 不同浏览器在高速连接下的表现有差异；代理客户端的实现和配置同样影响结果。
• 节点负载。 同一节点在不同时段的可用容量不同。

所以把所有问题都归因于机场是不成立的。定位瓶颈的方法只有一个：一次只改一个变量。

时段：凌晨的数字不算数

线路在不同时段的表现可能差异很大。晚高峰用户集中，拥塞概率和节点负载同时上升。

一个只在凌晨测过的节点，你并不知道它晚上八点是什么样。至少测两次：

1. 你真实使用的时段（多数人是晚上）。
2. 一个空闲时段作为对照。

两次差距很大，说明这个节点对拥塞敏感，适合当备选而不是主力。两次都稳定，才是可以依赖的结果。

怎么测才有意义

1. 先测基线。 不走代理时的延迟和速度，作为参照系。
2. 固定条件。 同一台设备、同样的连接方式、同一个测速服务器、同一个时段。条件变了就没有可比性。
3. 测三次取中位数。 单次结果偶然性太大。
4. 补一次单线程。 下载一个大文件，看实际速度曲线稳不稳，而不是只看峰值。
5. 用真实场景复核。 打开你真正要用的服务。数字和体验不一致时，以体验为准——测速只是诊断工具，不是目的。
6. 记录下来。 时间、节点、服务器、结果。没有记录就没有对照，下次还是只能凭感觉。

选到合适的节点之后怎么按用途分组，见 机场节点怎么选。

测速是快照，不是承诺

必须说清楚这一点：任何一次测速结果，都只代表

• 某个时间点，
• 某条链路（你的设备、你的运营商、这个节点、这条出口），
• 对某个测速服务器

的情况。它不是长期性能保证，也不构成任何形式的服务等级承诺。线路会变、负载会变、平台策略会变，一个月前的数据不能默认继续成立。

看到任何测速截图——包括本站的记录——都应该先问两个问题：什么时候测的？怎么测的？ 没有这两项信息的结果，参考价值有限。

和本站测试记录的关系

本站在 网络服务目录 里保留了部分服务的测试记录。需要说明分工：

• 测试方法说明 回答的是「本站怎么测」：关注 AI 服务可用性、节点地区与线路标注、连接稳定性、套餐与限制，每条记录标注实际测试日期与新鲜度，并且明确列出了测试不能保证什么。
• 这篇文章回答的是「你自己怎么测、怎么看懂结果」。

两者不重复。本站的记录是候选线索，你自己的测试才是决定依据——因为运营商、时段、设备都不一样，结论本来就可能不同。

参考资料

• Speedtest 常见问题：哪些因素会影响测速结果（Ookla）
• 网络速度术语表：延迟、丢包、抖动、Mbps（Ookla）
• RFC 8446：TLS 1.3 握手往返设计
• RFC 5681：TCP 拥塞控制
• RFC 7323：高性能 TCP 与窗口扩展