延迟、带宽与实际下载速度
延迟看一次交互要等多久，带宽看链路容量，下载速度看这次传输完成了多少数据。想判断游戏卡顿还是大文件下载慢，关注的指标会不同。
| 指标 | 常见单位 | 观察什么 |
|---|---|---|
| 延迟 / RTT | 毫秒 ms、秒 s | 探测发出到对应回复返回的等待时间。 |
| 带宽 / 吞吐量 | bit/s、Mbps，下载工具也可能用 MB/s | 容量与实际单位时间传输量；两者不能仅凭名称混为一谈。 |
| 抖动 | 常用 ms | 时延随样本变化的程度，具体公式取决于工具。 |
| 丢包比例 | 百分比 % | 特定探测、时间与等待阈值下未成功的样本比例。 |
测量报告还要写清上行还是下行、单连接还是多连接、空闲还是同时下载。没有这些条件，同样一个“速度”数字也可能在描述不同事情。
Ping 低，网页仍可能慢在哪里
Ping 常测 ICMP 小包的往返时间，网页还要做解析、连接、TLS 握手并等待服务端响应。前者正常，后面某一步仍可能很慢。
RTT 是往返时间，包含去程、回程与回复处理；互联网两方向的路径和排队情况可能不同，不能简单把 RTT 除以二当作真实单向延迟。Ping 目标与下载目标不一致时，测得的路径也可能完全不同。
下载受目标服务器限速、当前拥塞、丢包重传、连接数、无线链路、设备负载等条件影响。客户端里的“节点延迟”也可能测的是一个指定网页请求，并非整条业务链路。看该工具测了什么，再决定数字能说明什么。
Mbps 与 MB/s 的换算
先看单位里的大小写：b 是 bit，B 是 byte，1 byte 等于 8 bit。十进制 Mbps 和 MB/s 可以先按八倍关系换算。
100 Mbps ÷ 8 = 12.5 MB/s
1 Gbps ÷ 8 = 125 MB/s
1 MiB/s = 1,048,576 B/s ≈ 8.388608 Mbps这些是单位换算示意，不是实测速度或服务保证。真实有效下载量还受协议开销、共享使用、服务器与设备条件影响，不能把标称带宽直接当作应用可持续达到的速度。
有些工具使用二进制单位 KiB/MiB，却在界面上简写为 KB/MB；比较前要查看它的定义。流量 GB 表示总量，Gbps 或 MB/s 表示速率，也不能直接互换。计算文件下载时间时，需要用一致单位，并接受启动、波动和重试造成的实际差异。
平均延迟背后的抖动
延迟偶尔出现尖峰，平均值可能看不出来。假设三个样本是 20、20、200 ms，平均 80 ms，但第三次等待明显更久。
“jitter”在不同工具里可能使用相邻样本差、标准差、单向包时延变化等不同算法；即使都写 ms，也不能直接把数值拿来排名。正式比较需明确样本数量、间隔、统计方法与是否忽略超时样本。
可以在同一工具中比较中位数、较高分位和最大值，保留原始样本。空闲测量与下载中测量要分开：同时传输大流量可能造成排队，说明负载下等待变大；一次尖峰仍需要复核，不能直接归责某个设备或运营商。
丢包比例与路由追踪星号
先看终点和真实请求，再看中间跳。路由器可能限制探测回复，却继续转发业务流量；单个星号不能直接定位转发故障。
路由器可以限制自己生成 ICMP 回复的频率，同时继续正常转发其他流量。中间一跳显示星号或高未响应比例，而后续与终点仍正常回复，通常不能单独证明这跳存在转发故障。只看最差的中间跳截图容易得出错误结论。
如果异常从某段开始并延续到终点，且实际请求也受影响，才值得进一步排查。终点也可能限制探测回复，仍需使用业务协议对照。TCP 的疑似重传提示同样受抓包完整性影响，可用 Wireshark结合完整会话复核；逐跳观察见 NextTrace。
用 curl 查看请求各阶段时间
下面用一个短请求查看解析、连接和 TLS 的计时。它不适合测最大带宽；--noproxy "*" 只绕过 curl 的显式代理，TUN 或 VPN 仍可能接管。Windows PowerShell 使用 curl.exe。
curl --silent --show-error --noproxy "*" --http1.1 --head --connect-timeout 5 --max-time 20 --write-out "\nDNS_s=%{time_namelookup} TCP_s=%{time_connect} TLS_s=%{time_appconnect} First_s=%{time_starttransfer} Total_s=%{time_total}\n" https://example.com这些字段的单位是秒，且是从本次传输开始计算的累计时间，不是可以直接相加的独立耗时。在没有重定向、复用或代理等复杂条件的简单新连接中，可以用相邻阶段差值辅助估计等待发生在哪一段。
失败请求的后续字段可能为零或没有完成，不能把它当作“极快”。响应头请求数据很少，下载平均速率不具备带宽测速意义。若实际问题发生在代理路径上，要使用相同代理、目标和请求方式复核。这次结果只覆盖当时实际经过的路径；确认未被 TUN、VPN 或透明转发接管后，才能作为直连对照。
在相同条件下比较线路
比较前固定设备、目标、协议和测试方法。把空闲状态与下载中的结果分开记录，并保留普通和失败样本，而不只留下最快一次。
- 固定设备、目标地址、地址族、协议、连接数与工具版本，记录测试时间和使用网络。
- 先停止自己的后台大流量任务，记录空闲状态；需要看负载表现时再单独记录下载中的状态。
- 保留完整结果与错误，不只挑最快一次。少量 Ping 可发现连接线索，但不足以证明长期稳定性。
- 测吞吐时使用你有权测试的服务器与合适数据量，关注服务端能力；不要用一个很小的网页代替带宽测试。
- 最后复核真实应用，如页面首屏、语音中断或下载完成时间，明确结论只覆盖测试条件。
iperf3 这类专门工具需要合适的测试两端，结果描述端到端当次传输，不等于套餐承诺或任意网站的速度。无法固定目标或路径时，应在记录中说明，避免把差异全部归因于网络线路。排查顺序可见 DNS、TCP、TLS、HTTP 分层排查。
常见问题
延迟单位 ms 与 s 如何换算？
1 秒等于 1000 毫秒。比较时先统一单位，并确认数字测的是 RTT、连接建立还是网页响应时间，这些指标不能直接互换。
为什么不同测速工具给出不同 jitter？
算法、探测协议、样本间隔、目标与超时处理可能不同。应先核对方法，在同一工具和相同条件下比较，不把同单位当作同定义。
curl 的 time_connect 能直接当成纯 TCP 握手时间吗？
它是从传输开始到连接完成的累计时间，通常已经包含前面的名称解析等等待。简单新连接可参考相邻阶段差值，复杂代理或复用场景要另看。
参考资料
原理和协议定义可查以下标准与官方文档。文中的流程图由 AFQKit 绘制。