怎样判断网络是否稳定？看延迟、连续丢包和跨时段样本

“测速很快”和“用起来稳定”需要不同证据。一次下载峰值可以记录当时的吞吐表现，却看不到长时间使用中是否出现连续慢响应或短暂中断。判断稳定性，需要把时间顺序留下。

这篇文章关注如何读证据，没有测量任何线路，也不把某一组数字当作通用合格线。

一、延迟：平均值之外，保留慢响应

同样的平均值，可能来自一直接近平均的响应，也可能夹杂几次很慢的响应。保存典型水平和较慢一端的统计；工具支持 P50、P95 时，注明算法和有效响应数，否则保留工具实际提供的统计即可。

“P95 减 P50”可以作为观察延迟分散程度的辅助信息，但不要直接称为所有工具通用的抖动算法。RFC 3393专门提醒，“jitter”存在不同用法。比较抖动数字前，应先对齐定义。

超时不能填为 0 ms，也不能从失败记录中消失。如果延迟统计只包括成功回应，应把这一限制写在表旁。

设想两段各发送 100 个探测包的虚构记录：A 有 6 次未回应，分散在整段；B 也有 6 次未回应，但连续出现。两者总比例都是 6%，只看百分比就无法区分这两种形态。

这不意味着能仅凭这组探测算出视频会卡几秒。实际影响还要用通话、播放或交互任务核对。记录未回应发生的时间、最长连续次数，以及探测间隔；“连续 6 个包”和“中断 6 秒”也不能在没有间隔信息时直接画等号。

至少把问题容易出现的窗口单独观察，再补充另一个使用时段和另一天的记录。每条数据写完整日期、时区与起止时间，保留设备、接入方式、目标和代理路径。

如果只有某一天的夜间出现异常，就描述为那个窗口的异常。即使另外两天顺利，也不能把那次失败删掉后宣称“始终稳定”。

发包数、持续时间、总轮数和覆盖日期需要同时交代。短时间高频探测得到很多包，可能仍主要反映同一次拥堵。主动测量也会影响被测网络，相关原理见 RFC 2330。

家庭观察可先安排同窗口 3 轮、每轮相同的低频探测，再跨日复查；这是操作起点，不是推断长期可用性的保证。保留所有失败和中断，先约定安排，再收集结果。

对外结论最好限定为“这些日期和条件下表现如何”。想补充节点对照，可参考本站交替顺序与 P50/P90 的记录方法。本文资料核对于 2026 年 10 月 25 日。