利用多種算法和政策進行網絡傳輸控制，最大限度滿足弱網場景下的音視訊使用者體驗。
良逸｜技術作者
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架構演化史》（https://www.livevideostack.cn/news/the-evolutionary-history-of-rtc-architecture-after-5-generations-spanning-25-years/）。這裡面提到「谷歌在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伺服器》（https://zhuanlan.zhihu.com/p/554537113）。但很多媒體轉發伺服器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相關技術應用将會逐漸滲透。