9.1.4 协议在链路两端的分工：为什么两端不说同一种语言

9.1.1 的接力地图上藏着一个耐人寻味的细节：同一场直播，推流端说的是 RTMP 或 SRT，拉流端说的却是 HLS、HTTP-FLV 或 WebRTC——链路两端从来不用同一种语言。这不是历史巧合，而是两段旅程的客源结构根本不同。第七章按编年史逐个解剖过这些协议（7.5.4 的全景对照表），本节换一个问法：把它们按链路位置重新排座次，看看位置如何决定选择。

推流侧：一对一的远行，可靠性压倒一切

推流是一路流、一条连接、一段最不可控的WAN。它的处境决定了协议的选型逻辑：

• 连接是独享的：一对一的会话，状态维护的成本只有一份——RTMP 的 Chunk 流状态机（7.3.3）、SRT 的 ARQ 重传窗口（7.5.3），这些 "有状态" 的设计在推流侧毫无负担
• 网络是不可控的：场馆到源站跨越公网，丢包抖动是家常便饭——可靠性必须压倒一切，SRT 宁可加延迟也要把包重传到位，因为源头丢一帧，下游千万人同看花屏（9.1.3 的全员同病）
• 并发是微不足道的：源站接收的推流路数，比起拉流洪峰只是零头——HTTP 化的分发效率在这里毫无用武之地

一言以蔽之：推流侧买得是确定性——用一切工程手段保证码流完整准时地进站，贵一点、重一点都认。

拉流侧：一对百万的洪峰，可缓存性压倒一切

拉流侧换了一本账：同一份内容要分发给千万观众，协议的对手不再是网络质量，而是并发规模：

• 连接是海量的：每一路播放都是独立会话，源站绝无可能为千万观众维护千万份状态——无状态、可缓存成了硬性要求，恰是 HTTP 系协议（HLS/DASH）的看家本领：分片即静态文件，CDN 缓存即无限扩容（7.4.1 把直播搬进 HTTP 的全部理由）
• 状态被赶到了边缘：连接管理的复杂度没有消失，而是被外包给了 CDN 边缘节点——源站只见稀疏回源，边缘扛下洪峰（9.1.1 的漏斗隐喻在协议层的落点）
• 延迟需求是分级的：能忍十几秒的走传统 HLS，要秒级的走 HTTP-FLV 或 LL-HLS，要亚秒互动的走 WebRTC——9.1.2 的四级延迟表，在拉流侧就是一张协议选票

拉流侧买得是可伸缩性——宁可牺牲一点延迟与状态能力，也要换来 CDN 这台印钞机般的分发杠杆。

源站：双语种的翻译官

两端语言不通，总要有人翻译——这个角色还是源站。它用 RTMP/SRT 的协议接住推流，转成 HLS 的分片与播放列表交给 CDN，再把实时性要求高的流量转给 FLV/WebRTC 的出口。源站的本质是一座协议转换桥：桥这头是确定性的世界，桥那头是可伸缩的世界。理解了源站的翻译官角色，7.5.4 那张编年全景表就有了第二层读法——协议的编年史，同时是链路两端分工不断细化的历史。

小结：位置即立场

9.1 四节至此闭环：旅程给出了链路的地形，延迟给出了掐表的标尺，故障域给出了排障的地图，协议分工给出了这一切背后的结构性理由——推流买确定性，拉流买可伸缩，源站在中间当翻译。每个环节的选择，都不是技术的任性，而是位置的立场。

地图画完了，接下来要学会读图说话：链路上的体验好坏，如何变成可度量、可监控、可归因的数字？9.2，流分析与质量监控。