基于WebRTC搭建一个目前最流行视频会议服务架构

工程师 (已认证)

原创分享签约作者

发表于教程文章

1501

什么是 WebRTC ？

WebRTC 是由一家名为 Gobal IP Solutions，简称 GIPS 的瑞典公司开发的。Google 在 2011 年收购了 GIPS，并将其源代码开源。然后又与 IETF 和 W3C 的相关标准机构合作，以确保行业达成共识。其中：

Web Real-Time Communications (WEBRTC) W3C 组织：定义浏览器 API。
Real-Time Communication in Web-browsers (RTCWEB) IETF 标准组织：定义其所需的协议，数据，安全性等手段。

简单来说，WebRTC 是一个可以在 Web 应用程序中实现音频，视频和数据的实时通信的开源项目。在实时通信中，音视频的采集和处理是一个很复杂的过程。比如音视频流的编解码、降噪和回声消除等，但是在 WebRTC 中，这一切都交由浏览器的底层封装来完成。我们可以直接拿到优化后的媒体流，然后将其输出到本地屏幕和扬声器，或者转发给其对等端。

时序图：

搭建设计架构可以采用下面3种模式中的一种：

我使用的是第一种Mesh架构，无需任何流媒体服务器，直接利用成熟的WebRTC协议。该体系架构基于从每一个发送者创建多个一对一的数据流到每一个接收端。客户端创建多个对等连接，连接数量基于房间内的其它成员数。

入门篇

先请出我们今天的主角 - WebRTC，它是由谷歌推广的实时音视频技术栈，是音视频领域搜索热度最高的技术。它有多重身份，既是W3C的标准，也是一个开源项目，还有一个对应的IETF工作组(RTCWEB)。在WebRTC出现之前，音视频通信是高不可攀的领域，需要大量的专业积累才能入门，而现在，越来越多的开发者通过WebRTC来深入了解RTC技术。

WebRTC技术的本质是构建点对点的实时通信，目前主流的浏览器，包括Chrome, Firefox, Edge等，天然就支持WebRTC协议。对入门开发者来说，选用这几款浏览器，连开发客户端的时间都省了。最简单的Web视频会议，只需要架设一个Web服务器，服务器兼具信令交换的能力(信令服务也可以独立部署)，两个浏览器通过Web Server交换会话信息，就能建立P2P通道来传输媒体流，进行1v1的视频会议。如下图所示。

两个浏览器向Web服务器请求页面，并进行SDP交换，然后在浏览器之间直接建立P2P Transport，进行媒体流传输。这是最简单的WebRTC应用形式。

