WebRTC的技术架构
1. 背景简介
WebRTC（Web Real-Time Communication）是一个谷歌开源项目，它提供了一套标准API，使Web应用可以直接提供实时音视频通信功能，不再需要借助任何插件。原生通信过程采用P2P协议，数据直接在浏览器之间交互，理论上不需要服务器端的参与。
为浏览器、移动平台、物联网设备提供一套用于开发功能丰富、高质量的实时音视频应用的通用协议是WebRTC的使命。
WebRTC的发展历史如下:
- 2010年5月，谷歌收购视频会议软件公司GIPS，该公司在RTC编码方面有深厚的技术积累。
- 2011年5月，谷歌开源WebRTC项目。
- 2011年10月，W3C发布第一个WebRTC规范草案。
- 2014年7月，谷歌发布视频会议产品Hangouts，该产品使用了WebRTC技术。
- 2017年11月，WebRTC进入候选推荐标准（Candidate Recommendation，CR）阶段。
image.png
2. 技术架构
WebRTC技术架构的顶层分为两个部分。
一部分是Web API，一组JavaScript接口，由W3C维护，开发人员可以使用这些API在浏览器中创建实时通信应用程序。
另一部分是适用于移动端及桌面开发的libwebrtc，即使用WebRTC C++源码在Windows、Android、iOS等平台编译后的开发包，开发人员可以使用这个开发包打造原生的WebRTC应用程序。
WebRTC规范里没有包含信令协议，这部分需要研发人员依据业务特点自行实现。
在媒体传输层，WebRTC在UDP之上增加了3个协议:
- 数据包传输层安全性协议（DTLS）用于加密媒体数据和应用程序数据。
- 安全实时传输协议（SRTP）用于传输音频和视频流。
- 流控制传输协议（SCTP）用于传输应用程序数据。
WebRTC的网络拓扑
媒体服务器是WebRTC在服务器端的实现，起到了桥梁的作用，用于连接多个WebRTC客户端，并增加了额外的媒体处理功能。通常根据提供的功能，将媒体服务器区分成MCU和SFU。
- Mesh网络结构
Mesh是WebRTC多方会话最简单的网络结构。在这种结构中，每个参与者都向其他所有参与者发送媒体流，同时接收其他所有参与者发送的媒体流。说这是最简单的网络结构，是因为它是Web-RTC原生支持的，无须媒体服务器的参与。Mesh网络结构如下图所示:
image.png
缺点:
在Mesh网络结构中，每个参与者都以P2P的方式相互连接，数据交换基本不经过中央服务器（部分无法使用P2P的场景，会经过TURN服务器）。由于每个参与者都要为其他参与者提供独立的媒体流，因此需要N-1个上行链路和N-1个下行链路。众多上行和下行链路限制了参与人数，参与人过多会导致明显卡顿，通常只能支持6人以下的实时互动场景。
由于没有媒体服务器的参与，Mesh网络结构难以对视频做额外的处理，不支持视频录制、视频转码、视频合流等操作。
- MCU网络结构
MCU（Multipoint Control Unit）是一种传统的中心化网络结构，参与者仅与中心的MCU媒体服务器连接。MCU媒体服务器合并所有参与者的视频流，生成一个包含所有参与者画面的视频流，参与者只需要拉取合流画面。
image.png
优点:
这种场景下，每个参与者只需要1个上行链路和1个下行链路。与Mesh网络结构相比，参与者所在的终端压力要小很多，可以支持更多人同时在线进行音视频通信，比较适合多人实时互动场景。
缺点:
但是MCU服务器负责所有视频编码、转码、解码、合流等复杂操作，服务器端压力较大，需要较高的配置。同时由于合流画面固定，界面布局也不够灵活。
- SFU网络结构
在SFU（Selective Forwarding Unit）网络结构中，仍然有中心节点媒体服务器，但是中心节点只负责转发，不做合流、转码等资源开销较大的媒体处理工作，所以服务器的压力会小很多，服务器配置也不像MCU的要求那么高。
每个参与者需要1个上行链路和N-1个下行链路，带宽消耗低于Mesh，但是高于MCU。
我们可以将SFU服务器视为一个WebRTC参与方，它与其他所有参与方进行1对1的建立连接，并在其中起到桥梁的作用，同时转发各个参与者的媒体数据。SFU服务器具备复制媒体数据的能力，能够将一个参与者的数据转发给多个参与者。
SFU对参与实时互动的人数也有一定的限制，适用于在线教学、大型会议等场景，其网络结构见下图:
image.png
- Simulcast联播
Simulcast技术对SFU进行了优化，发送端可以同时发送多个不同质量的媒体流给接收端。SFU能够依据参与者的网络质量，决定转发给参与者哪种质量的媒体流。
缺点:
因为发送者需要发送多个不同质量的媒体流，所以会显著增加发送设备的载荷，同时占用发送者上行带宽资源。
