延迟和丢包测试

工作原理

1. 关闭其他下载和流媒体. 测试期间如果其他设备或应用占用带宽，会因为与你连接的真实表现毫无关系的原因，虚增负载下延迟的数值。
2. 优先使用以太网，或坐得离路由器近一些. Wi-Fi 会在你的网络线路本身之上叠加自己的延迟和抖动 —— 有线连接能把测量结果隔离到线路本身。
3. 点击开始并让标签页保持在前台. 浏览器会让后台标签页变慢，这会悄悄破坏这个测试所依赖的计时。
4. 先看空闲延迟，再看负载下的延迟. 第一阶段测量静止状态下的连接；第二阶段会在发送同样延迟探测的同时启动一次下载，看看繁忙时连接会慢多少。
5. 查看稳定性计数，而不是丢包百分比. 并没有丢包百分比 —— 原因见下文 —— 但没有收到响应的探测次数，以及返回异常缓慢的探测次数，几乎能告诉你同样的信息。
6. 在高峰时段再测一次. 延迟和缓冲膨胀比原始速度对时段更敏感 —— 晚上的结果可能和下午的结果有明显差异。

这个测试到底测量什么（以及为什么这里的"延迟"称呼略有不准确）

`ping` 命令发送一个原始 ICMP 数据包并计时等待回应。网页做不到这一点——浏览器无法访问 ICMP，也无法访问任何形式的原始套接字，原因和网页不能未经许可读取你的文件一样，都是沙盒限制。所以这个测试采用了最接近诚实的做法：为发往 Cloudflare 网络的一次普通 HTTPS 请求计时，再减去服务器自己上报的处理时间，只留下网络往返本身的时间。

• 这是真实测量得到的往返时间 —— 不是模拟也不是估算，只是用 HTTPS 代替了 ICMP。
• 通常会比终端里对同一目标发出的 ping 高出几毫秒，因为即使减去服务器处理时间，一次 TLS 加密的 HTTP 交换仍然比一次简单的 ICMP 回显消耗更多。
• 测量的是到 Cloudflare 边缘节点的路径，而不是到某个特定游戏服务器、通话服务商或网站的路径 —— 把它当作"我的连接整体上有多好"的参考，而不是到某个具体目标的精确数字。

为什么这个页面没有丢包百分比

这一点值得明确说明，而不是简单地省略这个数字——因为它的缺席是刻意的选择，而不是功能缺失。

• 每个普通网页请求底层的 TCP 协议会自动、无声地重传丢失的数据。一个丢失的数据包不会失败——它只是在重试一次后延迟到达。
• 这意味着为 HTTP 请求计时的网页，从原理上就无法把丢失的数据包识别为"丢包"——它看到的只是一次缓慢的响应，乍一看和普通拥塞没有区别。
• 一个从这类数据计算出"0% 丢包"的工具，报告的并不是低丢包率——它报告的是完全没能检测到丢包，这对正在排查连接不稳定问题的人来说是完全不同的信息。
• 真正的丢包测量需要一个不会隐藏丢包的协议——原始 ICMP 或 UDP——而这恰恰是浏览器不被允许发送的。

这个测试展示的替代信息是：在一个宽松的超时时间内，有多少延迟探测完全没有收到响应，以及有多少探测返回时明显比你这条连接的典型探测慢得多——这是可能发生了重传的信号，尽管无法直接计数。这两个数字都不是丢包率本身。它们都是浏览器实际能收集到的最接近的证据。

延迟、抖动和最差情况:每个数字的含义

该测试从其空闲延迟阶段报告三个相关但不同的数字。

• 延迟（ms）:典型的往返时间——技术上是所有探测的中位数，与平均值不同，它能抵抗被单个缓慢的异常值拉偏。
• 抖动（ms）:往返时间从一次探测到下一次探测的变化程度，而不是平均有多高。即使平均延迟还不错，如果抖动很高，通话依然可能听起来断断续续。
• 最差情况（ms）:第 95 百分位的往返时间——接近你在通话或游戏中真正会注意到的数字，因为一个非常缓慢的瞬间比典型情况更加突出。

