EP02：自建 CDN 的解决之道：PPCDN 架构总览

在 YouTube 打开

上集回顾	EP01《互动视频游戏的困境》：延迟悖论、被淘汰的 RTMP/HTTP-FLV、单点与主权悖论
下集预告	EP03《内容主权：自己可控，才是终极护城河》

0. 本集目标

看完这一集，观众应该能做到三件事：

1. 在白板上画出 PPCDN 的整体拓扑：推流端、Origin、Edge、观众、以及承担调度/信令的控制面各自在哪个位置。
2. 说清楚 PPCDN 架构面对 EP01 三个困境分别给出的工程回应——低延迟路径、实时协议选型、可控的分布式拓扑。
3. 说清楚"自建为什么能在性价比上反超大厂云服务"的三个具体工程原因，而不是只会说"自建更省钱"这句空话。

---

1. 架构总览：一张图看全貌

1.1 三层拓扑 + 一个控制面

PPCDN 的媒体链路只有三层，外加一个不碰媒体数据的控制面：

• 推流端：自研的 ppobs（基于 OBS Studio 深度定制），或任意标准 WHIP / SRT / ERTMP 推流端。
• Origin：接收推流的源站，是媒体数据进入系统的唯一入口。
• Edge（可多台）：从 Origin 回源，向观众分发；同一路流在同一 Edge 上被多个观众共享一条回源链路。
• ppcenter（控制面）：负责调度、鉴权、节点管理、P2P 信令、计费元数据和健康报告，不承载媒体数据、不代理媒体包。

控制面和媒体面彻底分开，是整套架构里最基础的一条设计原则，后面几乎所有"高可用"相关的结论都建立在这条原则之上。

1.2 为什么要把控制面和媒体面分开

如果调度、鉴权这些"决策逻辑"和音视频数据混在一条链路里，控制面抖一下，正在观看的观众也会跟着抖。PPCDN 的做法是让媒体包不经过 ppcenter：控制面主要参与连接建立、鉴权和调度，连接建立后媒体走独立链路，控制面故障不会中断正在进行的观看。 这从根本上缩小了故障域，也让媒体面可以独立、稳定地持续运行。

另一个前提是时钟同步。短期凭证的 iat/exp/txTime、跨端延迟埋点和故障判定都依赖时间：节点使用 NTP 等机制同步时钟并监控偏差，鉴权允许明确、有限的 clock-skew 容差。全网时钟以 ppcenter 为公共参照自洽，跨节点的时间戳相减才有意义。

---

2. 三个困境，分别怎么被回应

2.1 回应困境一（延迟悖论）：按解码能力智能选路的低延迟路径

EP01 讲过，Edge 路径多了一段服务器转发，时延还受编码、网络、恢复和缓冲策略共同影响。PPCDN 的架构回应是按播放端解码能力智能选路，并为 H264 客户端再开一条通常更短的 P2P 直连路径：

• 播放时按播放端解码能力分流：支持 HEVC 的客户端直接走 Edge 的 HEVC 流，同画质下 HEVC 通常比 H264 更省流量——本项目用离线 VMAF 在相同质量下实测过：NVENC 实时档约省 15%、软件编码约省 39%，幅度取决于编码器、预设和内容（EP20 给出完整数据与边界），这条路径还能避开 P2P 建连的首帧不确定性；同一个观众要么走 HEVC（直连 Edge），要么走 H264（可尝试 P2P），两项节省不叠加在同一个观众身上；不支持 HEVC 的客户端优先尝试 P2P 直连拉 H264。
• 走 P2P 时，ppcenter 先完成 NAT 资格判定并原子分配信令槽位（每路推流最多 3 路直连，这是平台默认值，可由管理员调整），双方再经 ppcenter 中继 SDP / ICE 建立直连——ppcenter 只转发信令，从不解析媒体。
• P2P 直连成功后，媒体直接从推流端送到观众，绕开 Origin / Edge，完全不占用边缘出口带宽，是延迟最低的路径。
• 任一环节未通过、超时或失败，立即干净回落到 Edge 的 H264 流，观众不会看到报错或黑屏。
• P2P 只使用推流端经过安全测算后的富余上行，一旦检测到上行拥塞立刻先牺牲 P2P，主推流永远优先。

