FIELD NOTE / STABILITY / DIAGNOSIS

节点丢包率怎么判断？先看样本数量、超时和连续丢包

“丢包1%”看起来很清楚，实际上还缺少三件事：一共发了多少包、多久没返回算丢失、丢失是零散还是连续。没有这些条件，百分比既不能复核，也很难对应实际卡顿。

TRIAGE

从现象开始缩小范围

测试包没有在设定时间内返回，工具通常会记为丢失。但超时阈值不同，极高延迟可能在一个工具里算丢包，在另一个工具里仍算迟到。记录工具名称、协议、包大小和超时时间，避免把不同定义的百分比放在同一张榜单直接比较。

发十个包丢一个就是10%，但这一个样本无法说明长期表现。增加样本与观察时间，才能区分偶发事件和持续问题。样本量扩大后还应保留每段时间的分布，不能只用全日平均冲淡晚高峰的集中异常。对比节点时必须使用相近样本规模。

同样丢十个包，均匀散落与连续丢失十个的用户感受不同。连续丢包可能让通话长时间静音、连接重置或游戏掉线；零散丢包可能被重传和缓冲部分吸收。记录序号和时间点，标记最长连续丢失段，能比单个百分比提供更多信息。

某些网络或目标会降低特定探测流量的优先级，测试包表现不一定等同于真实业务。不要只依靠一种协议。可将受控探测、真实文件传输和应用日志放在一起核对。如果探测显示丢包而实际任务稳定，应标注差异，不能擅自把其中一个当作真相。

先测直连到相同目标，再连接节点。如果两者同时丢包，检查Wi-Fi、移动信号、路由器和接入网络；只有连接节点后出现，才继续比较节点、协议和路由。断开重连后恢复不等于已经找到原因，需要重复相同条件验证异常是否随变量回来。

有效结论可以是：工作日晚高峰、某设备Wi-Fi接入、向指定目标连续测三十分钟，节点出现两段连续丢包并伴随会议静音。不要写“节点永久丢包”或“绝对稳定”。网络会变化，记录应包含复查日期和触发重新测试的条件。

用户任务不只在意是否丢包，还在意应用能否重传以及多久恢复。文件传输可能降速后继续，实时通话可能直接出现缺口。记录丢包发生后任务的恢复秒数、是否需要手动重连和是否丢失进度，才能把网络指标与实际代价联系起来。

有些服务器限制或忽略探测请求，但仍正常提供网页和文件服务。若只有一个目标不响应，应换经授权且稳定的测试目标，并用真实业务核对。未经判断就把目标不回包算成节点丢包，会制造错误结论；测试也不应对无关服务器发送高频流量。

FIELD RECORD

停止与安全边界目标不回复探测或中间设备限速回复，不等于业务数据必然丢失。

USER QUESTIONS

丢包0%就代表绝对稳定吗？

只能说明该测试窗口和方法未观察到丢失。样本、目标、协议和时段改变后仍需复查。

为什么ping丢包但下载没中断？

探测流量可能被不同处理，下载协议也会重传。应结合真实任务，不用单一ping结果替代完整判断。

需要测试多久？

初筛可做数分钟，重要通话或游戏场景应覆盖真实使用时长，并在晚高峰重复。

以下资料用于核对指标和方法，不代表资料发布方评价了本文中的具体节点或任务。