9.1.1 一场直播的完整旅程：七站接力

流媒体链路（Streaming Pipeline） 是指音视频内容从采集端到播放端所经过的完整处理与传输路径。一场球赛从场馆里的真实瞬间，到千万块屏幕上的画面，中间要经过的正是这样一条链路。前八章我们分别深入过链路上的若干环节，本节把它们串成一张全程地图。按数据流向划分，可以看作七站接力：

第一、二站：采集与推流

采集与推流负责把现场送出场馆。摄像机与麦克风完成光电转换，导播台完成切换与包装，编码器把信号压缩为 H.264/AAC 码流（即第六章介绍的编码规格）。接下来是第一段网络传输：从场馆到源站。这一段通常是全链路中网络条件最不可控的部分，场馆专线、酒店 Wi-Fi、主播的手机热点都有可能遇到。第七章介绍的传输协议在这里各司其职：RTMP 以简单成熟长期占据主播推流的主流位置，SRT 则依靠 ARQ 重传机制应对跨地域弱网回传（详见 7.5.3）。因此，推流段的核心目标可以概括为一句话：把码流完整、稳定地送入源站。

第三站：源站

源站（Origin Server） 是整条链路的中枢，负责接收各路推流、登记流的身份、向后方分发。它处理的并不只是 "一路流"，而是每一路流的一本账：从哪里推上来，供哪些转码模板使用，向哪些 CDN 分发。由于观众规模再大，推流端也只与源站建立一次连接，并发压力便在这一站被吸收。这也是源站存在的首要理由。

第四站：转码集群

源站收到的原始码流通常只有一路高码率版本，而观众的设备性能与网络条件千差万别。因此需要转码集群把原始流改制为一条 ABR 阶梯（Bitrate Ladder）：1080p/720p/480p 等多档码率与分辨率并行产出，7.4.4 介绍的自适应切换才有档可选。这里是全链路算力消耗最大的环节：第六章的编码知识被放大为数千路并行的工程问题，档次如何划分、硬编还是软编、关键帧对齐如何保证切换无缝，每一个问题都对应着成本与体验之间的权衡。

第五、六站：CDN 与边缘节点

分片与播放列表（即 7.4 介绍的 HLS 机制）从源站出发，进入 CDN 分发网络。CDN 的思路与 8.2.3 介绍的缓冲策略本质相同：用空间换时间。把热门分片预先缓存到离观众一跳之遥的边缘节点，观众取数就不必长途回源。千万级并发由此化解：源站只需应对 CDN 回源的稀疏请求，真正的流量洪峰由边缘节点群承担。

第七站：拉流播放

从边缘节点到播放器是观众的最后一公里，也是协议的换乘站：HLS 凭借对 CDN 友好的特性占据最大份额，HTTP-FLV 在互动直播场景中提供更低的延迟，WebRTC 则把实时互动的延迟压到亚秒级（详见 7.5.2）。第八章搭建的播放器在这里承担最终环节：解封装、解码、同步、渲染，把链路的终点变成观众眼中的画面。

回看整条链路，可以用两个隐喻帮助记忆。其一是漏斗：上行方向越走越宽，一路推流进入源站，千万路拉流从边缘节点流出，源站与 CDN 的作用就是保证漏斗的颈部不被并发冲垮。其二是账本：每一站都会在码流上留下处理记录，转码改变档次，分片改变包装，边缘缓存改变路径，9.2 将要介绍的监控体系，读取的正是这本接力账。链路各站的职责划分，本质上是对并发、算力与延迟三者的分配。

那么，这条链路跑完需要多长时间呢？9.1.2 我们来分析端到端延迟。