这套逻辑在 EP13 会展开讲 NAT 穿透和资格判定的细节，这一集只需要记住一句话：先按解码能力选路，H264 能直连就直连，连不上就干净回落 Edge。

2.2 回应困境二（被淘汰的协议）：统一走 WHIP/SRT 入库、WHEP 播放

EP01 讲过 TCP 可靠有序字节流在丢包时可能发生队头阻塞。PPCDN 的架构回应是优先选择能按媒体时效控制恢复等待的实时传输栈：

• 推流侧支持 WHIP、SRT 与 ERTMP（Enhanced RTMP，存量 RTMP 设备的兼容入口，仍跑在 TCP 上）：WHIP / SRT 的典型路径走 UDP，能按媒体时效限制恢复等待，弱网下不会被 TCP 队头阻塞拖垮。
• 分发与播放统一用 WHEP，Edge 只提供低延迟 WebRTC 播放，不提供 HTTP-FLV 端点——这条约束在需求阶段就已锁定。
• 弱网下的应对不是"硬扛丢包"，而是主动降级：服务端按丢包率和往返时延（RTT）自动在 simulcast 档位间升降级，先降码率（不中断推流），码率降到底仍不达标才降分辨率（这一步才有短暂中断）。EP04、EP07 会展开讲传输协议对比和弱网抗性的具体机制。

2.3 回应困境三（单点与主权）：把故障域做小，把控制权留在自己手里

• Edge 层可水平扩展：Edge 可以部署多台，按节点池调度、优先导向剩余容量最大的节点；同一路流在同一 Edge 上被多个观众共享一条回源链路，单台 Edge 过载不会拖垮全局。
• Edge 具备自治能力：Edge 每次回源前向 ppcenter 动态解析 Origin 地址和短期媒体凭据（POST /internal/mmx/v1/origin/resolve），并把解析结果缓存在内存里——控制中心不可用时复用未过期缓存继续重连，媒体面不随控制面抖动而中断（docs/ppcdn-development-progress.zh-CN.md §3.5，状态"已完成"）。
• 控制面与媒体面分离：控制面故障不会中断正在进行的观看，媒体链路稳定持续。
• 内容主权：整套系统可自建、节点可控，推流到分发的全链路都掌握在自己手里，具体的主权取舍与合规策略见 EP03。

---

3. 框图

3.1 总体架构图

flowchart LR
    PPOBS["ppobs 推流端"] -->|"WHIP / SRT / ERTMP"| Origin["Origin"]
    Origin -->|"转发"| Edge["Edge 1..N"]
    Edge -->|"WHEP"| Viewer["观众浏览器"]

    PPC["ppcenter 控制面<br/>调度 · 鉴权 · P2P 信令 · 计费元数据 · 健康报告"]
    PPC -.->|"控制 / 信令"| PPOBS
    PPC -.->|"控制 / 信令"| Edge

    PPOBS ==>|"P2P 直连：H264 优先，失败回退 Edge<br/>（HEVC 直接走 Edge）"| Viewer

图示要点（口播提示）：注意控制面（ppcenter）画在链路上方，用虚线箭头连接——它只参与"建立连接"这一步的决策，不在媒体数据的路径上。媒体数据本身走下面这条实线链路，P2P 直连则是绕过 Origin/Edge、直接从推流端到观众的一条捷径。

3.2 播放选路决策图

flowchart TD
    A["观众发起播放请求"] --> B["pplayer 探测浏览器能否硬解 HEVC"]
    B -->|"支持 HEVC"| C["直接走 Edge<br/>追加 /hevc/whep 播放"]
    B -->|"不支持 HEVC"| D["优先尝试 P2P 直连拉 H264"]
    D --> E{"ppcenter 准入通过<br/>且有空闲信令槽位？"}
    E -->|"是"| F["中继 SDP / ICE 建立直连<br/>采用 P2P"]
    E -->|"准入未过 / 超时 / 建连失败 / 槽位已满"| G["干净回落到 Edge 的 H264 流"]

3.3 控制面与媒体面分离：控制面故障不影响媒体面

flowchart TD
    A["ppcenter（控制面）故障"] --> B["已建立的媒体会话继续稳定传输"]
    B --> C["控制面恢复"]
    C --> D["各端自动重新注册、重建租约"]

图示要点（口播提示）：控制面与媒体面彻底分离，控制中心故障不会中断正在进行的观看；控制面恢复后，各端重新注册并重建租约。这正是 PPCDN 能把故障域做小的关键设计。

