去年十一月，我在一家做工业软件的客户那儿蹲了三天。他们的年度技术开放日在周五下午两点开播，周三联调的时候，会场屏幕上导播机出来的画面和手机端观众看到的画面，差了整整六秒半。技术总监拿着两台手机对着比，脸都绿了：设备是新的，网络是专线，编码器码率给到了 8Mbps，怎么会慢成这样。
后来查出来，问题不在现场任何一个环节，在直播CDN选型这一步。他们的采购图省事，直接沿用了公司官网用的那家静态资源加速服务商，对方的直播产品线只在华东有三个边缘节点，回源要绕到北京的中心机房。一来一回，两秒钟就这么凭空蒸发了。
这篇东西我不想写成参数罗列，就当一份实验室报告——我们在摄行科技的测试间里搭了个土法测速台，把三家主流服务商放在同一根网线后面跑了十一天，数据摆出来给你看。
测速台是怎么搭的：一台编码器、三条推流、六个探针
先说方法，不然数据没意义。
测试环境很朴素：一台 Blackmagic ATEM Mini Extreme 出一路 1080p50 的 SDI 信号，进一台硬件编码器，编码器同时开三路 RTMP 推流，分别打到 A、B、C 三家服务商的接入点。三路推流参数完全一致——H.264 High Profile，平均码率 6.2Mbps，GOP 2 秒，B 帧关闭。同源同码，这是保证公平的前提。
播放端我们没用云上的虚拟机，那玩意儿的网络太干净，测不出真实体感。我们找了六台真实设备当探针：办公室的千兆光纤两台（一台 Windows 一台 Mac）、员工家里的 300M 家宽两台（一个电信一个联通）、还有两台是插着移动流量卡的安卓手机，其中一台故意放在信号只有两格的地下车库。
每天早上九点半、中午十二点二十、晚上八点各跑一轮，每轮持续二十六分钟。录屏加时间戳水印，人工逐帧比对首帧时间和端到端延迟。这活儿真的很枯燥，我们组里那个刚毕业的小赵连着比了四天，比到最后看见时间码就想吐。
三家的数据长什么样
十一天下来一共 33 轮、198 组样本。我把中位数拉出来做了张表：
| 指标 | A 家（一线大厂） | B 家（专做直播） | C 家（客户原用） |
|---|---|---|---|
| 首帧时间（光纤） | 0.41s | 0.38s | 1.27s |
| 首帧时间（家宽） | 0.63s | 0.52s | 1.94s |
| 首帧时间（弱信号手机） | 1.86s | 1.42s | 4.31s |
| 端到端延迟（RTMP 拉流） | 3.2s | 2.7s | 5.8s |
| 26 分钟内卡顿次数 | 1.3 次 | 0.7 次 | 4.6 次 |
| 单价（元/GB，阶梯首档） | 0.166 | 0.213 | 0.148 |
C 家最便宜，每 GB 比 B 家省 3 分零 5 厘。但它的端到端延迟比 B 家多 3.1 秒，弱网首帧慢了将近 3 秒。一场 500 人在线的两小时直播，流量成本差额大概 260 块钱；而观众因为首帧慢而在四秒内退出的比例，我们从客户后台调出来是 11.8%——将近六十个人，没等画面出来就走了。这笔账怎么算都不划算。
反常识的地方在于：很多人做直播CDN选型时盯着"节点数量"这个宣传数字。C 家官网写着"全球 2800+ 节点"，A 家写"1200+"，B 家甚至没写。但拉 traceroute 一看就明白了，C 家那 2800 个节点绝大多数是静态图片和小文件加速用的，能吃实时流媒体的边缘只有一小撮，而且不做流内容的动态回源优化。节点总数和直播可用节点，压根是两回事。
回源路径才是延迟的大头
直播CDN选型之所以难，是因为延迟拆开看有四段：一条流从编码器到观众眼睛要经过：推流上行、接入层转码分发、中心到边缘的回源、边缘到播放器的下发。
我们用抓包在 C 家那条链路上量了一下，接入点在杭州，边缘节点在广州，中间硬生生绕了北京的中心节点。物理距离多跑了三千多公里，光在光纤里跑一趟大约 15 毫秒——听着不多，但真正吃时间的不是物理距离，是中间每一跳的排队和转发处理。三跳变七跳，每跳多 200 毫秒的缓冲区，加起来就是一秒多。
B 家的做法是接入点直接下沉，杭州推流杭州接入，边缘之间走它自己的私有回源网络，跳数压到三跳以内。这就是为什么它单价贵三成，但延迟能压到 2.7 秒。
所以摄行科技做直播CDN选型评估时，问服务商的从来不是"你们有多少节点"，而是这三个问题：我的推流地在 X 城市，最近的可用接入点在哪；从这个接入点到我主要观众所在的 Y 城市，回源要经过几跳；中间是走公网还是你们的专有回传。对方要是支支吾吾报不出来，基本可以判断他们的直播产品是外采转售的。
关于回传链路的技术标准，工信部的通信行业标准检索平台上有公开的分层规范可以查（通信行业标准查询），采购做技术评标的时候拿这个当参照挺方便。
自己怎么测：一套不用花钱的土办法
不是每家公司都有条件搭六探针的测试台。给个精简版，两个人半天能跑完：
找一台笔记本，装 OBS 和 ffmpeg。用 ffmpeg 生成一路带毫秒时间码的测试信号：画面上叠一个不断跳动的时间戳。这路信号同时推给候选的两三家服务商。
然后在播放端，把各家的播放页面和源时间码画面并排放在同一个屏幕上，用手机慢动作模式（240fps）拍下来。回放的时候数帧，一帧 4.17 毫秒，误差能控制在 10 毫秒以内。土是土了点，但比服务商给你的测试报告可信多了。
弱网测试更简单，摄行科技常用 Clumsy 或者 Network Link Conditioner 人工丢包。我们的经验值：丢包率拉到 3%、抖动 80ms 的时候，做得扎实的直播CDN节点画面会平滑降码率，做得糙的直接绿屏或者疯狂缓冲。这一项一测一个准。
如果你所在的活动场景本身网络条件就恶劣，比如工厂车间、临时展馆，那光测 CDN 不够，得连推流侧的链路聚合一起考虑，这块我们在弱网环境下直播如何保底里写过完整的双保险方案。
别忽略这几个隐性坑
一、鉴权配置和延迟是有关系的。 有家服务商的 Token 鉴权做在边缘，每次起播都要回中心校验一次，首帧硬生生多 300 毫秒。改成边缘本地缓存密钥之后就正常了。鉴权方式的选择其实和防盗链方案是一套东西，可以对照直播鉴权防盗链的四种做法里的对比表来定。
二、多平台分发别指望 CDN 帮你转推。 有些服务商提供"一路推多路分发"，听起来很美，实际上它内部还是串行转推的，最后一路平台的延迟会比第一路多两三秒。要真需要同步，还是老老实实在推流侧解决，具体的坑我们整理在多平台同步推流的技术坑。
三、合同里的 SLA 要看清赔付口径。 很多合同写"可用性 99.9%"，但定义的是"节点可用"，不是"你的流可播"。我见过一场直播观众全程卡成 PPT，服务商拿监控图证明节点一切正常，最后一分钱没赔。这类扯皮的防范思路，和直播项目验收标准该写哪几条是同一套逻辑——把指标写成可举证的数字。
那家客户后来怎么解决的
回到开头。周三晚上我们做了个决定：不换服务商，来不及了，走备选方案。摄行科技当晚从库房调了一台带多链路聚合的编码器过去，把推流分成主备两路，主路继续走 C 家保成本，备路走 B 家保体验，播放页面默认给 B 家的地址，C 家那路只作为录制留档。
周五下午的实际数据：首帧中位数 0.61 秒，全场两小时十七分钟，卡顿上报 3 次，最长一次 1.9 秒。技术总监在群里发了个"稳"字。
第二年他们的框架采购就把直播CDN选型单独拆出来招标了，评标细则里写进了"提供推流地到目标观众城市的实测 traceroute 与首帧数据"。这条要求一加，报名的六家里当场退掉两家。
最后说两句
直播CDN选型这事儿，最容易犯的错是拿静态加速的经验套流媒体。图片慢半秒没人在意，直播慢两秒，观众直接就走了。省下来的那点带宽费，还不够买回流失的注意力。
摄行科技这几年给不少企业客户做过传输链路的评估和压测，测速脚本、探针配置、评标细则模板这些东西我们都是现成的。如果你手上正好有一场重要活动，又拿不准现有服务商能不能扛住，可以把场地地址、预估并发和目标观众分布发给我们，48 小时内出一份带实测数据的评估报告，不收费。真到了要下单的时候再谈方案也不迟——摄行科技做技术出身，最怕的就是客户在错误的链路上花了钱还挨骂。
有想聊的，直接找我们要那套 ffmpeg 测速脚本也行，白送。
#摄行科技
