直播选择 RTC 还是 RTMP？

RTC 实时直播

RTC（Real Time Communication）实时音视频通信，它最大的特点就是低延时和无卡顿。从功能流程上说，它包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节，每一个细分环节，还有更细分的技术模块。比如，前后处理环节有美颜、滤镜、回声消除、噪声抑制等，采集有麦克风阵列等，编解码有 VP8、VP9、H.264、H.265 等等。RTC 不是靠“优化”各环节去实现的实时互动，而是依靠推流端实时的传输机制。

很多实时音视频服务专业厂商使用的就是 WebRTC 标准，这是一种基于浏览器的实时通信的开源解决方案，使用 UDP 私有协议来进行媒体推流，而不需要创建离散的媒体段。WebRTC 的好处在于用户体验好，不需要安装东西，分享一个链接就可以看。但这套方案需要主播端上传两路视频：一路 P2P 与连麦者进行交互，一路使用 RTMP 推到 CDN。还要下载一路视频：连麦者 P2P 发送过来的交互数据。对主播端带宽需求较高。另外，主播端需要进行多路视频的编码、解码，又对主播端设备配置要求较高。而由于主播端和连麦者经过 CDN 合并成一路，无法实现主播端和连麦者视频大小窗口切换。

除了低延时流传输外，WebRTC 还提供了一个实时双向数据通道，可用于发送和接收数据流。这种双向数据技术给在线流现在如何能成为一种交互式的体验提供了很多有趣的可能性。观众可以实时的在演唱会期间投票选出他们最想让歌手唱什么歌。体育粉丝可以在比赛或者比赛期间接收定制的体育直播数据统计。在线购物渠道可以显示不同客户的定制优惠或定价。这种可能性似乎可以深刻的改变实况视频的体验。

anyRTC 实时直播模式，通信的终端设备不在分发 CDN 网络，只通过 anyRTC RTN 网络进行直播，延迟可控制在 200ms 内，支持最大 50 人互动连麦，观看人数最大 100W。在频道直播过程中，可设定用户角色切换主播和观众身份，视图布局可根据客户端场景任意摆放。

RTMP+CDN 直播

RTMP （Real Time Messaging Protocol）基于 TCP 的流媒体传输协议，最大的特点是与 CDN 的强绑定，需要借助 CDN 的负载均衡系统将内容推送到接近用户的边缘节点，使用户就近取得所需内容，提高用户访问的响应速度和成功率，解决因分布、带宽、服务器性能带来的访问延迟问题。普通直播，一般采用 TCP 协议，使用 CDN 进行内容分发，会有几秒甚至十几秒的延时，主播和观众的互动只能通过文字短消息或送礼来进行。RTMP 更多适用于站点加速、点播、短视频等场景。

RTMP 是基于 TCP 的标准协议，与 CDN 架构兼容，对客户来说在现有单向直播架构上，接入成本比较低，但是缺点也很明显：主播与连麦者交互时，声音会产生干扰，形成回音；播与连麦者进行交互，在 CDN 中传输延时较大；观众端要接收两条视频流，带宽、流量消耗过大，并且两路视频流解码播放，耗费 CPU 等资源也非常多。

目前的 CDN，通常有 3-5 秒的延迟，在浏览图片、短视频等内容时用户感知不明显，对于不需要实时强互动的直播，比如体育赛事网络直播、演唱会网络直播、新闻现场直播，延迟是可以接受的，并不会影响用户体验。而在线视频会议、在线教育、电商直播、远程医疗会诊这些对互动有非常高要求的场景 RTMP+CDN 的模式与这些场景对于低延时、无卡顿的要求有一定差距。这时，选择 RTC 技术才能更好地满足开发者的需求。

有别于市面上最常见的 CDN + RTMP 直播技术，anyRTC 提供的直播方案使用独有直播技术以及 anyRTC SD-RTN，使主播端以及高级观众（嘉宾）端之间的实时通讯质量达到专线级别。此外，为满足现如今多样的直播需求，anyRTC 也与多家 CDN 进行对接，支持服务端推流到 CDN 和客户端推流到 CDN，在社交平台上分享直播内容。

一套实时音视频通信能力的搭建，除了要根据场景选择适合的技术外，还要看价格、服务的综合性价比。通常来说，使用 RTC 技术的成本比 RTMP+CDN 高。因为，从实践来看，UDP 传输比 TCP 传输对资源消耗要多，而且重传、封包、FEC 冗余计算等都会额外增加计算量，在多进程模式下可能还会遇到内存资源的过多消耗，这些都导致开发及使用成本的增加。

基于 RTMP 和 CDN 技术的连麦方案，对于产品来说非常可靠稳定，但可靠的同时延时也在增大，且使用两路 RTMP 推流拉流既耗带宽又耗 CPU。RTC 连麦方案成本高但低延时、是未来发展的趋势。开发者选型中，性价比需综合技术特点、适用场景、价格和服务四个方面的全面考量。服务在产品上线前后的开发阶段和运营阶段，都要发挥重要作用。