實(shí)時(shí)音視頻通話作為高效便捷的溝通手段在許多場(chǎng)景下得到應(yīng)用。隨著5G商用元年的真正到來，實(shí)時(shí)音視頻通話將會(huì)得到更加蓬勃的發(fā)展。本次LiveVideoStackCon 2020線上峰會(huì)我們邀請(qǐng)到了網(wǎng)易云信資深音視頻服務(wù)端開發(fā)工程師魯林俊，他將結(jié)合網(wǎng)易云信流媒體服務(wù)搭建的實(shí)戰(zhàn)經(jīng)驗(yàn)，進(jìn)行一些深入的分享。

文 / 魯林俊

整理 / LiveVideoStack

?

大家好，我叫魯林俊，很高興參加LiveVideoStackCon 2020線上峰會(huì)，本次我分享的主題是網(wǎng)易云信流媒體服務(wù)端架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)。

 

本次內(nèi)容主要分為三個(gè)部分：一是實(shí)時(shí)音視頻為基礎(chǔ)的流媒體服務(wù)端設(shè)計(jì)；二是錄制服務(wù)方案設(shè)計(jì)；三是視頻會(huì)議傳輸質(zhì)量控制。

實(shí)時(shí)音視頻為基礎(chǔ)的流媒體服務(wù)端設(shè)計(jì)

1.1 分發(fā)架構(gòu)

在設(shè)計(jì)以實(shí)時(shí)音視頻為基礎(chǔ)的流媒體服務(wù)器之前需要解決的一個(gè)問題是：轉(zhuǎn)發(fā)方案的選取。討論比較多的方案有三種：

 

一是Mesh方案，即通話各端兩兩進(jìn)行媒體通道的建立，并交換數(shù)據(jù)，實(shí)現(xiàn)媒體通話。從服務(wù)器角度看，這種方案比較簡(jiǎn)單，服務(wù)器只要實(shí)現(xiàn)一些信令和打洞相關(guān)的能力等就可以實(shí)現(xiàn)通話，但這種方案的缺陷是通話能否成功建立依賴于打洞的成功率。

 

二是SFU彈性轉(zhuǎn)發(fā)方案，下行轉(zhuǎn)發(fā)的單位是每個(gè)用戶的單個(gè)流。

 

三是MCU方案，媒體服務(wù)器會(huì)進(jìn)行媒體處理，將混合好的音頻和視頻進(jìn)行重新編碼并轉(zhuǎn)發(fā)給下行用戶。

 

網(wǎng)易云信搭建音視頻服務(wù)器時(shí)選取的是一個(gè)混合轉(zhuǎn)發(fā)方案，它是基于SFU為主的媒體轉(zhuǎn)發(fā)方案，輔助MCU進(jìn)行特定場(chǎng)景轉(zhuǎn)發(fā)。特定場(chǎng)景比如用戶為觀眾端，可以以一條MCU的流轉(zhuǎn)播給觀眾端。

這種方案的優(yōu)勢(shì)在于：一是基于SFU的設(shè)計(jì)，服務(wù)器邏輯輕、性能好。二是SFU彈性轉(zhuǎn)發(fā)設(shè)計(jì)，可以配合發(fā)布訂閱的邏輯，做到可選的下行轉(zhuǎn)發(fā)。三是可以配合MCU，做到下行寬帶的節(jié)省以及跨通話系統(tǒng)間的互通簡(jiǎn)化。

1.2 傳輸通道和協(xié)議

 

協(xié)議通道的設(shè)計(jì)中有兩個(gè)協(xié)議通道：非可靠的UDP通道和可靠的KCP通道。

 

非可靠的UDP通道主要用于傳輸媒體，可靠的KCP通道主要用于登入、登出、網(wǎng)絡(luò)狀態(tài)同步、傳輸控制等。

1.3 小程序網(wǎng)關(guān)和WebRTC網(wǎng)關(guān)

 

