EP20：省 30% 带宽是否可行：真实数据复盘¶

上集回顾	EP19《压力测试方法论：从单机到全球压测》
下集预告	全系列收官（Module 5 结束）

0. 本集目标¶

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

把“省 30% 带宽”改写成可验证假设：HEVC 相对 H264 的节省取决于编码器、preset、内容和质量指标；P2P 直连省的是部分 Edge 出站，两者不能混为一谈。
分清三种数字：实测的、建模的、还没验证的。这一集的重点就是把这三种数字摊开。
看懂单位经济性：为什么省下的每一个 TB 都是毛利，以及有哪些变量会侵蚀它。
带走一个诚实的结论：任何节省比例都要用同一质量目标、真实设备占比、P2P 命中率和一套统一成本模型验证，不能把行业经验值直接当运营结果。

1. 开场钩子（逐字稿要点）¶

这门课第一集就抛出了成本这个问题：传统 CDN 的成本随观众线性增长，出口带宽是大头。最后一集，我们回到这个商业问题本身——"省 30% 带宽"这句听起来很具体的宣传语，到底有没有真实数据支撑？我会把话说得很直：这句话背后其实是两件不同的事，一件是编解码层的估算，一件是分发结构层的能力，而其中一部分还没有被真实运营数据验证过。这一集不吹数字，只做一次诚实的复盘。

2. 先把"省 30% 带宽"拆成两件事¶

同样一句"省带宽"，这套系统里对应两条完全不同的技术路径：

	路径 A：HEVC 省流量	路径 B：P2P 省出站成本
机制	同画质下 HEVC 比 H264 编码效率更高	直连成功时，媒体不经过 Edge
在哪一层	编解码层	分发结构层
省的是	每个观众占用的码率/流量	Edge 节点的出口带宽
量级口径	先设区间假设，再按编码器/preset/内容/质量指标实测	取决于命中率，且每个 publisher 最多 3 路
前提	播放设备支持 HEVC	满足 P2P 直连准入条件（EP13）

把这两件事分开，是这一集能讲清楚的前提。混在一起谈"省 30%"，是对两套机制都不公平的简化。

3. 路径 A：HEVC 节省是待实测的区间，不是固定 30%¶

这套系统的做法是多轨同播（EP05 讲过）：推流端同时发布 H264 和 HEVC 两条独立的流，播放器按浏览器的解码能力选流——支持 HEVC 的设备拉 HEVC 流，不支持时自动回退 H264。

“HEVC 同画质省 30%”可以作为容量规划前的区间假设中心值，不能作为通用事实。实际差值会随编码器实现与版本、preset/延迟档、分辨率和帧率、内容运动与噪声、码率区间以及质量指标而变化；主观画质、VMAF、SSIM 或 PSNR 的“同画质”结果也可能不同。正确做法是对代表性内容做码率阶梯测试，绘制 BD-rate 或同质量码率差，并报告一个区间。

但有三个必须讲清楚的前提：

它只在支持 HEVC 的设备上生效。不支持的用户仍走 H264。整体节省不能简化为 30% × 设备占比，而应按各 codec 的实际观看字节、实测码率差和回退率加权。
它增加的是推流端的成本：两条独立码流意味着推流端的编码资源和上行带宽明显增加（系统为此按 codec session 分开统计容量、码率和告警，EP15/EP16 的容量模型要按双会话计）。
它省的是"流量"，不是"数量"：观众数不变、路径不变（还是走 Edge），只是每一份流更小了。

一句话：30% 只能作为待验证假设。先固定质量目标和低延迟约束，再按编码器、preset、内容集合与终端兼容性实测节省区间。

4. 路径 B：P2P 的节省——单路明确，总量受固定上限约束¶

第二条路径是这套系统更有想象力、也更需要验证的地方：P2P 直连。

它的省钱逻辑非常直接（EP13 讲过机制）：

直连成功的每一路观看，Edge 出口带宽是零——数据从推流端直接流向观众，完全不经过边缘服务器。
默认每个推流端最多同时服务 3 路直连（maxP2PSessions，默认 3，超管后台可调），由中心侧的原子租约严格控制。
推流主链路永远优先：P2P 只用推流端上行带宽里经过安全测算的富余部分，一旦检测到上行拥塞，系统会毫不犹豫地立即牺牲 P2P 连接，确保主推流质量不受影响——所以开 P2P 不会出现"为了省钱牺牲主播画质"的风险。
P2P 是叠加在稳定 Edge 网络之上的增强，不是必需项：某条流完全不具备直连条件时，观众体验和传统 CDN 一致，成本优势是纯粹的"锦上添花"。

单次 P2P 直连确实省掉该 viewer 的 Edge 媒体出站，但不能据此宣称总体节省必然高于某个 codec 比例。每个 publisher 最多 3 路，热门流的 P2P 分流比例会随 viewer 数增长而下降。总体节省要按实际 P2P 字节占比、Edge 的边际计费方式及 P2P 信令/运维成本计算。

而命中率——恰恰是目前最缺真实数据的地方。

5. 真实数据复盘：把三种数字摊开¶

