机场节点测速方法：可复核的测试条件、统计与记录模板

为什么机场测速结果要可复核

网络性能会随时间、地点、运营商和设备变化。同一个节点，晚上用家庭光纤测和白天用移动网络测，结果可能相差很大，而两者都可能是真实的。只给一个数字，读者看不出它是常态还是偶然。

可复核是指别人（包括几个月后的你）能按记录的条件重做测试，并对照新旧结果。IETF 的 RFC 2330 把“可重复”列为测量方法应有的性质：在相同条件下多次使用同一方法，应当得到一致的结果。现实中条件很难完全相同，复测结果也会有出入；条件写得越完整，出现差异时越容易找到原因，例如时段不同、客户端升级或测试服务器更换。

RFC 2330 测量框架：样本、包类型与误差

RFC 2330（Framework for IP Performance Metrics）于 1998 年发布，是 IETF IP 性能指标工作的基础框架，后来又经多份文档更新。其中三个概念对个人测速最实用。

第一，区分单次测量、样本与统计量。单次测量（singleton）是一次原子测量，例如一个包的往返时间；样本（sample）是一组单次测量；统计量（statistic）是由样本算出的数值，例如中位数。记录时应保留每次测量的原始值，而不只是统计量，别人才能重新计算。

RFC 2330 还比较了几种抽样方式：固定间隔的周期抽样简单，但如果被测对象本身有周期性变化、且周期恰好吻合，只能观察到其中一部分，固定的时间点也容易被预料；反复的周期性测量流量还可能让网络进入同步状态，放大原本轻微的影响。间隔随机的抽样可以避免同步效应，其中间隔服从指数分布的泊松抽样是 RFC 2330 总体上更推荐的方式。个人测试可以简化为在固定间隔上加入随机偏移，避免总在整点开始。

第二，测试包的类型会影响结果。RFC 2330 指出，许多指标的取值取决于所用 IP 包的类型，并用“type P”表示这一点：端口、校验和等属性不同的包，在防火墙等设备面前可能得到不同的结果。所以要写清测试用的是 ICMP 回显、TCP 连接还是 HTTPS 请求，不宜直接拿一种流量的结果代表另一种。

第三，误差来源要写出来。RFC 2330 提出，设计测量方法时应尽量减少误差和不确定性，弄清并记录误差的来源，并尽可能量化。例如，执行测量的主机自身的处理开销会混入测得的时延；两台主机的时钟不同步时，单向时延的计算就会出错。它还建议做自洽性检查：算出负的往返时间，说明测量过程出了问题，应当查明错误出在哪里。把这类异常值标注出来并说明排查结果，不要悄悄删掉。

主动测量与被动测量

RFC 7799（2016 年）把测量方法分为三类：

• 主动方法（Active Methods）：生成专门用于测量的数据包流，包内通常带有序号，常常还有时间戳。ping、iperf3 和测速网站都属于这一类。
• 被动方法（Passive Methods）：只观察已经存在的流量，按 RFC 7799 的定义，不得添加、修改或删除数据包。例如只读取路由器或客户端对日常流量的统计。
• 混合方法：介于两者之间，例如在观察已有流量的同时附加一股负载流量。

RFC 7799 提醒，主动方法向网络加入流量，会在一定程度上影响被测量的对象，测试者应量化或尽量减小这种影响。因此记录里要写明测试本身产生了多少流量，例如每次下载多大的文件、持续多少秒；大流量测试还会消耗套餐额度。

每次测速要记录的条件

下表的示例列展示填写格式：

填写时注意几点：

• 时间写法：RFC 3339 规定的时间戳带有与 UTC 的偏移，偏移量等于“本地时间减去 UTC”，结尾的 Z 表示 UTC。按这个规则，20:30:00+08:00 与 12:30:00Z 是同一时刻；只写“晚上八点半”，其他时区的读者就无法换算。
• 地点只写到城市，不必公开精确住址。
• 测试时是否有其他设备在下载、用的是有线还是 Wi-Fi，都写进备注。
• 不清楚的项目（例如签约带宽）写“未知”，不要估一个数字填进去。