除此之外，傳輸層是基于我們自己的私有協(xié)議。

 

做PaaS服務(wù)僅僅覆蓋三端是不夠的，要盡可能覆蓋更多的平臺(tái)，比如基于web的開發(fā)、基于小程序的開發(fā)。由于基于私有協(xié)議比較困難，我們搭建了WebRTC網(wǎng)關(guān)和小程序網(wǎng)關(guān)。

WebRTC網(wǎng)關(guān)基于WebRTC標(biāo)準(zhǔn)的實(shí)現(xiàn)，接收RTP/RTCP的流，進(jìn)行協(xié)議的轉(zhuǎn)封裝，并推送到中轉(zhuǎn)分發(fā)服務(wù)器的骨干節(jié)點(diǎn)上面，最終推送到私有用戶上，這就實(shí)現(xiàn)了私有端和web端的互通，小程序的網(wǎng)關(guān)同理。這兩個(gè)網(wǎng)關(guān)的搭建足夠滿足純粹的實(shí)時(shí)音視頻場(chǎng)景，但要做純粹的實(shí)時(shí)音視頻，PaaS服務(wù)是無法滿足用戶的需求的。

1.4 流媒體處理輔助系統(tǒng)

 

當(dāng)一個(gè)擁有幾十萬粉絲的用戶進(jìn)行一個(gè)簡(jiǎn)單的聊天時(shí)，想要獲得聊天內(nèi)容又想將聊天內(nèi)容直播給粉絲看，此外，也想和粉絲聊天并將聊天內(nèi)容給其他粉絲看。這就是在基于純粹的實(shí)時(shí)音視頻的基礎(chǔ)上去獲得錄制、直播、互動(dòng)直播的功能。

 

為了滿足用戶的場(chǎng)景需求，在基于實(shí)時(shí)音視頻為主要核心系統(tǒng)的基礎(chǔ)上，搭建了兩個(gè)輔助的媒體處理系統(tǒng)：直播系統(tǒng)和錄制點(diǎn)播系統(tǒng)。

圖中左邊展示的是實(shí)時(shí)通話系統(tǒng)，實(shí)時(shí)通話內(nèi)容把媒體數(shù)據(jù)推給互動(dòng)直播服務(wù)器進(jìn)行媒體數(shù)據(jù)協(xié)議封裝，封裝成私有協(xié)議或者RTMP協(xié)議，并推送到CDN和我們自建的直播源站，這樣用戶就可以基于標(biāo)準(zhǔn)協(xié)議從CDN或者直播源站上進(jìn)行拉流，這也正是圖中右側(cè)所展示的直播系統(tǒng)。

直播系統(tǒng)中還有一個(gè)單項(xiàng)的直播功能，主播支持RTMP協(xié)議或者私有協(xié)議并推送到直播源站，用戶從直播源站拉流觀看即可。另外，錄制功能同樣是將媒體內(nèi)容推送到錄制服務(wù)器，錄制服務(wù)器進(jìn)行相應(yīng)的錄制后上傳到NOS存儲(chǔ)上，最后到達(dá)點(diǎn)播源站，用戶通過CDN回源到點(diǎn)播源站，并進(jìn)行錄制內(nèi)容的點(diǎn)播。以上就是在實(shí)現(xiàn)純粹的實(shí)時(shí)音視頻通話基礎(chǔ)上，我們相應(yīng)擴(kuò)展了其他媒體處理能力，使用戶使用場(chǎng)景最大化。

1.5 中心控制系統(tǒng)

 

因?yàn)闀?huì)面臨會(huì)話如何發(fā)起、節(jié)點(diǎn)如何就近接入、通話過程中如何對(duì)通話進(jìn)行管理等問題，所以我們搭建了三個(gè)中心控制服務(wù)器。

第一個(gè)是會(huì)議接入控制中心，它的主要職能是提供IM通道，用戶基于IM消息通知服務(wù)器發(fā)起通話。

