（93615部隊，天津 300220）

互聯(lián)網(wǎng)技術(shù)迅速發(fā)展，視頻服務(wù)更加普及，除了傳統(tǒng)的視頻網(wǎng)站如國外的Youtube，國內(nèi)的Youku、土豆、騰訊視頻，QQ、微信等在線視頻通訊工具的應(yīng)用也越來越廣泛，視頻成為互聯(lián)網(wǎng)流量的主要來源，思科數(shù)據(jù)報告稱，2015年，互聯(lián)網(wǎng)流量有95%都來自視頻，因此研究網(wǎng)絡(luò)視頻流量傳輸機制，并進行進一步優(yōu)化，對節(jié)省網(wǎng)絡(luò)帶寬，加快視頻加載速度，提高用戶體驗有著重要意義。

一、Web RTC擁塞控制算法

網(wǎng)頁實時通信（Web Real-Time Communication）是使用瀏覽器實時語音和視頻對話的技術(shù)。2010年，谷歌收購Global IP Solution，同時獲得了Web RTC技術(shù)，谷歌大力支持，且該技術(shù)開源，因此迅速成為實時視頻通信的研究熱點。

Web RTC擁擠控制探測網(wǎng)絡(luò)帶寬，并將探測結(jié)果發(fā)送給發(fā)送方，告知最大可用帶寬，使用前向糾錯編碼冗余反饋調(diào)整解碼器解碼速率。Web RT發(fā)送端與接收端都進行帶寬估計，實際發(fā)送速率是二者實際帶寬中的最小值以及其他修正。

1.發(fā)送端估計帶寬

采用基于丟包的算法，接收端估算分組丟失率，將該數(shù)據(jù)反饋給發(fā)送端，每隔一段時間接收端就反饋一次丟失率，發(fā)送端接到報文之后將采用線性加乘性減算法估算網(wǎng)絡(luò)可用帶寬。具體邏輯如表1。

表1 基于接收端丟包率的發(fā)送端帶寬估計

帶寬估計算法如式（1-1）。

fl（tk）-第k次接收端回傳丟包率；

2.接收端估計帶寬

接收端估計帶寬采用單項時延算法。

2.1 到達時間濾波器

發(fā)送端發(fā)送數(shù)據(jù)包，將發(fā)送時間封在數(shù)據(jù)包中，接收端通過發(fā)送時間和接收時間差計算單項時延，并將單項時延劃分為傳輸時延、排隊時延和時延噪聲三部分：

其中，d（ti）-兩個數(shù)據(jù)包之間單項時延；

d（L（ti））/C（ti）- 分組長度傳輸時間差；

m（ti）- 排隊時間；

《紅樓夢》之所以到現(xiàn)在都被人所稱道，其最主要的原因在于它塑造了一批栩栩如生的人物。下面我就選擇兩個性格或背景部分相似的人物進行比較，我選擇了林黛玉和香菱，讓大家初步進行一個比較分析。”

n（ti）- 網(wǎng)絡(luò)抖動。

數(shù)據(jù)包單項時延與分組長度傳輸時間差均可測量，其余時延可根據(jù)噪聲分布，用卡爾曼濾波器進行估算。

2.2 過使用

通過排隊時間判斷網(wǎng)絡(luò)環(huán)境，排隊時間超過閾值且持續(xù)增長，表示網(wǎng)絡(luò)擁堵，發(fā)出“overuse”信號，低于閾值，表示網(wǎng)絡(luò)正常，發(fā)出“underuse”信號，排隊時間接近0，表示正常，將發(fā)出“normal”信號。

3.HTTP流媒體技術(shù)

基于HTTP的流媒體服務(wù)器為視頻源提供各種碼率視頻文件，將不同碼率視頻文件均切割為碎片，且每一段的播放時間均相等，一般在2-10s左右，所有分塊都能夠聽過單獨解碼器進行播放。用戶接收端將會生成緩存文件，存儲接收到的數(shù)據(jù)信號數(shù)據(jù)，緩沖帶寬波動，視頻客戶端開始工作之后，將占用更大帶寬更大速度的下載視頻文件分段，直到緩沖數(shù)據(jù)存儲達到一定閾值，開始從緩存文件中讀取數(shù)據(jù)并播放，同時繼續(xù)向服務(wù)器請求數(shù)據(jù)維持緩存視頻文件長度。至于視頻碼率選擇，國內(nèi)主流網(wǎng)站都將選擇權(quán)交給用戶，如優(yōu)酷、土豆、騰訊視頻等視頻網(wǎng)站播放頁面都有超清、高清、標清的選項，也有一些流媒體播放器根據(jù)網(wǎng)絡(luò)帶寬自動選擇合適碼率的視頻分塊文件。

