1，WebRTC介绍
WebRTC是Web实时通信技术（Web Real-Time Communication）的缩写，是谷歌收购Global IP Solutions公司而获得的一项技术，并且谷歌将其开源。
WebRTC提供了实时音视频的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，WebRTC虽然冠以“Web”之名，但并不受限于传统互联网应用或浏览器的终端运行环境。实际上，无论终端运行环境是浏览器、桌面应用、Android、iOS、IoT设备，只要IP连接可到达且符合WebRTC规范就可以互通。
webRTC架构图
架构图颜色标识说明
- 紫色以及浅紫色部分是Web开发者API层
- 蓝色实线部分是面向浏览器厂商的API层
- 蓝色虚线部分浏览器厂商可以自定义实现
Web API
Web API层表示的是WebRTC开放给应用层开发人员的API(主要是JavaScript API 供web端使用), 在这层中开发者无需关心复杂的底层技术，只需了解webRTC的大致流程原理，调其API即可利用webRTC实现点对点的通讯功能。
WebRTC C++ API
主要是一些C++的接口层，这一层提供了一些 C++ API，主要是供浏览器支持WebRTC规范而调用的API。
Session management
提供了会话功能管理功能，可进行创建会话、管理会话、管理上下文环境等。而这一层又会涉及到各种协议，比如说信令服务器的SDP协议等，主要用于进行信令交互和管理 RTCPeerConnection的连接状态。
引擎层
这一层又分为三个小模块，分别是：Voice Engine（音频引擎）、Video Engine（视频引擎）以及Transport（传输模块）。
引擎层我们主要关注P2P模块。WebRTC是一种基于P2P的通信技术。而STUN、TURN、ICE这些则是实现P2P的一些关键技术。
STUN、TURN、ICE又称为NAT穿透，在现实生活中不同局域网中的内外ip是无法直接通信的，比如说局域网A中192.168.2.1与局域网B中192.168.2.2是无法互相直接发送消息的， 那么如果要在两个不同的局域网中建立起可以直接通信的通道就得依靠STUN+TURN+ICE这些技术。
驱动层
也就是蓝色虚线部分，这部分由Audio Capture/Render（音频的采集和渲染模块）、Video Capture（视频采集模块）和Network I/O（网络IO模块）组成。
2，音视频采集基本概念介绍
- 摄像头。 用于捕捉（采集）图像和视频。
- 帧率。 现在的摄像头功能已非常强大，一般情况下，一秒钟可以采集 30 张以上的图像，一些好的摄像头甚至可以采集 100 张以上。我们把摄像头一秒钟采集图像的次数称为帧率。帧率越高，视频就越平滑流畅。然而，在直播系统中一般不会设置太高的帧率，因为帧率越高，占的网络带宽就越多。
- 分辨率。 摄像头除了可以设置帧率之外，还可以调整分辨率。我们常见的分辨率有 2K、1080P、720P、420P等。分辨率越高图像就越清晰，但同时也带来一个问题，即占用的带宽也就越多。所以，在直播系统中，分辨率的高低与网络带宽有紧密的联系。也就是说，分辨率会跟据你的网络带宽进行动态调整。
- 宽高比。 分辨率一般分为两种宽高比，即 16:9 或 4:3。4:3的宽高比是从黑白电视而来，而 16:9的宽高比是从显示器而来。现在一般情况下都采用 16:9的比例。
- 麦克风。 用于采集音频数据。它与视频一样，可以指定一秒内采样的次数，称为采样率。每个采样用几个bit表示，称为采样位深或采样大小。
- 轨（Track）。 WebRTC 中的“轨”借鉴了多媒体的概念。火车轨道的特性你应该非常清楚，两条轨永远不会相交。“轨”在多媒体中表达的就是每条轨数据都是独立的，不会与其他轨相交，如 MP4 中的音频轨、视频轨，它们在 MP4 文件中是被分别存储的。
- 流（Stream）。 可以理解为容器。在 WebRTC 中，“流”可以分为媒体流（MediaStream）和数据流（DataStream）。其中，媒体流可以存放0个或多个音频轨或视频轨；数据流可以存0个或多个数据轨。
3，WebRTC 1对1音视频实时通话过程
这幅图从大的方面可以分为4部分，即两个 WebRTC 终端（上图中的两个大方框）、一个 Signal（信令）服务器和一个 STUN/TURN 服务器。
- WebRTC 终端，负责音视频采集、编解码、NAT 穿越、音视频数据传输。
- Signal 服务器，负责信令处理，如加入房间、离开房间、媒体协商消息的传递等。
- STUN/TURN服务器，负责获取WebRTC终端在公网的IP地址，以及NAT穿越失败后的数据中转。
当一端（WebRTC终端）进入房间之前，它首先会检测自己的设备是否可用。如果此时设备可用，则进行音视频数据采集。
采集到的数据一方面可以做预览，也就是让自己可以看到自己的视频；另一方面，可以将其录制下来保存成文件，等到视频通话结束后，上传到服务器让用户回看之前的内容。
在获取音视频数据就绪后，WebRTC终端要发送 “加入” 信令到 Signal 服务器。Signal 服务器收到该消息后会创建房间。在另外一端，也要做同样的事情，只不过它不是创建房间，而是加入房间了。待第二个终端成功加入房间后，第一个用户会收到 “另一个用户已经加入成功” 的消息。
此时，第一个终端将创建 “媒体连接” 对象，即RTCPeerConnection（并将采集到的音视频数据通过 RTCPeerConnection 对象进行编码，最终通过 P2P 传送给对端。
当然，在进行 P2P 穿越时很有可能失败。当P2P穿越失败时，为了保障音视频数据仍然可以互通，则需要通过 TURN 服务器进行音视频数据中转。
对端收到音视频数据后，首先将收到的音视频数据进行解码，最后再将其展示出来，这样就完成了一端到另一端的单通。如果双方要互通，两方都要通过 RTCPeerConnection 对象传输自己一端的数据，并从另一端接收数据。
4，多人音视频直播架构方案
比较常见的WebRTC 的多对多实时通信架构有以下三种：
Mesh（网络拓扑）方案
多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当A想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
Mesh方案架构图
上图中的B1、B2、B3、B4 分别表示4个浏览器，它们之间两两相连，同时还分别与 STUN/TURN服务器进行连接
当某个浏览器想要共享它的音视频流时，它会将共享的媒体流分别发送给其他3个浏览器，这样就实现了多人通信。这种结构的优势有如下：
- 不需要服务器中转数据，STUN/TUTN只是负责 NAT 穿越，这样利用现有 WebRTC 通信模型就可以实现，而不需要开发媒体服务器。
- 充分利用了客户端的带宽资源。
- 节省了服务器资源，由于服务器带宽往往是专线，价格昂贵，这种方案可以很好地控制成本。
不足：
- 共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，这样对上行带宽的占用很大。参与人越多，占用的带宽就越大。除此之外，对 CPU、Memory 等资源也是极大的考验。一般来说，客户端的机器资源、带宽资源往往是有限的，资源占用和参与人数是线性相关的。这样导致多人通信的规模非常有限，通过实践来看，这种方案在超过4个人时，就会有非常大的问题。
MCU（Multipoint Conferencing Unit）方案
MCU 主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。
MCU方案架构图
我们假设一个B1 与 B2 同时共享音视频流，它们首先将流推送给 MCU 服务器，MCU服务器收到两路流后，分别将两路流进行解码，之后将解码后的两路流进行混流，然后再编码，编码后的流数据再分发给 B3 和 B4。
MCU 主要的处理逻辑如下图所示：
这个处理过程如下所示：
- 接收共享端发送的音视频流。
- 将接收到的音视频流进行解码。
- 对于视频流，要进行重新布局，混合处理。
- 对于音频流，要进行混音、重采样处理。
- 将混合后的音视频进行重新编码。
- 发送给接收客户端。
优点：
- 作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化
不足：
- 重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大。
SFU（Selective Forwarding Unit）方案
该方案也是由一个服务器和多个终端组成，但与MCU不同的是，SFU不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。
SFU方案架构图
上图中B1、B2、B3、B4 分别代表4个浏览器，每一个浏览器都会共享一路流发给 SFU，SFU 会将每一路流转发给共享者之外的3个浏览器。
优点：
- 由于是数据包直接转发，不需要编码、解码，对 CPU 资源消耗很小。
- 直接转发也极大地降低了延迟，提高了实时性。
不足：
- 由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步；相同的视频流，不同的参与人看到的画面也可能不一致。
- 参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。总之，整体在通用性、一致性方面比较差。
参考链接: