網絡視頻傳輸機制的測量分析

（93615部隊，天津 300220）

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

一、Web RTC擁塞控制算法

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

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

1.發送端估計帶寬

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

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

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

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

2.接收端估計帶寬

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

2.1 到達時間濾波器

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

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

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

m（ti）- 排隊時間；

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

n（ti）- 網絡抖動。

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

2.2 過使用

通過排隊時間判斷網絡環境，排隊時間超過閾值且持續增長，表示網絡擁堵，發出“overuse”信號，低于閾值，表示網絡正常，發出“underuse”信號，排隊時間接近0，表示正常，將發出“normal”信號。

3.HTTP流媒體技術

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

二、Web RTC實時通信測量

在1M物理帶寬網絡環境下測量分析Web RTC性能。

1.獨享帶寬

1.1 SFQ算法

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

1.2 CoDel算法

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

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

1.3.fq_codel算法

只有一個數據流，fq_codel算法結果和CoDel算法相同，波動很大，參數變化基本相同。

2.與TCP共享寬帶

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

2.1 SFQ算法

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

2.2 CoDel算法

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

2.3 fq_codel算法

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

結語

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