二、Web RTC實時通信測量

在1M物理帶寬網(wǎng)絡(luò)環(huán)境下測量分析Web RTC性能。

1.獨享帶寬

1.1 SFQ算法

應(yīng)用SFQ算法，視頻流能夠充分利用帶寬，數(shù)據(jù)傳輸效率和帶寬相當，傳輸穩(wěn)定，總體丟失率很小。發(fā)送端和輸出端的帶寬估計值基本相等，和物理帶寬接近，發(fā)送方對可用帶寬的估計將小于等于接收可用帶寬，因此接收方擁塞控制發(fā)揮主要作用。

1.2 CoDel算法

CoDel算法下，WebRTC發(fā)送速率波動很大，丟失率偏高且變化幅度大，因為CoDel機制選擇一段時間內(nèi)排隊時延最小值，當該最小值超過某一閾值，將會認為網(wǎng)路擁堵，丟棄數(shù)據(jù)包，如果排隊時延繼續(xù)增加，數(shù)據(jù)包丟棄速度將加快，會導致丟包率上升。

發(fā)送端估算帶寬小于等于接收端估算帶寬，丟包率很高，導致根據(jù)丟包率估算出的帶寬較小，以發(fā)送方擁塞控制為主，如果網(wǎng)絡(luò)上只有一個WebRTC視頻流用戶，CoDel算法反而會導致發(fā)送速率出現(xiàn)較大波動。

1.3.fq_codel算法

只有一個數(shù)據(jù)流，fq_codel算法結(jié)果和CoDel算法相同，波動很大，參數(shù)變化基本相同。

2.與TCP共享寬帶

分析只有一個WebRTC和一個TCP數(shù)據(jù)流的1M物理帶寬鏈路上的傳輸性能，從0s開始，建立WebRTC數(shù)據(jù)流，第120s建立TCP流。

2.1 SFQ算法

120s之前WebTCP傳輸速度接近物理帶寬，TCP鏈路連通后，WebRTC視頻流發(fā)送速率迅速下降到公平帶寬以下，40s之后恢復(fù)到公平帶寬，而TCP流量直接獲得公平帶寬。在只有視頻流時仍然存在丟包，而TCP鏈路接入后，丟包率基本下降為0，發(fā)送帶寬基本等于接收端估算帶寬，丟失率很低，發(fā)送方估算帶寬值很大，接收方擁堵控制為主，說明SFQ算法下，WebRTC能夠和TCP公平共享寬帶，且視頻流速率變化不大。

2.2 CoDel算法

TCP流接入之后，視頻流和TCP流基本公平共享帶寬，但是發(fā)送速率變化波動較大，丟包率遠高于SFQ算法。因為TCP總嘗試填滿緩存，造成了很大的排隊時延，而取排隊延時最小值估算帶寬的CoDel算法在排隊時延超過一定值之后開始丟包，延時增加，丟包速率也增加。

2.3 fq_codel算法

使用fq_codel算法，TCP流啟動之前基本能夠占滿物理帶寬，TCP流啟動之后，WebRTC和TCP之間基本能夠公平共享帶寬，但是存在較大發(fā)送速率波動，丟包率介于SFQ和CoDel之間。

結(jié)語

三種隊列管理算法下，Web RTC對帶寬都能夠充分利用，發(fā)送速率接近物理帶寬，其中SFQ算法下Web RTC性能最優(yōu)，波動較小，而CoDel和fq_codel算法下丟包率將上升，導致通信質(zhì)量下降，出現(xiàn)較大的速率波動，但是三種算法下都沒有出現(xiàn)被TCP徹底擠占帶寬的情況。