这一集的核心，是把所有相关数字分成三类。诚实的复盘，就是绝不把第二、三类伪装成第一类。

① 实测的（有报告、可复现）¶

端到端时延：P2P 直连跑通约 70ms；走 Edge 分发时，入库协议是主要变量——WHIP 入库约 108ms、SRT 入库约 386ms（差值主要来自 SRT 入库端的 TSBPD 固定接收窗口，这是协议层"丢包鲁棒性 ↔ 时延"的取舍，不是编解码器差异——这组数字的变量是入库协议 WHIP/SRT，不是 codec HEVC/H264，引用时不要把两个轴混在一起，详见《直播时延性能测试报告》）。
NAT 准入的各类拒绝原因，有单元测试覆盖；Play/NAT/records/split-rec 的 HTTP 契约还有一层针对线上真实部署的黑盒生产回归测试（EP19 第 4 节讲过），但它只验证接口契约，不验证真实媒体链路是否建立。
但要注意：这些是有限场景下的近似观测。必须连同每组样本量、分位数、设备/网络/编码参数和测量误差发布，不能把点估计当 SLA，也不能仅由差值断言因果。

② 建模的（有公式、有口径，但不是实测）¶

为了避免把“按节点摊销”和“按 GB 云计费”两套模型混用，本集统一采用月度全成本模型：

月总成本 = 节点固定费 + 实际出站超额费 + 跨区/回源费
         + 存储与请求费 + 控制面/监控费 + 运维成本
有效交付流量 = Edge 交付字节 + P2P 交付字节
单位成本 = 月总成本 / 有效交付流量

套餐节点包含的流量计入节点固定费，只有超过套餐额度的字节再计超额费；不能同时把同一批流量按 $4/TB 和 $0.0122/GB 重复记账。
“加权平均码率 1.75 Mbps”和观看分辨率分布可以作为流量预测输入，但必须用实际观看时长、codec 占比与观测码率更新。
P2P 的计费口径是"时长 × 平均流量"，而"平均流量"在当前实现里是固定常量 1Mbps，不采集每条会话的真实吞吐（docs/design/ppcdn-billing-and-traffic-monitoring.zh-CN.md §2.7）。所以即便以后想用它反推"P2P 帮你省了多少流量"，那也是一个建模数字，不是实测数字。
对外价格和成本是不同维度。若采用目标毛利率 m，价格为 单位成本 / (1-m)；“成本 × 2”对应 50% 毛利率或 100% markup，术语要分清。

③ 还没验证的（缺口）¶

P2P 的真实命中率与实际字节分流比例：P2P 已真实跑通，但尚缺足够生产样本来量化成本收益；时延跑通不等于命中率已验证。
HEVC 的实测码率区间与实际使用占比：需要按内容和质量目标实验，不能先固定为 30%。
跨 AZ 流量、云厂商配额超额、运维人力：这些都是会侵蚀毛利的变量，且不在系统监控范围内（EP16 讲过云配额是盲区）。

本集最重要的一句话：链路已跑通不等于节省比例已验证。HEVC 要做同质量编码实验，P2P 要测实际交付字节占比，最后全部代入同一套月度全成本模型。

6. 单位经济性：用一套模型计算节省¶

不要直接用售价减一个来自另一模型的“Edge 边际成本”。在统一模型中，应分别跑基线与优化场景：

基线单位成本 = 基线月总成本 / 基线有效交付流量
优化单位成本 = 优化月总成本 / 优化有效交付流量
月度节省     = 基线月总成本 - 优化月总成本

如果 Edge 按量计费，P2P 分流可能直接降低边际出站费；如果 Edge 是含固定流量的包月节点且仍在额度内，短期账单可能完全不变，只提高可售余量。只有避免新增节点、减少超额流量或降低实际账单时，才形成可确认成本节省。收入是否不变还取决于计费合同，不能自动把分流字节等同为毛利。

"收入是否不变"不是一句空话——这套系统自己的计费现状刚好是个现成例子。生产环境目前实际执行的是固定 $1/天/活跃账户，完全不看字节（internal/store/billing_store.go 的 dailyFeeUSD 硬编码常量）：也就是说，今天省下的每一个 GB 出站流量，100% 落进运营方自己的毛利，不会改变任何一张客户账单，因为账单压根不读流量字段。按流量计费的新方案（$0.0244/GB 下行 + $0.02/GB·月录像存储，按分钟实时扣费，无月度最低消费，当日有使用但计量低于 $0.0001 时补到 $0.0001）在代码层面已经实现（ProcessRealtimeUsageBills/BillingManager），但受配置开关 BillingConfig.UsageBasedEnabled 控制——BillingManager.Start() 按这个开关二选一启动"旧的固定日费循环"或"新的按分钟实时计费循环"，没有任何已知生产部署记录证明这个开关已经被打开：本地仓库配置文件显示的 true 不能当证据（远程配置被手工改过、和本地不同步的情况已经发生过），而部署记录本身完全没有"按流量计费已上线"这类条目。连 P2P 的"时长 × 1Mbps"计费累加器也挂在同一个被这个开关控制的实时计费循环里（chargeRealtimeP2PUsage 是 ProcessRealtimeUsageBills 内部调用的子函数，不是独立的常驻循环）——设计文档说 P2P 计费"独立于 Edge 下行流量计费"，指的是账务结构独立（独立累加器、独立账单组件），不是独立生效：开关没打开时，这条计费逻辑和带宽计费一样完全不会运行。这是本集反复强调的"代码实现"与"生产生效"之间又一处容易被混淆的边界。换句话说：如果这个开关有一天真的打开，HEVC/P2P 省下的流量会第一次直接体现在客户账单上；但截至目前，省带宽这件事对收入侧没有任何已确认的影响，能确认的效果全部在成本侧。

