EP01：互动视频游戏的困境¶

0. 本集目标¶

看完这一集，观众应该能回答两个问题：

我的互动直播/互动游戏项目，是不是也卡在延迟、旧协议生态和单点/主权这些困境里？
如果我的链路里还在用 RTMP 或 HTTP-FLV，弱网下会发生什么，为什么这不是危言？

这一集只摆出问题和可验证的事实，不给解药——解药是 EP02～EP20 的内容。

1. 三类真实困境¶

1.1 困境一：延迟悖论 —— 协议成熟度和业务实时性反着来¶

HLS/DASH 是最成熟的互联网视频分发方式，基于"切片再下载"，天然自带秒级延迟。对单向点播影响很小，对强互动场景则是结构性冲突：

场景	延迟敏感的原因	传统分片方案的后果
真人视讯 / 实时交易	互动窗口以秒计，画面必须与业务状态同步	用户看到的是过期画面，无法参与
在线竞拍 / 限时抢购	出价先后决定公平性，画面不能与业务状态脱节	时序错乱，产生争议
互动课堂	师生问答与练习需要即时反馈	互动退化为单向录播
社交连麦	对话依赖自然轮次	抢话、延迟叠加，体验不可用

改用通常基于 UDP 的实时协议（WebRTC/SRT）能不能自动解决问题？不能。端到端时延由采集、编码、网络排队与传播、丢包恢复、接收端抖动缓冲、解码和渲染共同决定；其中有些等待由参数约束，有些随网络和实现动态变化，不能把若干默认值简单相加当作实测结果，更不能把某个缓冲区参数当作整个协议的严格数学时延上界。

本项目已经确认的同口径实测数据如下。它们是 PPCDN 案例数据，不是 WebRTC、SRT 或某种编解码器对所有环境的保证值：

场景	实测端到端时延	口径说明
P2P 直连	约 70ms	真实链路跑通结果，媒体不经过 Origin/Edge 转发
入库 WHIP（经 Edge 分发）	约 108ms	当前实际拉流链路的测量结果
入库 SRT（经 Edge 分发）	约 386ms	当前实际拉流链路的测量结果

WHIP 与 SRT 的差异主要来自入库协议本身——SRT 的接收窗口（TSBPD）天然比 WebRTC 入库引入更多排队延迟，这是协议差异，不是编解码器差异：HEVC 目前不参与 P2P 直连，只走 Edge 分发，而编码格式本身并不是决定这组数字的变量。P2P 少一段服务器转发通常有利于降低时延，但最终结果仍取决于网络路径、NAT 穿透结果、编码器和播放器。协议名称只能说明可用机制，是否达到实时目标必须在统一埋点、统一起止点和时钟口径下实测。

1.2 困境二：一个正在被淘汰的协议 —— 弱网下的 RTMP/HTTP-FLV¶

1.2.1 一次已经发生的行业迁移¶

Adobe 于 2020 年 12 月 31 日正式终止对 Flash Player 的支持，随后主流浏览器陆续移除了 Flash 运行环境。RTMP（Real-Time Messaging Protocol）最初正是为配合 Flash Player 在浏览器中播放而设计的协议——它"浏览器原生播放"这条路径，事实上已经不存在了。
今天在浏览器里能看到的所谓"RTMP 直播"，播放环节实际用的已经不是 RTMP 本身，而是重新封装成 HTTP-FLV（容器换了，传输层仍是 TCP，浏览器仍需要 flv.js 之类的 JavaScript 库在客户端手动解封装）或者转码成 HLS/DASH（用分片下载换来播放兼容性，代价是牺牲实时性，见困境一）。
WHIP（WebRTC-HTTP 摄取协议）与 WHEP（WebRTC-HTTP 播放协议）在 IETF 标准化过程中逐步成熟，已被包括 OBS Studio 在内的主流推流软件和多家实时互动服务采纳为新一代推拉流协议，目标正是取代 RTMP 在"推流入口"这一环节的位置。
这不是单一厂商的技术偏好，而是过去几年浏览器能力、编解码标准和协议标准化共同推动的方向：播放侧的 RTMP/Flash 组合已经退场，入库侧的传统 RTMP 也在被 WHIP/SRT（以及能承载 HEVC 与多轨的 Enhanced RTMP）逐步替代。

1.2.2 技术根因：为什么弱网下是灾难，而不是夸张¶

RTMP 和 HTTP-FLV 都构建在 TCP 之上。TCP 提供的是"有序、完整"的字节流交付：任何一个包丢失，都必须等它重传成功后，才能把后面已经到达、但排在它后面的数据交给上层——这就是队头阻塞（Head-of-Line Blocking），是 TCP 协议本身的设计特性，不是某个实现的缺陷。

