直播分发选低延迟 RTC 还是 CDN？

直播链路选择

简单来看，一个完整的直播应用实现原理是：主播端采集音视频，推到服务器，再由服务器分发给观众观看。

主播端负责推流，需要配置选用 RTC 链路分发直播画面或者用 CDN 链路分发。如果涉及连麦还需要考虑如何做 MCU 合流，观众订阅合流的好处是能保证多个主播对话是基本对齐的，不会出现因为网络差订阅多个订阅主播时某一主播画面卡顿或延迟造成“慢半拍”等现象。

本文福利， 免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

影响用户体验的几个问题

直播平台的竞争核心，无论支点放在主播还是内容，都离不开应用本身 “好不好用”的体验问题。从技术逻辑上看，直播要无限接近线下实时沟通，也就是要实现低延时 、高流畅的交互

而面对直播场景实现上如此复杂的链路选择和场景切换，直播应用常会遇到延迟、链路切换失败、首屏耗时长等导致用户给“差评”的问题，也是开发者需要重点思考的地方。

延迟问题

早期的直播应用一般都是单主播，只能通过文字与观众互动。当时业界对直播实时性要求也不高，软件开发者一般会选用 RTMP 推拉流，让直播画面在 CDN 链路上进行分发。这样主播和观众之间的延迟一般是 2～5s，也就是说：观众看到或听到的直播画面，声音是主播 2～5 秒之前发出的。

当主播与观众互动时，比如询问大家想听什么歌，得到反馈结果就要等较长时间。这种情况在电商直播中尤其影响整体效果，当主播发布商品让观众抢购时，会先出现购买入口，然后才听见主播的口播“商品已上架，快抢购”。这种错位的体验，实在谈不上优质。

想要解决这个问题，开发者必须选一个靠谱的 CDN 直播加速服务，或者干脆选择 RTC 服务做直播分发。共建互动直播场景的多场景、多链路切换； RTC 直播上，实现了主播到观众延迟在 500ms 以内的低延迟直播。

（直播链路对比）

连麦时切换链路失败

如果使用 CDN 链路做直播分发，在连麦场景中观众切换为连麦主播时涉及从 CDN 链路切到 RTC 链路，终端则需要切换音视频播放器。开发者需要维护两个播放器的状态，经常出现黑屏、卡顿等问题。

开发者需要在做这两个场景切换时充分考虑了各种异常情况，避免切换失败、黑屏等影响用户体验的问题；

（多房间主播连麦）

（多房间主播连麦）

首屏耗时长

随着网络技术和通信技术的发展，我们对于延迟的容忍度越来越低。而传统链路涉及直播地址分发、请求数据等一些列耗时操作，无法满足用户对于“打开一个直播，希望立即加载出视频画面”的需求。

直播稳定性

观众侧无论订阅低延迟还是 CDN 链路都可以抗弱网，支持观众在网络差时切换为仅订阅音频，或者订阅更小尺寸的视频。回过头来，我们再说说 CDN 的好处。首先，CDN 分发成本低，费用消耗往往比 RTC 链路低很多，非常利好价格敏感型项目；其次，借助遍布全球的服务节点，出海业务的跨国直播也能快速响应；