第二個(gè)是會(huì)話調(diào)度中心，它的職能是為用戶創(chuàng)建房間、加入房間調(diào)度一個(gè)最佳節(jié)點(diǎn)。

第三個(gè)是房間管理中心，它負(fù)責(zé)整個(gè)房間信息生命周期的管理，并提供RESTful Api，為用戶提供房間管理，比如查詢目前通話的房間內(nèi)容等，都可以通過房間管理中心進(jìn)行相應(yīng)的處理。

舉個(gè)例子，當(dāng)用戶發(fā)起一通通話，用戶A可以基于IM消息發(fā)一個(gè)創(chuàng)建會(huì)議的消息，會(huì)議接入控制中心會(huì)將此消息推送給用戶B。同時(shí)會(huì)議接入控制中心，從房間管理中心、會(huì)議調(diào)度中心獲取相應(yīng)的信息后，通過IM通道將結(jié)果反饋給用戶A，用戶A再將這些信息反饋給用戶B。用戶A或者用戶B獲取信息后推送給中轉(zhuǎn)分發(fā)服務(wù)器集群，實(shí)現(xiàn)整個(gè)會(huì)議接入點(diǎn)流程。

以上的內(nèi)容主要介紹了網(wǎng)易云信如何基于用戶的需求打造音視頻的PaaS服務(wù)。

錄制服務(wù)方案設(shè)計(jì)

 

以下部分我將介紹了錄制服務(wù)的搭建，很多人認(rèn)為云端錄制比較容易，但是由于2B業(yè)務(wù)的用戶場(chǎng)景的多樣化，使得錄制服務(wù)會(huì)面臨很多挑戰(zhàn)。

首先是錄制服務(wù)方案如何選取。如果采用實(shí)時(shí)錄制，全量通話進(jìn)行MCU處理，性能無法滿足。

如果采用離線處理，會(huì)遇到一些用戶需求問題，比如用戶要馬上看到文件，但錄制還未開始。

另外，有些用戶想要有錄制的功能，但是媒體數(shù)據(jù)他們自己加密了，我們的服務(wù)器沒法進(jìn)行解密，所以也無法進(jìn)行錄制。以上都是一些客觀存在的問題，為了應(yīng)對(duì)各種用戶場(chǎng)景，我們?cè)O(shè)計(jì)了一套融合錄制方案。

2.1 融合錄制方案

 

這張圖向大家展示了融合錄制方案的內(nèi)容。對(duì)于即時(shí)點(diǎn)播需求很高的用戶，我們提供了實(shí)時(shí)MCU服務(wù)器，實(shí)時(shí)通話時(shí)會(huì)把通話內(nèi)容轉(zhuǎn)給MCU服務(wù)器進(jìn)行數(shù)據(jù)的混合編碼，以H264單幀的方式投遞到MP4/FLV協(xié)議封裝服務(wù)器上，并將封裝后的MP4/FLV數(shù)據(jù)上傳到云存儲(chǔ)，這樣用戶就可以進(jìn)行相應(yīng)的點(diǎn)播。

另外，對(duì)于錄制功能有要求但對(duì)即時(shí)點(diǎn)播要求不高的客戶，需要選擇離線處理的方案，網(wǎng)絡(luò)碼流Dump服務(wù)器實(shí)時(shí)地將需要錄制的會(huì)話Dump下來，并轉(zhuǎn)成私有Dump文件，離線MCU處理器將私有Dump文件進(jìn)行調(diào)度處理，最終上傳到MP4/FLV協(xié)議封裝服務(wù)器上，用戶就可以進(jìn)行相應(yīng)的點(diǎn)播操作。以上就是實(shí)時(shí)錄制方案和離線錄制方案。

針對(duì)于用戶想要將媒體數(shù)據(jù)加密并且保留錄制功能的需求，我們開發(fā)了錄制SDK。用戶可以基于錄制SDK開發(fā)用戶自建錄制服務(wù)器，這套錄制方案可以解決大多數(shù)用戶的錄制場(chǎng)景。

