李超：WebRTC传输与服务质量

为了保证音视频的质量，WebRTC底层做了大量的工作，尤其是网络传输与服务质量，更是其核心技术，本文由北京音视跳动科技有限公司 首席架构师 李超在LiveVideoStack线上分享的演讲整理而成，详细解析了WebRTC底层技术与优化在网络质量、传输实时性与服务质量之间的矛盾以及平衡之道。

作者 | 李超
整理 | LiveVideoStack

非常高兴和大家一同探讨WebRTC传输是如何保证音视频服务质量的。

本次分享我将从四个方面向大家介绍一下WebRTC传输是如何保证音视频服务质量的。第一，实时通信的目标。我们首先需要确定实时通信的目标，才能够知道要将实时通信做成怎样的系统、保证怎样的实时性；第二，WebRTC如何保障数据传输的实时性；第三，进行实时传输时，想要满足实时性，网络与服务质量之间可能存在的矛盾；最后，就是WebRTC如何解决网络与服务质量之间的矛盾。

1. 实时通信的目标

1.1 实时通信的目标是什么？

首先提出两个问题：第一，开会时你是喜欢在办公室里，还是更喜欢在线上开？第二，如果有一场演唱会，你愿意去现场呢？还是愿意在线上听？

1.2 线上与现在不同的原因

相信大家更多都会选择线下，理由是线上线下感觉不一样。其不同点在于：首先是摄像头与人眼看到的效果不一样，例如摄像头采集的角度过小、无法拍到某些角度的画面；其次是采集设备的质量参差不齐，一场会议中大家所使用的设备有的高清、有的模糊；最后，也是最关键的一点就是现场的气氛无法被摄像头采集到，每个人都有自己的气场，当大家聚集在一起时，现场氛围感非常热烈，但隔着屏幕无法感受到。

1.3 实时通信的目标

根据以上几点，我们可以总结出实时通信最终的目标是： 尽可能逼近或达到面对面交流的效果。从目前的情况来看，超越面对面交流的效果是几乎不可能的。

2. 几个重要指标

2.1 几个重要指标

那么如何才能达到面对面交流的效果呢，这里涉及到几个重要指标。

最为关键的是实时通信的延迟指标，只有将延迟指标搞清楚，才能知道做实时通信时，达到怎样的延迟才算符合要求的，即接近面对面交流的效果。然后是音视频服务质量指标，延迟指标达到后，再根据这项指标判断音视频服务质量的好坏。

2.2 实时通信延时指标

下面具体看一下延迟指标的分级标准。通过图中表格可以看到，如果端到端延迟在200ms以内，说明整个通话是优质的，通话效果就像大家在同一个房间里聊天一样；300ms以内，大多数人很满意，400ms以内，有小部分人可以感觉到延迟，但互动基本不受影响；500ms以上时，延迟会明显影响互动，大部分人都不满意。

所以最关键的一级是500ms，只有延迟低于500ms，才可以说是合格的实时互动系统。

2.3 音频服务质量指标

接下来是音频服务质量指标，它根据MOS值来打分。4.0-5.0为”优”，评值标准是听得非常清楚，延时小，交流顺畅；3.5-4.0为”良”，音质稍差，听得清，延时小，有点杂音；3.0-3.5为”中”，音质较可，能听清，有一定时延，可以交流；1.5-3.0为”差”，勉强能够听清，交流时需要重复多次才能够表述清楚；0-1.5为”劣”，完全听不清，延时大，交流不畅。

2.4 视频服务质量指标

视频服务质量的评价标准有几个，它们也都是通过MOS值打分来判断质量好坏的，图中参考是以码流大小为标准评估指标。以640480为例，如果想达到MOS值为4.5的优质效果，可以看到产生的码流的大小大概在3Mbps左右。这样的码流对于实时传输来说太大了，如果是640480的视频占用3Mbps的带宽，那是一件非常奢侈的事儿。一般情况下，我们会选择MOS值为3.5（绿色线）的码流，其码流范围在600kbps左右。

从以上可以看到，在保证传输的实时性时，由于带宽是一定的，可能会牺牲一定的服务质量。

3 主要矛盾

3.1 实时通信与服务质量的矛盾

通过了解上述三个指标，我们可以得到实时通信与服务质量的主要矛盾。

第一，码流与带宽之间的矛盾。要想达到好的质量，码流一般会比较大（当然，不能超过最大码流)，而带宽是有限的，于是码流和带宽之间就会产生矛盾；第二，实时性和服务质量之间的矛盾。通常为了保证好的实时性我们会选择UDP，而UDP不保证网络传输的可靠性，丢包、乱序是经常发生的。一旦出现丢包、乱序，网络传输质量就无法得到保证，最终会影响到音视频的质量。

这里我们就可以总结出实时通信的主要矛盾，即：音视频的质量与带宽大小、实时性和网络质量之间存在矛盾，其它包括3A问题都属于次要矛盾。

4 解决矛盾方法

4.1 解决矛盾的方法

下面来看下解决矛盾的方法。对于WebRTC来说，主要从以下几个方面解决主要矛盾：如何保障数据传输的实时性、如何提高网络质量、如何更准确的评估带宽、如何平衡码流与带宽。