测试设计：重复测量、晚高峰对照与直连基线

重复测量，报告中位数与百分位数

一次测试只是一个单次测量。下面用一组 10 次延迟样本（示例数据，单位 ms，按测试顺序）说明为什么要看分布：42、45、44、47、43、120、46、44、48、45。

RFC 2330 给出了百分位数和中位数的定义，并强调用百分位数汇总样本时必须同时写出样本量 N，因为比 1/N 更细的百分位差异低于样本的分辨率。上例只有 10 个样本，按同一定义，第 95 百分位数就是最大值 120 ms，单独报告它不提供额外信息。RFC 6703 建议时延报告同时给出平均值和中位数，并认为最小值、最大值和第 95 百分位数对描述分布有价值；它还建议把未到达的包的时延视为未定义、计入丢包，而不是当作无限大。

归纳起来：每个条件测一组样本并写明 N；用中位数代表典型情况，用高百分位数或最大值反映波动；超时和失败次数单独记录。

晚高峰与对照时段分开测

网络负载随时间变化，因此至少选两个时段：一个是你最常使用的时段（例如工作日晚上），另一个作为对照（例如工作日上午）。两个时段用相同的样本量和间隔，分开统计。 只测了一个时段时，在结论里写明适用的时段。

先测一组不经代理的直连基线

要判断代理本身带来多少额外时延或吞吐量损失，需要用同一台设备、同一时段、同一个测试目标，分别在直连和经过代理时测试，并尽量交替进行（直连、代理、直连、代理……），减少网络状况变化的影响。没有基线，就分不清慢在本地宽带、测试服务器还是代理节点。 基线测试应选择在你所在地可以正常、合法访问的目标。

常用测速工具：ping、curl、iperf3 与 NDT

以下要点来自各工具的官方文档，具体参数以你实际使用的版本为准。

ping：只反映 ICMP 的往返情况

ping 发送的是 ICMP 回显请求。按前面的 type P 概念，它的结果只代表 ICMP 包在测试时的往返情况，不一定等同于应用实际使用的 TCP 或 UDP 流量。使用代理时还要注意路径：RFC 1928 为 SOCKS5 定义了 CONNECT、BIND 和 UDP ASSOCIATE 三种命令，并说明它位于应用层与传输层之间，不提供转发 ICMP 消息这类网络层网关服务。因此，在只让应用经由 SOCKS5 代理的设置下，系统 ping 发出的 ICMP 包不经过代理，测到的是直连路径；其他工作方式是否转发 ICMP，取决于客户端的具体实现。客户端界面显示的“延迟”测量方式因客户端而异，记录时写明客户端版本及其说明的测试方式。

curl：TCP 连接与 HTTP 分段计时

curl 的 -w（--write-out）选项可以输出一次请求各阶段的耗时。按 curl 官方手册，time_namelookup、time_connect、time_appconnect、time_starttransfer 分别是从开始到域名解析完成、TCP 连接完成、SSL/SSH 等握手完成（HTTPS 请求即 TLS 握手）、收到第一个字节所用的秒数，time_total 是整个操作的总时长。手册注明 time_connect 是到远程主机“或代理”的 TCP 连接完成时间，所以让 curl 自身通过代理（例如用 -x 指定）测试时，它反映的是到代理的连接，而不是到最终网站的连接。 如果代理客户端在系统层面接管流量、curl 本身没有设置代理，各项计时的含义取决于客户端的工作方式，记录时应写明。

示例命令如下，把网址换成记录中写明的测试目标：

curl -o /dev/null -s -w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total} %{http_code}\n' https://example.com/

每行输出是一次单次测量。重复运行时，把每次的输出连同时间戳追加保存到文件，并用 curl --version 记下版本。

