去年11月初，我们在西北一个工业园区做企业峰会保障，现场只有一条不太靠谱的运营商专线，晚高峰丢包率经常摸到8%。用传统RTMP推流的那一路，画面每隔两三分钟就糊一次，观众端评论区已经开始刷"卡了卡了"。同一台编码器上并行跑的SRT推流协议那一路，从头到尾没掉过一帧。这件事之后，摄行科技把所有对稳定性有要求的项目都换成了以SRT为主链路的方案。这篇把当时的实测数据、协议差异和成本账摊开讲，别急着跟风换协议，先看看你的场景值不值。
RTMP的问题不在老，在于它假设网络是好的
RTMP是2002年前后为Flash设计的协议，跑在TCP上。TCP本身有重传机制，听起来挺可靠，问题在于TCP的重传是"死等"——一个包没到，后面的包全部堵在缓冲区里等它，直到超时重发成功。直播是实时流，等一秒和丢一帧比起来，观众其实更能接受丢一帧。TCP不懂这个道理，它是给文件传输设计的，追求的是一个字节都不能错。
所以RTMP在优质网络下表现完全够用，可一旦丢包率超过3%，画面就开始出现累积性的卡顿和音画漂移。更麻烦的是它默认不加密，链路中间任何一个节点都能把流拉下来看。企业内部会议、未发布的产品信息走这条路，风控部门第一个不同意。
SRT推流协议的思路完全反过来。它跑在UDP上，自己实现了一套基于时间窗的选择性重传：只重传那些"还来得及"的包，超过延迟预算的直接放弃，用前向纠错顶上。说白了就是承认网络会烂，然后在烂网络里保住时间线不崩。
一次跨省弱网实测：三组数据
那场峰会之后，摄行科技专门做了一轮受控测试。测试环境用网络损伤仪模拟，源站在华东，接收端在西南，链路人为注入丢包和抖动。
第一组是丢包耐受。在2%丢包下，RTMP和SRT推流协议表现基本持平，肉眼看不出差别。丢包提到5%，RTMP的卡顿次数每十分钟出现6.4次，SRT是0.3次。丢包拉到12%这种基本可以宣告链路报废的水平，RTMP直接断连重连，SRT仍能维持画面，只是码率自动降到原来的六成左右，画质糊但流没断。
第二组是端到端延迟。这里有个反常识的结果：SRT的延迟不一定比RTMP低。SRT需要设置一个延迟缓冲窗口（latency参数），这个窗口就是它用来做重传的时间预算。我们把窗口设成120毫秒时，端到端延迟约1.9秒，比RTMP的2.3秒略低；窗口拉到500毫秒换取更强的抗丢包能力时，延迟反而涨到2.7秒。所以说SRT等于低延迟，是销售话术，不是技术事实。它换来的是稳定，代价往往是可控范围内的延迟增加。
第三组是加密开销。SRT原生支持AES-128/256加密，我们实测开启AES-256后，编码器CPU占用增加约4个百分点，延迟增加不到10毫秒。这个代价对涉密内容来说基本可以忽略，比另外搭VPN隧道划算得多。企业内训、未公开发布会这类内容，加密这一项就足够构成换协议的理由，具体的权限设计思路可以对照私有化部署直播系统的取舍那篇里的分层逻辑。
什么场景该换，什么场景别折腾
先说结论：不是所有项目都值得换。
固定场地、专线质量稳定、内容不敏感的常规会议直播，RTMP完全够用，换协议带来的收益抵不上改造和培训成本。这类场地我们通常连备用链路都不上，把预算放在机位和音频上更实在。
真正应该上SRT推流协议的有三类。一是户外和临时场地，网络靠4G/5G聚合或者临时拉的线路，丢包是常态；二是跨省、跨国的长链路传输，中间跳数多，抖动累积明显；三是内容有保密要求的场合，加密是硬需求。
还有一类容易被忽略：分会场回传。异地分会场把信号回传到主会场做同框时，回传链路往往是整场最脆弱的一环，这里用SRT能显著降低翻车概率，相关的信号调度设计在直播中台的多路信号调度里讲得更细。
换协议的实际成本，摊开算
设备侧：主流专业编码器近五年的型号基本都原生支持SRT，不用换硬件。老一点的设备可以加一台SRT网关做转封装，单台成本在几千到一万五之间，看并发路数。软件编码器里OBS从25版本起就带SRT输出，免费。
服务端：这是主要开支。公有云直播服务对SRT接入的支持参差不齐，有些要走定制通道，单路月费比RTMP接入贵三到五成。自建SRT接收网关的话，一台中配云主机能扛七八路1080p并发，长期算下来比公有云便宜，但要有人运维。
人力侧：真正的隐性成本在这。SRT的latency参数、带宽超发系数（oheadbw）、加密密钥管理，这些都需要现场技术人员理解原理才能调对。我们内部培训一个熟手大概要两周加三场实操，参数配错的典型症状是"明明网络不差，画面却一顿一顿"——多半是latency设得比实际RTT还小，重传窗口不够用。
摄行科技这两年做的项目里，SRT主链路加RTMP备链路的双通道配置成了默认选项，两条路同时推，前端做健康检测自动切换。多路并推带来的码率和水印坑，之前在多平台同步推流的技术坑里踩过一轮，这次算是把经验用上了。
落地时的几个具体建议
latency参数别拍脑袋。先用ping测出链路的RTT，再按RTT的3到4倍设置，是行业里比较稳的起点。RTT 40毫秒的链路，设120到160毫秒；跨国链路RTT两百多毫秒的，就得设到七八百毫秒，同时接受延迟变高的事实。
带宽预留要留够。SRT重传本身要占带宽，默认的超发系数是25%，也就是你推6Mbps的流，实际上行要准备7.5Mbps。现场踏勘实测上行速率这件事，摄行科技一直坚持做，不看运营商标称值，只看实测峰值。
密钥别硬编码在配置文件里。加密开了但密钥全项目通用，等于没开。每场活动生成独立密钥，活动结束即失效，这是最低要求。我们内部还额外加了一条：密钥由项目经理单独下发，不进群聊、不进邮件正文，这条规矩看着麻烦，但涉密项目的客户风控部门看到之后普遍会松口气，因为他们最怕的不是技术不行，是流程随意。传输安全的合规底线可以参考国家网信办公开的相关管理规定；协议本身的技术规范和RFC文档在IETF官网可以查到完整版本，选型时让供应商明确标注实现版本，能避开不少私有魔改的坑。
如果你正在纠结自家的直播链路要不要动协议，摄行科技可以做一次免费的链路体检：实测你现有推流路径的丢包率、RTT和抖动分布，再结合内容保密等级给出协议建议和改造报价。测完再决定，比听谁吹得响靠谱。
#摄行科技
