WebRTC概述

前言

WebRTC的出现使实时通信技术得以广泛应用。 WebRTC制定、实现了一套统一且完 整的实时通信标准，并将这套标准开源。这套标准包含了实时通信技术涉及的所有内容， 使用这套标准，开发人员无须关注音视频编解码、网络连接、传输等底层技术细节，可以 专注于构建业务逻辑，且这些底层技术是完全免费的。

WebRTC统一了各平台的实时通信技术，大部分操作系统及浏览器都支持 WebRTC, 无须安装任何插件，就可以在浏览器端发起实时视频通话。WebRTC技术最初为Web打造，随着 WebRTC自身的演进，目前已经可以将其应用于各种应用程序。

1.WebRTC的历史

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 阶段。

2.WebRTC的技术架构

从技术实现的角度讲，在浏览器之间进行实时通信需要使用很多技术，如音视频编解 码、网络连接管理、媒体数据实时传输等，还需要提供一组易用的API给开发者使用。这 些技术组合在一起，就是 WebRTC技术架构，如下图所示。

WebRTC技术架构的顶层可以分为两个部分。一部分是Web API，一组JavaScript接口，由W3C维护，开发人员可以使用这些API在浏览器中创建实时通信应用程序。另一部分是适 用于移动端及桌面开发的 libwebrtc,即使用 WebRTC++源码在 Windows、 Android、ios 等平台编译后的开发包，开发人员可以使用这个开发包打造原生的 WebRTC应用程序。

第二层是 WebRTC++API,它是 Web API和 libwebrtc的底层实现。该层包含了连接 管理、连接设置、会话状态和数据传输的API。基于这些API,浏览器厂商可以方便地加入 对 WebRTC的支持。

WebRTC规范里没有包含信令协议，这部分需要研发人员依据业务特点自行实现 。

WebRTC支持的音频编码格式有OPUS和G.711,同时还在音频处理层实现了回音消除 及降噪功能。 WebRTC支持的视频编码格式主要有VP8和H264(还有部分浏览器支持VP9 及H265格式), WebRTC还实现了 Jitter Buffer防抖动及图像增强等高级功能 。
在媒体传输层，WebRTC在UDP之上增加了3个协议。

• 数据包传输层安全性协议(DTLS)用于加密媒体数据和应用程序数据。
• 安全实时传输协议(SRTP)用于传输音频和视频流。
• 流控制传输协议(SCTP)用于传输应用程序数据。
  WebRTC借助ICE技术在端与端之间建立P2P连接，它提供了一系列API,用于管理连接。 WebRTC还提供了摄像头、话筒、桌面等媒体采集API,使用这些API可以定制媒体流。

3.WebRTC的兼容性

据 caniuse.com统计，大部分浏览器都实现了对WebRTC的支持，各浏览器支持情况如下。

• Firefox版本22+
• Chrome版本23+
• Safari版本11+
• iOS Safari版本11+
• Edge版本15+
• Opera版本18+
• Android Browser版本81+
• Chrome for Android版本84+
• Firefox for Android版本68+
• IE不支持

Android和iOS原生应用都支持 WebRTC,可以使用原生SDK开发跨平台的 WebRTC 应用。 Android WebView自36版本之后，提供了对 WebRTC的支持，这意味可以使用 WebRTC API开发 Android混合App注意，一些手机厂商对部分 Android版本里的 Web View进行了裁剪，导致不能使用 WebRTC,这时候下载并安装最新的 Web View即可。

iOS Web View目前还不支持 WebRTC,但是可以使 cordova的插件 cordova-plugin- iosrtc在混合App中使用 WebRTC。

WebRTC目前处于活跃开发阶段，各个浏览器的实现程度不一样。为了解决兼容性的 问题，谷歌提供了 adapter库。

在 GitHub上可以下载最新版本的 adapterjs库，地址如下所示。
https://github.com/webrtc/adapter/tree/master/release

将下载的文件放到Web服务器根目录，在Web应用中引用。

4.WebRTC的网络拓扑

WebRTC规范主要介绍了使用ICE技术建立P2P的网络连接，即Mesh网络结构。在 WebRTC技术的实际应用中，衍生出了媒体服务器的用法。

使用媒体服务器的场景，通常是因为P2P连接不可控，而使用媒体服务器可以对媒体 流进行修改、分析、记录等P2P无法完成的操作。实际上，如果我们把媒体服务器看作 WebRTC连接的另外一端，就很容易理解媒体服务器的工作原理了。媒体服务器是WebRTC在服务器端的实现，起到了桥梁的作用，用于连接多个 WebRTC客户端，并增加了额外的媒体处理功能。通常根据提供的功能将媒体服务器区分成MCU和SFU。

4.1 Mesh网络结构

Mesh是WebRTC多方会话最简单的网络结构。在这种结构中，每个参与者都向其他所有参与者发送媒体流，同时接收其他所有参 与者发送的媒体流。说这是最简单的网络结构，是因为它是Web RTC原生支持的，无须媒体服务器的参与。Mesh网络结构如图所示。

