RTMP，WebRTC，UDP 三种互动直播方案的优劣比较(非原
首先我最近在做一个视频直播的功能（正在谈的项目有这个功能，但是还没谈好），还有一个多人视频的demo（demo是为了竞标，三五个人能正常使用就行了。）
然后在这之前一点直播经验都没有的我有点方。各种百度解决问题。然后找到了一种ffmpeg+nginx的解决方案。后来又看了一些直播的知识，看到一个帖子说的挺好的，虽然帖子最后居然是个打广告的。。
前期的叙说我是看明白了，并且信了。然后因为不是一个平台，我也不知道怎么保存这个帖子，所以就粘贴了一份啊，先附上这个文章的链接：
RTMP，WebRTC，UDP 三种互动直播方案的优劣比较
正文
据《 2017 年中国直播行业研究报告》显示，直播行业用户人数达到了 4.2 亿，同比增速超过 50%，整体直播市场的总营收达到 304.5 亿元，比去年同期增长近 39%。
直播作为一种新兴社交方式，已然成为一项互联网基础应用，也成为技术大牛们探索更高效轻量的技术方案的新阵地。
由于用户对社交互动的强烈需求，“互动直播”已成为直播发展趋势。通过视频连麦，用户之间可以进行视频互动，达到更深层次的超越语言文字的交流。
那么互动直播是怎样实现的呢？主要有以下几种可以实现的技术方案：
-
基于RTMP 和 CDN 技术的连麦
-
基于 WebRTC（P2P）与旁路直播的连麦
-
基于低延时网络的连麦
那这三种技术方案该如何权衡选择呢？它们又有何优劣呢？
基于 RTMP 技术的连麦
image
当有连麦者时，则主播端和连麦端，都分别推一路 RTMP 流到 CDN，CDN 再将这两路 RTMP 流发送给观众端，观众端将两路 RTMP 流合成为一个画面。
RTMP 是基于 TCP 的标准协议，与 CDN 架构兼容，对客户来说在现有单向直播架构上，接入成本比较低，但是缺点也很明显：
-
主播与连麦者交互时，声音会产生干扰，形成回音；
-
播与连麦者进行交互，在 CDN 中传输延时较大；
-
观众端要接收两条视频流，带宽、流量消耗过大，并且两路视频流解码播放，耗费CPU等资源也非常多。
基于 WebRTC 方式的连麦
image
WebRTC 是 Google 公司的开源技术，降低了音视频通信的接入门槛。也有公司采用该项技术实现连麦。主播与连麦 用户采用 P2P 方式进行交互，然后在主播端进行混流，然后在 CDN 上进行混流，发送到观众端。
WebRTC 的好处在于用户体验好，不需要安装东西，分享一个链接就可以看。
但这套方案需要主播端上传两路视频：一路 P2P 与连麦者进行交互，一路使用 RTMP 推到 CDN。还要下载一路视频：连麦者P2P发送过来的交互数据。对主播端带宽需求较高。
另外，主播端需要进行多路视频的编码、解码，又对主播端设备配置要求较高。而由于主播端和连麦者经过 CDN 合并成一路，无法实现主播端和连麦者视频大小窗口切换。
基于低延时网络的连麦
基于 UDP 的私有协议与 RTMP 相比具有先天的优势，它是面向无连接的，避免了 TCP 做网络质量控制所需要的开销，能够做到比较低的延迟。
但是私有协议的兼容性不好，如果采用该方案也需要解决一系列的技术问题：
-
UDP 的可靠性传输如丢包重传、网络抖动的处理
-
网路拥塞的控制算法
-
在全球节点的部署与智能调度
-
各种端的全面支持
而以上问题都是在短期内很难实现的。
基于 RTMP 和 CDN 技术的连麦方案，对于产品来说非常可靠稳定，但可靠的同时延时也在增大，且使用两路 RTMP 推流拉流既耗带宽又耗 CPU。基于 WebRTC P2P 方式的连麦，接入门槛低，用户体验好，却对主播端带宽及设备配置要求较高。基于低延时网络的连麦看起来很美，但私有协议的兼容性令人头大。