这种简单的媒体流直联的方式，线上有很多教程，也可以参考WebRTC的demo (https://webrtc.github.io/samples/)，这里不展开。

如果拓展到多方的视频会议，架构是这样的：

可以看到，这种”简单”的视频会议，有两个风险点：

P2P在两个客户端之间建立，不可避免的涉及到NAT穿透的问题，打洞的成功率直接影响P2P的可用性，在会议场景是不能接受的。

在多人场景下，本地的媒体流以拷贝的形式发送给每个对端，对网络带宽是个极大的浪费，上行网络的带宽瓶颈决定了会议的方数上限，影响体验，也不利于扩展。

要解决这两个问题，就要引入媒体服务器。看下面的架构图：

加入媒体服务器后，每个浏览器只和服务器建立媒体传输通道。

媒体服务器架设在公网，P2P的可用性有保障。

每个浏览器只向服务器发送一路本地媒体流，由服务器负责转发给远端，避免了带宽浪费。

对于视频会议来说，这是更优的架构选择。

常用的媒体服务器主要分为SFU(Selected Forward Unit)和MCU(Multipoint Control Unit)，SFU只负责媒体流转发，不做太多复杂的媒体处理，并发能力会强一些。MCU除了媒体流的接收/发送，还会进行转码和混流，对服务器的性能要求比较高，在实时传输系统中，转码会带来额外的延时，在选型时也必须考虑。多人视频会议场景下的SFU/MCU架构示意如图：

SFU对接入的媒体流进行全网转发，MCU对接收到的媒体流做转码后，只转发一路合成后的媒体流。它们的优势和劣势总结如下表：

WebRTC的生态中，有许多优秀的开源媒体服务器，下面列出部分关注度高的项目。

大家可以根据自己的需求，选择合适的项目来搭建媒体服务器。对于实时性和高并发有强要求的会议场景，笔者还是推荐采用SFU架构，下面的进阶篇中也会基于SFU展开介绍。

另外，如果不满足于浏览器入会，有扩展客户端覆盖的需求，上述的开源项目中，也有相应的native的客户端库，比如mediaSoup，有提供一个libmediasoupclient的C++ library，这个库本身是基于libwebrtc的，大家可以基于这个库来搭建iOS/Andriod/PC的客户端，需要一定的时间摸索编译环境，但不会太复杂。

这还不是WebRTC生态的全部，在客户端扩展方面，WebRTC是一直走在路上的，各种前沿的混合开发框架项目中，都能看到它的身影，比如RN/Flutter/Cordova等等，在Github上都有WebRTC开发库，愿意实践的开发者可以尝试，不过，要用这些开发框架做到产品化，还是需要一定积累的，需要踩一些坑。

到这里，我们完成了基础的视频会议搭建，或许在通话时会面对这样那样的质量问题，但至少实现了听得见、看得到，浅尝则止的目标已达成。下面的进阶篇，就留给打算深入学习RTC的小伙伴(需要一些音视频基础)。

进阶篇

视频会议的基础是实时音视频通信(RTC)技术，在上一篇解决了听得见、看得到的问题之后，在接下来的进阶篇中，我们重点关注下如何能让音视频通信稳定、流畅、可靠，也就是关乎视频会议的质量体验问题。

大家可能都会有这样的体会，视频会议总是很难保持稳定，偶尔会视频卡住，或者声音断续，或是今天可以正常完会，改天就不好。其实实时音视频通信的原理就是信号的采集，处理和传输，而其中传输部分是最难把控的，为了做到实时性，我们要摒弃长时延、可靠的TCP，选择不可靠，但有可能做到实时的UDP。在公共互联网上用UDP搭建传输网络，它的不可靠的因子会被放大，比如时延，抖动，丢包等，都有可能影响视频会议的体验。

下面的章节中，我们重点介绍实时音视频通信中的Quality of Service(QoS)。QoS可以狭义地理解为链路分组数据传输的质量指标，相对的另一个指标是Quality of Experience(QoE)，它是用户对设备，网络和系统总体的端到端主观体验。

QoS那些事

WebRTC中已经具备了一些保障QoS的策略，比如ARQ，FEC，Jitter Buffer，Congestion Control等，让我们结合前面的SFU架构来展开探讨。

QoS策略的主要任务是对抗影响数据传输的网络变量，比如时延，抖动，丢包，带宽等。我们简单介绍下QoS的常规武器。

ARQ：自动重传请求，是数据链路层的错误纠正协议之一，WebRTC中用到是协议中的NACK机制，即接收端监测到数据包SeqN丢失后，发送对该数据包的重传请求，由发送端执行重传。
FEC：前向纠错，是增加数据通讯可靠度的方法，利用原始数据编码进行冗余信息的传输，当传输中出现丢包，允许接收端根据冗余信息重建。WebRTC利用UlpFEC进行数据保护，冗余系数由链路上的丢包率决定。
Jitter Buffer：抖动缓冲，通过在接收端维护一个数据缓冲区，可以对抗一定程度的网络抖动，丢包和乱序，需要考虑的是接收延时和卡顿之间的平衡。
Congestion Control：拥塞控制， WebRTC利用GCC算法来控制传输，通过兼顾丢包和时延的算法来估计网络可用带宽，并以此估算值来控制源端发送码率，避免网络拥堵。

在典型的SFU传输链路中，媒体流(RTP数据包)由Sender发送到Receiver，媒体控制流(RTCP包)由Receiver反馈给Sender。控制流中包括了NACK, PLI, REMB, Receiver Report等反馈信息。这些反馈信息是配合QoS策略的辅助手段。

有了这些QoS策略的加持，WebRTC的视频通话能够对抗一定程度的网络状况，正常情况下的通话质量可以保障。但是，这种默认的策略也存在明显的改进空间，比如：

QoS的策略是在端到端之间生效的，接收端发现丢包后，才会向发送端发送NACK请求重传，全链路的路径(rtt)过长，影响数据重传和恢复的效率。
接收端在发现无法恢复视频帧后，才会发送PLI(Picture Lost Indicator)向源端请求关键帧，直到下一个关键帧到达前，所有链路上的视频帧都无法正常解码，影响接收端的视频帧率，较大概率造成卡顿。

针对这两个典型的问题，我们可以分别尝试改进。