2.2 離線錄制實(shí)現(xiàn)

 

這部分細(xì)致介紹一下離線錄制方案，用戶基于RESTful Api向房間管理中心發(fā)送錄制請(qǐng)求，房間管理中心基于調(diào)度中心就近調(diào)度到一個(gè)實(shí)時(shí)網(wǎng)絡(luò)碼流Dump服務(wù)器，同時(shí)將錄制請(qǐng)求和錄制參數(shù)（用戶錄制如何布局、是否進(jìn)行音頻能量的選取等）下發(fā)到選中的網(wǎng)絡(luò)碼流Dump服務(wù)器。網(wǎng)絡(luò)碼流Dump服務(wù)器收到請(qǐng)求通知后會(huì)和中轉(zhuǎn)分發(fā)服務(wù)器建立拉流鏈路并獲取媒體數(shù)據(jù)，之后進(jìn)行私有協(xié)議文件的封裝，這相當(dāng)于進(jìn)行一個(gè)離線處理，將實(shí)時(shí)數(shù)據(jù)封裝到離線文件里，然后經(jīng)過離線MCU服務(wù)器進(jìn)行離線文件處理并錄制，再將錄制好的碼流投遞到文件封裝上傳服務(wù)再到存儲(chǔ)點(diǎn)播服務(wù)器，這樣從錄制的發(fā)起到上傳、存儲(chǔ)的離線錄制就完成了。

其中私有協(xié)議文件格式設(shè)計(jì)非常重要，離線處理要處理好音頻和視頻的同步以及畫面中所有人的音頻和視頻的同步，就需要建立一個(gè)合適的同步機(jī)制以適配私有協(xié)議文件。

2.3 實(shí)時(shí)音視頻錄制與白板錄制同步回放機(jī)制

 

教育場(chǎng)景下，如何進(jìn)行實(shí)時(shí)音視頻錄制和白板錄制同步回放？

由于白板通訊基于TCP，實(shí)時(shí)音視頻基于UDP，兩者相互獨(dú)立。用戶基于白板SDK進(jìn)行白板數(shù)據(jù)的傳輸，基于音視頻SDK進(jìn)行音視頻通話，這就要解決如何進(jìn)行跨系統(tǒng)之間的錄制文件的同步回放問題。

首先，白板服務(wù)器集群和音視頻服務(wù)器集群要基于NTP同步服務(wù)器進(jìn)行時(shí)間同步操作，即做到離散服務(wù)器之間的系統(tǒng)時(shí)間一致。

其次，需要制定一個(gè)合理的同步方案，即在白板錄制文件和MP4文件里增加同步字段（NTP時(shí)間）。每一個(gè)白板數(shù)據(jù)和視頻幀都增加NTP時(shí)間，也就是基于NTP時(shí)間進(jìn)行相應(yīng)的同步。但要解決NTP存放的問題，對(duì)于白板錄制而言，因?yàn)榘装邃浿莆募撬接袖浿莆募恍枰赥AG-HEADER字段里每個(gè)隔一個(gè)字段存放NTP這個(gè)時(shí)間的字段即可。

對(duì)于實(shí)時(shí)音視頻錄制而言，MP4或者FLV要基于H246一幀插入一個(gè)NAL-SEI，NAL-SEI的payload type要設(shè)置為5，在用戶自定義數(shù)據(jù)里同樣插入一個(gè)NTP字段。MP4播放時(shí)間是基于MP4player的，無法控制其播放進(jìn)度，所以整體的同步方案是基于白板播放時(shí)，實(shí)時(shí)的用位于同步時(shí)間軸上下的兩個(gè)NTP進(jìn)行校準(zhǔn)，進(jìn)行白板的加速播放或者慢播放，這樣就可以做到音視頻錄制文件和白板錄制文件同步回放的效果。

