机场测速指标详解：延迟、抖动、丢包与晚高峰变慢

机场测速的四个核心指标

这四项互相牵连：拥塞时排队会同时推高延迟和抖动，队列满了就丢包，丢包和高延迟又会压低 TCP 的速度。 只看其中一项，很难判断实际体验。

延迟：单向时延与往返时延（RTT）

单向时延由 RFC 7679 定义：从源端发出数据包第一个比特，到目的端收到最后一个比特所经过的时间。要测准它，两端时钟必须严格同步，所以普通用户很少直接测单向时延。包在约定的等待时间内没有到达时，RFC 7679 把它的时延记为“未定义”（非正式地说是无穷大）。

日常用 ping 看到的是往返时延（RTT）。RFC 2681 的定义是：从源端发出数据包第一个比特起，目的端收到后立即回包，到源端收到回包最后一个比特为止的时间。目的端的处理时间理想情况下为零，现实中会带来额外误差。RFC 2681 还指出，去程和回程可能走不同路径，往返测量其实是把两条路径合在一起测，所以 80 ms 的 RTT 不代表每个方向各 40 ms。

RTT 之所以重要，是因为建立连接、加密握手、请求与响应都要“一问一答”，每次来回至少花一个 RTT。打开一个网页往往要来回好几次，RTT 越大，等待累积越明显，单靠提高带宽难以弥补。

抖动（时延变化）：只看平均延迟会漏掉卡顿

“抖动”（jitter）在不同领域有不同用法。RFC 3393 为了避免歧义，尽量不用这个词，而是定义了 IP 包时延变化：两个选定数据包的单向时延之差。这个差值可以是正数、负数或零，选取方式之一是在一段时间内取前后相邻的数据包。两端时钟之间固定的偏差在相减时会抵消，但两端时钟走速不一致（RFC 3393 称为 skew）仍会带来误差。

例如，连续 5 次测得的延迟是 40、42、41、120、43 ms，平均约 57 ms。只看平均值像是“整体略慢”，实际却是大多数时候很快、中间夹着一次尖峰。网页浏览对偶尔的尖峰不太敏感，语音、视频通话和游戏的卡顿却常常来自这里。

RFC 3393 提到，最大时延变化是确定播放缓冲区大小的重要依据。缓冲区设大，能吸收更大的波动，但整体延迟增加；设小则延迟低，但来得太晚的包只能放弃。RFC 7680 也举过例子：晚于播放时间点到达的音频包，和丢失没有区别。不同工具报告的“抖动”算法可能不同，比较前先确认工具和算法一致。

丢包：TCP、UDP 与代理隧道下的不同表现

RFC 7680 对单向丢包的定义很直接：目的端在约定的等待时间 Tmax 内没有收到数据包，就记为丢失。这个阈值是测量参数，标准有意没有规定具体数值。按这个定义，晚于阈值到达的包算丢包，损坏的包也计为丢失；不同工具的等待时间不同，报告的丢包率也可能不同。RFC 7680 还指出，丢包过多可能让某些实时应用难以正常工作，丢包越多，传输层协议越难维持较高速率。具体影响取决于传输方式：

• TCP：丢包表现为等待和降速。 网页、文件下载等很多应用使用 TCP。TCP 提供可靠传输，丢掉的数据会被重传，代价是时间；RFC 5136 也提到，丢包会触发重传，并可能让发送速率下降。因此对 TCP 来说，丢包表现为“变慢”和“卡一下”，而不是数据缺失，丢包比例看起来不高，下载速度也可能明显下降。
• UDP：丢包直接交给应用处理。 RFC 8085 把 UDP 描述为不可靠、尽力而为的传输方式，本身不提供拥塞控制，需要可靠送达的应用必须自己实现相应机制。语音和视频通话等实时应用常用基于 UDP 的协议，例如 RFC 8085 提到的 RTP。迟到的数据对它们用处不大，所以丢包常直接表现为声音断续、画面花屏或动作跳跃。
• 代理隧道会改变丢包的表现。 RFC 8085 提到，把 UDP 用作隧道协议越来越常见，这类隧道可用于构建虚拟（专用）网络。隧道本身使用 TCP 这类可靠传输时，这一段的丢包先由隧道重传，上层看到的多是延迟突然升高；隧道把数据原样装进 UDP 数据报转发时，丢包会交给上层协议处理。也有基于 UDP 的协议自行实现重传，不能只凭底层是 TCP 还是 UDP 下结论。某个协议或客户端是否支持转发 UDP 流量，以协议说明和服务商文档为准。

带宽与吞吐量：为什么跑不满宽带

日常说的“带宽”常常混用了好几个概念。RFC 5136 做了更细的区分：

• 链路容量：一条链路在一段时间内最多能正确传送的 IP 层比特数，除以这段时间。
• 路径容量：路径上容量最小的那段链路，决定整条路径的容量。
• 利用率与可用容量：利用率是实际使用量占容量的比例；可用容量 = 容量 ×（1 − 利用率）。可用容量最小的那段链路，往往就是一条连接的瓶颈。

RFC 5136 还指出，标称的物理速率只是上限，编码、成帧等开销会让 IP 层容量低于标称值；应用能用上的速度属于传输层测量（RFC 5136 称为批量传输容量），只计不重复的有效数据，不含包头和重传，还受传输算法和传播时延等路径特性影响。宽带合同上的“500M”只是接入这一段链路的标称速率，既不是整条路径的容量，也不是下载软件显示的速度。

