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

6.5 NACK适合使用的场景

当然，通过NACK重传，会产生一定的延时，该延时包括：等待发送NACK的时间（10或20ms），NACK经过网络的时延以及RTP的网络时延和重传RTP包的网络时延，即1.5RTT+10或20ms 。通过这个公式我们可以知道，如果RTT时延比较大，比如200ms，那么1.5RTT就是300ms 。通过前面讲述的实时传输延时指标我们可以知道，端到端实时传输的时延需要控制在500ms之内，如果仅数据的网络传输就占了300ms，那数据再经过采集、编码、解码、渲染等流程，这些处理时间加在一起很有可能就超过500ms 。
所以可以得出结论，丢包重传仅适用于网络传输时延比较小的情况，如果RTT比较大时，就不适合使用丢包重传来保障网络质量了。
6.6 FEC

FEC的作用是通过冗余数据解决丢包。实际上，它就是一个异或操作。如图所示，假设传输的数据是Data1和Data2，这两个数据如果在传输的过程中没有FEC进行保护，其中一个数据丢失了，那只能通过NACK重新找回。那么，能否在传输过程中加一些冗余数据，以保证接收时，当某一个数据丢失后，不经过重传就可以将丢失的包找回来呢？这就是FEC 。
在图中我们可以看到，Data1和Data2同时发送到对端，在发送时对它们做一下异或操作，即Data1的最后一位0与Data2的最后一位0异或为0，Data1的倒数第二位1与 Data2的倒数第二位1异或为0，依次类推，最后就产生了冗余数据R，同时将三个包从一端传输到另一端。传输过程中，如果Data1丢失，通过Data2和冗余包R就可以将Data1找回来。找回包的算法也是异或操作，即在接收端将Data2的每一位与冗余包中的相同位进行异或操作就算出了Data1 。这就保证了不用重新请求，就将丢失包找回的作用。
而且异或具有传递性，A、B、C三个包可以同时异或得到D，如果其中任意一个包丢失，可以通过D和其它包找回丢失的包。
6.7 ULPFEC

对于WebRTC来说，它默认使用的是ULPFEC 。其原理是，将要传输的数据包先进行分组，如将三个包分为一组，然后为这一组包产生一个冗余包，如果这一组中某个包丢失了，就可以通过冗余包和其它包的异或操作将其找回。从图中第一行可以看到1和2到了，3丢了，通过R1可以找回3，第三行同样可以找回9 。其缺点是，如果连续的两个包都丢失了，这种算法就失效了，比如第二行4和5丢失后，通过6和R2无法找回它们。
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更为复杂一些），都是通过一个队列（缓存区）对接收到的数据做下缓冲，然后再从队列的另一端将数据包一个个均匀的取出，这样取出的数据就是平滑的了。