視頻會(huì)議傳輸質(zhì)量控制

 

對(duì)于視頻會(huì)議傳輸質(zhì)量控制要從三個(gè)模塊分析：一是第一公里接入；二是多流發(fā)布訂閱機(jī)制；三是傳輸層上下行QoS策略。

3.1 第一公里接入

 

第一公里接入主要采取兩種方法：一是邊緣加速代理和傳輸層路由策略結(jié)合。二是進(jìn)行網(wǎng)絡(luò)探測(cè)和智能選路。

3.1.1 邊緣加速代理和傳輸層路由策略結(jié)合

 

第一公里接入模塊的具體操作是，首先在基于現(xiàn)有的中轉(zhuǎn)分發(fā)服務(wù)器集群覆蓋的場(chǎng)景下，無法做到覆蓋所有的地域、運(yùn)營(yíng)商，一些偏遠(yuǎn)地域或者運(yùn)營(yíng)商還是依賴于其他的云服務(wù)器廠商，并利用他們的節(jié)點(diǎn)進(jìn)行就近接入。

就近接入就是在云廠商的云主機(jī)上部署我們的代理服務(wù)器，代理服務(wù)器監(jiān)管傳輸層的數(shù)據(jù)和PaaS傳輸層的協(xié)議，并獲取下一跳地址，也就是用戶就近把數(shù)據(jù)發(fā)送到第一跳加速節(jié)點(diǎn)上，加速節(jié)點(diǎn)進(jìn)程接管傳輸層，由傳輸層的頭部獲取下一跳地址，再把數(shù)據(jù)拋給下一跳加速節(jié)點(diǎn)上，然后推送到中轉(zhuǎn)分發(fā)服務(wù)器集群，并最終推送到實(shí)際的接收端。

3.1.2 網(wǎng)絡(luò)探測(cè)和智能選路

 

網(wǎng)絡(luò)探測(cè)和智能選路方法的具體操作是：當(dāng)用戶發(fā)起接入時(shí)，會(huì)調(diào)度給它一組就近接入的節(jié)點(diǎn)。節(jié)點(diǎn)的選取是在會(huì)話開始前和開始過程中都進(jìn)行網(wǎng)絡(luò)探測(cè)，并按一定頻率的機(jī)制去發(fā)送探測(cè)數(shù)據(jù)包。當(dāng)節(jié)點(diǎn)接收探測(cè)數(shù)據(jù)包時(shí)會(huì)進(jìn)行接收信息反饋，基于這些信息反饋將這次探測(cè)結(jié)果的丟包率、RTT、jitter、BW指標(biāo)計(jì)算出來，基于這些指標(biāo)進(jìn)行評(píng)分，最終從調(diào)度基礎(chǔ)的就近接入節(jié)點(diǎn)選取最佳的接入節(jié)點(diǎn)。

3.2 多流發(fā)布訂閱機(jī)制

 

多流發(fā)布訂閱機(jī)制可以解決兩個(gè)問題：一是用戶可以根據(jù)自己的意愿或者能力進(jìn)行下行接收；二是媒體處理服務(wù)器在進(jìn)行下行QoS控制時(shí)會(huì)基于探測(cè)到的網(wǎng)絡(luò)真實(shí)的帶寬，幫助用戶智能的選取可以接受的碼流。所以基于發(fā)布訂閱機(jī)制可以做到兩件事情：一是滿足用戶需求；二是做好傳輸質(zhì)量。

具體實(shí)現(xiàn)是在媒體服務(wù)器上有兩個(gè)模塊：一是媒體處理模塊，二是Pub/Sub管理器。用戶發(fā)布流時(shí)會(huì)基于可靠信道，發(fā)布一條想要Pub流的信令給發(fā)布訂閱管理器，發(fā)布訂閱管理器會(huì)將所有用戶的Pub列表廣播到所有接收端，由所有的接收端根據(jù)需要通知發(fā)布訂閱管理器訂閱哪一條流，然后發(fā)布訂閱管理器會(huì)將所有消息同步到媒體線程并進(jìn)行下行轉(zhuǎn)發(fā)的管理，這樣就實(shí)現(xiàn)了發(fā)布訂閱功能。

 

