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

一场球赛从场馆里的真实瞬间，到千万块屏幕上的画面，走的是一条七站接力。前八章我们分别以 "当事人" 的视角拜访过其中几站——现在把她们串成一张全程地图：

第一、二站：采集与推流——把现场送出场馆

摄像机与麦克风完成光电转换，导播台完成切换与包装，编码器把信号压成 H.264/AAC 码流（第六章的手艺）。接下来是第一段网络旅程：从场馆到源站。这一段是全程网络条件最不可控的一跳——场馆的专线、酒店的 Wi-Fi、主播的手机热点，什么都可能是路况。第七章的协议群像在这里各就各位：RTMP 以简单成熟坐镇主播推流的老位，SRT 以 ARQ 重传专治跨地域弱网回传（7.5.3）。推流段的使命只有一个：把码流完整地送进可靠的车站。

第三站：源站——链路的总调度

源站（Origin）是整条链路的中枢：接收各路推流、登记流的身份、向后方分发。它处理的并非 "一路流"，而是 "一路流的一本账"——谁推上来的、给哪些转码模板用、向哪些 CDN 分发。观众规模再涨，推流端也只跟源站打一次交道，压力被这一站拦下，这是它存在的首要理由。

第四站：转码集群——一份原料，多档产品

源站收到的原始码流通常只有一路高码率版本，可观众的设备与网络千差万别。转码集群把这份原料改制成一条 ABR 阶梯：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，端到端延迟。