上次写作还是在上次之——WebRTC（一）

背景

一切还得从九月份一个认真工作（摸🐟）的下午说起，在一个名为“便宜又好用的前端”群里有位贴心的老大哥关心我的情感状况，碍于面子的我只好以“撩妹只会影响学习 Rust 的速度”为由进行搪塞，想不到老大哥竟提出了输出 Rust 文章以证明清白的要求，那我只好唯唯诺诺地答应了。但最近确实十分慵懒，对于 Rust 产出 WebAssembly 再结合 Vite 的方案属实没有研究透，自然也就没有这个底气输出文章。但最近还是有关注 WebRTC 方面的知识，心想“不如...厚个脸皮，再搪塞一次吧👀”。

前言

该系列将会以 WebRTC 相关技术作为写作主题，目前您看到的是该系列的第一篇，至于会有多少篇俺也不知道，但不会是（说不定就是）最后一篇。各位看官看个乐，文章有错误或欠缺之处还请您能指出。

WebRTC 是个啥？

WebRTC 是由 Google 于 2011 年开源的一个库，或称其为一套解决方案，于 2021 年 1 月正式成为 W3C 与 IETF 标准。主要用于音视频数据的传输，当下如娱乐、教育直播及线上会议等场景都有其用武之地。

当下实时通信存在的矛盾

古人云鱼与熊掌不可兼得，就好比在开发时咱们总在思考时间与空间的问题。针对业务场景，做一名合格的“端水大师”才能打磨出高质量且符合业务需求的产品。

有哪些质量指标？

当下咱们使用较多的直播客户端产品大概有两类，其代表分别是线上会议产品（如腾讯会议）及直播类产品（如斗鱼、虎牙）。线上会议类产品注重实时交互，对实时性要求较高。直播类产品则更注重音视频质量，允许一定程度内的延迟，可一旦画质感人咱也就不想看了。因此简单地梳理出以下两个指标：

• 实时性

• 服务质量

存在什么矛盾？

上面咱们总结了实时性及服务质量两个指标，对用户来说就是在使用产品过程中“网络好不好”及“画质清不清晰”，因此要提升产品的服务质量咱们就可以从这两个大指标着手优化。音视频直播服务质量的高低很大程度取决于其数据传输质量，因此可以有以下优化方法：

• 减少数据量

• 提高网络带宽

• 适当增加时延

• 提高网络质量

• 动态评估网络带宽

既然有了优化思路，那么咱们能否提供实时性强且服务质量高的服务呢？理论上是可以的，但在打磨一款产品的时候我们必须控成本，总不能为了提高实时性而无上限地提高网络带宽（土豪请忽略），也不能为了提高服务质量而使用超出成本预算的网络传输线路。因此就形成了音视频服务质量与网络带宽大小、质量及实时性之间的矛盾，咱们只有平衡两者或将重心放在某一侧才能令成本可控。

WebRTC 如何淡化矛盾

实际上 WebRTC 也是围绕上文提到的五个方向来保证或提升音视频服务质量的，但其解决方案中已经实现了大量的优化模块，如下图。

（摘自《WebRTC音视频实时互动技术：原理、实战与源码分析》）

WebRTC 的优势

要区分优劣就需要引入参照物，无非是自研架构或者基于 WebRTC，以下咱们分别聊聊两者。

先看看自研架构

一个完整的直播客户端至少包含以下模块：

• 音视频采集

• 音视频编码

• 音视频数据传输

• 音视频解码

• 音视频渲染

从上图可以看出要实现直播客户端至少包含五个模块，但实则在开发过程中音频及视频的处理是完全独立的，无论是音频或是视频都有多种编解码器。那么就意味着在细化架构后，在自研过程中要实现的音视频直播客户端模块不止五个，而且在实现过程中还需要面对该架构能否跨平台或跨端的问题，因此自研模块的开发及维护成本将会相对较高。

再看看 WebRTC 架构

根据以下架构图可以了解到大致分为四层：

• 接口层

• Session 层（会话管理）

• 引擎层（提供音视频引擎、制定数据传输规范）

• 设备层（管理音视频数据采集设备）

下面将简要介绍每一层的作用。

（摘自WebRTC官网）

接口层

接口层包括 Web API 及 WebRTC C++ API 两部分，那就意味着咱们不但可以在 PC 端上实现音视频直播功能，还能在移动端（Android/IOS）上实现，也就说明已解决了跨端的问题。

Session 层

该层承担了端与端之间的会话建立、会话管理等工作，再细化一些会涉及到媒体协商、交换对端信息等内容。也就是说其定义了一种通用的会话机制供开发者使用，若是自研架构则还需考虑会话建立问题。

引擎层

该层涵盖了音频引擎、视频引擎及定义了网络传输规范，俺认为是 WebRTC 核心中的核心。音频方面包括了 NetEQ（音频质量优化技术）、编解码器（Opus、iLBC 等）、3A（算法）。视频方面有 Jitter Buffer（视频质量优化技术）及各类编解码器（H264、VP8、VP9）。再者是网络传输方面，其定义了端与端之间如何连接、如何交换数据，其中有一个非常重要的“打洞”（NAT 穿越）行为也将在后续的文章中分享。

设备层

该层主要通过访问硬件设备采集音视频数据及最终在指定端上渲染数据，对于常用的 Windows 及 macOS 而言两者通过 I/O 访问硬件设备的方式是有一定差异的，但在该层的帮助下已抹去了两者的差异，妈妈再也不用为我加班解决跨平台问题而操心了👀。

优劣总结

不多说了，看图吧。

（摘自《WebRTC音视频实时互动技术：原理、实战与源码分析》）

本篇最后

本篇主要讲述了 WebRTC 的一些概念及设计理念，篇幅较短且内容较虚🤐，但也算给该系列开了个头。下一篇将会讲述如何构建 WebRTC 的信令服务器及通过代码实现一个最简单的一对一通信案例，还请各位看官期待。最后，感谢您阅读本文，这一定（真）不会是最后一篇。