發(fā)布訂閱機(jī)制發(fā)布的內(nèi)容是：以stream為發(fā)布單位，以編碼能力為基本內(nèi)容。其中編碼能力包括：codec、分辨率、幀率、碼率。

訂閱分為兩個(gè)部分：客戶端訂閱和服務(wù)器訂閱。客戶端訂閱以stream為訂閱單位，并攜帶訂閱優(yōu)先級(jí)，也就是流在下行接收中的重要性會(huì)反饋在訂閱優(yōu)先級(jí)上。另外，當(dāng)所有的客戶發(fā)布訂閱消息后是交由服務(wù)器訂閱，它匯聚所有端的訂閱消息，向發(fā)布源端發(fā)送訂閱消息，同時(shí)將訂閱碼率反饋給源端。

右圖顯示的是多流的發(fā)布機(jī)制是彈性碼率大小流機(jī)制，上行發(fā)布的大小流并不是固定的分辨率，而是一個(gè)可伸展的碼率空間，小流的碼率范圍和大流的碼率范圍都是很大的，這樣的設(shè)計(jì)是以彈性的碼率針對(duì)上行的帶寬，并動(dòng)態(tài)的調(diào)整碼率，以進(jìn)行最佳的上行發(fā)布,針對(duì)下行所有的接收端來調(diào)整碼率，做到最大程度提高用戶體驗(yàn)。

3.3 傳輸層上下行QoS策略

3.3.1 傳輸層上行QoS策略

 

對(duì)于上行QoS服務(wù)器策略主要設(shè)計(jì)了四種：一是FEC/RED；二是NACK重傳請(qǐng)求；三是PLI/FIR；四是接受信息反饋。

在這里我區(qū)分了FEC/RED，因?yàn)槭褂肦ED是為了增強(qiáng)音頻的保障性。對(duì)于視頻，使用矩陣運(yùn)算的方式生成額外的冗余包去對(duì)抗丟包。NACK重傳請(qǐng)求是服務(wù)器作為接收端在上行傳授過程中，如果數(shù)據(jù)有丟失的話會(huì)主動(dòng)作為接收端發(fā)送重傳請(qǐng)求進(jìn)行對(duì)抗丟包。

PLI/FIR主要是首幀問題，在偏大量的丟包場(chǎng)景下，也會(huì)進(jìn)行關(guān)鍵幀請(qǐng)求去替代NACK請(qǐng)求。

接受信息反饋是記錄上行接受信息，并反饋給源端，源端基于接收信息計(jì)算帶寬、網(wǎng)絡(luò)指標(biāo)等進(jìn)行一個(gè)上行的把控。

 

FEC/RED和NACK重傳請(qǐng)求這兩種設(shè)計(jì)都是比較普通的對(duì)抗丟包的手段。

FEC/RED機(jī)制是基于預(yù)測(cè)丟包，提前產(chǎn)生冗余，對(duì)抗丟包。它的優(yōu)勢(shì)是低時(shí)延；劣勢(shì)是抗丟包效果依賴于丟包預(yù)測(cè)準(zhǔn)確性。NACK/RTX機(jī)制是如果丟包已經(jīng)發(fā)生，則基于測(cè)量的RTT做重傳請(qǐng)求的控制。它的優(yōu)勢(shì)是不用預(yù)測(cè)，低時(shí)延恢復(fù)率高，產(chǎn)生額外流量小；劣勢(shì)是產(chǎn)生時(shí)延，高時(shí)延場(chǎng)景恢復(fù)效果差，設(shè)計(jì)不好容易產(chǎn)生NACK風(fēng)暴。

 