但毛利会被四个变量侵蚀，必须同时看：

P2P 命中率——已有真实跑通样本，但生产样本不足以估算稳定命中率（§5 的缺口）。
HEVC 使用比例——支持设备越多，流量越省。
套餐额度与超额单价——额度通常是计费阈值，不是断流线；额度内外的边际成本不同。
运维人力——扩容、证书、节点加入目前仍偏人工（EP15 讲过），这是自建 CDN 最现实的一项边际成本。

这里有一个容易想当然的假设要澄清："HEVC 和 P2P 可以叠加"目前不是真的——当前播放决策按 codec 提前分流（见 EP13），支持 HEVC 的客户端直接走 Edge，从一开始就不会尝试 P2P；只有 H264 客户端才有机会拿到 P2P 直连资格。也就是说，这两条降本路径今天是互斥的：一路流要么享受 HEVC 的编码层省流量，要么享受 P2P 的分发层省出站，不能同时拿两份收益。要同时拿到两者，前提是先把 HEVC 接入 P2P 资格判断这件事做完——这是一项尚未完成的工程，不是已经叠加生效的能力。

7. 诚实的结论¶

“HEVC 省流量”：方向成立，比例不是常数。必须按编码器、preset、内容、低延迟约束和质量指标得到实测区间，再按真实设备/观看占比加权。
“P2P 省带宽成本”：P2P 已真实跑通约 70ms，单次直连会减少相应 Edge 出站；但每 publisher 最多 3 路，生产命中率、字节分流比例和账单节省仍待验证。
把"成本下降"从架构能力变成可稳定复现的商业指标，是下一阶段的第一优先级——而这正需要 EP19 讲的那套方法论：真实网络验收 + 可复现的证据。
所以对“省 30% 带宽是否可行”的诚实回答是：可以把 30% 当实验假设，不能当结论；最终数字必须来自同质量编码测试、真实流量分布和统一成本模型。

8. 框图¶

8.1 两条降本路径，不要混为一谈¶

        "省 30% 带宽"
              │
      ┌───────┴────────┐
      ▼                ▼
  HEVC（编解码层）    P2P（分发结构层）
  实测节省区间         直连成功 → 该路 Edge 媒体出口 = 0
  省"每份流更小"      省"整份出站"
      │                │
  前提：设备支持      前提：H264（HEVC 当前不参与 P2P 资格判断）
      │                变量：命中率 × 出站单价
      └───────┬────────┘
              ▼
   今天互斥，不可叠加：HEVC 客户端直接走 Edge、从不尝试 P2P；
   只有 H264 客户端才会进入 P2P 资格判断（顺序回退，不是竞速）

8.2 三种数字，别把后两种当第一种¶

① 实测（有报告）
   · 时延：P2P直连约70 / WHIP入库约108 / SRT入库约386 ms（协议差异，非codec差异）
   · 边界：报告样本量、分位数、场景与误差；不等于 SLA

② 建模（有公式）
   · 加权码率 1.75 Mbps
   · P2P 计费口径：时长 × 固定 1Mbps（非实测吞吐）
   · 月总成本 / 有效交付流量；基线与优化使用同一公式
   · 边界：套餐额度内外边际成本不同，成本与售价分开；
     省流量≠省账单（现网固定$1/天，按流量计费开关未确认打开）

③ 未验证（缺口）
   · P2P 生产命中率 / 字节分流比例
   · HEVC 同质量码率区间 / 实际设备占比
   · 跨 AZ / 云配额超额 / 运维人力

9. 全系列收官¶

到这里，这门课就全部讲完了。我们从第一集的"互动视频游戏的困境"出发，走过了协议选型、弱网、可观测性、质量、P2P、节点池、扩容、突发、部署、录像，最后回到商业模式本身。

如果要用一句话总结这套系统的方法论：每个数字都要说明测量边界、样本量和模型。约 70ms 的 P2P 直连和约 108ms/386ms 的 WHIP/SRT 入库都是一次真实链路观测，差值来自接入协议、不是编解码器；"省 30%"只是等待按编码器、preset、内容和质量指标验证的假设；哪怕 P2P 真的省了带宽，在固定 $1/天的现行账单模型下这笔节省目前也只影响运营方自己的毛利，还没有任何已确认证据表明它已经体现在客户账单里。区分实测、建模和未知，比漂亮的单点数字更重要。

感谢看到这里的每一个人。这套系统的代码是开源的，欢迎自己去部署、去压测、去把那些"还没验证的"补上——那才是这门课真正的续集。