EP02：自建 CDN 的解决之道：PPCDN 架构总览¶
| 上集回顾 | EP01《互动视频游戏的困境》：延迟悖论、被淘汰的 RTMP/HTTP-FLV、单点与主权悖论 |
|---|---|
| 下集预告 | EP03《内容主权：自己可控，才是终极护城河》 |
0. 本集目标¶
看完这一集，观众应该能做到两件事：
- 在白板上画出 PPCDN 的整体拓扑：推流端、Origin、Edge、观众、以及承担调度/信令的控制面各自在哪个位置。
- 说清楚 PPCDN 架构面对 EP01 三个困境分别给出的工程回应——低延迟路径、实时协议选型、可控的分布式拓扑。
- 说清楚"自建为什么能在性价比上反超大厂云服务"的三个具体工程原因，而不是只会说"自建更省钱"这句空话。
1. 开场钩子（逐字稿要点）¶
上一集我们拆了三个困境：链路各环节累积且动态变化的延迟、逐步退出浏览器播放生态的 RTMP/HTTP-FLV、以及单点和第三方依赖。这一集不再摆问题，我们把 PPCDN 的整体架构图画出来，看看它如何回应这三个困境。
2. 架构总览：一张图看全貌¶
2.1 三层拓扑 + 一个控制面¶
PPCDN 的媒体链路只有三层，外加一个不碰媒体数据的控制面：
- 推流端：自研的
ppobs（基于 OBS Studio 深度定制），或任意标准 WHIP/SRT 推流端。 - Origin：接收推流的源站，是媒体数据进入系统的唯一入口。
- Edge（可多台）：从 Origin 回源，向观众分发；同一路流在同一 Edge 上被多个观众共享一条回源链路。
- ppcenter（控制面）：负责调度、鉴权、节点管理、P2P 信令、计费元数据和健康报告，不承载媒体数据、不代理媒体包。
控制面和媒体面彻底分开，是整套架构里最基础的一条设计原则，后面几乎所有"高可用"相关的结论都建立在这条原则之上。
2.2 为什么要把控制面和媒体面分开¶
如果调度、鉴权这些"决策逻辑"和音视频数据混在一条链路里，控制面抖一下，正在观看的观众也会跟着抖。PPCDN 的做法是让媒体包不经过 ppcenter：控制面主要参与连接建立、鉴权和调度，连接建立后媒体走独立链路，控制面故障不会中断正在进行的观看。 这从根本上缩小了故障域，也让媒体面可以独立、稳定地持续运行。
另一个前提是时钟同步。短期凭证的 iat/exp/txTime、跨端延迟埋点和故障判定都依赖时间：节点使用 NTP 等机制同步时钟并监控偏差，鉴权允许明确、有限的 clock-skew 容差。全网时钟以 ppcenter 为公共参照自洽，跨节点的时间戳相减才有意义。
3. 三个困境，分别怎么被回应¶
3.1 回应困境一（延迟悖论）：按解码能力智能选路的低延迟路径¶
EP01 讲过，Edge 路径多了一段服务器转发，时延还受编码、网络、恢复和缓冲策略共同影响。PPCDN 的架构回应是按播放端解码能力智能选路，并为 H264 客户端再开一条通常更短的 P2P 直连路径：
- 播放时按播放端解码能力分流：支持 HEVC 的客户端直接走 Edge 的 HEVC 流，同画质下 HEVC 通常比 H264 更省流量——"省约 30%"是行业和项目内部常引用的一个待验证的区间假设中心值，不是本项目已实测验证的固定数字（EP20 会展开实测方法与边界），但这条路径确实能避开 P2P 建连的首帧不确定性；不支持 HEVC 的客户端优先尝试 P2P 直连拉 H264。
- 走 P2P 时，ppcenter 先完成 NAT 资格判定并原子分配信令槽位（每路推流最多 3 路直连，这是平台默认值，可由管理员调整），双方再经 ppcenter 中继 SDP / ICE 建立直连——ppcenter 只转发信令，从不解析媒体。
- P2P 直连成功后，媒体直接从推流端送到观众，绕开 Origin / Edge，完全不占用边缘出口带宽，是延迟最低的路径。
- 任一环节未通过、超时或失败，立即干净回落到 Edge 的 H264 流，观众不会看到报错或黑屏。
- P2P 只使用推流端经过安全测算后的富余上行，一旦检测到上行拥塞立刻牺牲 P2P，主推流的画质和带宽预算绝不受影响。
这套逻辑在 EP13 会展开讲 NAT 穿透和资格判定的细节，这一集只需要记住一句话：先按解码能力选路，H264 能直连就直连，连不上就干净回落 Edge。
3.2 回应困境二（被淘汰的协议）：统一走 WHIP/SRT 入库、WHEP 播放¶
EP01 讲过 TCP 可靠有序字节流在丢包时可能发生队头阻塞。PPCDN 的架构回应是优先选择能按媒体时效控制恢复等待的实时传输栈：
- 推流侧同时支持 WHIP 与 SRT：典型路径走 UDP，能按媒体时效限制恢复等待，弱网下不会被 TCP 队头阻塞拖垮。
- 分发与播放统一用 WHEP，Edge 只提供低延迟 WebRTC 播放，不提供 HTTP-FLV 端点——这条约束在需求阶段就已锁定。
- 弱网下的应对不是"硬扛丢包"，而是主动降级：服务端按丢包率和往返时延（RTT）自动在 simulcast 档位间升降级，先降码率（不中断推流），码率降到底仍不达标才降分辨率（这一步才有短暂中断）。EP04、EP07 会展开讲传输协议对比和弱网抗性的具体机制。
3.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。
4. 框图¶
4.1 总体架构图¶
ppcenter（控制面）
调度 · 鉴权 · P2P 信令 · 计费元数据 · 健康报告
▲ ▲
│ 控制 / 信令 │ 控制 / 信令
│ │
ppobs 推流端 ──WHIP/SRT──▶ Origin ──转发──▶ Edge 1..N ──WHEP──▶ 观众浏览器
│ ▲
└──── P2P 直连：H264 优先，失败回退 Edge（HEVC 直接走 Edge）────┘
图示要点（口播提示）：注意控制面（ppcenter）画在链路上方，用虚线箭头连接——它只参与"建立连接"这一步的决策，不在媒体数据的路径上。媒体数据本身走下面这条实线链路，P2P 直连则是绕过 Origin/Edge、直接从推流端到观众的一条捷径。
4.2 播放选路决策图¶
观众发起播放请求
│
▼
pplayer 探测浏览器能否硬解 HEVC
│
├─ 支持 HEVC ──▶ 直接走 Edge，追加 /hevc/whep 播放
│
└─ 不支持 HEVC
│
▼
优先尝试 P2P 直连拉 H264
│
├─ ppcenter 准入通过 + 有空闲信令槽位 ──▶ 中继 SDP/ICE 建立直连 ──▶ 采用 P2P
│
└─ 准入未过 / 超时 / 建连失败 / 槽位已满 ──▶ 干净回落到 Edge 的 H264 流
4.3 控制面与媒体面分离：控制面故障不影响媒体面¶
ppcenter（控制面）故障
│
▼
已建立的媒体会话继续稳定传输
│
▼
控制面恢复后，各端自动重新注册、重建租约
图示要点（口播提示）：控制面与媒体面彻底分离，控制中心故障不会中断正在进行的观看；控制面恢复后，各端重新注册并重建租约。这正是 PPCDN 能把故障域做小的关键设计。
5. 性价比：为什么自建能在成本效益上反超大厂云服务¶
前面几节讲的是"自建能不能做到低延迟、能不能控制风险"，这一节回答一个更现实的问题：同样投入下，为什么自建的性价比可以超过腾讯云快直播、华为云这类大厂云直播/RTC 服务？ 不是靠规模折价，而是靠三个大厂结构上很难复制的工程杠杆。
5.1 定制 ppobs：端到端全链路可优化，大厂拿不到这个杠杆¶
大厂云直播/RTC 服务通常只能优化"自己这一侧"——源站和边缘分发；推流端要么是客户自己接的通用 SDK，要么是标准 OBS，采集、编码、打点、QoS 策略都不在服务商的控制范围内，服务商和客户端是两个团队、两套代码。
PPCDN 的 ppobs 是深度定制的推流客户端，和服务端由同一套架构协同设计，能做到"买 SDK"模式做不到的联动优化：
- 码流内嵌入绝对时间戳（H.264/HEVC 用 SEI，AV1 用 metadata OBU），播放端据此算出真实端到端延迟——这需要改编码器/打包逻辑，不是配置项，通用 SDK 做不到。
- P2P 与主推流复用同一份编码，不为每个观众重复编码，节省推流端本地 CPU；同时对 P2P 和主推流做独立的发送队列与带宽预算隔离，保证"开 P2P 省钱"不会牺牲主播画质。
- 弱网降级（先降码率、不中断推流）由编码器和服务端协同触发，而不是服务端单方面限流猜测。
这些联动优化本质上是"端到端可编程"带来的增值：只有同时掌握两端，才能把整条链路当一个系统来调，而不是把两个黑盒简单拼接。
5.2 WHIP/SRT Simulcast：客户端一次编码出多档，网络侧不用转码¶
多档画质（如 1080P/720P/360P 同播）在大厂云直播里通常靠服务端转码实现——腾讯云快直播的转码就是按输出档位单独计费，档位越多、时长越长，这部分开销越高，这是行业惯例，不是个例。
ppobs 用 WHIP/SRT 同播 simulcast，在编码端一次性输出多档画质，服务端只做转发，不解码、不转码。对本来就要开多档的客户，免掉转码这一项往往能把总账单砍掉很大一块——在不少方案里，多档转码费是仅次于带宽的第二大开销，去掉之后账单结构会发生实质变化。
5.3 ppobs + pplayer 协同直连：真实跑通约 70ms¶
P2P 直连能不能打通、时延能压多低，关键不只在"有没有 NAT 穿透库"，还在推流端和播放端能否协同做资格判断与时间戳对齐（见 §3.1、框图 4.2）。本项目 P2P 直连已经真实跑通，端到端时延约 70ms；走 Edge 分发的入库链路实测 WHIP 约 108ms、SRT 约 386ms（差异来自入库协议的接收窗口，不是编码格式）。
6. 结尾与下集预告（逐字稿要点）¶
这一集的架构图回应了 EP01 的三个困境：按解码能力智能选路为 H264 客户端增加了一条更短的 P2P 直连路径，实时协议选型摆脱了 TCP 队头阻塞带来的积压风险，而控制面与媒体面分离、Edge 水平扩展把故障域做小、把控制权留在自己手里。PPCDN 用定制客户端、免服务端转码和端到端协同，做出了一套在低延迟、成本和可控性上都明显更强的自建方案。
下一集，我们先啃"主权"这一条——为什么"自己可控"是一条比性能参数更硬的护城河，以及自建和依赖第三方之间，到底应该怎么权衡。