iperf3：吞吐量测试

iperf3 官方文档说明，它用于测量网络吞吐量，可以测试 TCP、UDP 或 SCTP，并且需要同时运行服务器端（-s）和客户端（-c）。因此你需要一台自己控制或明确允许测试的服务器，结果反映的是到这台服务器的路径。文档中与记录相关的选项有：

• -t：测试时长，默认 10 秒。
• -R：反向测试，由服务器向客户端发送数据，可用于测下载方向。
• -P：并行流数量，会改变测试条件，必须写明。
• -u：改用 UDP；此时目标速率默认只有 1 Mbit/s，需要更高速率时用 -b 设置。
• -O：先预测试若干秒，并丢弃这段统计。
• -J：以 JSON 格式输出，适合作为原始数据保存；--logfile 可把输出写入文件。
• -v：显示版本信息。

文档还提示，网页上的手册文本不一定对应当前版本，以随程序安装的手册页为准。记录时用 iperf3 -v 记下版本，并保存完整命令行。

M-Lab NDT：单流测速

M-Lab 的 NDT（Network Diagnostic Tool）文档说明，它是测量连接批量传输能力的单流测试，报告上传、下载速度和延迟指标；其中 ndt7 协议在可用时使用 TCP BBR，运行在标准的 HTTP(S) 端口 80 和 443 上。结果反映的是到 M-Lab 平台上某台测试服务器的路径，记录时写明协议版本和服务器。M-Lab 还说明，运行 NDT 时，运营商分配给你的 IP 地址会随测试结果一起被收集，全部测试结果都会公开发布。

公开原始数据与披露利益关系

最后一步，是让别人看到结论所依据的数据：

• 公开原始输出：例如 iperf3 的 JSON 文件、curl 每次运行的输出，以及计算中位数所用的脚本或表格。
• 说明剔除了哪些数据及原因，例如因断网作废的一组，不要直接删除。
• 发布前去除敏感信息：删掉公网 IP、账户信息、订阅链接及其中的令牌，必要时替换为“已隐去”。
• 披露利益关系：被测服务是否由服务商免费提供、是否有推广链接或赞助，都应写在结果旁边。本站的做法见推广披露，发现错误后的处理见更正规则。

核对他人测速结果的方法见机场宣传与评测核对清单。

本站测速记录字段对照

本站测速记录的固定字段见评测方法中的测速记录说明，与上述项目的对应关系如下：

metrics 每项只填一个数，建议在 method 写明是中位数还是平均值。下载和上传以 Mbps 填写，工具显示 MB/s 时先乘以 8 换算。 没有测量的指标保持空值（页面显示为“未记录”），不能填 0。

测速记录模板（可直接复制）

每组测试填写一份。不知道的项目写“未知”，不适用的写“不适用”。

| 项目 | 填写内容 |
| --- | --- |
| 记录编号 | |
| 测试日期与开始时间（含时区，如 +08:00） | |
| 测试时段（繁忙 / 对照） | |
| 地点（城市） | |
| 运营商 | |
| 接入方式与签约带宽 | |
| 连接方式（有线 / Wi-Fi）及同时段其他占用 | |
| 设备型号 | |
| 操作系统与版本 | |
| 客户端与版本 | |
| 协议 | |
| 节点地区与名称（服务商标注） | |
| 测试目标（网址或服务器） | |
| 工具与版本 | |
| 完整命令或设置 | |
| 样本量、间隔与总时长 | |
| 直连基线结果（同时段、同目标） | |
| 汇总：中位数 / 第 90 百分位数 / 最大值 | |
| 超时或失败次数 | |
| 测试产生的流量 | |
| 原始数据位置 | |
| 剔除的数据及原因 | |
| 利益关系披露 | |
| 备注 | |

测试和使用网络服务时，请遵守所在地的法律法规，以及服务商、测试服务器和测试平台的使用条款，不要对未获授权的服务器做高强度测试。