直播软件开发技术栈选型：WebRTC与RTMP的优劣对比
近期趋势
直播行业对低延迟的需求持续上升，互动直播（连麦、在线教育、远程医疗）占比扩大。传统RTMP方案在延迟和可扩展性上逐渐面临挑战，WebRTC因其浏览器原生支持和端到端加密受到更多关注。同时，厂商正尝试将两者融合，例如用RTMP推流配合WebRTC播放，形成混合架构。
行业背景
RTMP由Adobe推出，长期用于推流至CDN或服务器，依赖Flash播放器（现已淘汰）或HLS/FLV转封装。WebRTC是W3C/IETF标准，无需插件，直接浏览器对浏览器或对服务器通信，广泛应用于视频会议和RTC场景。当前主流直播平台在延迟容忍度较高的场景（如大型活动、秀场）仍以RTMP+HTTP-FLV为主；但在需要毫秒级互动的场景（如在线答题、远程手术）则倾向于WebRTC或基于WebRTC的低延迟方案。
用户关注点
- 延迟表现：WebRTC经优化后延迟可稳定在200～500ms，RTMP常规延迟在3～10秒（含缓冲），通过分片优化可降至1～3秒但整体不如WebRTC。
- 浏览器兼容性：WebRTC原生支持所有主流浏览器（Chrome、Firefox、Safari、Edge），无需插件；RTMP无法直接浏览器播放，需转成HLS或FLV（通过MSE或WebSocket代理），额外增加开发与延迟。
- 复杂网络适应性：RTMP基于TCP，高丢包场景下易卡顿；WebRTC基于UDP+ICE/STUN/TURN，能自动选择最佳路径，通过FEC和NACK抗丢包，但TURN服务器费用较高。
- 安全与加密：WebRTC强制DTLS/SRTP加密，RTMP本身无加密，需配置RTMPS（RTMP over TLS）或使用自定义加密方案。
- 生态系统与工具链：RTMP的开源服务器（如Nginx-RTMP、SRS）成熟，推流端支持OBS、FFmpeg等；WebRTC需要搭建信令服务器、媒体服务器（如Janus、Mediasoup、LiveKit），复杂度较高。
可能影响
- 开发成本：选择WebRTC需投入更多精力在信令、NAT穿透、带宽预估、码率自适应上，而RTMP推流+转码再分发仍是成本较低、门槛较低的方式。
- 用户体验分层：非交互型直播（纯观看）中，延迟3～5秒用户可接受，RTMP+HLS足够；强互动型直播（如直播间打赏、连麦）必须用到WebRTC，否则用户会因延迟产生沟通断裂。
- 部署灵活性：WebRTC可部署全球边缘节点（SFU/MCU），配合CDN可降低回源带宽；RTMP对CDN要求较低，但大规模并发时边缘节点对RTMP支持不统一，需要额外转码。
- 未来兼容性：苹果、谷歌等浏览器已彻底淘汰Flash，RTMP作为原始推流协议仍会在服务端保留，但播放侧将全面转向HTTP-FLV或WebRTC。WebRTC生态快速进化，但在弱网环境、多流混流、录制等功能上仍需自定义开发。
后续观察
- 混合协议趋势：主流方案可能是“RTMP推流 + 转WebRTC分发”或“WebRTC推流 + 转HLS/FLV供旧端播放”。需要关注开源媒体服务器对混合协议的支持成熟度。
- WebRTC标准演进：如SVC可伸缩编码、插入流（Insertable Streams）等新特性的普及，将进一步提升WebRTC在直播场景的编码效率和灵活性。
- 成本与运营权衡：TURN服务器带宽费用仍是WebRTC大规模部署的瓶颈，后续需关注厂商是否降低TURN使用成本，或推出P2P/CDN混合方案。
- 低延迟HLS/CMAF挑战：Apple推动的LL-HLS（低延迟HLS）可将延迟降至2～6秒，虽不及WebRTC，但无需升级服务端架构，可能削弱WebRTC在低延迟领域的独占优势。
总结观点：选型不应非此即彼，应基于场景的延迟容忍度、用户终端分布、运维团队能力做权衡。WebRTC更适合强互动、低延迟、轻客户端的场景；RTMP在成熟度、推流工具丰富度、高并发成本上仍有优势。建议直播软件开发者在初期采用RTMP快速验证，再针对交互模块逐步引入WebRTC。