5 保障数据的实时性

对于WebRTC来说，为了保障数据的实时性，提供了两种方法：一种是传输路径的选择，它首先会选择最佳的传输路径，使得端到端传输时采取最好、最短的传输路径从而保障数据传输的实时性；另一种是传输协议的选择，可以选择TCP或者UDP。下面咱们先看一下WebRTC是如何选择最佳传输路径的。

5.1 选择一条最好的路径

图为WebRTC路径选择的架构图。图中包括三个端，A端、B端和C端，其中A和B在同一个局域网内，对于WebRTC来说，如果发现同一局域网内的两端需要通信时，会选择局域网内直连，从而保障网络路径最短最优；如果是A和C通信，它们不在同一局域网内，那么WebRTC会选择P2P直连，做NAT穿越，如果穿越成功，便可进行直连，这样路径相对服务器中转来说也比较短。只有在P2P不成功时，才会选择服务端中转。从图中可以看到，当一端通过TURN服务器将数据传输给另一端时，其传输路径明显长于P2P直连，所以对于WebRTC来说，它一定会选择最短、最优的路径，从而保障端到端的实时传输。

5.2 使用TCP还是UDP？

接下来看一下WebRTC对TCP/UDP协议的选择。在网络比较优质时，TCP/UDP都可以用于实时传输，但大多数情况下，我们首选UDP（后面会介绍UDP的优势）；弱网环境下不能使用TCP；而在进行网络穿越时，使用TCP又有较大的好处，在企业内可以使用TCP访问外网的80端口进行穿透。

5.3 为什么极端网络环境下不能用TCP？

为什么在弱网环境下不能用TCP？这是由于TCP的机制所造成的。TCP的机制是发送、确认、丢包、重传。正常情况下，数据从一端传输到另一端是没有任何问题的，但当出现丢包时就会有较大的麻烦。

图中显示了多次丢包时的延迟情况：从客户端向服务端发送数据包，服务端需要返回ACK消息进行确认; 客户端收到确认消息后, 才能继续发送后面的数据（有滑窗时也是类似的）。每次客户端发完数据后，都会启动一个定时器，定时器的最短超时时间是200ms。如果因某种原因，在200毫秒客户端没有收到返回的ACK包，客户端会重发上一个包。由于TCP有退避机制，以防止频繁发送丢失包，因此会将重发包的超时时间延长到400ms。如果重发包依然没有收到确认消息，则下一次重发的超时时间会延长到800ms。我们可以看到，连续几次丢包后，就会产生非常大的延迟，这就是TCP在弱网环境下不能使用的根本原因。

5.4 选择UDP带来的问题

由于TCP的机制问题，因此通常我们会选择UDP来保障音视频传输的实时性。UDP在实时性方面有优势，但缺点同样明显。由于UDP是不可靠传输，它只能尽力送达，所以出现丢包、乱序是常见的事儿，但对于网络质量来说，丢包是非常严重的事情，这就需要我们自己处理这个问题。下面咱们就来看看WebRTC是如何解决这个问题的吧！

6 如何提高网络质量

6.1 网络质量包含哪些指标

那么，WebRTC是如何处理UDP的网络质量的呢？

要想解决网络质量，首先要知道影响网络质量的几个因素：它包括了丢包率、延迟时间、抖动、乱序。如果网络丢包率低、延迟时间小、不抖动、不乱序，这就是非常优质的网络啦。但如果丢包率很高，那么网络质量一定会很差。

6.2 造成丢包的原因

图中是网络基本的拓扑，造成丢包的原因有很多，如链路质量差，当手机与基站连接时，由于信号不好会造成丢包，这就属于链路差，这种情况在移动端是经常发生的；第二是带宽满，比如一台机子上行发送码率比较大，而下行接收链路比较小，这时在上游的路由器会把数据缓存起来慢慢发送，但缓存是有限制的，一旦缓存被塞满，后面就会造成大量丢包；第三是主动丢包，比如路由是跨运营商的，在不同运营商之间传输数据时，可能由于运营商未知的原因造成丢包；第四是光线被挖断等偶然原因造成丢包。

6.3 减少丢包的方法

WebRTC主要通过两种方式解决丢包：NACK和FEC。

6.4 NACK

NACK的作用是丢包重传。从图中你可以看到，WebRTC的发送端不停地向接收端发送RTP包，接收端每隔一小段时间，就对这段时间内的丢包情况进行统计。如果发现丢包，它会给发送端回一个NACK消息，NACK消息中记录了这一段时间内哪些包丢失了。发送端收到NACK后，会在之前的发送历史记录中找到丢失的包并重新发送。

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更为复杂一些），都是通过一个队列（缓存区）对接收到的数据做下缓冲，然后再从队列的另一端将数据包一个个均匀的取出， 这样取出的数据就是平滑的了。

对于乱序的处理也比较好解决，如图中所示，每个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 基于丢包的带宽评估

基于丢包的带宽评估方法比较简单，根据丢包率进行计算。实际上，正常带宽也有一定的丢包，如果丢包率

Original: https://www.cnblogs.com/lidabo/p/16493333.html
Author: DoubleLi
Title: 李超：WebRTC传输与服务质量