針對(duì)前兩個(gè)設(shè)計(jì)對(duì)抗丟包的特點(diǎn)，網(wǎng)易云信分三個(gè)步驟來進(jìn)行傳輸質(zhì)量控制：一是建立網(wǎng)絡(luò)狀態(tài)的觀測(cè)器，評(píng)估網(wǎng)絡(luò)相關(guān)指標(biāo)。二是ARQ手段先行，F(xiàn)EC手段做兜底，也就是盡量利用ARQ對(duì)抗丟包，再利用FEC兜底，這樣可以減少帶寬的浪費(fèi)，做到較好的抗丟包效果，圖中的式子是FEC需要做兜底的丟包率。三是基于接受端反饋以及模塊自檢的策略調(diào)整，這一模塊會(huì)統(tǒng)計(jì)NACK成功率、NACK響應(yīng)時(shí)長(zhǎng)和FEC恢復(fù)率。

 

具體做法是：ARQ和FEC并不是割裂的兩個(gè)模塊，它們的統(tǒng)籌由抗丟包綜合控制器進(jìn)行管控，抗丟包綜合控制器最核心的地方是FEC兜底的丟包率的計(jì)算公式，它的計(jì)算來源于網(wǎng)絡(luò)觀測(cè)器基于對(duì)它的觀測(cè)，計(jì)算出來的網(wǎng)絡(luò)的指標(biāo)，去生成公式。而且基于服務(wù)器端FEC模塊數(shù)據(jù)統(tǒng)計(jì)反饋、服務(wù)器端ARQ請(qǐng)求響應(yīng)模塊數(shù)據(jù)統(tǒng)計(jì)反饋和擁塞控制模塊數(shù)據(jù)反饋統(tǒng)籌的告知抗丟包綜合控制器。

此外，ARQ模塊和FEC模塊產(chǎn)生的，流量也會(huì)統(tǒng)籌的告知抗丟包綜合控制器，最終由抗丟包綜合控制器進(jìn)行公式的參數(shù)調(diào)整，最終做到在不影響網(wǎng)絡(luò)質(zhì)量的場(chǎng)景下做到最大的丟包場(chǎng)景。

3.3.2 傳輸層下行QoS策略

 

下行QoS服務(wù)器策略在復(fù)用了上行QoS服務(wù)器策略的基礎(chǔ)上增加了一些其他的QoS手段，主要有四個(gè)模塊：一是設(shè)計(jì)出下行接收端可彈性接收流組合的方案；二是準(zhǔn)確的探測(cè)出用戶真實(shí)的下行寬帶；三是制定合理的寬帶分配方案；四是進(jìn)行流量的平滑發(fā)送以及擁塞控制。

 

這張圖展示了四個(gè)模塊相互作用的關(guān)系。用戶在上行發(fā)布了兩天流，要做到下行的最佳體驗(yàn)，實(shí)際接收到的流要匹配用戶的真實(shí)帶寬。如果上行發(fā)布的都是大流，而用戶的帶寬不足，無法支撐所有大流的支撐，可能就會(huì)將某些大流切成小流。

智能訂閱

總體就是首先是發(fā)布訂閱管理模塊，基于多流的發(fā)布訂閱管理，進(jìn)行下行的一個(gè)可智能選取的方案。其次是帶寬分配模塊，探測(cè)出用戶真實(shí)的帶寬之后告知帶寬分配器，再結(jié)合用戶實(shí)際訂閱以及上行流的碼率等數(shù)據(jù)后，幫助用戶選取最佳的接受組合。最后是總體把控?fù)砣刂颇K，它的工作是進(jìn)行下行流量的平滑，另外，它基于其他的設(shè)計(jì)能夠避免讓網(wǎng)絡(luò)產(chǎn)生擁塞，最終讓下行產(chǎn)生最佳的效果。

下行帶寬探測(cè)

 

