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

对于乱序的处理也比较好解决，如图中所示，每个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时）所示。如果丢包率<10%，说明现在的带宽评估的比较准确，此时应该保持这个带宽，不增加也不减少；
7.3 基于延时的带宽评估

基于延时的带宽评估方法比基于丢包的评估更好一些，因为它可以提前预估是否发生了拥塞。基于丢包的评估丢包率一旦超过10%就说明可能已经发生拥塞了，而网络一旦拥塞，再想恢复回原来的状态，需要花费一段时间，而这段时间就会影响音视频的服务质量。
而基于延时的带宽评估就不会产生这种情况。它的基本原理是，如果接收到的数据包的网络传输时延在持续增长，就说明网络变差了，当达到一定程度时，就要将评估的带宽值降下来，以防止发生网络拥塞。它的计算公式是根据状态机来的（状态机比较复杂，我这里就不讲了），当状态非常好时，需要增加带宽，同丢包增加带宽一样，每次增加8%；如果延时一直累加，则需要降低带宽，带宽降为原来85%，其它情况就保持当前带宽，无增无减。
8 媒体数据与带宽的平衡
8.1 媒体数据与带宽的平衡