良逸｜技术作者
01 什么是QoS？音视频通讯QoS是哪一类
上面的这些描述，都指的是传统的、原始的QoS的定义和技术栈，其来源于早期互联网的网络传输设备间的质量保证体系。而本文要讨论的QoS，是在一个完全不同层次的质量保证体系，我们先看一下这两个层次QoS的关系。
QoS分为两类，一类是基于网络的服务质量（Network-Based QoS）NQoS，一类是基于应用的服务质量（Application-Based QoS）AQoS。 下图展示了两种QoS不同的作用使用场景和不同的质量保障层次。
很难对特定领域做太多的针对性优化，所以本文重点讨论的音视频通讯QoS其实是一类基于应用的AQoS，是针对音视频通讯领域的相关应用程序的传输质量保障技术。
02 音视频通讯QOS背景
算法和策略进行网络传输控制，最大限度满足弱网场景下的音视频用户体验的能力」，如下图所示：
03 音视频通讯QoS面临的挑战
网络场景
各种网络条件非常复杂：网络的种类和组合多样，特别是在最后一公里，有双绞线、同轴电缆、光纤、WIFI、4G、5G等；即使同样的网络链接，又会随着不同的场景产生变化，比如4G，5G，WIFI这种无线信号，会随着位置的变化信号强弱也飘忽不定，会出现4G、5G、WIFI信号的切换。即使是有线网络，也会因为链路上多种App共用、多个用户共用，出现竞争拥塞等问题。
业务场景
用户体验
如下图所示，音视频通讯场景，用户体验主要从清晰度、流畅性、实时性三个方面来衡量。
清晰度，是用户感受到的视频画面清晰还是模糊，一般情况下分辨率越高越清晰，越清晰的画面包含的信息量就越多，传输时占用的流量就多；
流畅性，是用户感受到的视频画面运动起来的时候是顺畅还是卡顿，一般情况每秒钟看到的画面数量越多越流畅，同样每秒画面数量越多，传输时占用的流量也越多；
实时性，是音视频信息从其发生到被远端用户感受到所需要的时间，时间越短实时性越好，实时性越好对传输速度的要求就越高。
极低延时和可沉浸的场景不断涌现，用户对音视频体验，可以说是既要又要还要，而且要求越来越高，留给技术人辗转腾挪的空间越来越小。在这种趋势下，对音视频传输QOS的技术要求也变得越来越高。
本文主要讨论基于UDP传输的，最具挑战性、技术最复杂的音视频短延时通讯QoS技术，包括实时音视频通讯RTC场景和低延时直播RTS场景。
04 弱网的分类
然而，现实离这种美好相去甚远，现代的音视频通讯是建立在互联网的基础设施之上的一类应用，这让互联网的传输质量，变成了音视频通讯传输质量不可能突破的天花板。众所周知，互联网的传输是复杂的、昂贵的、不可靠的、不稳定的，没有办法搞清楚所有的传输环节的状况，我们需要对这些问题进行抽象分类，以便于更好地针对不同的场景进行有效应对，竭尽所能的保证用户的音视频体验不受太大的影响。
网络传输质量不符合预期的场景叫弱网场景，弱网分成拥塞、丢包、延时、抖动、乱序、误码等。拥塞，是可用带宽不足的表现，如同高速堵车；丢包，是数据在传输过程中丢了，不知去向，如同快递丢失包裹；延 时，一般是中转太多或者拥塞排队导致时效性变差，如同转机或堵车；抖动，是数据传输间隔忽大忽小，如果不做处理，可能会导致音视频忽快忽慢；乱序，是后发先至，先发出去的数据比后发出去的数据到的还晚，如果不处理，可能会导致音视频的回放；误码，是传输过程中数据错误，由于传输层会有校验、修正、重传，所以应用层一般都无感知、无需特别处理。
05 音视频通讯QoS技术体系
QoS技术分类
音视频通讯QoS技术和策略就是为了对抗上述弱网场景而诞生的，其目的就是尽最大可能消除因为网络变差给用户带来的体验衰退，所以对应上面讲的不同弱网场景的分类，用到的QoS技术也被分成了几大类：拥塞控制、信源控制、抗丢包、抗抖动，每一类技术都包含很多的不同的技术点和技术细节，后面再来展开。
拥塞控制，是网络状况探测和数据发送方式的决策中心，是整个发送侧QoS技术的核心，是传输控制的大脑；
信源控制，是在拥塞控制的决策下，控制音视频信源产生的方式，控制信源的码率，来适应探测出来的网络状况，实现抗拥塞的目的；
抗丢包，是在网络有丢包的场景下，对信源数据增加冗余信息，达到部分信息被丢失的场景，也能够完整地恢复出原有数据；
抗抖动，是在网络延时有波动、数据时快时慢、时有时无的情况下，增加一部分延时，对数据进行缓冲，让用户体验更流畅，不至于卡顿；
QoS在音视频通讯流程中的位置
我们知道音视频通讯是端到端的全链路通讯，其涉及的技术领域非常广泛，跨度非常大、非常复杂。比如，客户端侧就包含了市面上能见到的Windows、MacOS、iOS、Andorid四个平台的所有终端的适配、兼容、互通，甚至要跟浏览器进行互联互通，同一个平台每款不同的设备也存在较大的差异，很多时候需要单独的适配。还有音频3A（AEC、AGC、ANS）、音频编解码（Opus、AAC）、视频编解码（H264、H265、AV1）等任何一个领域展开都是非常复杂的技术栈。而云端的各种服务器也是实现互联互通不可缺少的环节，包括信令服务器、媒体服务器、混流、转码、录制、节点部署、调度选路、负载均衡等等，每个节点、每种服务都是复杂的存在。
下图是对音视频实时通讯链路功能的一个抽象，用媒体发送和媒体接收的P2P模式，省略了复杂的服务器传输部分，方便大家的理解。
压缩，就到了编码部分，用到了音视频的编码器，编码完成之后，数据依然很大，需要进行切片，然后经过RTP对切片后的数据做封装，封装完之后，从发送队列发送到网络上，经过服务器的一系列透传或处理，到达拉流客户端，拉流端收到网络发送过来的RTP数据包之后，要先进行RTP包的完整性判断，判断编码后的数据帧切片数据是否都已经被收到，之后再解RTP封装，恢复编码后的端数据帧，并送给解码器进行解码，解码完的数据送到渲染模块，用户就看到和听到了推流端的画面和声音。
从上图还可以看出两个特点，第一，QoS功能跟很多其它模块都相关，这是因为QoS技术是全链路控制的技术，需要触达的模块比较多；第二，发送侧的QoS功能明显比接收侧的QoS功能多，这是因为目前很多都是发送侧带宽估计和拥塞控制，因为这样会更接近信息产生的源头，从源头解决问题的效率更高，防患于未然。接收侧的技术往往是比较被动的，是出了问题之后的最后补救，亡羊补牢。
QoS技术体系
l 音视频推流客户端
GCC（google congestion control），一个是BBR（Bottleneck Bandwidth and Round-trip Time），两个都是谷歌推出的拥塞控制算法。
平滑发送PacedSender配对使用，很少出现只估计不控制的情况，平滑发送控制策略也是估计算法架构设计中的一部分，为了让发送的码流尽量是比较平顺的，防止忽高忽低的波动，以免对链路造成冲击，带来不必要的拥塞。
Padding数据来临时填充带宽，这些Padding数据有时是用重复发送原始包的方式，有时就干脆发一堆垃圾数据，目的只是用来填充带宽，收到之后也会将其丢掉。
带宽分配模块中，会按照一定的优先级和分配策略，将可用的带宽，分给每一条音视频流，而且在有丢包的场景，需要同时为每条音视频流分配对应的冗余信息带宽。
信源控制部分，音视频流的码控模块会根据各自的码流特征、编解码能力、技术手段进行各自的控制，例如基础的音频码率、帧长、视频的码率、帧率、分辨率、QP等基本控制，同时也有一些编码相关的特定技术点的控制，例如音频DTX（Opus编码器不连续传输-->降低带宽占用）、视频simulcast（同时推送多流-->满足不同订阅场景降低带宽）、视频SVC（可分层视频编码-->实现动态抽帧能力降低拥塞）、视频LTR（长期参考帧-->降低重传带宽）、视频屏幕共享SCC（屏幕内容编码-->降低屏幕共享场景带宽）等等。
一种是丢包重传，收流端发现数据丢包了，不再连续的时候，主动通过NACK报文（RTCP报文的一种）发送重传请求到推流端，而推流端则需要随时缓存之前发过的数据，以满足丢包之后的重传需求，对丢失的数据进行补发。这是一种滞后性的补救措施，所以相对比较节省带宽，但是会增加延时；
冗余信息，恢复部分或全部的原有数据。这是一种预防性的技术手段，因为冗余和原始数据同时发送，所以可以即刻进行丢包恢复，不存在延时问题，但因为有冗余信息存在，所以会占用更多的带宽。这里增加冗余信息的方式有2种，一种是RED封装，用在数据包比较小的音频传输场景；另一种是FEC编码封装，用在数据包比较大的视频或音频场景，目前有很多种FEC编码方式可用，这方面算法的研究也比较多。
l 媒体转发处理服务器SFU
分段抗丢包能力，分段意味着上行和下行分开来做抗丢包，互不影响，好处是可以简化设计，同时对不同的下行弱网和非弱网用户，可以提供按需服务，有比较强的自适应能力。收流侧和拉流侧的抗丢包跟上面说的客户端的抗丢包一样，也包含丢包请求、重传，对应RED编解封装，对应FEC编解码、编解封装的功能，这部分功能相对比较固定，在跟客户端推流侧进行SDP媒体能力协商之后，就确定了哪些功能可以开或者是关。
拥塞控制算法以及带宽分配，服务器上的这些算法跟客户端推流侧的算法基本的框架结构和基本功能都是一样的，只是算法的参数配置、使用的策略，都跟客户端是不一样的，因为服务器侧的信源控制力跟客户端推流侧的信源控制力，是完全没法比的，不可同日耳语。同时，服务器需要顾及很多的推流端和很多的拉流端，更需要平衡各种关系，众口难调是服务器面临的主要矛盾。
视频的抽帧（抽掉一些不影响解码的帧数据来降带宽）、视频切流（主动切换到带宽和清晰度较低的流上来降低带宽）、视频按需推流（根据实际的订阅关系准许推流端直推需要的流来降低带宽）、音视频带宽反馈（特定场景可以将拉流测信息反馈给推流侧让其提供更准确的码控服务）、音频AudioRanking（多人会议场景将不说话人的声音过滤掉来降低带宽）等等。服务器相关的更详细的技术点描述，可以参考《阿里云 GRTN QoS 体系 — 构建实时音视频产品最佳体验》。
l 音视频拉流客户端
长期参考帧LTR请求，这两个视频帧请求目的都是为了恢复视频帧的参考链，以便能够重新开始视频解码。
另外拉流客户端比其它部分多了抗抖动的功能，主要思想是增加一个数据缓冲的buffer，增加了一部分延时。就像一个水库一样，雨季的时候蓄水，将快速流入的水储存起来，旱季的时候放水，将之前存储起来的水慢慢放出来，确保自始至终有水流出。
音视频的拉流侧或播放侧一般都会有音视频同步（又叫唇音同步lip sync）的需求，否则会出现只闻其声不见其人，或只看到闪电听不见雷声的情况。WebRTC原有的音视频同步机制非常的复杂，我之前也有过介绍《WebRTC 音视频同步原理与实现》，而且在NetEQ及优化实践中也提到了一种简单的替代方案，这里也不展开。
06 音视频通讯QoS技术的演进
WebRTC以前
在WebRTC面世以前，因为门槛较高，音视频通讯基本都是几大头部玩家的之间的游戏，例如Polycom、华为、思科、微软、BT、Vidyo等，各家都有自己的私有架构，都在闭关修炼。他们用到的QoS技术也都是各自的武功秘籍，只能从一些公开的文章或者协议标准的提交中窥探一二。2012年当我在Polycom看到WebRTC开源的消息时，还完全没有觉得是什么了不起的事情，Polycom当时有着一众音视频技术的科学家，支持各种编解码技术，是行业里的绝对头部，没想到几年光景下来就泯然于众了。
WebRTC以后
然而，WebRTC本身定位源于P2P的互联网浏览器间的通讯，其重点在客户端侧的架构与实现，而伴随云上音视频通讯业务场景的发展，媒体转发服务器变成了两个客户端之间不可缺少的一环。支持WebRTC协议的媒体服务器也有多种，例如janus、mediasoup、srs、licode、kurento、jitsi等，可以参考《十大必知开源WebRTC服务器》。但很多媒体转发服务器SFU都只是实现了转发功能，对链路控制的QoS技术支持非常的薄弱，有的甚至聊胜于无，而且由于服务器代码架构跟WebRTC的端侧代码架构差异巨大，导致迁移原有WebRTC的QoS算法，也变得非常困难。
QoS技术算法优化阶段
这种QoS单点技术的优化升级，是提升QoS性能的核心手段，是最终提升用户体验的立足点，将会一直持续下去。但是这些单点算法优化也有瓶颈，一旦到达现有基础科学研究的天花板，想再提高就很难了，因为需要基础理论研究的突破为前提，这个投入产出不是一般商业公司愿意承担的，也不是一般的算法技术人员能够突破的，所以大部分的国内的公司和技术人员都选择了知难而退，也是大环境使然。
QoS技术架构升级阶段
随着疫情进入后半段，互联网热潮不再，IOT、云渲染、云游戏等新场景的出现，大家逐渐慢了下来，重新开始思考WebRTC这套框架是否是适合自己业务的，有没有更好的解法。对WebRTC源代码有一些了解或者参与过相关编译的同学都应该知道，WebRTC是非常庞大的一个实现，包含引用的第三方库的话，源文件数量接近20万个，这种数量级的代码给环境部署、编译配置、工程引用都带来了很大的麻烦，以至于网上有人把编译WebRTC做成了一门生意，按次收费。很少有公司能拿WebRTC直接使用，都是需要找专门的同学，做环境的配置、代码的裁剪等一系列对业务没啥价值的事情，费力不讨好。
这种架构的升级演进具体如何来做？我认为，首先要从音视频通讯技术链路和功能模块的抽象来入手，抽象到一定高度，就看清了事物的本质，看清了本质，就能比较容易看清各个模块之间的关系，然后才能物以类聚进行解耦。下图是对QoS推拉流功能和处理流程的抽象。
本文从更宏观、更宽泛的角度介绍了QoS的概念和分类，从音视频通讯QoS领域的常用技术到架构的演进过程做了简单汇总。随着音视频通讯新场景的不断涌现，更实时，更高清变得越来越重要，相关技术也会往这个方向倾斜，同时基于大数据分析的QoS相关技术应用将会逐渐渗透。