本文首发在云+社区，未经许可，不得转载。
11月份，W3C发布了WebRTC的标准。另外一个专注于WebRTC的国际组织RETF在12月份也发布了第一个RFC8298，目前还没有成为真正的标准。我今天讲的重点，是围绕网络传输的一些心得。
2017年3月份CallStatus.io WebRTC发布的全球质量报告中，第一个有10%的通话会因为各种带宽、丢包、流失原因，造成中途中断。第二个是有10%到15%的用户，对音视频通话的质量不满意。第三个是有7%左右的大丢包，有95%左右的用户已经流失在240毫秒以下。
正是因为现在的WebRTC方案有很多问题，我们简单分析一下刚才的一些质量不佳的原因，有大概三个原因：
第一个，本身WebRTC涉及的是P2P的网络连接，中间可能没有大量的中转系统，在遇到跨运营商，甚至小运营商的时候，它的网络链路是没有质量保证的。
第二个，各个浏览器互操作性、兼容性很差。这些问题刚好都是我们的专长。我们基于此开发了一套解决方案。
两个核心的技术优势
第一个是我们的实时音视频；第二个是基于QQ浏览器的TBS内核的浏览器上面支持了WebRTC的能力。我们可以针对WebRTC代码做很多修改，甚至优化。
我们用户端可以在微信、QQ浏览器上面，对WebRTC进行编程。我们还有一些推流、录制、点播等等的能力。
三种差异化的服务质量
实现一套基本的WebRTC，工作量是后台的搭建，接入部署，包括在后台实现传输控制、媒体加密，增加运营能力。QQ的东西是十多年海量用户的经验，我们现在每天QQ的通话时长大概在10到20亿分钟左右。扩展的WebRTC，是相当于在QQ浏览器内核里面，集成了WebRTC的内核，同时对它做了一个扩展，解决了现在WebRTC的一些问题。我们对QOS也做了一些简单的扩展。我们会根据后面用户量的一些使用情况来决策，看这三个怎么更好地协调，或者说优势互补。
接口机的分配及接入的状况
我们建立了一套机房节点全球链路质量监控系统，在WebRTC项目里面，大概部署了60多个节点，覆盖了30多个国家。国内98%的节点之间链路延时小于36ms。有90%全球的网络节点之间，大概链路节点小于100毫秒。链路优化是持续的过程，包括节点的部署，也会根据用户量的使用情况来决策，在哪些地域或者是地区投放我们的节点部署。
QOS优化——拥塞避免算法和抗丢包技术
后台质量控制示意图中能看到我们实现了SFU和MCU。质量控制，就是三级策略，接口级这个地方，先估计终端上行网络的质量，包括做带宽估计，包括抗丢包机制的对接。下行的带宽估计，抗丢包的一些机制对接。最核心的地方，控制策略是根据上下行的一些质量信息，来决策我们的流量控制到底应该怎么做，这里面有一个核心决策体系，这个东西也是我们整个实时数据里面一个非常核心、非常有竞争力的技术。
QOS优化到底有哪些技术？
分带宽、丢包和延时、抗抖四个领域。想做好QOS，环节特别多，从编解器、链路、传输、处理、设备等众多环节，处理好技术的协作关系，各种算法的调度、管理、配合是核心难点。
带宽工具，包括网络拥塞，有GCC、NANA、SCReam、FRACTal。抗丢包技术里面有ARQ、FEC、PLC延时构成，包括我们的核心在做采集播放的时候，我们会控制很多领域的东西。不同的问题牵扯到不同的技术，各种基础技术的理解深度和广度以及应用策略，这是第一个层面的东西。
第二个层面，各种技术、各种因素，它的配合影响，包括反馈以及联动策略，相对来说比较综合的第二个层面的东西。
第三个层面，很多业务特性决定了基于场景的差异化的策略，也会导致要采用的策略不一样。
想做好QOS，必须要把这三个层面的东西解决好，不然QOS是做不好的。
什么样的算法才是比较好的拥塞控制算法？
实时媒体拥塞避免控制方案，一直是IETF RMCAT的热点研究课题。传输延时要小于100毫秒。数据流之间不能相互干扰，不能因为自发引起不恰当的使用带宽。丢包是越小越好，带宽应用率要高，尽可能使用带宽。在带宽有限的情况下，传输通道不能饿死。出于安全的考虑，要对可能的一些拥塞控制领域的反馈攻击做一些处理。安全性方面，媒体数据的发送一定要是平滑的。公平性方面，不要饿死，也不能抢更多的带宽，要共享带宽。
适应性有很多方面，第一适应实际带宽的波动。比如说在音频里面会启动不连续传输，可能导致带宽越来越弱，这时候怎么处理？最后一个就是反馈，反馈通道不好了怎么办？反馈包丢失了怎么办？怎么去控制好？能把这10个方面做好，就提供了比较好的工具。
TFRC是大概十年前用的技术，最大的问题是延时不可控，视频帧大小经常发生变化。有速率振荡行为。高丢包下的准确度有问题。
LEBDBT，好处是延时相对来说绝对可控。它的缺点是太灵敏了，有网络波动或者是在带宽上有一些突发流量，都会导致它迅速崩溃，导致带宽饥渴。还有一个是后来者效应。它会把第一路的带宽给抢占了。
GCC，它是有两部分，第一部分是收端是基于延时的控制算法，发端是基于丢包的。它主要有几个问题：它在移动网络环境多流共存情况下，表现很差。
在有TCP流并存的情况下会过度退让从而导致WebRTC流饥饿在多WebRTC流并发的情况下，新加入的WebRTC流会损害已有流的通信质量。 SCReam是基于窗口和面向字节。缺点是见SCREAM-CPP-implementaion，有线网络不如GCC。NADA是基于延迟和损失，目前仍是实验代码。FRACTal是FEC探测带宽，缺点是鲁棒性仍需要提高，移动和无线网络待验证。QUIC是Quick UDP，默认拥塞控制算法无法保证低延时，可提供私有拥塞算法。
两套实现方案：现有WebRTC已切换到绿色部分基于延时的发端拥塞方案，上下两套算法通过SDP参数控制。
这是几个主流的浏览器的实践状况。Edge还是老的算法。OpenWebRTC主要推荐的是SCReam算法。
我们的应用策略对于不同的浏览器、不同的版本能力是不一样的，提供WebRTC解决方案，必须要清楚。我们在基本的WebRTC通话场景，通过SDK参数交换使用的拥塞控制方案。不同浏览器里面，必须要管理好这些拥塞控制算法。我们提供私有的拥塞控制算法，主要是基于我们已有的经验积累，包括刚才我对各种算法的解读，包括优缺点的优化方法，同时我们也会在运营层面上对比不同的算法。
FEC算法有很多种，第一个是Inband FEC，在语音的编码器里面，生成一部分冗余信息。它的缺点是以牺牲语音质量为前提的，虽然可以保证流量是稳定的，但是它的质量是不好的。
异或，这个是WebRTC里面一个主要的实现方法。
Reed-Solomon的纠错率比较高一点。交织编码，在WebRTC里面也有使用。它的目的不是纠错，而是把丢包给散化。还有一个Fountain，这个技术也非常老了，近两年在实施领域，可能在广播里面应用比较多。它是无码率的注册编码，特别适合多场景使用。它增加了流量和延时，但是相对来说FEC机制增加的延时量是比较稳定的，适合信道特征稳定的场景。
WebRTC提供了异或和交织编码这两种。 WebRTC中使用的XOR FEC，异或是通过分组的原码实现的。我提了4个数据包生成三个冗余包。如果收到数据包123，数据包123丢失了，收到4567。123是数据包，4也是数据包，冗余包是567，通过47，把数据包给否了。
需要损失程度和乱序相关的反馈，才能正确选择KFecMaskRandom还是KFecMaskBursty。
这个是WebRTC中FLEXFEC，还是刚才的异或关系。一种是非交织，一种是交织的。非交织的比如说1234进行异或生产一个数据包。5678生成一个数据包。
对于交织的情况，可能就是159，然后生成一个纵向的冗余包。现在还有二维的，横向的也生一个冗余包，纵向也生成一个冗余包，它的纠错能力不是那么强，这是WebRTC里面的事情。
还有一种是FEC和交织搭配的使用。数据包1234、1234，写入一个矩阵，然后读的时候是按列取的，这样就实现了交织。
交织目标是为了把差错离散化，再用FEC技术恢复。交织深度M越大，离散度越大，抗突发丢包能力越强，延时越大。
怎么设计一套好的FEC算法？
1、抗丢包算法要纳入拥塞控制算法，必须是网络自适应的，非常重要，是前提。
2、保证抗丢包能力的前提下如何减少冗余流量。
3、如何最大化发挥各种FEC机制的优点，场景反馈（连续丢包次数，丢包特性）。
4、FEC算法，分组大小的选择，对流量、延时，抗丢包性能的影响均要考虑到。
5、动态冗余率机制，收敛速度。
6、FEC效果评价。
7、一对多场景，需要对每路接收定制化FEC保护方案。
收端要做好各种反馈，收端收到数据包的时候，要做一些成功率的计算，都反馈到策略中心，来做相应的统计、控制。
NACK算法关键点：
1、结合音频/视频的Jitter buffer状态决策请求。
2、发端/收端延时控制。
3、其它很多精细化控制细节。
4、重传效果的评估。
5、运营、数据监控。
结合纠错和同传的机制。上面对比了一下ARQ和FEC的能力。ARQ引入了突发抖动，较难处理。突发丢包处理能力好，流量效率高。引入延时不固定，但可以设置限制。
FEC抖动变化小，大小丢包均能处理好，但要牺牲带宽突发丢包处理不好。引入延时相对固定。
WebRTC RetEQ算法里面的关键点：
1、延时估计算法。
2、播放延时估计算法。
3、自适应决策逻辑。
4、语音变速算法。
5、VAD、CNG数据算法。
关于流量。
1、降低传输包头：传输层包头。
2、增加组包时长，20毫秒调整到60或者80毫秒，减少包头负载。
3、降低内核码率。1：VAD、DTX2codec层面优化码率。
4、降低冗余。
关于延迟
网络延时：处理延时，排队延时，传输延时和传播延时。
设备延时：采集、播放设备。
播放延时，是数据包到达时和播放时间之间的延时，抗抖延时。
编解码和处理延时：编解码和各种前后处理算法延时。
运营方法
第一部分是专业的实验室，保证了我们测试数据的准确性和可靠性，以及可追诉性，为系统正式上线运营提供了保障。
QOE的影响因素是非常复杂的，目前我们仅关注客观质量，设计了一套评估体系。我们在线上系统运营的时候，可以提供一个简单的指标，衡量我们的算法到底是好还是坏，直到后续的优化方向，做一些板块监控。甚至具体到算法调优层面，可以做一些聚类，划定一些分析样本，做进一步的有针对性的优化。
问题分析工具：还原通话过程技术参数，快速问题还原，分析、诊断，也为进一步优化提供丰富案例。
我们通过ABTest运营进行工作方法效果验证。安卓平台FEC优化版本新策略（奇数房间）质量明显优于老策略（偶数房间）。好的系统和算法是要通过运营数据来验证和不断迭代的。
我们云语音质量的数据到底怎么样？2分以下占比小于3%。10%的通话中断了，10%到15%的用户对质量不满意，这个数据可以做一下对比。
我们的优化是永无止境的课题。WebRTC从M56到前两天发布的M66版本，WebRTC解决了1000多个Bug。
Q/A
Q：我想问一下，比如说在接入请求的时候，可能会有一些效率，你的软件、你的网络，还有一些其他硬件的原因。我想了解一下，您这个优化的时候，都是会遇到什么样的问题点？怎么避免这些问题？问一下，比如说你硬件会有一些传输的效率，还有你的软件，或者各个系统之间的一个集成交互的时候，这些忧患点能不能分享一下？
A：我刚才讲到的，系统集成层面上，如果仅仅用浏览器，除了在后台做优化之外，没有太多的优化方法。可能更多的是优化你的流程层面的。如果你有从WebRTC内部层面做优化，那就太多了。音视频所有的领域都可以做，这个范围太大了。我讲的仅仅是网络传输这一个层面，有回升、有效率等等，太多方面了。