EP09：时延稳定性，比平均延迟更重要¶

上集回顾	EP08《视频埋点：如何量出端到端延迟》
下集预告	EP10《如何量化视频质量》

0. 本集目标¶

看完这一集，观众应该能做到两件事：

说清楚为什么"平均延迟"是一个会撒谎的指标，以及应该看哪些统计量才能反映真实体验。
理解本项目里好几处看起来"和延迟无关"的设计，其实都是在为稳定性买单——抖动缓冲区、P2P 的连接预算、SLA 的百分位阈值，本质上都是同一件事。

1. 开场钩子（逐字稿要点）¶

EP08 讲了怎么把延迟这个数字测出来。这一集讲一个更容易被忽略的问题：测出来一堆延迟数字之后，应该看哪个统计量？如果只看平均值，很可能会得出一个和观众实际体验完全对不上的结论。

2. 为什么平均值会撒谎¶

假设一路直播，99% 的时间延迟是 100ms，剩下 1% 的时间因为一次网络抖动飙到 5 秒——平均下来大概是 149ms，看起来是一个相当不错的数字。但观众的真实体验是什么？观众会记住那 1% 的时间，画面卡死了一下，而不会因为另外 99% 的时间"只有 100ms"而觉得体验多好。平均值把一次剧烈的卡顿，稀释成了一个看起来无害的小数字，这个卡顿本身却完全没有消失。

这在分布式系统和实时媒体领域是一个有名字的问题：长尾延迟（tail latency）——真正影响用户体感和投诉率的，往往不是"大多数时候有多快"，而是"最差的那一小部分有多差、多频繁"。平均值恰恰是对长尾最不敏感的统计量，因为极端值会被大量正常样本"平均"掉，这正是它会撒谎的原因。

3. 百分位数：P50、P80、P95、P99 分别在说什么¶

正确的做法是看百分位数，而不是平均值：

P50（中位数）：一半的样本比这个数快，一半比这个数慢。它天然抗极端值干扰——哪怕 1% 的样本飙到 10 秒，P50 也几乎不受影响，能代表"典型情况下"的体验。
P80/P95/P99：分别表示约 80%/95%/99% 的样本不超过该值，也就是约 20%/5%/1% 的样本更慢。它们描述尾部开始出现的位置，不等同于尾部最差值；判断极端体验时还应同时看 P99.9、最大值和超阈值比例。

这不是一个假想的例子——这组阈值和判定顺序就是本项目当前生产环境里真实在跑的 P2P 延迟 SLA（ppcenter/internal/ws/play_hub.go 的 p2pSLAP80TargetMs=300、p2pSLAP80MaxMs=600、p2pSLAP99WarnMs=1000、p2pSLAP99MaxMs=2000）：P80 目标 ≤300ms、可接受上限 ≤600ms；P99 上限 ≤2s，按北京时间自然日聚合 path=p2p 的样本后判定。状态必须互斥，避免同一组数据同时命中 pass 和 warn：先判 fail（P80>600ms 或 P99>2s），再判 pass（P80≤300ms 且 P99≤1s），其余有效数据统一为 warn。这组判定顺序本身就在解决一个文档表述上的小陷阱：如果直接按"P80≤300 且 P99≤2000"判 pass，会和"P99 在 1000~2000ms 之间判 warn"的区间重叠，必须靠先 fail、再 pass、剩下才是 warn 的顺序把两者分开，不能把三条规则当成互相独立的三个判断来并行执行。

即便阈值是真实生产值，它仍然只是当前的业务决策，不是协议常数——换一个业务目标、换一批样本基线，这组数字本身也应该被重新校准；而且这组判定目前只用于后台展示和可选告警（AppLatencyDaily.slaStatus），不触发任何赔偿，官网近期的文案也已经把对外的"P2P 延迟 SLA"措辞收窄为更谨慎的"视频指标监控"，避免被解读成一份承诺。统计周期、最小有效样本数和无效样本处理这几条仍然需要单独规定，不能假设阈值一确定就自动覆盖了这些边界。

4. 抖动缓冲区：把"不稳定"换成"稳定"的核心手段¶

网络传输的延迟从来不是一个恒定值——排队、瞬时拥塞、路由抖动，都会让包的到达时间参差不齐，这种参差不齐就是"抖动"（jitter）。EP04 讲过 SRT 的 TSBPD 接收窗口、WHIP 的重排缓冲区，当时的角度是"怎么处理丢包"；换一个角度看，这两个机制做的其实是同一件事的另一半：故意让数据在缓冲区里多等一小会儿，把参差不齐的到达节奏，拉平成一个固定、可预测的播放节奏。

这笔交易很直接：增加等待预算可以吸收更多到达抖动，但也会增加播放延迟。现代实时媒体的 jitter buffer 通常不是固定时长，而是根据到达抖动、丢包/重传、帧率、解码耗时和延迟目标动态伸缩；网络转稳时收缩，抖动增大时扩张。

