RTC、QoS、WebRTC 的定義
RTC 實時通訊，泛指各種資料的實時傳輸技術，包括音訊，影片，文字，圖片等媒體和非媒體資料的實時傳輸。
QoS 服務質量，指一個網路能夠利用各種基礎技術，為指定的網路通訊提供更好的服務能力，是網路的一種安全機制， 是用來解決網路延遲和阻塞等問題的一種技術。
RTC 技術的出現滿足了使用者透過網際網路進行實時音視訊通話的需求，在 QoS 技術的加持下，RTC 技術在複雜的網路條件下能達到更高的弱網抗性、更低的延遲，極大地提升使用者的實時通話體驗。
WebRTC 是一個由 Google 發起的實時通訊解決方案，其中包含影片音訊採集、編解碼、傳輸、QoS、音影片渲染等功能。其名為 WebRTC，但是實際上它不光支援 Web 之間的音影片通訊，還支援 Android 以及 IOS 端。由於該專案是開源的，各即時通訊廠商都基於 WebRTC 進行研究、開發，研製自身的全平臺的 RTC 解決方案。
WebRTC 中有很多優秀的演算法、設計值得研究，音訊 QoS 技術就是其中之一。
音訊 QoS 技術
音訊 QoS 技術主要包括了：頻寬估計及編碼碼控、DTX、FEC、RED、RTX/NACK、加速/減速/PLC 等。
音訊資料雖然沒有影片資料那麼大的量，但在 QoS 方面同樣要面對：頻寬、延遲、質量之間的三維平衡。把音訊 QoS 技術的各項能力歸納到這三維平衡問題中時，我們可以知道：
頻寬估計及編碼碼控：在既定的網路頻寬情況下，估計的頻寬越高、編碼位元速率越高，音訊質量越好；
DTX（輸入編碼器的音量低時編碼器編出靜音指示資料，後續不出編碼資料或出靜音指示資料，直到輸入音量不再低）：有效節省靜音情況下的編碼位元速率；
FEC（透過前向糾錯編解碼演算法，實現丟包恢復）：冗餘度越高，恢復率越高，但頻寬消耗越大；分組越大，恢復率越高，恢復延遲越大；在低丟包率、非連續丟包情況下，具有位元速率優勢；
RED（原始音訊包同時攜帶冗餘的音訊包）：冗餘層數越多，頻寬消耗越大；在低丟包率、非連續丟包、高延遲情況下，具有恢復延遲優勢；對於冗餘包擴充頭的支援程度因實現而異；
RTX/NACK（丟包重傳/丟包請求）：丟包重傳屬於按需重傳，丟包越高，重傳需求越高，頻寬消耗越大，需要避免重傳風暴；在高丟包、連續丟包情況下，具有恢復率優勢，但有較大的恢復延遲劣勢；
加速：接收端緩衝過多時，透過加速降低緩衝量，降低延遲，會帶來一定的加速感；
減速：接收端緩衝不足時，透過減速提升緩衝量，增加延遲，會帶來一定的減速感；
PLC（丟包補償）：接收端快取缺失時，透過收到的前序包模擬丟失包，會帶來一定的音質損傷。
QoS 分段策略
從整體角度看，RTC 實時音影片系統至少會涉及 3 個端：傳送端、服務端、接收端。雲信 RTC 以 SFU 架構實現客戶端媒體流的接入和轉發。以此為基礎形成了傳送端到服務、服務到接收端（服務級聯由網易雲信 WE-CAN 大網提供）的分段 QoS 策略。
分段 QoS 的優勢在於，上下行獨立進行 QoS 策略有利於隔離上行段、下行段不同網路情況，對每條鏈路適用更佳的應對方法。但其劣勢在於，策略的設計、開發、調優會更加複雜，問題排查難度增加，服務端效能可能成為瓶頸。
頻寬估計
頻寬估計主要用來對傳送端（或伺服器的下行轉發端）進行位元速率控制。
上行端側透過 GCC（Google Congestion Contrl）演算法基於接收端的資料反饋對其傳送頻寬進行估計。估計出的頻寬會分配到編碼位元速率、RED 位元速率、FEC 位元速率、RTX 位元速率、PADDING（填充）位元速率。雖然頻寬估計演算法在各公司是大同小異，但是頻寬分配策略卻是五花八門。因為如何分派編碼位元速率和抗性位元速率（包括 RED、FEC、RTX）決定了一款 RTC 產品在媒體質量、會話延遲、頻寬耗費上的競爭力高低。
伺服器下行轉發側同樣也有頻寬估計演算法。服務端對下行鏈路的頻寬估計結果是基於會話的，但服務端同時接通一個會議中的多個下行會話，因此服務端可以彙總多個下行會話的頻寬估計結果，結合場景，利用如 topN 頻寬回傳上行做位元速率約束、VIP 使用者 QoS 優先保證等策略，提升服務端的頻寬利用率。
在頻寬估計領域還有許多可以最佳化的方向，比如：反饋的位元速率納入頻寬估計、基於機器學習進行頻寬估計和分配。
DTX 編碼
OPUS 音訊編碼器的 DTX 特性，能夠有效降低發聲靜音時的位元速率，它利用靜音時傳送端每 400ms 編碼傳送一個 DTX 包通知接收端靜音狀態仍在持續，接收端在接收到首個 DTX 包後，進入 DTX 狀態，每次音訊裝置獲取資料時編碼器輸出一個靜音幀。服務端對 DTX 進行透傳。
WebRTC 利用 OPUS 的 DTX 特性引入了一些斷流誤判、收包反饋的問題。雲信對此進行了最佳化，利用了靜音狀態位元速率低的特性，同時保證了資料流的連續性。
FEC
端側 FEC 分帶內和帶外兩種，WebRTC 中影片是透過帶外 FEC（ULPFEC、FLEXFEC）來產生冗餘包，音訊則可以透過 OPUS 帶內 FEC 、帶外 FEC 來生成冗餘包。服務端 FEC 是用帶外 FEC。
帶內 FEC 由於會佔用一部分編碼位元速率，所以對音訊的音質會有所降低。帶外 FEC 不會影響音質，但會額外佔用網路頻寬，各有優缺點。
FEC 典型的編碼方式有 XOR 和 Reed Solomon。WebRTC 的帶外 FEC 使用的是 XOR 編碼方式，其特點是計算量相對少，但其抗丟包能力有限。
在 WebRTC 中，帶外 FEC，不論是 ULPFEC，還是 FLEXFEC 都是根據 MASK 掩碼來確定 FEC 包和被保護的源 RTP 包的對映關係，其中定義了兩種型別的掩碼：RandMask 和 BurstMask，前者在隨機丟包中保護效果要好些；後者則是對突發導致連續丟包效果會好些，但是不論哪種，都有其缺點。
FEC 冗餘度和原始包分組長度計算準則是：根據丟包和 rtt 預置分組長度，在該分組長度下，根據貝葉斯定律，在當前丟包率下，確定至少需要多少冗餘包能夠保證接受到足夠的原始包和冗餘包來透過 FEC 解碼恢復丟包。值得注意的是，分組長度對 FEC 的恢復延遲有決定作用。
RED
RED 是在一個包中額外攜帶前序若干包的抗性策略。其冗餘層數以最大包長度為限制，同時也受到耗費頻寬的約束。其優勢在於 RED 包攜帶的冗餘資料與原始包序號越接近，RED 恢復時延越低；原始包與冗餘包的最大序號差，決定了最大恢復延遲。
端側 RED 打包常採用連續相鄰序號作為冗餘資料，跳躍序號的打包方式未證明存在明顯恢復優勢，但會引入更大的平均恢復延遲。
服務端下行側 RED 打包受到上行弱網、抗性恢復能力、恢復時間影響。若採用連續相鄰序號作為打包方式，則需要等待上行丟包的恢復包；若採用跳躍序號的打包方式，則會引入更大的下行側 RED 恢復延遲。延遲取決於上行丟包恢復的耗時。因此分段 RED 策略下，若上行存在弱網，那麼服務端下行側 RED 的恢復時間優勢就不再明顯。此時最佳化上行鏈路弱網的恢復時間更為有效。
RTX
RTX 是弱網抗性演算法中引入延遲最嚴重的。一個包的重傳請求到該重傳包被成功恢復，至少要經歷一個 rtt 耗時，在丟包嚴重、rtt 較大時，重傳包也可能丟失進而造成多次重傳，這個耗時將變得不可接受。
重傳耗時的主要決定因素是：rtt、丟包率、重傳請求時機、重傳請求響應策略。其中 rtt、丟包率可能由於鏈路頻寬擁塞、弱網測試引起的，重傳請求時機取決於請求間隔約束、當前資料快取量、丟包檢測機制等；重傳請求響應策略取決於傳送端快取、傳送端攔截機制、估計頻寬、是否有冗餘重傳機制等。綜合考慮以上因素，可以極大地最佳化重傳效果（包括恢復效果、恢復耗時、重傳位元速率）。
結語
在網路飛速發展的今天，音訊 QoS 的最佳化顯得比影片更加容易，因為頻寬的顧慮會越來越少。但是從企業運營角度考慮，當 RTC 業務中的音訊業務佔據主導時，控制音訊頻寬的成本時非常有價值的。這是音訊 QoS 最佳化中，直接和利潤相關的部分。因此上述策略中，有許多都提到了頻寬耗用，這意味著我們不能一味追求抗性和實時性，而忽略了頻寬成本的增加。
QoS 的終極課題就是在有限的頻寬資源下，提升弱網抗性，降低恢復時延。在這條路上，還有非常多的空間等著 QoS 從業人員去探索。