在弱网（有一定丢包率）环境下，这个特性会造成级联式的后果：

一个包丢失 → 触发重传，至少多等一个网络往返（RTT）；
重传期间，后面已经到达的音视频数据全部被阻塞在缓冲区里，不能播放；
丢包持续或多次重传叠加 → 阻塞时长可以从几十毫秒累积到秒级甚至更高，且没有理论上界；
播放器缓冲区被填满或耗尽 → 表现为卡顿、追帧，严重时触发断线重连。

这与常见 WebRTC/SRT 实现的取舍不同：应用可以根据包的时效性限制重传等待，并在数据过期后丢弃，以避免为了完整性持续积压。SRT 由 ARQ、TSBPD 和过期包丢弃等机制共同完成这件事；WebRTC 则由 RTP/RTCP 反馈、拥塞控制、抖动缓冲和解码器丢帧策略共同作用。两者都没有脱离网络、配置和实现条件的严格数学延迟上界：拥塞、排队、断网、重连或实现策略仍可能让时延显著增长。

一句话说明取舍：TCP 字节流优先可靠、有序交付，丢包会造成队头阻塞；实时媒体栈可以按时效放弃过期数据，通常更容易控制时延，但不是无条件的上界保证。

1.2.3 协议对比¶

维度	RTMP / HTTP-FLV	SRT	WebRTC（WHIP / WHEP）
传输层	TCP	UDP + ARQ	通常为 UDP + RTP/RTCP，也可回退到 TURN/TCP/TLS
丢包时的处理方式	TCP 必须可靠、按序交付，可能产生队头阻塞	ARQ 请求重传；TSBPD 按时间交付；配置过期包丢弃时可放弃迟到数据	NACK/FEC 是否使用取决于协商和实现；接收端可丢弃过期帧
弱网下的时延特征	排队和重传可能累积到秒级甚至断流	可通过 latency 等参数做工程约束，但无无条件数学上界	抖动缓冲和拥塞控制动态调整，无无条件数学上界
浏览器原生播放	已不支持（依赖已停更的 Flash Player）	不支持（通常需服务端转换协议）	原生支持，标准 Web API
当前定位	历史遗留协议，正在退出播放环节	弱网上行的现代选择	主流实时播放协议

1.2.4 一个具体的架构选择¶

这不是抽象讨论——本项目当前公开的技术说明写得很清楚：推流侧支持 WHIP、SRT 与 Enhanced RTMP（ERTMP）三种入库协议（本集 §1.1 的 SRT 入库实测数据正是 SRT 这条路径），播放侧统一使用 WHEP，并明确不提供 HTTP-FLV 播放端点。换句话说，"不提供 HTTP-FLV"不是遗漏，而是在协议选型阶段就锁定的约束，SRT 的存在也不矛盾——它解决的是弱网上行的鲁棒性；ERTMP 同样不矛盾——它只是让存量 RTMP 设备能接入同一套多轨同播（仍跑在 TCP 上，不承诺低延迟，见 EP04），播放侧依然只走 WHEP。这类约束在成熟的实时互动系统里越来越常见，是本节讨论的"行业迁移"在具体项目里的体现。

1.3 困境三：单点与主权悖论 —— 越省事，越把命脉交出去¶

除了协议层面的困境，真实项目里还有两条同样重要、但不体现在延迟数字里的结构性风险：

单点故障：源站（Origin）通常只有一份，是全部推流的唯一入口。一旦故障，后果不是"降级"，而是全链路中断——所有观众同时失去画面。这不是理论推演：架构设计文档把"Origin 推流断开"列为一种已知故障模式，而且不是自动无缝切换——必须等推流端重新发布到一个新 Origin，所有观众才能恢复。这正是很多真实互动直播项目当下架构里客观存在的风险点，也是后续需要认真做取舍的地方——一个单点到底值不值得投入去消灭，是一笔要算清楚的工程账，不是"有单点就必须消灭"的教条。
内容主权：为了减少工程投入，一些团队会把直播分发外包给单一第三方服务，甚至把它当作"备用兜底"线路。这看起来是双重保障，实际上把业务连续性交给了一个自己无法控制的第三方——对方的限流策略、服务调整或跨境合规要求的变化，都可能直接影响业务的可用性，而自己在这类决策上没有话语权。