pplayer 这一侧的默认行为是一个具体例子：如果没人显式指定缓冲长度，它不会去设置任何固定的 jitterBufferTarget/playoutDelayHint，而是直接让浏览器自己那套持续自适应的 jitter buffer 接管——"没有指定"在这里被当作"让浏览器自己判断"，不是悄悄套用某个默认数值。只有当观众通过 ?bufferMs= 显式要求一个固定缓冲长度时，才会用这个值覆盖浏览器的自适应行为，取值范围被钳制在 [100, 1000] 毫秒之间（pplayer/buffer-config.mjs 的 MIN_BUFFER_MS/MAX_BUFFER_MS）。换句话说，"动态伸缩"不是一句抽象描述，而是默认路径本身的真实行为；固定缓冲是观众主动选择放弃动态伸缩后才会发生的例外。

评价 jitter buffer 不能只看平均延迟，还要同时看目标延迟、实际缓冲时长、迟到丢弃、卡顿和恢复速度，避免把"延迟稳定"误判为缓冲越大越好。

5. 连接预算是"愿意等多久才认输回退"，不是首帧上限¶

早期版本里 P2P 和 Edge 是并行"双路竞速"：两条路径同时建立，谁先出帧就用谁，用一个 500ms 窗口限制"为候选路径等待多久"。这套并行竞速已经被替换成顺序模型：播放决策现在提前在服务端做分支（docs/design/ppcdn-architecture-design.zh-CN.md §6.2）——HEVC 客户端直接拿到 edge-only，从一开始就不尝试 P2P；H264 且满足 NAT 资格的客户端拿到 p2p-connect，单独尝试 P2P，Edge 地址只作为失败后的顺序回退，不会和 P2P 同时建立。pplayer 源码里旧版"双路竞速"的实现函数还留着，但注释直接写明"kept for rollback ... no longer wired to the play decision"；服务端下发的 raceWindowMs/connectTimeoutMs 字段也还在响应里（兼容旧客户端），但当前客户端的注释写着"described the old symmetric race and no longer apply"——字段没删，但不再被用来做路径选择。

当前真正生效的时间预算也变成了两个不同量级的数字：等待推流端应答 SDP offer 最多 5 秒（P2P_HANDSHAKE_TIMEOUT_MS，纯信令往返，和建连、解码无关）；SDP 换完之后再给 max(4000, connectTimeoutMs + 2000) 毫秒（默认即 4 秒起）的宽限期等第一帧真正解出来，超时才回退到 Edge（pplayer/main.js 的 graceMs）。数字比旧的 500ms 大了一个量级，但背后的教训是同一条：这是"愿意为 P2P 等多久才认输回退"的预算，不是首帧一定会在这个时间内出现的承诺——DNS、鉴权、ICE、Edge 建连、关键帧等待、解码和渲染仍然都在这个预算之外独立发生。应该分别观测"路径决策/回退耗时"和"首帧耗时"，并为首帧单独制定 SLA，不要把前者的数字当成后者的上限。

6. 框图¶

6.1 同一组数据，平均值和百分位数讲出两个故事¶

一组延迟样本（100 次播放的首帧耗时）：
98 次 100ms，2 次 5000ms

【看平均值】
(98 × 100 + 2 × 5000) / 100 = 198ms
   → 结论："体验相当不错"

【看百分位数】
P50 = 100ms   → 典型体验确实不错
P99 = 5000ms  → 最慢的尾部已经进入 5 秒区间
   → 结论："大多数人没问题，但确实存在明显长尾"

同一组数据，平均值把长尾"平掉"了，百分位数把它显性地摆出来

6.2 抖动缓冲区：拿固定延迟换稳定节奏¶

【没有缓冲区：包的到达时间参差不齐】
包1(10ms) 包2(80ms) 包3(15ms) 包4(120ms) 包5(20ms) ...
   │
   ▼
播放节奏忽快忽慢，画面时而流畅时而卡顿

【有自适应缓冲区：按当前抖动估计安排播放】
包1 包2 包3 包4 包5 ... 在缓冲区里等到各自的"计划播放时刻"
   │
   ▼
播放节奏趋于稳定；目标缓冲会随网络状态扩张或收缩

代价：增加一定延迟       收益：减少迟到丢帧和卡顿

6.3 SLA 判定：为什么按 P80/P99 分档，不按平均值¶

每天的 P2P 延迟样本
        │
        ▼
   计算 P80 和 P99（不是平均值）
        │
先判 fail：P80>600ms 或 P99>2s
        │ 否
        ▼
再判 pass：P80≤300ms 且 P99≤1s
        │ 否
        ▼
其余为 warn（各状态互斥）

（哪怕平均延迟很低，只要 P99 表现差，也不会判定为 pass）

7. 结尾与下集预告（逐字稿要点）¶

这一集的核心就一句话：稳定性问题不能用平均值回答，要看定义清楚的百分位和尾部样本。jitter buffer 应动态平衡延迟与卡顿，P2P 的连接预算只是"愿意等多久才回退"，不是首帧上限，SLA 状态也必须设计成互斥并明确样本口径。

下一集，我们从"延迟稳不稳"转到另一个同样容易被平均值误导的话题——怎么量化视频质量。