机场三个数字，回答三个不同的问题
延迟描述一次交互需要等待多久；带宽描述链路的传输能力，实际吞吐量则反映一段时间里真正传输了多少数据；丢包表示部分数据没有按预期到达。它们相关，却不能互相替代。低延迟的连接可能因为吞吐量不足而下载缓慢，高吞吐量的连接也可能因为延迟波动影响实时通话。
客户端中标为“延迟”的数字，还取决于它使用的测试目标、协议和计算方式。有的测试包含连接建立或应用响应，有的只反映某一层的往返时间。比较前先确认测量对象，否则两个界面的数字相差很多，也可能是在回答不同问题。
从实际任务选择指标
- 阅读网页：观察首次打开、切换页面和图片加载的等待，不只看下载峰值。
- 视频播放：关注持续播放是否缓冲、清晰度是否频繁变化，以及较长时间内的吞吐表现。
- 语音会议：留意声音断续、互动延后和延迟波动，单次测速的最高速度参考有限。
- 文件上传：单独观察上传过程，下载表现不能替代上传能力。
- 远程交互：关注操作反馈是否稳定，偶尔很快与持续顺畅是不同体验。
例如，一条连接打开小网页很快，但长视频经常缓冲，值得继续观察持续吞吐量；另一条连接下载很快，但会议交谈经常互相打断，应重点观察延迟和波动。这些是假设场景，用于说明诊断方向，不是对某家服务的测试结果。
区分单位，避免把数字看大八倍
带宽宣传常用 Mbps，下载应用可能显示 MB/s。小写 b 表示比特，大写 B 表示字节，理论换算中一个字节等于八个比特。因此，100 Mbps 对应的理论数据量约为每秒 12.5 MB；实际应用还有协议开销、远端限制和网络波动，不能直接把理论上限当成下载保证。
还要分清瞬时峰值与持续结果。刚开始下载时的缓存或短时冲高，可能让某一秒的数字特别漂亮；更有用的是同一任务在一段时间内能否稳定完成。不要将自己的单连接下载速度与另一工具的多连接测速结果直接对比。
准备一次可解释的比较
- 固定设备、目标任务和连接方式，记录客户端及策略。
- 暂停自己可控制的云同步、游戏下载等大流量任务，留意其他家庭设备的占用。
- 用平时常用的任务观察一小段时间，再进行必要的测量。
- 只更换一个条件，例如节点或时段，重复同一任务。
- 记录多次表现和异常出现的范围，而不是只保存最好的一张截图。
需要测速时控制次数与数据量，尤其是在流量额度有限的套餐中。测试流量本身会占用连接，可能使同时进行的会议或播放变差。不要在网络已经繁忙时持续跑满带宽，再把被测试挤占的应用表现作为额外故障证据。
先排除身边的网络因素
靠近路由器，或者在条件允许时临时使用网线，再观察同一个任务。如果仅在距离远、隔墙多的位置出现问题，应先检查无线覆盖与干扰。信号图标较满也不能单独证明无线链路没有竞争或重传。
比较自己常用的直连服务与代理场景。两者同时变慢时，家庭网络、宽带负载和设备资源值得优先检查；只有某个节点或某个目标异常时，再比较另一条路径。但不同服务的服务器和内容并不相同，这种参照用于缩小范围，不能单独判定责任归属。
怎样看待丢包与路由追踪
丢包可能发生在本地、远端路径或终点，也可能受到设备策略影响。诊断工具通常依赖特定探测与响应，探测未获回复不总是等于正常业务数据被丢弃。路由追踪中的某一跳不响应，也可能是中间设备限制诊断请求。
因此，应结合后续跳与终点表现、重复测量以及实际应用症状判断。只有中间一跳显示异常，而终点持续正常时，不能直接把它认定为故障点；反过来，一次探测成功也不能证明所有应用协议均正常。
如果表现是页面长时间等待后才开始传输，还要区分域名解析、连接建立和服务器响应。可以接着阅读DNS 与分流，不要把所有等待都写成带宽不足。
留下一份真正有用的记录
记录日期时段、运营商、连接方式、目标服务、客户端、节点和具体症状。比如“同一电脑与 Wi-Fi，晚间视频连续播放时多次缓冲，直连参照正常，更换节点后有所改善”，比“延迟很低但很卡”更容易继续分析。
选机场时，可以用这些维度建立观察清单，但别把别人的一次测速替代自己的长期体验。网络路径会随地区、时段和目标变化。若问题集中在繁忙时段，继续使用晚高峰排查流程，保持可比较的条件再作判断。
