9.1.2 端到端延迟：从采集到视网膜

9.1.1 的接力跑完了，现在要给它掐表。可 "延迟多少" 这个问题，比听上去狡猾——推流端说我的 RTMP 只有两秒，播放器说我的缓冲只有一秒，观众却骂骂咧咧地说慢了半分钟。谁都没撒谎，只是掐的不是同一段表。要给延迟一个严肃的定义，得先把起点与终点钉死。

glass-to-glass：把表掐在两块玻璃之间

IETF 的运营指南 RFC 9317 给出了权威定义：流媒体延迟是 glass-to-glass（玻璃到玻璃） 时长——从现实事件发生（镜头这块玻璃），到流媒体在终端设备上恰当地播放出来（屏幕那块玻璃）的全程时滞 [1]。

这个定义有两个容易被忽略的深意。其一，它不等于网络延迟：编解码、缓冲、乃至 CDN 摄入分发的耗时全部计入——RTT 只是其中一小段，端到端延迟是全链路各环节延迟之和 [1]。其二，它把测量的锚点钉在了内容上而非报文上——这正是 9.3 实战里条码测延法的设计依据：不靠抓包时间戳，而是让摄像机去拍一个秒表，再看屏幕上显示的秒表读数差。

延迟的四级世界

同样是 "直播"，产品对延迟的胃口天差地别。RFC 9317 按目标延迟把流媒体应用分成四级 [1]：

分级表的价值不在记数字，而在看清朝哪一级迈步要付出什么。超低延迟难在物理：1 秒与常见的网络波动同量级——bufferbloat、Wi-Fi 纠错、包重排，任何一阵妖风都能把它吹破，追求它的代价往往是更频繁的用户可见瑕疵 [1]。低延迟直播难在账本：更高成本、更低画质、ABR 档位收缩，且对瞬时波动更敏感；RFC 里那个经典反面案例几乎人人都遇过——球赛进球，邻居的欢呼先到，你的屏幕还在中场倒脚 [1]。

CMAF 的解耦：延迟与画质的离婚协议

压延迟最直觉的手段是缩短分片：6 秒分片压到 2 秒，延迟立省。可第七章埋过一个隐患——分片越短，关键帧越密，编码效率越差（6.6 的 GOP 消融实测过 I 帧之贵）。延迟与画质，被分片时长捆成了一对冤家。

RFC 9317 给出的现代解法，正是 7.4.5 实测过的那套：CMAF chunk 让延迟与分片时长解耦 [1]。分片照旧做长（保住 GOP 长度与编码画质），传输却按小块流式下发——LL-HLS 逐 chunk 一个 GET，LL-DASH 用 chunked transfer 单 GET 持续推送 [1]。我们在 7.4.5 抓包里数过的那些 moof+mdat 小对，就是这份 "离婚协议" 的字据：长分片保画质，小 chunk 保延迟，各论各的。

小结：延迟是一条链，不是一个点

回到开头的掐表纠纷：推流端、缓冲、观众说的都对，只是各自掐了链路的一段。glass-to-glass 把所有段拧成一根绳，四级分类给每类产品定好目标档位，CMAF 则解开了延迟与画质最紧的那个死结。延迟有了全貌，下一个问题接踵而至：这条链上的每个环节，坏起来各是什么模样？9.1.3，角色与故障域。