---

4. 性价比：为什么自建能在成本效益上反超大厂云服务

前面几节讲的是"自建能不能做到低延迟、能不能控制风险"，这一节回答一个更现实的问题：同样投入下，为什么自建的性价比可以超过腾讯云快直播、华为云这类大厂云直播/RTC 服务？ 不是靠规模折价，而是靠三个大厂结构上很难复制的工程杠杆。

工程杠杆	大厂云服务的结构限制	PPCDN 的做法
定制推流端（ppobs）	推流端不在服务商控制范围内，两端两套代码	推流端与服务端同一套架构协同设计，端到端可编程
Simulcast 一次性多档	靠服务端转码，按输出档位单独计费	编码端一次编出多档，服务端只转发、不转码
pplayer + ppobs 协同直连	无法协同两端做资格判断与时间戳对齐	P2P 直连实测约 70ms

4.1 定制 ppobs：端到端全链路可优化，大厂拿不到这个杠杆

大厂云直播/RTC 服务通常只能优化"自己这一侧"——源站和边缘分发；推流端要么是客户自己接的通用 SDK，要么是标准 OBS，采集、编码、打点、QoS 策略都不在服务商的控制范围内，服务商和客户端是两个团队、两套代码。

PPCDN 的 ppobs 是深度定制的推流客户端，和服务端由同一套架构协同设计，能做到"买 SDK"模式做不到的联动优化：

• 码流内嵌入绝对时间戳（H.264/HEVC 用 SEI，AV1 用 metadata OBU），播放端据此算出真实端到端延迟——这需要改编码器/打包逻辑，不是配置项，通用 SDK 做不到。
• P2P 与主推流复用同一份编码，不为每个观众重复编码，节省推流端本地 CPU；同时对 P2P 和主推流做独立的发送队列与带宽预算隔离，保证"开 P2P 省钱"不会牺牲主播画质。
• 弱网降级（先降码率、不中断推流）由编码器和服务端协同触发，而不是服务端单方面限流猜测。

这些联动优化本质上是"端到端可编程"带来的增值：只有同时掌握两端，才能把整条链路当一个系统来调，而不是把两个黑盒简单拼接。

4.2 WHIP/SRT/ERTMP 同播：客户端一次编码出多档、多 codec，网络侧不用转码

多档画质（如 1080P/720P/360P 同播）在大厂云直播里通常靠服务端转码实现——腾讯云快直播的转码就是按输出档位单独计费，档位越多、时长越长，这部分开销越高，这是行业惯例，不是个例。

ppobs 用 WHIP / SRT / ERTMP 同播，在编码端一次性输出多档画质，还能同时发布 H264 与 HEVC 两条轨，服务端只做转发，不解码、不转码。对本来就要开多档的客户，免掉转码这一项能把总账单砍掉很大一块——在典型的云直播账单里，转码费可以占到一半左右（这是对账单结构的假设，具体以您的账单为准，EP20 把这笔账算清）；代价是多占一份推流方自己的上行带宽，PPCDN 不对上行计费。

4.3 ppobs + pplayer 协同直连：真实跑通约 70ms

P2P 直连能不能打通、时延能压多低，关键不只在"有没有 NAT 穿透库"，还在推流端和播放端能否协同做资格判断与时间戳对齐（见 §2.1、框图 3.2）。本项目 P2P 直连已经真实跑通，端到端时延约 70ms；走 Edge 分发的入库链路实测 WHIP 约 108ms、SRT 约 386ms（差异来自入库协议的接收窗口，不是编码格式）。

---

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

这一集的架构图回应了 EP01 的三个困境：按解码能力智能选路为 H264 客户端增加了一条更短的 P2P 直连路径，实时协议选型摆脱了 TCP 队头阻塞带来的积压风险，而控制面与媒体面分离、Edge 水平扩展把故障域做小、把控制权留在自己手里。PPCDN 用定制客户端、免服务端转码和端到端协同，做出了一套在低延迟、成本和可控性上都更有优势的自建方案（优势的大小和成立条件，EP20 逐项算清）。

下一集，我们先啃"主权"这一条——为什么"自己可控"是一条比性能参数更硬的护城河，以及自建和依赖第三方之间，到底应该怎么权衡。

---