网络视频传输机制的测量分析

（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）- 排队时间；

《红楼梦》之所以到现在都被人所称道，其最主要的原因在于它塑造了一批栩栩如生的人物。下面我就选择两个性格或背景部分相似的人物进行比较，我选择了林黛玉和香菱，让大家初步进行一个比较分析。”

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彻底挤占带宽的情况。