一、目前流行的直播技术架构
目前主流的直播方案一般采用RTMP架构，首先客户端采集音视频流（如obs studio客户端），然后通过 RTMP 协议将流推到流媒体服务器，最后流媒体服务器将流处理后分发给各个直播客户端。
优点：
良好的 CDN 支持，目前主流的 CDN 厂商都有比较成熟的解决方案，另外也有可用的商用 SDK 方便集成，例如声网等，只要集成对应平台的 SDK 即可。由于有 CDN 的支持，相较于端对端的 webrtc 方式，其并发度高，适合多人直播场景。缺点：
由于 RTMP 协议基于是 TCP 的，相对于基于 UDP 协议的 WebRTC 方式延时较大，所以对于某些低延时场景体验较差，这也是为什么现在直播应用中只能通过弹幕的方式与主播互动，不能实时连麦互动了，因为延迟太大，体验太差。
浏览器没有集成对 RTMP 协议的支持，所以不支持浏览器推流等，需要主播端安装特定的客户端软件。
二、基于端对端的 WebRTC 直播方案
严格的讲，基于端对端的 WebRTC 直播方式不属于 WebRTC 常规应用场景，WebRTC 设计之初是用来进行多人实时通信的，所以 WebRTC 代码中集成了很多语音方面的算法，如人声检测等。若将 WebRTC 应用在直播方案中，则主要工作流程如下图所示：
- 优点：
单纯使用 Javascript 在 Web 端即可实现推流，这对于开发者来说，简化了音视频通信的开发工作，降低了门槛低，不必熟悉流媒体等技术细节；对于主播来说，在浏览器中打开网页即可进行直播，方便快捷。
如果点对点连接成功就可以不通过服务器中转，可以节省服务器带宽费用。
相对于基于 TCP 的 RTMP 推拉流方式，基于 UDP 的 webrtc 方式延时更低。
- 缺点：
- PC 端浏览器的性能有局限，如果是 1v1 方式的直播连麦，浏览器尚能支撑；如果同时进行多人直播连麦，则浏览器需要同时给多人推流，这对于浏览器来说恐难支撑。
- 虽然目前浏览器提供的 WebRTC Javascript API 越来越多，但一旦现有 API 无法满足需求，则单纯的依靠 JavaScript 恐难为力（可以修改 WebRTC C++源码，另外开发浏览器客户端提供 Javascript 接口，但这就失去了主流浏览器支持 WebRTC 的天然优势）。
- 音视频的传输质量难以保障，尤其在跨地区、跨运营商的情况下，即便可以端对端连接成功，但质量也难保障。
- 由于端对端连接没有经过服务器，所以无法在服务器端对直播流进行审录制回放等。
三、基于服务器转发的 WebRTC 直播方案
基于端对端的 WebRTC 直播方式受限于浏览器性能、连接人数等限制，很难适用于直播场景。为了解决这些问题，从而引入媒体服务器，主播客户端仅传输一路音视频流到媒体服务器，其余客户端通过与媒体服务器建立连接获取音视频流。
目前适用于 WebRTC 的媒体服务器有 SFU 和 MUC 两种类型，两种的差别可以参考：
WebRTC的三种架构虽然两种类型的 WebRTC 服务器架构都有开源的解决方案，也存在一些商用的解决方案，但终究没有基于RTMP+CDN方式的直播方案成熟，这也就意味着一旦采用此方案需要投入更大的研发力度。
基于服务器转发的 WebRTC 直播方案虽然看起来和当前流行的RTMP+CDN方式类似，都经过了服务器的转发，但 WebRTC 基于 UDP 方式延迟可以做到更低，且 WebRTC 内置了很多音视频方面的算法，如 AEC, VAD, VP9 等，并且在网络传输方面做了很多优化工作。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