缓冲膨胀:为什么下载一开始你的连接就变卡

这是大多数速度测试完全忽略的数字，也常常是"我的连接明明很好，直到有人开始下载东西"这种现象的真正解释。

• 大多数路由器和调制解调器会在发送前把出站数据放进一个缓冲区排队——这本是个合理的想法，但当这个缓冲区相对于连接来说过大时就会出问题。
• 当一次大型下载或上传占满这个缓冲区时，其他所有数据包——包括这个测试的延迟探测，以及通话或游戏的每一个数据包——都必须排在它后面等待。
• 结果是:连接空闲时表现良好的延迟，会在某个东西开始占满线路的瞬间从 20ms 跳到 300ms 甚至更多，然后在结束后再降回来。
• 这个测试正是测量这一点:它在后台运行一次占满带宽的下载，同时持续发送延迟探测，然后比较之前和期间的延迟差异。

评级从 A+ 到 F，取决于负载下延迟增加了多少——A+ 是几乎察觉不到的几毫秒，F 是数百毫秒，也就是那种会让手机在同一连接上刚开始云备份，通话就立刻卡断的那种延迟激增。

按使用场景划分的良好数值参考

并不存在单一的"好"数字——重要的完全取决于你在这条连接上做什么。

• 语音通话:往返延迟在约 200ms 以内、抖动较低即为舒适；大多数 VoIP 编解码器有足够的缓冲能力，比视频更能平滑处理这些波动。
• 视频通话:延迟低于 150ms、抖动低于 30ms 会感觉稳定；缓冲膨胀评级为 C 或更差，往往是每当有其他人上线通话就卡断的真正原因。
• 在线游戏:延迟低于 50ms 且抖动很小，对任何竞技类游戏都很出色；50-100ms 对大多数休闲类在线游戏来说也没问题。
• 云游戏:最严格的情况——需要低于 40ms 且抖动极低，因为整个视频帧都要往返，而不仅仅是一次输入。
• 网页浏览、流媒体、下载:延迟在这里几乎不重要——真正决定这些体验的数字请参考网速测试。

这就是为什么这个测试会直接为上述每一种使用场景给出结论，而不是让你自己去解读三个原始数字。

Wi-Fi、VPN 以及其他会拉高结果的因素

在断定糟糕的结果就意味着线路本身有问题之前，先排除那些最可能自行增加延迟的因素。

• Wi-Fi:会增加自身的延迟，尤其是在拥挤的 2.4GHz 频段或有几十个重叠网络的居民楼里，还会增加自身的抖动——往往比互联网线路本身贡献的还要多。
• VPN:会将每个数据包路由经过一个额外的服务器，通常还是一个较远的服务器，在加密开销之外增加真实的往返距离。
• 过载的路由器:老旧或性能不足的路由器可能会在负载下增加处理延迟，这与你实际的互联网连接无关——从外部看起来和缓冲膨胀一模一样。
• 后台应用:云同步、自动更新，以及同一网络上的其他设备，都可能在你以为是空闲测试的时候悄悄占满连接。

隔离原因最快的方法是:先暂停其他一切，用有线连接跑一次测试，再在正常后台负载下用 Wi-Fi 跑一次——两者之间的差距会告诉你问题究竟出在哪里。

结果何时真正指向问题

大多数不理想的结果都能用上述原因之一解释。只有一小部分模式真正值得向你的运营商反映。

• 有线连接下缓冲膨胀评级为 D 或 F，且在多次测试中都得到确认——如果运营商支持现代队列管理（通常以 SQM 或 fq_codel 命名），这通常可以在运营商一侧解决。
• 有线连接到附近 Cloudflare 节点的空闲延迟持续远高于 100ms，且在不同时段都是如此——这指向的是上游的路由或拥塞问题，而不是你家里的问题。
• 在没有开启 VPN 的有线连接上出现大量无响应探测——值得复现并附截图报告，因为这可能表明运营商网络存在真实问题。
• 凌晨 3 点数值正常，但每天晚上都持续偏差——这是本地网络拥塞，值得把这个具体的规律直接反映给你的运营商。

常见问题