这是本系列的最后一篇。我们做两件事1. **压力测试**——实战里最容易被跳过、也最不能跳过的一步。为什么 go test ./... 全绿和「能扛住生产流量」之间隔着好几级台阶2. **成本复盘**——回到最初那个商业问题「省 30% 带宽」这句听起来很具体的宣传语到底有没有真实数据支撑---## 第一部分压力测试是一场分层的攀登### 1. 每一层回答不同的问题先用一张表说清楚每一层测什么、不测什么| 层级 | 代表做法 | 回答的问题 | 不回答的问题 || --- | --- | --- | --- || **单元测试** | 全量单测 静态检查 | 逻辑对不对、边界处理对不对 | 真实网络下能不能工作 || **黑盒集成测试本地** | 编译真实媒体二进制、真实推流 | 协议/接口契约对不对 | 性能上限、容量 || **黑盒生产回归** | 对线上真实部署发请求 | 生产 API 的鉴权/校验/路由契约是否还对得上文档 | 媒体是否真的建立、播放质量 || **单机单流时延实测** | 一条真实流、限定网络场景 | 端到端时延的量级与构成 | 并发规模、全网 SLA || **单机容量压测** | 对一台真实节点做并发阶梯加压 | 这台机器的并发天花板在哪、退化是线性还是悬崖 | 多机/多区域规模下的容量 || **真实网络验收** | 两个**真正独立**的 NAT 环境 | NAT 穿透、失败兜底 | 规模化容量 || **全球容量压测** | 多区域、多并发、峰值流量 | 系统容量上限、瓶颈在哪 | —— |核心原则**在哪一层测就只能得到那一层的结论。** 单元测试全绿证明的是「代码逻辑自洽」不是「生产能扛住」。### 2. 怎么测端到端时延时延是整个系列的主轴它怎么被测出来一套可复现的方法是这样的1. **在码流里打绝对 UTC 时间戳**H.264/HEVC 用 SEIOrigin/Edge 逐跳透传不解码、不转码——打点本身不破坏「网络侧不转码」的架构原则。2. **播放端做应用层时钟校准**类似 NTP 的 offset 估算把本地时钟校正后再和码流里的时间戳相减corrected_now local_clock offsetone_way_delay corrected_now − embedded_timestamp3. **不用固定常数掩盖不可观测段**打点之后到真正显示之间若无法直接测量应分别埋点或报告「测量边界」而不是把所有读数机械加同一个补偿。4. **跨浏览器可测**部分浏览器读不了码流里的 SEI可以由此让边缘节点解析入库流的时间戳通过播放端已经打开的控制 WebSocket 下发——复用已有连接而不是新开一条。5. **单次读数 → 带样本信息的分布**报告样本量、测试时段、P50/P80/P95/P99并尽可能给置信区间。**百分位没有样本量就无法判断稳定性。**测出来的代表性结果**特定条件下的一次观测**P2P 直连约 70ms经边缘分发时 WHIP 入库约 108ms、SRT 入库约 386ms。这里要特别强调**这组对比的变量是入库协议WHIP vs SRT不是编解码器HEVC vs H264。** 差值主要来自 SRT 入库端为了弱网重传特意放大的固定接收窗口这是协议层「丢包鲁棒性 ↔ 时延」的有意取舍。如果把协议差异的数字拿去回答「codec 谁更快」的问题就是把两个轴混在了一起。### 3. 黑盒测试对着真实产物测单机实测之前有一层比单元测试更「真」、又比真实部署更可控的测试。以录像链路为例**编译真实的媒体二进制**不是进程内 mock、用**真实的推流**触发分片真正落盘、通过**真实 HTTP** 覆盖两阶段协议和鉴权失败分支再拿 API 返回和磁盘上真实写出的文件交叉核对。它有几条值得借鉴的铁律- **一次性、隔离**每次运行自己编译、自己起进程、自己用临时目录测试产物和密钥每次新生成。- **绝不碰生产**测试可以真写真删但只在自己的一次性沙盒里。- **知道自己的「不覆盖」清单**把「不覆盖什么」写清楚比多写几条用例更重要。比如本地没有对象存储就只能验证「上传不阻塞响应」不能验证真实上传成功。还可以有第二档**直接对线上真实部署**发请求覆盖播放选路、NAT 探测、录像查询等 HTTP 契约。它用专门的测试账号凭证只放本机、不进源码库覆盖鉴权失败、字段校验、过期令牌、跨应用冒用等负向用例。正向用例要写得足够诚实——比如播放接口的 happy-path 同时接受「成功」「暂时没有可用边缘」「账号刚好欠费」三种结果因为测试并不控制「此刻是否真有边缘可用」一个诚实的「没有容量」也证明鉴权校验那一层工作正常。但它仍然只测**控制面契约**播放接口返回「用哪个 URL 去连哪个边缘」这套测试只验证返回值对不对**不会真的去建一条 WebRTC/WHEP 连接看画面**。### 4. 真实网络验收mock 不出来的东西有些东西再好的 mock 都模拟不出来只能上真实网络- **先证基线连通性**用最容易满足准入的组合先确认整条链路是通的排除「根本没走到直连」这类底层问题。- **再造真实 NAT 组合**两端各自过一层真实的运营商/路由 NAT且**不是同一个 NAT 设备**。你可以 mock 出「对称 NAT」这个类型但 mock 不出真实 NAT 设备在真实运营商网络下的行为。- **验证「拒绝也要无感」**决定不做中继之后「该拒绝的组合是否被干净拒绝、而且用户完全无感」就成了上线关键。- **独立的媒体证据**在边缘节点上看这条流的会话字节数——直连建立后应该趋于零。这是独立证据证明「媒体真的没走边缘」。- **把探索性场景和 pass/fail 分开**像「直连失败后回退边缘的真实耗时分布」这类目标是**拿到一组真实数据**去校准参数而不是判定通过与否。- **证据留档**每次留 WebRTC 内部统计截图、播放接口完整响应、准入判定原因。**没有证据的「测过了」等于没测。**一句话真实网络验收的特点是——**慢、靠人、但不可替代。**### 5. 单机容量压测退化是悬崖不是渐变前面测的是「协议/接口对不对」和「时延量级」都是单流视角。还有一层问题**一台真实机器能同时扛住多少路天花板垮的时候是什么样子**方法通常是用压测工具对一台真实节点做并发阶梯加压边加边看 CPU/内存/断连/丢包。几份不同机型的报告放在一起能得出三条跟单元测试无关、但同样重要的教训1. **退化是悬崖不是渐变。** 健康区 CPU 平缓爬升约 2~3%/路但某一档之后几秒到十几秒内直接从「健康」冲到「过载」中间几乎没有过渡带。按前面的斜率外推会严重高估容量。2. **不能跨机型线性外推。** 单核机器没有第二个核心兜底 GC、网络轮询和突发处理悬崖来得早得多、也窄得多。按双核的斜率对半估算单核容量往往得出乐观值。3. **「是不是机器的锅」必须换个环境才能确认。** 同一台机器换一家网络给得起的云厂商承载能力可能从 50 跳到 250——说明原先那次崩溃测的根本不是 CPU而是**供应商的出口限速**。一次压测的失败结论如果不换环境复测很容易把「供应商的隐藏限速」误判成「机器的真实天花板」。压测还有一个意外收获**有些 bug 只有在真实环境里才会暴露。** 比如自建节点用授权码注册时拿不到凭证、或者公网部署下 ICE 候选采集到容器内部 IP 导致播放连不上——这些都不是「数据点」却是压测过程里最有价值的产出。### 6. 诚实的现状- **做完了的**单元测试单机单流的时延实测黑盒集成测试针对线上真实部署的生产回归自建节点的单机容量压测。- **做了一半的**P2P 已真实建立并观测到约 70ms但跨运营商、跨 NAT 类型、不同设备的样本量和误差分析仍不足不能据此形成命中率或 SLA。- **还是空的**真实媒体链路WebRTC 建连 播放质量的自动化端到端测试、全球容量压测、平台自身节点的容量校准。结论必须直白**不能仅凭单元测试结果推导生产容量。** 容量是真实流打出来的不是代码推出来的。### 7. 可以带走的七条原则1. 在正确的层级测正确的问题。2. 对着真实产物测——编译真二进制、跑真推流比进程内 mock 真得多。3. 隔离、一次性、不碰生产。4. 写清楚「不覆盖」清单。5. 区分「通过/不通过」和「取数据」。6. 压测要逼近真实——NAT 多样性、地理分布、峰值形态。7. **怀疑你的测试环境本身**同一个「失败」结论换一家云厂商、换一台机器很可能完全不成立。---## 第二部分成本复盘——省 30% 带宽### 8. 先把「省 30%」拆成两件事同样一句「省带宽」对应两条完全不同的技术路径| | 路径 AHEVC 省流量 | 路径 BP2P 省出站成本 || --- | --- | --- || 机制 | 同画质下 HEVC 编码效率更高 | 直连成功时媒体**不经过边缘** || 在哪一层 | 编解码层 | 分发结构层 || 省的是 | 每个观众占用的**码率/流量** | 边缘节点的**出口带宽** || 前提 | 播放设备支持 HEVC | 满足 P2P 直连准入条件 |**把这两件事分开是这一部分能讲清楚的前提。** 混在一起谈「省 30%」是对两套机制都不公平的简化。### 9. 路径 AHEVC 的节省是「待实测的区间」不是固定 30%一个常见做法是**多轨同播**推流端同时发布 H264 和 HEVC 两条独立的流播放器按浏览器解码能力选流——支持 HEVC 的拉 HEVC 流不支持时自动回退 H264。「HEVC 同画质省 30%」可以当作容量规划前的**区间假设中心值**不能当作通用事实。实际差值会随编码器实现与版本、preset/延迟档、分辨率和帧率、内容运动与噪声、码率区间以及质量指标而变化主观画质、VMAF、SSIM、PSNR 的「同画质」结果也可能不同。正确做法是对代表性内容做码率阶梯测试绘制 BD-rate 或同质量码率差并报告一个区间。三个必须讲清楚的前提- **只在支持 HEVC 的设备上生效。** 整体节省不能简化为 30% × 设备占比而应按各 codec 的实际观看字节、实测码率差和回退率加权。- **它增加的是推流端的成本**两条独立码流意味着推流端编码资源和上行带宽明显增加容量模型要按双会话计。- **它省的是「流量」不是「数量」**观众数不变、路径不变只是每一份流更小了。### 10. 路径 BP2P 的节省——单路明确总量受固定上限约束P2P 的省钱逻辑很直接- **直连成功的每一路观看边缘出口带宽是零**- **默认每个推流端最多同时服务固定的 N 路直连**由原子租约严格控制在中心侧- **推流主链路永远优先**P2P 只用富余上行一旦检测到拥塞立刻牺牲 P2P不会为了省钱牺牲主播画质- **P2P 是叠加在稳定边缘网络之上的增强**不是必需项。单次直连确实省掉该 viewer 的边缘出站但**不能据此宣称总体节省必然高于某个 codec 比例**。每个推流端最多 N 路热门流的 P2P 分流比例会随观众数增长而**下降**。总体节省要按实际 P2P 字节占比、边缘的边际计费方式及 P2P 信令/运维成本计算。而命中率——恰恰是目前最缺真实数据的地方。### 11. 把三种数字摊开**诚实的复盘就是绝不把后两类伪装成第一类。**#### ① 实测的有报告、可复现- 端到端时延P2P 直连约 70ms边缘分发下 WHIP 入库约 108ms、SRT 入库约 386ms差值来自入库协议不是编解码器。- NAT 准入的各类拒绝原因有单元测试覆盖播放/录像的 HTTP 契约有生产回归覆盖但只验证接口契约不验证真实媒体链路。**边界**这些是有限场景下的近似观测必须连同样本量、分位数、设备/网络/编码参数和测量误差发布不能把点估计当 SLA。#### ② 建模的有公式、有口径但不是实测为了避免把「按节点摊销」和「按 GB 云计费」两套模型混用统一采用月度全成本模型月总成本 节点固定费 实际出站超额费 跨区/回源费 存储与请求费 控制面/监控费 运维成本有效交付流量 边缘交付字节 P2P 交付字节单位成本 月总成本 / 有效交付流量- 套餐节点包含的流量计入固定费只有超过套餐额度的字节再计超额费**不能把同一批流量按两种费率重复记账**。- 「加权平均码率」和观看分辨率分布可以作为流量预测输入但必须用实际观看时长、codec 占比与观测码率更新。- P2P 的计费口径是「时长 × 平均流量」而「平均流量」在很多实现里是一个**固定常量**不采集每条会话的真实吞吐——所以即便用它反推「P2P 省了多少流量」那也是建模数字不是实测数字。- 对外价格和成本是不同维度。若采用目标毛利率 m价格为 单位成本 / (1−m)「成本 × 2」对应 50% 毛利率或 100% markup术语要分清。#### ③ 还没验证的缺口- **P2P 的真实命中率与实际字节分流比例**已真实跑通但尚缺足够生产样本来量化成本收益**时延跑通不等于命中率已验证**。- **HEVC 的实测码率区间与实际使用占比**需要按内容和质量目标实验不能先固定为 30%。- **跨可用区流量、云厂商配额超额、运维人力**这些都是会侵蚀毛利的变量且往往不在系统监控范围内。### 12. 单位经济性用一套模型算节省不要直接用售价减一个来自另一模型的「边缘边际成本」。在统一模型中应分别跑基线和优化场景基线单位成本 基线月总成本 / 基线有效交付流量优化单位成本 优化月总成本 / 优化有效交付流量月度节省 基线月总成本 − 优化月总成本如果边缘按量计费P2P 分流可能直接降低边际出站费如果边缘是含固定流量的包月节点且仍在额度内短期账单可能完全不变只提高可售余量。**只有避免新增节点、减少超额流量或降低实际账单时才形成可确认的成本节省。** 「省流量」不等于「省账单」。这里还有一个最容易想当然的假设要澄清**「HEVC 和 P2P 可以叠加」目前未必成立。** 如果播放决策按 codec 提前分流——支持 HEVC 的客户端直接走边缘从一开始就不尝试 P2P只有 H264 客户端才有机会拿到 P2P 资格——那么这两条降本路径当天就是**互斥**的一路流要么享受 HEVC 的编码层省流量要么享受 P2P 的分发层省出站。要同时拿到两者前提是先把 HEVC 接入 P2P 资格判断这件事做完。### 13. 诚实的结论- **「HEVC 省流量」**方向成立比例不是常数。必须按编码器、preset、内容、低延迟约束和质量指标得到实测区间再按真实设备/观看占比加权。- **「P2P 省带宽成本」**已真实跑通单次直连会减少相应边缘出站但每个推流端上限固定生产命中率、字节分流比例和账单节省仍待验证。- **把「成本下降」从架构能力变成可稳定复现的商业指标**是下一阶段的第一优先级——需要真实网络验收 可复现的证据。- 所以对「省 30% 带宽是否可行」的诚实回答是**可以把 30% 当实验假设不能当结论最终数字必须来自同质量编码测试、真实流量分布和统一成本模型。**---## 全系列收官我们从第一集的「互动直播的困境」出发走过了架构、协议、画质、安全、弱网、可观测性、P2P、节点池、扩容、突发、部署、录像、压测最后回到商业模式本身。如果要用一句话总结这套方法论**每个数字都要说明测量边界、样本量和模型。** 约 70ms 的 P2P 直连和约 108ms/386ms 的 WHIP/SRT 入库都是一次真实链路观测差值来自接入协议、不是编解码器「省 30%」只是等待按编码器、preset、内容和质量指标验证的假设哪怕 P2P 真的省了带宽在固定计费模型下这笔节省也可能只影响运营方自己的毛利还没有任何已确认证据表明它已经体现在客户账单里。**区分实测、建模和未知比漂亮的单点数字更重要。** 祝你自建顺利。---**系列导航**- 上一篇[09 · 从零部署与录像回放](09-从零部署与录像回放.md)- 返回[系列导览](README.md)