直播传输协议选型有哪些权衡点？怎么选？

没有绝对最好的协议，只有最适合场景的方案，延迟、稳定性、成本、生态四者不可兼得，选型前必须先把需求边界画清楚。

直播推流协议怎么选：先看延迟天花板

做直播选协议，第一个要问自己的问题是：你允许观众看到画面的时间晚多久？

延迟区间决定协议命运

行业共识认为,直播场景按延迟容忍度可以粗暴分成三档：

• 3秒以上：传统赛事、教育大课、秀场娱乐，观众对延迟不敏感，但对流畅度要求极高
• 1秒到3秒：电商带货、在线拍卖、远程指导，需要主播和观众有互动，但不需要太强的实时性
• 500毫秒以内：视频连麦、在线PK、音视频会议，这种场景下延迟高一点都会让对话变得痛苦

先说结论：延迟需求在1秒以上的，优先考虑RTMP或SRT；延迟需求在1秒以内的，WebRTC几乎是唯一选择。

RTMP是老牌选手，基于TCP，在公网传输时拥塞控制机制非常成熟，配合CDN分发是当前国内直播生态最稳固的链路，它的缺点是延迟通常在3到5秒，但换来的是极高的推流稳定性和极低的丢包率，大多数直播平台的基础推流链路至今仍然是RTMP，不是因为它先进,而是因为它皮实。

SRT则是近年的新锐，基于UDP但自带重传机制，在弱网环境下的表现比RTMP强得多，同样丢包30%的网络条件下，RTMP可能已经花屏卡死，SRT还能维持基本可看的画面，近年来，国内不少广电级直播项目开始转向SRT,很大程度就是看中它在复杂网络下的抗丢包能力。

WebRTC则是另一个极端，它把延迟压到了200到400毫秒，但代价是它的传输质量极度依赖网络质量，一旦网络抖动，画面会直接卡顿或马赛克,没有RTMP那种缓冲兜底的能力。

延迟和卡顿的权衡逻辑

有一个很难受的事实：延迟越低，卡顿风险越高，这不是某个厂商的缺陷,而是网络传输的物理规律。

• 延迟本质上是缓冲区在起作用，缓冲区越大，网络抖动时越能平滑度过
• WebRTC为了压延迟，缓冲区被压到极小，网络稍微抖动就直接表现出来
• RTMP为什么延迟高？因为它把数据包缓冲在客户端，等数据齐了再播，你看不到网络波动，代价是慢几秒

所以选型时要做的第一件事，是找一个测试脚本，把网络模拟成丢包5%、延迟50毫秒、抖动20毫秒的状态，然后把候选协议各跑一遍,看哪个卡顿率你能接受。

RTMP和SRT哪个好：稳定性与弱网表现的实测对比

这是直播从业者问得最多的问题，RTMP统治直播推流行业十几年，SRT则是后起之秀,两者经常被放到台面上比较。

协议机制打底，先搞懂两者本质区别

RTMP选公网传输时，数据包一旦丢失，TCP机制会触发重传，而重传期间的后续数据全部堆积在缓冲区里等待，这导致网络越差，RTMP延迟越高,有时候甚至从3秒飙到10秒以上。

SRT做的优化是：同样走UDP，但丢包重传只针对丢失的那几个包，不会阻塞后续数据流动，在20%丢包率的网络环境下，SRT仍能保持可用的画面质量，而RTMP已经出现明显卡顿或断流,这是SRT在近两年大量进入广电和户外直播领域的核心原因。

推流端的实际选择建议

• 如果你的推流设备大部分时间处于运营商骨干网络（室内固定宽带、机房），RTMP完全够用，生态成熟，对接CDN和播放器都不用折腾
• 如果你的推流场景涉及移动网络、卫星链路、户外无线传输等不稳定环境，SRT会显著降低断流率
• 如果对延迟有要求，SRT可配置的延迟机制让它在1秒左右的延迟档位可以提供比RTMP更平滑的体验

价格上也值得关注，RTMP的CDN分发链路非常成熟，国内主流云厂商的直播推流价格基本都基于RTMP链路定价，SRT虽然支持，但部分CDN厂商的SRT接入能力仍在完善中，选择SRT时建议先确认源站和分发节点的支持情况,避免推流端搞定后播放端接不住。

国内直播选型看什么：场景、设备与协议生态

国内直播环境和海外差异不小，国内直播平台几乎清一色走RTMP推流，而海外则更接受HLS和LL-HLS的播放链路，这种差异不是技术上的优劣,而是生态积累的结果。

直播推流协议价格与成本构成

选协议时，很多人只看技术参数，忽略了成本，直播成本大头不在协议本身,而在分发链路。

• CDN分发费用：国内主流CDN厂商的直播分发按流量计费，单价相差不大，但SRT和WebRTC对CDN节点质量要求更高，意味着你要买的节点资源更贵
• 转码费用：RTMP推流后通常需要转码成HLS或其他格式才能在网页端播放，这个转码过程是按分钟计费的
• WebRTC的隐性成本

  

  ：WebRTC的端到端低延迟依赖SFU（选择性转发单元）服务器，这类服务器资源消耗大，同样并发数下，WebRTC的服务器成本通常比RTMP高出数倍

• SRT的接入成本：SRT协议本身是开源的，但你需要自己搭建SRT源站或购买支持SRT的云直播服务，目前国内主流云厂商对SRT的接入支持和价格策略参差不齐

