平均延迟变低，为什么实验仍可能更不稳定：分布尾部、丢包与采样时间怎么分

新版线路的平均延迟从 86 ms 降到 71 ms，团队准备把它写成远程实验更稳定。可是在同一晚，终端仍出现几次长时间停顿，两个探测包也没有返回。平均值确实下降了，却没有回答慢样本有多慢、失败发生多少次，以及两轮测量是否覆盖相同时段。

平均延迟只描述样本中心。远程实验还会受到尾部延迟、丢包、延迟变化和采样设计影响。要判断稳定性，应把中心、尾部与失败放在同一份记录里，并保证探针、目标、协议和时间窗可比。

平均值会把少量极慢样本压扁

假设 99 次探测都在 50 ms 左右，另一次耗时 5 秒，平均值约为 99.5 ms。报告只写平均不到 100 ms，会让读者以为多数操作都接近这个数字；实际上绝大多数很快，少数一次却足以打断交互。Google SRE 给出的服务例子更直接：平均延迟 100 ms 时，1% 请求仍可能耗时 5 秒。

高分位能把尾部保留下来。95 分位回答约 95% 样本不超过什么水平，99 分位更靠近最慢的一小段。它们不能替代完整分布，但比单一平均值更容易看出偶发卡顿。样本很少时，99 分位可能只由一两个观测决定，因此必须同时报告样本数。

直方图也很实用。把延迟按 0—30、30—60、60—100、100—300、300 ms 以上分桶，可以看出新版线路是整体左移，还是多数样本变快、尾部反而拉长。Google SRE 建议以近似指数增长的区间记录请求数，目的就是保留分布形状。

丢包没有正常延迟值，却不能从报告消失

一个探测包未返回时，无法像成功样本那样得到正常往返时间。若程序直接删除失败项，再计算剩余样本平均值，线路可能出现一种误导性结果：平均延迟下降，丢包率上升。远程桌面、语音和交互实验对这种组合通常不会感到更稳定。

RFC 5481 要求在延迟变化分析中处理丢包、长延迟与重排，并把频繁丢包列为挑战条件。RFC 6703 进一步说明，网络特征描述与应用表现估计的用途不同，丢失包如何进入报告也会随用途改变。共同原则是失败不能悄悄从分母消失。

因此每个窗口至少写明发送多少包、收到多少包、丢失多少包和丢包率。延迟统计只对成功样本计算时，要在旁边明确标注。若应用设有超时阈值，还可以另列超过阈值的比例，但不能把超时值随意替换成一个较小数字再加入平均。

抖动必须说明计算方法

RFC 5481 区分两类常见延迟变化。IPDV 以前一包为参照，观察相邻包延迟如何变化；PDV 常以样本中的最小延迟为参照，观察其他包偏离基准多少。两者回答的问题不同，用同一个抖动标签会让独立测量难以比较。

对远程实验来说，相邻包变化大，可能影响播放或交互缓冲；相对于最小延迟的偏离，则更容易呈现排队增加。报告应写清采用哪种定义、发送间隔和参照方式。只记录软件界面上的一个数字，却不保存定义与原始样本，下一次就无法复现。

路径改变和负载均衡也会改变分布。某些包走不同路径后，平均值可能仍接近旧值，尾部与相邻变化却明显扩大。此时应把路由观察作为解释线索，不能仅凭延迟数字断言具体设备或运营商发生故障。

采样时段不同，会制造看似确定的改善

上午十分钟与晚高峰十分钟即使使用相同目标，也面对不同负载。把新版线路放在上午测、旧版放在晚上测，差异同时包含线路版本和时段，无法归因。RFC 6703 要求长期报告交代测试流特征与样本规模，因为发送方式、覆盖时间和观测数量都会影响统计稳定性。

受控比较应固定探针、目标地址、协议、包大小、发送间隔和窗口长度，在相同小时分别运行两版。若无法同时测量，可以跨多个相同工作日重复，并把日期保留下来。不要把一个时段的结果外推成全天，也不要把一个城市探针的结论写成所有地区都相同。

采样粒度也要匹配现象。Google SRE 指出，一分钟平均 CPU 会漏掉造成尾部延迟的短时尖峰；过密采样又会提高收集和保存成本。远程实验若关心几秒内的停顿，按小时只存一个平均值显然太粗；若观察数月趋势，每秒永久保存全部样本则未必必要。

建立一张同时包含中心、尾部和失败的表

每个时间窗可以保存探针、目标、开始与结束时间、样本数、平均值、中位数、95 或 99 分位、最大值和丢包率。平均值与中位数差距扩大时，通常说明分布偏斜；高分位或最大值上升时，尾部正在变差；丢包率上升时，即使成功样本更快，也不能写成全面改善。

比较两版线路时，先确认定义完全相同。若新版平均值从 86 ms 降到 71 ms，95 分位从 140 ms 升到 260 ms，丢包率从 0.1% 升到 1.2%，准确表述应是多数成功样本更快，但尾部和失败增加。这比单独宣布延迟下降更接近远程实验的实际风险。

表格还应保留成功样本和全部发送样本两个分母。例如一轮发送 1000 包、成功 998 包，另一轮发送 1000 包、成功 970 包，不能只拿两组成功样本的延迟均值比较。前者丢包率是 0.2%，后者是 3%；即使后者的成功包平均值更低，实际失败频率仍明显增加。把分母写出来，能避免软件默认过滤超时后造成的乐观偏差。

同一线路也要按相同小时做重复测量。一次十分钟窗口可能恰好避开拥塞，连续多个工作日的对应时段才更能区分偶然波动和稳定变化。若各轮样本数差异很大，应先解释中断、探针离线或采集缺口，再决定是否合并；不能用样本更多的一轮自动替代样本较少的一轮。保存原始结果后，还能重新计算不同分位或检查异常点，而不必依赖无法追溯的截图。

报告还应注明时钟同步、探测工具版本和超时阈值；这些条件改变时，应另起一组而不是与旧数据混算。

若平均值、中位数、高分位和丢包率都改善，而且多组同时段重复结果一致，才较有依据说这组探针与目标下更稳定。仍应保留路径、地区和应用层限制，因为网络测量不等于实际实验软件的任务成功率。

结论只覆盖测量真正观察到的范围

平均值变低是一个有用信号，却不是稳定性的完整证明。尾部决定少数最慢交互，丢包记录失败，延迟变化描述到达节奏，采样设计决定这些数字能否比较。漏掉任何一项，都可能把成功样本更快写成所有体验更稳定。

最终记录应保存原始结果、测量定义和样本数，再按小时汇总中心、尾部与丢包。结论限定在已观测探针、目标和时段，不替其他地区或全天作保证。这样下一次线路变化时，团队能够重做同一比较，而不是面对两个无法解释的平均数。

资料来源

• IETF / RFC Editor：《RFC 5481: Packet Delay Variation Applicability Statement》，发布或更新于 2009-03-01
• IETF / RFC Editor：《RFC 6703: Reporting IP Network Performance Metrics: Different Points of View》，发布或更新于 2012-08-01
• Google SRE / O'Reilly：《Monitoring Distributed Systems》，发布或更新于 2017-01-01