在Mesh网络结构中，每个参与者都以P2P的方式相互连接，数据交换基本不经过中央 服务器(部分无法使用P2P的场景，会经过TURN服务器)。由于每个参与者都要为其他参 与者提供独立的媒体流，因此需要N-个上行链路和N-1个下行链路。众多上行和下行链 路限制了参与人数，参与人过多会导致明显卡顿，通常只能支持6人以下的实时互动场景。由于没有媒体服务器的参与，Mesh网络结构难以对视频做额外的处理，不支持视频录制、视频转码、视频合流等操作。

4.2 MCU网络结构

MCU( Multipoint Control Unit)是一种传统的中心化网络结构，参与者仅与中心的 MCU媒体服务器连接。MCU媒体服务器合并所有参与者的视频流，生成一个包含所有参与者画面的视频流，参与者只需要拉取合流画面，MCU网络结构如下图所示。这种场景下，每个参与者只需要1个上行链路和1个下行链路了。

与Mesh网络结构相比，参与者所在的终端压力要小很多，可以支持更多人同时在线进行音视频通信。但是MCU服务器负责所有视频编码、转码、解码、合流等复杂操作，服务器端压力较大，需要较高的配置。同时由于合流画面固定，界面布局也不够灵活。

4.3 SFU网络结构

在SFU( Selective Forwarding Unit)网络结构中，仍然有中心节点媒体服务器，但是中心节点只负责转发，不做合流、转码等资源开销较大的媒体处理工作，所以服务器的压 力会小很多，服务器配置也不像MCU的要求那么高。每个参与者需要1个上行链路和N-1个下行链路，带宽消耗低于Mesh,但是高于MCU。

我们可以将SFU服务器视为一个 WebRTC参与方，它与其他所有参与方进行1对1的 建立连接，并在其中起到桥梁的作用，同时转发各个参与者的媒 体数据。SFU服务器具备复制媒体数据的能力，能够将一个参与 者的数据转发给多个参与者。SFU服务器与TURN服务器不同， TURN服务器仅仅是为 WebRTC客户端提供的一种辅助数据转发通道，在无法使用P2P的情况下进行透明的数据转发，TURN服务器不具备复制、转发媒体数据的能力。

下图为各解决方案的流量对比图

那么我们应该使用哪种架构呢？

这个就需要根据自己的项目的需要了。其实，商业解决方案，包括上述所有方案，往往需要根据客户的实际应用场景选择对于的方法。不过，也有经验，你可以使用一些通用规则。

1. 如果你仅是提供P2P音视频传输的服务，Mesh架构可能是最适合你的。另外，如果基础设施的成本不是问题，并且参与者具有异构连接，这可以是一个很好的解决方案。
2. 假设你提供企业级服务，且有较好的宽带和高效的硬件（即一个企业内部服务），参加人数是有限的，那么你非常适合MCU方案。
3. 一般来说，如果你提供大规模服务的，应优先考虑到SFU的方案。Router传输接近把情报在网络的边界，构建最终用户应用程序时，以达到更好的可扩展性和灵活性的网络的范例

Simulcast联播

在进行 WebRTC多方视频会话时，参与人数较多，硬件设施、网络环境均有差异，这种情况下如何确保会话质量呢?使用MCU时，这个问题相对简单一些。MCU可以根据参与者的网络质量和设备能力，提供不同的清晰度和码率。但是随之而来的问题是服务器资源压力较大，难以支撑大规模并发，同时也显著增加了使用成本。

多人会话场景选择SFU网络结构是目前通用的做法。早期的SFU只是将媒体流从发送 端转发给接收端，无法独立为不同参与者调整视频码率，其结果是发送者需要自行调整码 率，以适应接收条件最差的参与者。而那些网络环境较好的参与者只能接收相同质量的媒 体流，别无选择。

Simulcast技术对SFU进行了优化，发送端可以同时发送多个不同质量的媒体流给接收 端。SFU能够依据参与者的网络质量，决定转发给参与者哪种质量的媒体流。因为发送者需要发送多个不同质量的媒体流所以会显著增加发送设备的载荷，同时占用发送者上行带宽资源。

可伸缩视频编码

可伸缩视频编码( Scalable Video Coding,SVC)是 Simulcast的改进技术。它使用分层编码技术，发送端只需要发送一个独立的视频流给SFU,SFU根据不同的层，解码出不同 质量的视频流，并发送给不同接收条件的参与者。

SVC中多个层次的媒体流相互依赖，较高质量的媒体数据需要较低质量的媒体数据解码。SFU接收到SVC编码的内容后，根据客户端的接收条件选择不同的编码层次，从而获得不同质量的媒体流。

如果媒体流包括多个不同分辨率的层，则称该编码具有空间可伸缩性；如果媒体流包 含多个不同帧率的层，则称该编码具有时间可伸缩性；如果媒体流包含多个不同码率的层，则称该编码具有质量可伸缩性。

在编码空间、时间、质量均可伸缩的情况下，SFU可以生成不同的视频流，以适应不同客户端的接收条件。

总结

本文仅对WebRTC作一个简单的介绍，具体参考了栗伟老师的书《WebRTC技术详解》以及其他的一些博客，在此表示感谢。