接下來我將介紹以上四個(gè)模塊是如何具體操作的。第一個(gè)模塊是發(fā)布訂閱模塊。第二個(gè)模塊是帶寬探測(cè)模塊，它是基于google的BBR音視頻場(chǎng)景下的優(yōu)化，主要有六點(diǎn)：一是probe_RTT階段的隱藏弱化；二是上行網(wǎng)絡(luò)丟包帶寬補(bǔ)償；三是上行網(wǎng)絡(luò)RTT突變以及高jitter場(chǎng)景優(yōu)化；四是下行鏈路抖動(dòng)自己丟包的優(yōu)化；五是padding流量的優(yōu)化；六是快速上探機(jī)制的實(shí)現(xiàn)。右圖展示了我們優(yōu)化后的BBR在弱網(wǎng)下的探測(cè)效果，基本做了探測(cè)準(zhǔn)確度為95%以上。

帶寬分配策略

 

探測(cè)出帶寬后如何結(jié)合地域關(guān)系、上行的實(shí)際碼率做下行帶寬的分配。假如下行用戶實(shí)際帶寬有2M，訂閱了A、B、C的大流，A、B、C的大流的最大碼率和最小碼率分別是2M、800k，1M、700k，1.6M、1M。那么下行用戶實(shí)際帶寬2M是不可以接收所有的大流的。

 

針對(duì)以上問題，帶寬的分配策略為：首先基于現(xiàn)有大小流進(jìn)行選擇性接收；其次綜合所有下行接收端的帶寬以及預(yù)分配結(jié)果，反饋到發(fā)送端，進(jìn)行上行流的碼率的壓制。

擁塞控制

 

擁塞控制模塊主要有四個(gè)模塊：一是平滑發(fā)送；二是基于流級(jí)別的優(yōu)先級(jí)策略以及可選擇性發(fā)送策略；三是擁塞避免；四是擁塞緩解。

 

基于流級(jí)別的優(yōu)先級(jí)策略以及可選擇性發(fā)送策略中優(yōu)先級(jí)是在實(shí)際發(fā)送包后制定的包的優(yōu)先級(jí)：重傳包>音頻包>視頻包>被切掉的流>padding包。

可選性發(fā)送策略是在實(shí)際轉(zhuǎn)發(fā)中基于上行流SVC的碼流，我們制定了SVC時(shí)域分層選取：在實(shí)際下行轉(zhuǎn)發(fā)時(shí)會(huì)實(shí)時(shí)評(píng)估各個(gè)層總體的碼流，在實(shí)際分發(fā)過程中會(huì)基于當(dāng)前近程發(fā)送隊(duì)列的擁塞程度去實(shí)時(shí)選取應(yīng)該分發(fā)的層。

 

擁塞緩解的具體工作為：首先下調(diào)SVC分層選取，如果擁塞嚴(yán)重就切小流，然后基于包級(jí)別的優(yōu)先級(jí)發(fā)送。其次是如果實(shí)際網(wǎng)絡(luò)發(fā)生擁塞，需要改造BBR的發(fā)送周期，即減少1.0倍發(fā)送周期。另外，如果數(shù)據(jù)超發(fā)，源端的碼率波動(dòng)比較大，需要代替網(wǎng)絡(luò)主動(dòng)丟包。

下圖是具體的丟包策略：綠色條柱是應(yīng)用程序發(fā)送隊(duì)列的堆積情況，基于堆積的安全閾值和堆積的Trendline這兩個(gè)去判斷當(dāng)前是否需要主動(dòng)丟包。

 

上圖是擁塞控制總圖，首先是擁塞避免從BBR獲取匹配的發(fā)送數(shù)據(jù)，當(dāng)避免不了的時(shí)候就需要進(jìn)行流優(yōu)先級(jí)控制以及SVC分層選取控制，并進(jìn)行擁塞緩解，最后數(shù)據(jù)真實(shí)發(fā)送給用戶時(shí)要進(jìn)行平滑發(fā)送。