服务质量的五个标准 服务质量分析模型有什么( 五 )


6.8 FlexFEC
于是就有了改进的FlexFEC,它做了双向冗余处理,不仅横向做了冗余,而且纵向也做了冗余 。
此时,当4和5同时丢失时,通过1、7和C1可以找到4,2、8和C2可以找到5,这样就可以找回连续的两个丢包 。当然它也有弊端,其弊端是无法处理批量的连续丢包,例如连续丢失了10个包,FlexFEC对这种情况也无能为力 。
以上就是WebRTC对于丢包的解决方法,通过“NACK FEC”防止丢包 。
6.9 如何解决抖动和乱序
下面来说说抖动和乱序 。抖动的意思是,一会儿来了很多包,一会儿又一个没有,包是一波一波的来,包到达的时间很不平均;而乱序指的是先发的包后到了,后发的包先到了 。
WebRTC处理抖动和乱序使用的是JitterBuffer和NetEQ 。JitterBuffer用于处理视频包,NetEQ用于处理音频包 。它们的原理大致相同(NetEQ更为复杂一些),都是通过一个队列(缓存区)对接收到的数据做下缓冲,然后再从队列的另一端将数据包一个个均匀的取出, 这样取出的数据就是平滑的了 。
对于乱序的处理也比较好解决,如图中所示,每个RTP包进来的时候有一个序号(Sequence Number),在数据进入队列时,它会根据序号插到对应的位置上,比如图中104、107包已经到达,并且在对应的位置上,而103、105和106没来,位置就空着,等它们来了再插入对应的位置,这样就可以防止乱序,所以通过JitterBuffer和NetEQ就可以同时解决乱序和抖动了 。
总结一下,NACK和FEC解决丢包问题,NACK会增加时延,FEC会占用带宽 。JitterBuffer解决视频的乱序与抖动,NetEQ解决音频的乱序与抖动 。
6.10 网络延时产生的原因
说到延时,实际上就与带宽评估有密切的关系了 。延时的产生有两个原因:第一是链路问题,正常的网络上,数据包的传输都是时快时慢的;第二是发生了网络拥塞,当发生拥塞后,数据包会进行缓冲,就会造成延时,而当缓冲溢出时,就出现了丢包 。
所以对于延时来说,我们需要解决的是因拥塞而造成的延时,链路问题无法解决 。下面咱们就来看看WebRTC是如何防止拥塞的 。
7 准确的带宽评估方法
7.1 如何解决抖动和乱序
WebRTC防止拥塞的根基是有准确的带宽评估方法 。它提供了两种带宽评估方法,一种是基于丢包的带宽评估,另一种是基于延时的带宽评估 。而基于延时的评估方法又分为接收端(Goog-REMB)和发送端(Goog-TCC)的带宽评估方法,目前默认采用的是Goog-TCC方法,因为其相对来说更为精准 。
7.2 基于丢包的带宽评估
基于丢包的带宽评估方法比较简单,根据丢包率进行计算 。实际上,正常带宽也有一定的丢包,如果丢包率<2%,属于网络质量不错的正常丢包,说明带宽还没有达到上限,应该增加评估的带宽值 。举个例子,比如你家里的带宽是8M,WebRTC最开始是不知道你家里的真实带宽的,它必须一点点测量,所以一开始它先给你的带宽设置一个假设值,即500K,当发现丢包率很低时,它再增加带宽的评估值,如从500K升到1兆,如果丢包率还是很低,就会加到1.5兆、2兆……,带宽评估值增加的速度是每次增加8%;如果丢包率>10%,说明发生拥塞了,此时应该立即降低带宽,公式如图(loss>0.1时)所示 。如果丢包率

推荐阅读