另外，1 字节等于 8 比特，100 Mbps 折合 12.5 MB/s（按 1 MB = 1,000,000 字节）；有的软件按 1 MiB = 1,048,576 字节显示，约为 11.9 MiB/s。两者都是扣除开销前的理论值。

单条 TCP 连接的速度上限：窗口与 RTT

RFC 6349 给出了两个实用的关系。第一，带宽时延积（BDP）= RTT × 瓶颈带宽，表示路径上同时“在路上”的数据量；要把路径跑满，接收窗口至少要达到 BDP 对应的字节数。第二，当窗口小于 BDP 时，单条 TCP 连接的吞吐量上限约为：接收窗口（字节）× 8 ÷ RTT。

代入数字看一下。瓶颈带宽 100 Mbps、RTT 50 ms 时，BDP = 100,000,000 比特/秒 × 0.05 秒 = 5,000,000 比特，即 625,000 字节。如果接收窗口只有 65,535 字节：

• RTT 50 ms 时，65,535 × 8 ÷ 0.05 ≈ 10.5 Mbps；
• RTT 200 ms 时，65,535 × 8 ÷ 0.2 ≈ 2.6 Mbps。

窗口不变时，RTT 变成 4 倍，单条连接的速度上限降到四分之一。 实际窗口大小由操作系统和应用决定。RFC 6349 也提到，窗口不足时需要多条 TCP 连接才能跑满链路；测速工具如果同时开多条连接，测出的数字就可能高于单个下载任务实际拿到的速度。

负载下的延迟：空闲时快，用起来卡

路由器和家用网关里都有缓冲区，用来吸收短时间的突发流量。RFC 7567 认为，缓冲区应能容纳必要的突发，但平时队列宜保持较小。链路被占满时，数据进入的速度超过发送速度，队列变长，每个包都要排队。RFC 7567 指出，传统的尾部丢弃可能让队列长时间接近满载，而过度排队会带来不必要的延迟。这类由过大且长期填满的缓冲区造成的问题，业内常称为 bufferbloat。

排队延迟可以粗略地用“队列中的数据量 ÷ 发送速率”估算。例如上行速率 10 Mbps、缓冲区积压了 1,000,000 字节时，新到的包约要等 1,000,000 × 8 ÷ 10,000,000 = 0.8 秒。空闲时 ping 很低的网络，在有人上传大文件时游戏和通话突然变卡，排队延迟往往是原因之一。

RFC 7567 建议网络设备实现主动队列管理（AQM），保持较小的平均队列以降低延迟。对用户来说，更实际的做法是同时看空闲时和链路占满时的延迟，后者更接近多人共用网络时的体验。

晚高峰为什么变慢

晚高峰变慢，常见原因是共享资源在同一时段被更多人使用。 家庭上网通常集中在晚间，而一次访问经过的很多环节都是共享的：

1. 家里的 Wi-Fi 和路由器，家人可能同时在用；
2. 运营商的接入网和城域网；
3. 运营商之间的互联链路和出口链路；
4. 代理节点所在服务器的网络出口，由使用这个节点的用户共同分享；
5. 节点到目标网站之间的路径。

套用 RFC 5136 的公式举例：一条 1 Gbps 的链路白天利用率 30%，可用容量约 700 Mbps；晚上利用率升到 95%，只剩约 50 Mbps。利用率接近饱和时队列堆积，延迟和抖动上升；队列满了开始丢包，TCP 随之降速。因此晚高峰往往同时影响前面提到的各项指标。

节点的用户数和利用率通常不公开，实际表现要靠不同时段的反复测试来判断，RFC 6349 也建议在一天中的不同时段测试吞吐量。路径上任何一段都可能成为瓶颈，晚高峰变慢不一定是节点本身的问题。

走代理后的延迟：节点延迟低，网页为什么还慢

不使用代理时，数据从你的设备经运营商网络直接到达目标网站。使用代理后，路径被分成两段：

• 第一段：你的设备 → 代理节点；
• 第二段：代理节点 → 目标网站，响应再沿反方向返回。

端到端往返时延大致是两段之和，再加上节点处理时间。 客户端显示的节点延迟如果是直接测到节点得到的，只反映第一段；如果是经由节点访问某个测试地址得到的，则包含到该地址的第二段，还可能包含多次握手往返，而测试地址不一定和你要访问的网站同方向。各客户端测法不同，结果不宜直接比较，以客户端文档为准。

举例来说，节点 A 显示 40 ms，但离目标网站较远，第二段往返要 150 ms；节点 B 显示 80 ms，离网站很近，第二段只要 20 ms。不计节点处理时间，A 的整体往返约 190 ms，B 约 100 ms。只按节点延迟排序，就可能选错节点。 再结合 RFC 6349 的关系，整体 RTT 越大，即使节点带宽充足，单条连接的速度也可能受限。

一次测速截图能说明什么

单次测速只回答一个问题：此刻、经由这个节点、到某台测速服务器、用某种连接方式，最多能跑多快。 它没有说明：

• 测速服务器和你常用的网站是否同方向，第二段路径可能完全不同；
• 测试时间是否覆盖晚高峰；
• 用的是单条还是多条并行连接；
• 链路占满时延迟、抖动和丢包如何；
• 一次结果是偶然还是稳定。

宣传页或截图没有交代这些条件时，数字只能作为参考。逐项核对宣传说法与评测的方法见机场宣传与评测核对清单，本站对测速记录的要求见评测方法中的测速记录部分。

按用途选择重点指标：看视频、通话与游戏

先按主要用途确定重点指标，再结合预算挑选套餐，具体方法见按预算和用途选择套餐。使用任何网络服务，都应遵守所在地的法律法规和服务商的条款。