共计 10979 个字符，预计需要花费 28 分钟才能阅读完成。
利用多种算法和策略进行网络传输管制，最大限度满足弱网场景下的音视频用户体验。
良逸|技术作者
01 什么是 QoS？音视频通信 QoS 是哪一类？
QoS（Quality of Service）是服务质量的缩写，指一个网络可能利用各种根底技术，为指定的网络通信提供更好的服务能力，是网络的一种平安机制，是用来解决网络提早和阻塞等问题的一种技术，包含流分类、流量监管、流量整形、接口限速、拥塞治理、拥塞防止等。通常 QoS 提供以下三种服务模型：Best-Effort service（尽力而为服务模型），Integrated service（综合服务模型，简称 Int-Serv），Differentiated service（辨别服务模型，简称 Diff-Serv）。
下面的这些形容，都指的是传统的、原始的 QoS 的定义和技术栈，其来源于晚期互联网的网络传输设施间的品质保证体系。而本文要探讨的 QoS，是在一个齐全不同档次的品质保证体系，咱们先看一下这两个档次 QoS 的关系。
视频会议公司 Polycom 的 H323 白皮书 QoE and QoS-IP Video Conferencing 里提到，QoS 分为两类，一类是基于网络的服务质量（Network-Based QoS）NQoS，一类是基于利用的服务质量（Application-Based QoS）AQoS。 下图展现了两种 QoS 不同的作用应用场景和不同的品质保障档次。
NQoS 是网络传输设施间的根底通信品质保障能力，是这类通讯设备间特有的一组品质保障协定，这些设施有路由器、交换机、网关等。而 AQoS 则是应用程序外部，依据利用对应的终端设备类型、业务场景、数据流类型所实现的，在不同网络状态下尽力而为地保障用户体验的能力。
尽管 NQoS 和 AQoS 都会对最终用户的体验有决定性影响，但如果将利用场景限定在音视频通信畛域，则 AQoS 这种基于利用的 QoS 就极为重要了，因为 NQoS 作为互联网的基础设施的一部分，为兼顾各种应用场景，更多的是一种「普适」的传输品质保障技术，很难对特定畛域做太多的针对性优化，所以本文重点探讨的音视频通信 QoS 其实是一类基于利用的 AQoS，是针对音视频通信畛域的相干应用程序的传输品质保障技术。
02 音视频通信 QOS 背景
集体了解，音视频通信 QoS 是「利用多种 算法和策略 进行 网络传输管制 ，最大限度满足 弱网场景 下的音视频 用户体验 的能力」，如下图所示：
数据从音视频媒体生产环节，通过各种弱网网络条件的两头传输环节，到音视频媒体的生产环节，造成最终的用户体验。QoS 通过各种策略和算法，对端到端全链路进行管制，最终让用户可能获得最佳体验。
03 音视频通信 QoS 面临的挑战
网络场景
各种网络条件非常复杂：网络的品种和组合多样，特地是在最初一公里，有双绞线、同轴电缆、光纤、WIFI、4G、5G 等；即便同样的网络链接，又会随着不同的场景产生变动，比方 4G，5G，WIFI 这种无线信号，会随着地位的变动信号强弱也飘忽不定，会呈现 4G、5G、WIFI 信号的切换。即便是有线网络，也会因为链路上多种 App 共用、多个用户共用，呈现竞争拥塞等问题。
业务场景
各种音视频通信业务场景多样，例如，点播、直播(RTMP/RTS)、会议、互动娱乐、在线教育、IOT、云游戏、云渲染、云桌面、近程医疗等等。不同的业务场景，又有不同的体验需要，例如，直播场景重视晦涩的体验，而对音视频互动时效性，要求并不是太高；会议场景则对沟通交流的实时性要求会比拟高，而对音视频画质的要求没有那么高；但对云游戏等场景，则要求极低的延时，同时要保障极高的清晰度。
用户体验
如下图所示，音视频通信场景，用户体验次要从清晰度、流畅性、实时性三个方面来掂量。
清晰度，是用户感触到的视频画面清晰还是含糊，个别状况下分辨率越高越清晰，越清晰的画面蕴含的信息量就越多，传输时占用的流量就多；
流畅性，是用户感触到的视频画面静止起来的时候是顺畅还是卡顿，个别状况每秒钟看到的画面数量越多越晦涩，同样每秒画面数量越多，传输时占用的流量也越多；
实时性，是音视频信息从其产生到被远端用户感触到所须要的工夫，工夫越短实时性越好，实时性越好对传输速度的要求就越高。
后面说过，不同的业务场景对清晰度、流畅性、实时性三者的要求有着不同的偏重，然而随着音视频通信业务场景的一直倒退，越来越多 极低延时 和可沉迷 的场景不断涌现，用户对音视频体验，能够说是既要又要还要，而且要求越来越高，留给技术人辗转腾挪的空间越来越小。在这种趋势下，对音视频传输 QOS 的技术要求也变得越来越高。
从底层协定来看，基于 TCP 传输的音视频通信，例如直播、点播等，个别都延时比拟大，而且因为数据都封装在 TCP 协定外部，依附 TCP 自身的抗弱网机制来保障可靠性，应用层很难有机会参加其中的管制和优化，只实用于延时容忍度较大的场景。对于延时容忍度较小的场景，根本都是基于 UDP 的，大家都晓得 UDP 传输的特色就是可靠性差，须要应用层通过各种抗弱网技术手段来保障数据传输的可靠性，QoS 技术就有了大显神通的机会。
本文次要探讨基于 UDP 传输的，最具挑战性、技术最简单的音视频短延时通信 QoS 技术，包含实时音视频通信 RTC 场景和低延时直播 RTS 场景。
04 弱网的分类
如果咱们的传输网络十分的完满，有足够大的带宽、有足够低的延时、有足够高的保障，那咱们就能很容易地实现像真人一样的面对面交换，咱们也不须要 QoS 技术，不须要编解码，只有把音视频采集下来，再霎时传送到对端播放进去就能够了，人与人的近程互动将变得非常美妙。
然而，事实离这种美妙相去甚远，古代的音视频通信是建设在互联网的基础设施之上的一类利用，这让互联网的传输品质，变成了音视频通信传输品质不可能冲破的天花板。家喻户晓，互联网的传输是简单的、低廉的、不牢靠的、不稳固的，没有方法搞清楚所有的传输环节的情况，咱们须要对这些问题进行形象分类，以便于更好地针对不同的场景进行有效应对，竭尽所能的保障用户的音视频体验不受太大的影响。
咱们个别把 网络传输品质不合乎预期的场景叫弱网场景 ，弱网分成拥塞、丢包、延时、抖动、乱序、误码等。 拥塞 ，是可用带宽有余的体现，如同高速堵车； 丢包 ，是数据在传输过程中丢了，不知去向，如同快递失落包裹； 延 时 ，个别是直达太多或者拥塞排队导致时效性变差，如同转折或堵车； 抖动 ，是数据传输距离忽大忽小，如果不做解决，可能会导致音视频忽快忽慢； 乱序 ，是后发先至，先收回去的数据比后收回去的数据到的还晚，如果不解决，可能会导致音视频的回放； 误码，是传输过程中数据谬误，因为传输层会有校验、修改、重传，所以应用层个别都无感知、无需特地解决。
上图用管道灌水比拟形象的把几种弱网场景做了阐明：右边是流量生产侧，左边是流量生产侧，管道的长度是链路的根本延时；管道传输过程中会产生一些谬误和丢包；当管道由宽变窄而且流量超过管道的宽度，就会产生带宽拥塞；当拥塞产生时会呈现流量排队的状况，局部流量会被放到缓存队列，相应地产生队列延时；当缓存队列满了之后，会产生队列溢出，溢出的流量就对应了溢出丢包；链路数据传输过程中会有一些稳定和信号烦扰，导致数据的传输速率不是恒定的，最初收到的数据变得忽快忽慢，咱们将其归类为链路抖动。事实中，这些不同的弱网类型往往是混合在一起同时呈现，对其做不同的分类，能够不便咱们从技术上对其各个击破。
05 音视频通信 QoS 技术体系
QoS 技术分类
音视频通信 QoS 技术和策略就是为了反抗上述弱网场景而诞生的，其目标就是尽最大可能打消因为网络变差给用户带来的体验消退，所以对应下面讲的不同弱网场景的分类，用到的 QoS 技术也被分成了几大类：拥塞管制、信源管制、抗丢包、抗抖动，每一类技术都蕴含很多的不同的技术点和技术细节，前面再来开展。
拥塞管制，是网络情况探测和数据发送形式的决策核心，是整个发送侧 QoS 技术的外围，是传输管制的大脑；
信源管制，是在拥塞管制的决策下，管制音视频信源产生的形式，管制信源的码率，来适应探测进去的网络情况，实现抗拥塞的目标；
抗丢包，是在网络有丢包的场景下，对信源数据减少冗余信息，达到局部信息被失落的场景，也可能残缺地复原出原有数据；
抗抖动，是在网络延时有稳定、数据时快时慢、时有时无的状况下，减少一部分延时，对数据进行缓冲，让用户体验更晦涩，不至于卡顿；
下面也阐明了不同类的 QoS 技术对应能够解决不同的用户体验问题，能够看出都是围绕流畅性、清晰度、实时性这三点来改善的。拥塞管制是总指挥，很多时候对整个链路的体验起决定性作用，信源管制能够晋升流畅性和清晰度方面的体验，抗丢包和抗抖动能够晋升流畅性和实时性方面的体验。
QoS 在音视频通信流程中的地位
咱们晓得音视频通信 是端到端的全链路通信，其波及的技术畛域十分宽泛，跨度十分大、非常复杂。比方，客户端侧就蕴含了市面上能见到的 Windows、MacOS、iOS、Andorid 四个平台的所有终端的适配、兼容、互通，甚至要跟浏览器进行互联互通，同一个平台每款不同的设施也存在较大的差别，很多时候须要独自的适配。还有音频 3A（AEC、AGC、ANS）、音频编解码（Opus、AAC）、视频编解码（H264、H265、AV1）等任何一个畛域开展都是非常复杂的技术栈。而云端的各种服务器也是实现互联互通不可短少的环节，包含信令服务器、媒体服务器、混流、转码、录制、节点部署、调度选路、负载平衡等等，每个节点、每种服务都是简单的存在。
在如此简单的音视频通信技术链路中，QoS 技术也只是其中的一个比拟窄的畛域，但也是不可或缺的，对线上的音视频通信的可用性有着决定性意义。QoS 技术看起来也是音视频通信畛域为数不多的全链路的技术，它端到端、全链路管制着媒体传输、媒体编解码的各个环节，以至于从事 QoS 技术的相干工程师须要对客户端和服务器的全链路的技术都要有肯定的理解，须要从全局的视角来看整个音视频通信。
下图是对音视频实时通信链路性能的一个形象，用媒体发送和媒体接管的 P2P 模式，省略了简单的服务器传输局部，不便大家的了解。
音视频通信的根本流程：首先是推流客户端，从终端设备的音视频采集模块采集的音视频数据是未通过压缩的原始数据，按帧（frame）存储的、尺寸较大的媒体数据，是没有方法间接在网络上传输的，须要先进行 压缩 ，就到了编码局部，用到了音视频的编码器， 编码 实现之后，数据仍然很大，须要进行 切片 ，而后通过 RTP 对切片后的数据做 封装 ，封装完之后，从发送队列 发送 到网络上，通过服务器的一系列透传或解决，达到拉流客户端，拉流端收到网络发送过去的 RTP 数据包之后，要先进行 RTP 包的完整性判断，判断编码后的数据帧切片数据是否都曾经被收到，之后再解 RTP 封装，复原编码后的端数据帧，并送给解码器进行 解码，解码完的数据送到渲染模块，用户就看到和听到了推流端的画面和声音。
上图右边是媒体发送侧的解决流程：音视频采集模块、前解决模块、编码模块、RTP 封装模块、发送队列、网络数据发送。左边是媒体接管侧的解决流程：网络数据接管、RTP 包解析模块、接管队列治理、解码模块、后处理模块、渲染模块。两头的右边蓝色的框内性能是发送侧 QoS 相干的性能，左边的蓝色框内的性能是接管侧 QoS 相干的性能。另外，从 RTCP 协定自身的定位看，它就是对基于 UDP 的媒体 RTP 数据进行管制的协定，所以也能够看成 QoS 管制的一部分。
从上图还能够看出两个特点，第一，QoS 性能跟很多其它模块都相干，这是因为 QoS 技术是全链路管制的技术，须要触达的模块比拟多；第二，发送侧的 QoS 性能显著比接管侧的 QoS 性能多，这是因为目前很多都是发送侧带宽预计和拥塞管制，因为这样会更靠近信息产生的源头，从源头解决问题的效率更高，防患于未然。接管侧的技术往往是比拟被动的，是出了问题之后的最初补救，亡羊补牢。
QoS 技术体系
讲完 QoS 技术的分类和 QoS 技术在音视频通信技术中的地位，接下来咱们聚焦在 QoS 技术畛域外部，从客户端和服务器媒体链路来看 QoS 技术体系和其中比拟大的技术点，如下图所示。左下角的推流客户端侧，用到了信源管制、拥塞管制、抗丢包技术；中上部的媒体转发服务器 SFU，用到了信源管制、拥塞管制、抗丢包技术；右下角的拉流客户端侧，用到了抗丢包、抗抖动技术。上面简要串一下相干的技术点的大略流程和意义。
l 音视频推流客户端
所有媒体 RTP 数据包发送的时候，会在 RTP 的扩大头中减少一个对立的序列号，能够认为每个数据包有一个惟一的编号，这样所有收回去的数据都有了对应的序列号、发送时刻、包大小三个信息。在接收端收到这些 RTP 数据包之后，会把每个收到的序列号以及收到的此序列号的接管时刻信息，依照 TransportFeedback（twcc）报文定义的格局封装到 RTCP 包中，反馈到推流端。参考：《WebRTC 钻研：Transport-cc 之 RTP 及 RTCP》, 推流端依据这些反馈信息，就能估算出以后网络传输的情况，包含丢包、延时、带宽三个方面的信息。这些估算的算法，就是带宽预计算法（也叫拥塞控制算法），上图提到了比拟罕用的两种，一个是 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 媒体能力协商之后，就确定了哪些性能能够开或者是关。
服务器的发送侧性能，跟客户端推流侧一样也比较复杂，蕴含拥塞管制 GCC、BBR、平滑发送、Padding 等 拥塞控制算法 以及带宽调配，服务器上的这些算法跟客户端推流侧的算法根本的框架结构和基本功能都是一样的，只是算法的参数配置、应用的策略，都跟客户端是不一样的，因为服务器侧的信源控制力跟客户端推流侧的信源控制力，是齐全没法比的，不可同日耳语。同时，服务器须要顾及很多的推流端和很多的拉流端，更须要均衡各种关系，众口难调是服务器面临的主要矛盾。
服务器的这种位置也衍生出了一些特定的技术手段，比方 视频的抽帧 （抽掉一些不影响解码的帧数据来降带宽）、 视频切流 （被动切换到带宽和清晰度较低的流上来升高带宽）、 视频按需推流 （依据理论的订阅关系准许推流端直推须要的流来升高带宽）、 音视频带宽反馈 （特定场景能够将拉流测信息反馈给推流侧让其提供更精确的码控服务）、 音频 AudioRanking（多人会议场景将不谈话人的声音过滤掉来升高带宽）等等。服务器相干的更具体的技术点形容，能够参考《阿里云 GRTN QoS 体系 — 构建实时音视频产品最佳体验》。
l 音视频拉流客户端
最初到了音视频拉流客户端，这里的抗丢包性能除了下面说的丢包重传、RED、FEC，又多出了两个，一个是关键帧申请，一个是 长期参考帧 LTR 申请，这两个视频帧申请目标都是为了复原视频帧的参考链，以便可能从新开始视频解码。
关键帧申请是须要视频从新开始编码，让收到关键帧的任意客户端都能够解码，使视频帧的参考链从新开始。长期参考帧则是在确认曾经收到一个长期参考帧的状况下，不用再从关键帧开始编码，只有发送一个长期参考帧就能够复原参考链，即用发送长期参考帧的形式代替发送关键帧。这样做的益处次要是升高重传带宽，但同时减少了复杂性，因为服务器须要确认每个拉流客户端，都收到了某个特定的长期参考帧，在拉流客户端数量较多的场景，这个条件比拟难以满足。能够参考《阿里云 RTC QoS 弱网反抗之 LTR 及其硬件解码反对》。
另外拉流客户端比其它局部多了抗抖动的性能，次要思维是减少一个数据缓冲的 buffer，减少了一部分延时。就像一个水库一样，旱季的时候蓄水，将疾速流入的水储存起来，雨季的时候放水，将之前存储起来的水缓缓放进去，确保从头至尾有水流出。
音频和视频的数据流有各自不同的特色，对应音频的抖动缓存机制和视频的抖动缓冲机制也是不一样的，目前用的较多的都是 WebRTC 外面的音视频抖动管制机制，视频是基于卡尔曼滤波器的 JitterBuffer，音频是 NetEQ，具体的算法都非常复杂，这里就不开展了，有趣味的同学能够参考《WebRTC 视频 JitterBuffer 详解》和我之前的一篇白话文《文言解读 WebRTC 音频 NetEQ 及优化实际》。
音视频的拉流侧或播放侧个别都会有音视频同步（又叫唇音同步 lip sync）的需要，否则会呈现只闻其声不见其人，或只看到闪电听不见雷声的状况。WebRTC 原有的音视频同步机制十分的简单，我之前也有过介绍《WebRTC 音视频同步原理与实现》，而且在 NetEQ 及优化实际中也提到了一种简略的代替计划，这里也不开展。
06 音视频通信 QoS 技术的演进
下面粗略地讲述了音视频通信 QoS 用到的技术体系，任何技术都是须要肯定的软件架构来承载和实现的，音视频通信畛域的 QoS 技术也是随着音视频通信的软件架构演进而一直降级的。对于实时音视频通信 RTC 的演进历史，能够参考《历经 5 代逾越 25 年的 RTC 架构演化史》。这外面提到「谷歌在 2011 年开源了 WebRTC，作为 RTC 技术畛域的里程碑事件，大大降低了 RTC 开发的门槛，催生了起初挪动互联网 RTC 利用的大时代」。
WebRTC 以前
在 WebRTC 面世以前，因为门槛较高，音视频通信根本都是几大头部玩家的之间的游戏，例如 Polycom、华为、思科、微软、BT、Vidyo 等，各家都有本人的公有架构，都在闭关修炼。他们用到的 QoS 技术也都是各自的文治秘籍，只能从一些公开的文章或者协定规范的提交中窥探一二。2012 年当我在 Polycom 看到 WebRTC 开源的音讯时，还齐全没有感觉是什么了不起的事件，Polycom 过后有着一众音视频技术的科学家，反对各种编解码技术，是行业里的相对头部，没想到几年光景下来就泯然于众了。
WebRTC 当前
在 WebRTC 面世当前，音视频通信畛域第一次将其技术栈较全面的裸露在了阳光下，人人都能够基于下面做本人的试验、优化、演进，吸引了大量开发者、初创企业、互联网巨头的参加，不论是技术小白，还是行业专家，都不盲目的、被动或被动地卷入了 WebRTC 从新定义的音视频通信行业。因为 WebRTC 自身也是一个比拟优良的架构，其 QoS 技术和带来的通信成果都是不错的，所以很多企业也都放弃了原有的公有架构，转而在 WebRTC 的根底之上适配本人的业务逻辑，减少本人业务场景特有的 QoS 算法优化。
然而，WebRTC 自身定位源于 P2P 的互联网浏览器间的通信，其重点在客户端侧的架构与实现，而随同云上音视频通信业务场景的倒退，媒体转发服务器变成了两个客户端之间不可短少的一环。反对 WebRTC 协定的媒体服务器也有多种，例如 janus、mediasoup、srs、licode、kurento、jitsi 等，能够参考《十大必知开源 WebRTC 服务器》。但很多媒体转发服务器 SFU 都只是实现了转发性能，对链路管制的 QoS 技术支持十分的单薄，有的甚至聊胜于无，而且因为服务器代码架构跟 WebRTC 的端侧代码架构差别微小，导致迁徙原有 WebRTC 的 QoS 算法，也变得十分艰难。
QoS 技术算法优化阶段
大略在 2021 年疫情前半段以前，互联网逐步走到巅峰，大家都是业务低落、疾速迭代，各家都是拿来主义，间接把 WebRTC 编译通过之后，就集成到本人的 SDK 外面去了，先把业务做起来，再缓缓调优 QoS 算法，只有能满足低落的业务需要，不会思考架构是否简单、实现是否优雅。这个阶段都是基于 WebRTC 的 QoS 算法优化，各类技术文章层出不穷，基本上笼罩了下面 QoS 技术体系中提到的各个技术点，网上 90% 以上对于 QoS 优化的文章都是这一类单点算法的优化和算法的深度解析。大家的技术水平很快被拉到了同一个起跑线上，对新入坑的音视频技术同学十分敌对，只有违心学很快就能上手。
这种 QoS 单点技术的优化降级，是晋升 QoS 性能的外围伎俩，是最终晋升用户体验的立足点，将会始终继续上来。然而这些单点算法优化也有瓶颈，一旦达到现有基础科学钻研的天花板，想再进步就很难了，因为须要基础理论钻研的冲破为前提，这个投入产出不是个别商业公司违心承当的，也不是个别的算法技术人员可能冲破的，所以大部分的国内的公司和技术人员都抉择了急流勇退，也是大环境使然。
当然，大家也不必放心算法技术人员就无用武之地了，毕竟很多技术还没有达到基础科学的天花板，咱们还有一些工夫；毕竟咱们最善于的就是拿来主义，搞不了脑力，就搞膂力，短期进步不了技术的高度，那咱们能够从技术的广度动手，只有能开掘足够多的用户场景，咱们就能够针对特定的场景，进行因地制宜，通过缝缝补补，就能够让各种场景都有一个比拟好的体验，这也是一种价值体现罢。不止是 QoS 技术，咱们的很多科学技术畛域，每每说到这个层面总是让人心酸，也是没有方法的事件，心愿有一天这种场面能有改观。
QoS 技术架构降级阶段
随着疫情进入后半段，互联网热潮不再，IOT、云渲染、云游戏等新场景的呈现，大家逐步慢了下来，从新开始思考 WebRTC 这套框架是否是适宜本人业务的，有没有更好的解法。对 WebRTC 源代码有一些理解或者参加过相干编译的同学都应该晓得，WebRTC 是十分宏大的一个实现，蕴含援用的第三方库的话，源文件数量靠近 20 万个，这种数量级的代码给环境部署、编译配置、工程援用都带来了很大的麻烦，以至于网上有人把编译 WebRTC 做成了一门生意，按次免费。很少有公司能拿 WebRTC 间接应用，都是须要找专门的同学，做环境的配置、代码的裁剪等一系列对业务没啥价值的事件，费劲不讨好。
QoS 技术作为 WebRTC 中最有价值的技术之一，则被深度捆绑在整个代码框架外面，如果不做伤筋动骨的革新，很难间接被用在非 WebRTC 的代码框架中。下图是简略梳理的 WebRTC 中跟 QoS 相干的媒体解决局部流程，相熟 WebRTC 代码的同学应该能够比较清楚地晓得图外面每个模块的意义和作用，这里就不开展介绍了。其中红色的局部是 QoS 相干的模块，咱们能够看出，整个流程互相耦合在一起，没有方法独自将 QoS 性能抽取进去。
同时，对于 IOT、云游戏、云渲染等场景，因为有本人特有的采集渲染、编解码性能，不能应用 WebRTC 的整个框架，而只须要媒体传输、QoS 控制能力，所以不得不对 WebRTC 做裁剪，对 QoS 算法进行剥离。这种业务需要推动了，对原有 WebRTC 架构的思考和降级，推动了 QoS 技术的架构演进。
这种架构的降级演进具体如何来做？我认为，首先要从音视频通信技术链路和功能模块的形象来动手，形象到肯定高度，就看清了事物的实质，看清了实质，就能比拟容易看清各个模块之间的关系，而后能力物以类聚进行解耦。下图是对 QoS 推拉流性能和解决流程的形象。
通过下面的形象之后，咱们就能比较清楚地定义出 QoS 性能的边界，可能进一步将 QoS 外部的各个性能进行从新设计实现，最终可能会变成下图分层解耦、性能模块化的样子。有了这种架构的 QoS 模块，就能够十分不便地迁徙到各种不同的场景，甚至能够迁徙到媒体转发服务器 SFU 下面去，实现 QoS 能力的疾速复用，一次优化多点受害，减速新场景的商业化速度。例如，央视三星堆奇幻之旅的我的项目中的 QoS 局部，就是应用了演进后的 QoS 模块性能，《三星堆大型沉迷式数字交互空间最佳实际》。
从音视频通信软件演进的状态来看，最终的后果可能是又回到了 WebRTC 开源之前的状态，各家有各自的公有软件架构，各家又回到了本人的 QoS 技术优化的小圈子，看起来绕了一圈又回到了终点，只是每家都排汇了 WebRTC 的精髓。
本文从更宏观、更宽泛的角度介绍了 QoS 的概念和分类，从音视频通信 QoS 畛域的罕用技术到架构的演进过程做了简略汇总。随着音视频通信新场景的不断涌现，更实时，更高清变得越来越重要，相干技术也会往这个方向歪斜，同时基于大数据分析的 QoS 相干技术利用将会逐步浸透。