播放端的兼容性决定了很大一部分选型

推流协议再先进,播放端不支持就等于白搭。

• 网页播放：RTMP在2020年后已被各大主流浏览器禁用了，现在网页端的播放基本走HLS或HTTP-FLV，如果你的用户集中在浏览器观看，推流端用RTMP没问题，但播放链路要考虑转HLS
• 移动App端：iOS原生不支持RTMP播放，Android原生也不支持，都需要集成第三方播放器SDK，SRT同样面临播放端SDK覆盖的问题
• WebRTC播放：如果已经有WebRTC播放器集成经验，那么WebRTC的端到端方案是低延迟场景里最省心的

实际经验是：在直播间互动场景里，推流和播放两端的协议栈最好统一。 RTMP推流转WebRTC播放，或者SRT推流转HLS播放，都会在协议转换节点引入额外延迟,这个延迟通常没人帮你优化。

三个真实场景的协议选型实操路径

与其背参数,不如直接看同行是怎么选的。

户外直播带货，网络环境不稳定

一位做户外带货的团队，使用移动WiFi加手机热点作为推流网络，信号波动比较大，早期用RTMP推流，经常在步行移动时出现断流，直播间观众大量流失，后来切换为SRT推流，相同网络条件下断流率明显下降，直播能持续跑通一整个场次。

实操路径：

• 推流端使用OBS或专业编码器，选择SRT协议推流到SRT源站
• 源站转RTMP进入到云直播平台，利用云平台已有的CDN分发能力
• 播放端继续走平台的HLS或HTTP-FLV链路，无需改动播放器

这套方案把SRT的抗丢包优势集中用在了网络最薄弱的推流段，同时保留了云平台的成熟分发能力,是目前户外直播里性价比最高的组合。

在线互动教学，需要连麦和共享屏幕

在线教育场景的核心体验是老师和学生能实时互动，延迟超过1秒对话就非常别扭,RTMP完全无法胜任这个场景。

实操路径：

• 推流端和播放端都集成WebRTC SDK，走SFU架构实现音视频双向通道的单向直播则使用RTMP推流，转HLS做大规模分发
• 兼顾了互动的实时性和大班课的分发成本

这种混合架构是当前在线教育平台的主流做法,因为它同时发挥了WebRTC的低延迟能力和RTMP的生态覆盖面。

大型活动直播，网络有专线保障

大型发布会、赛事直播，现场有专线网络或者专门搭建的视频传输链路，这种场景网络质量极高，

RTMP和SRT的差异在实际表现中几乎无感，这时候选型主要看团队对哪种协议更熟,以及CDN厂商的配合程度。

直播延迟优化不止协议的事

聊完协议，有个必须提醒的点：协议选型只占延迟优化的三分之一，很多团队把延迟高的问题归结于协议,实际上问题出在链路其他环节。

推流端编码参数的影响

编码器的参数设置直接影响首帧画面到达播放端的时间。

• GOP（关键帧间隔）设置越长，播放端起播越慢，但画面码率更稳定，2秒一个关键帧是安全值
• 编码器缓冲设置过大，延迟会显著增加，但画质更稳定。延迟敏感场景建议将编码缓冲控制在500毫秒以内
• 编码档次越高，单帧编码耗时越长，也会增加延迟

播放器的缓冲策略

播放器端的缓冲设置对延迟影响极大，主流播放器默认缓冲参数偏保守，会额外引入1到2秒的延迟。

• 将播放器缓冲设置调低，延迟会明显改善
• 开启播放器的追帧模式，在延迟累积过大时自动跳过部分帧来拉近时间差

CDN节点的覆盖质量

CDN节点离观众越远，网络跳数越多，延迟越高，国内主流CDN厂商在华北、华东、华南的节点覆盖较好，偏远地区的延迟会偏高，若你的用户集中在特定城市，选一个有本地节点覆盖的CDN服务,效果立竿见影。

直播传输协议选型的常见问题

低延迟直播用什么协议比较好？

延迟需求在1秒以内，选WebRTC；1秒以上，选SRT或RTMP，如果追求延迟和成本的平衡，SRT以可配置的延迟档位（通常0.5秒到2秒）配合UDP传输，比WebRTC便宜,比RTMP延迟低。

RTMP会被淘汰吗？

短期内不会，RTMP在当前直播生态中的推流端占比依然最高，CDN基础设施、编码器兼容性、播放器SDK支持度都围绕RTMP形成了成熟闭环，国内直播平台的推流链路仍然大量使用RTMP,这个惯性在5年内不会有根本性变化。

国内直播和海外直播选型有什么差异？

国内直播平台的播放链路以HTTP-FLV为主，因为它兼容性好且不需要HTTPS证书，海外则以HLS为主，推流端国内和海外都大量使用RTMP，但海外的低延迟场景更倾向于用SRT或LL-HLS，国内则更多用WebRTC做连麦互动补充，选择协议时先确定目标用户所在区域的分发链路,再倒推推流端的协议选择。

直播传输协议的选型从来不是一个纯技术问题，它受制于场景、预算、团队能力和用户分布等多重因素，把延迟需求、网络环境、播放端生态、成本预算列成一张表，逐项对照排查,比盲目追逐新协议更能解决实际问题。