这两条困境目前在大多数互动直播项目的讨论中还是空白项——很少有人系统评估过一个单点到底值不值得投入去消灭，也很少有人讲过内容主权这件事该如何权衡（EP03 会展开）。这一集只是先把这两个风险点指出来。

2. 框图¶

2.1 端到端时延组成：不能用默认值代替实测¶

flowchart LR
  A[采集] --> B[编码] --> C[发送队列] --> D["网络传播 / 排队 / 丢包恢复"] --> E["接收端重排与抖动缓冲"] --> F[解码] --> G[渲染]

上述各项会重叠或动态变化，不能把配置值机械相加。PPCDN 同口径实测值：

链路	实测端到端时延	说明
P2P 直连	约 70ms	媒体不经过 Origin/Edge 转发
入库 WHIP（经 Edge 分发）	约 108ms	当前实际拉流链路
入库 SRT（经 Edge 分发）	约 386ms	接收窗口引入更多排队

（差异来自入库协议的接收窗口，不是编码格式——HEVC 目前不参与 P2P 直连）

图示要点（口播提示）：先统一测量起止点和时钟，再看各阶段埋点。网络、编码器和缓冲策略都可能成为瓶颈；不能仅凭一个 RTP 包数、SRT latency 参数或播放器目标缓冲值反推端到端时延。

2.2 协议定位三角：时延、弱网鲁棒性、生态兼容性，一个协议同时占全三个角很难¶

                    时延最低
                   ╱        ╲
                  ╱ WebRTC    ╲
                 ╱ (WHIP/WHEP) ╲
                ╱________________╲
     弱网鲁棒性最强 ──────────── 生态兼容性最好
        (SRT，用重传窗口          (RTMP 曾靠 Flash
         换弱网下的可用性)         播放器统一天下；
                                  Flash 停更后，
                                  这个角已经塌了)

图示要点（口播提示）：RTMP 历史上的优势正是"生态兼容性"这一角——几乎所有浏览器都能通过 Flash 播放它。Flash 停更之后，这个角对 RTMP 已经不再成立，而它在"弱网鲁棒性"这一角上（见 §1.2.2 的队头阻塞分析）本来就没有上限保证。这就是"RTMP/HTTP-FLV 正在被淘汰"这个判断的图形化解释：不是被某个竞品打败，是自己原本唯一的优势角塌了。

2.3 弱网丢包处理对比：队头阻塞 vs 按时效放弃¶

flowchart TB
  subgraph TCP["RTMP / HTTP-FLV（TCP）"]
    direction TB
    T1["帧1 帧2 帧3（丢包）帧4 帧5…"] --> T2["TCP 要求按序 + 完整交付"] --> T3["帧4、帧5 排队等帧3 重传成功才能交付"] --> T4["重传 ≥ 1 个 RTT，弱网下可叠加到秒级，无理论上界"] --> T5["播放器缓冲区被占满 → 卡顿 / 追帧 / 断线重连"]
  end
  subgraph RT["SRT / WebRTC（实时媒体策略，典型 UDP 路径）"]
    direction TB
    R1["帧1 帧2 帧3（丢包）帧4 帧5…"] --> R2["按协议和实现策略尝试重传、纠错或等待重排"] --> R3["数据过期后可放弃恢复，避免继续积压"] --> R4["以局部画质损失换取更可控的时延"]
  end

2.4 真实项目架构现状：单点与第三方依赖¶

flowchart TD
  Pub["推流现场 · 长时间在线"] -->|入站接收| O["Origin 源站<br/>唯一入口，单点，故障 = 全链路中断"]
  O -->|内部网络转发| E["Edge 1 … Edge N"]
  E -->|出站分发| V["观众 / Internet"]
  O -. 备用线路 .-> T["第三方云厂商直播服务<br/>业务连续性依赖第三方决策"]

图示要点（口播提示）：这张图对应的是一个真实互动直播项目当下的分发架构结构，不是理论推导。困境三的两条风险在图上都能对号入座——Origin 是唯一入口（单点风险）、备用线路挂在第三方云厂商身上（主权风险）。这也是这门课要从"困境"讲起，而不是直接讲方案的原因。

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

这一集看到的几类困境，可以归成一句话：面向单向观看优化的传统直播链路，不能直接假定满足实时互动目标。动态或配置的缓冲、TCP 队头阻塞、架构里的单点和第三方依赖，都需要结合场景测量和取舍，而不能只凭协议名称下结论。

下一集，我们开始拆 PPCDN 具体怎么从架构上应对这些困境——P2P 优先尝试、失败顺序回退 Edge 的播放决策、按媒体时效控制弱网积压的策略，以及怎么把关键链路留在自己手里。