本文首发在云+社区，未经许可，不得转载。算法
云+导语：4月21日，腾讯云+社区在京举办“‘音’你而来，‘视’而可见——音视频技术开发实战沙龙”，腾讯音视频实验室高级工程师张轲围绕网络传输方面讲解了《腾讯云H5语音通讯QoE优化》，包含腾讯云H5解决方案，音频QOS优化总体框架及优化技术，和运营方法几个方面。QOS优化包含带宽估计拥塞控制、抗丢包技术、延时、抗抖动技术四个领域。张珂重点分享了WebRTC与WebRTC之间，tbs与WebRTC之间，tbs与natvie之间互通所涉及的QoS相关的技术问题，回溯分析工具可以提升工做效率，能够快速发现潜在技术改进点，加快技术迭代速度。编程
腾讯音视频实验室高级工程师张轲
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进行编程。咱们还有一些推流、录制、点播等等的能力。dom
三种差别化的服务质量
实现一套基本的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和交织搭配的使用。数据包123四、1234，写入一个矩阵，而后读的时候是按列取的，这样就实现了交织。
交织目标是为了把差错离散化，再用FEC技术恢复。交织深度M越大，离散度越大，抗突发丢包能力越强，延时越大。
怎么设计一套好的FEC算法？
一、抗丢包算法要归入拥塞控制算法，必须是网络自适应的，很是重要，是前提。
二、保证抗丢包能力的前提下如何减小冗余流量。
三、如何最大化发挥各类FEC机制的优势，场景反馈（连续丢包次数，丢包特性）。
四、FEC算法，分组大小的选择，对流量、延时，抗丢包性能的影响均要考虑到。
五、动态冗余率机制，收敛速度。
六、FEC效果评价。
七、一对多场景，须要对每路接收定制化FEC保护方案。
收端要作好各类反馈，收端收到数据包的时候，要作一些成功率的计算，都反馈到策略中心，来作相应的统计、控制。
NACK算法关键点：
一、结合音频/视频的Jitter buffer状态决策请求。
二、发端/收端延时控制。
三、其它不少精细化控制细节。
四、重传效果的评估。
五、运营、数据监控。
结合纠错和同传的机制。上面对比了一下ARQ和FEC的能力。ARQ引入了突发抖动，较难处理。突发丢包处理能力好，流量效率高。引入延时不固定，但能够设置限制。
FEC抖动变化小，大小丢包均能处理好，但要牺牲带宽突发丢包处理很差。引入延时相对固定。
WebRTC RetEQ算法里面的关键点：
一、延时估计算法。
二、播放延时估计算法。
三、自适应决策逻辑。
四、语音变速算法。
五、VAD、CNG数据算法。
关于流量。
一、下降传输包头：传输层包头。
二、增长组包时长，20毫秒调整到60或者80毫秒，减小包头负载。
三、下降内核码率。1：VAD、DTX2codec层面优化码率。
四、下降冗余。
关于延迟
网络延时：处理延时，排队延时，传输延时和传播延时。
设备延时：采集、播放设备。
播放延时，是数据包到达时和播放时间之间的延时，抗抖延时。
编解码和处理延时：编解码和各类先后处理算法延时。
运营方法
第一部分是专业的实验室，保证了咱们测试数据的准确性和可靠性，以及可追诉性，为系统正式上线运营提供了保障。
QOE的影响因素是很是复杂的，目前咱们仅关注客观质量，设计了一套评估体系。咱们在线上系统运营的时候，能够提供一个简单的指标，衡量咱们的算法究竟是好仍是坏，直到后续的优化方向，作一些板块监控。甚至具体到算法调优层面，能够作一些聚类，划定一些分析样本，作进一步的有针对性的优化。
问题分析工具：还原通话过程技术参数，快速问题还原，分析、诊断，也为进一步优化提供丰富案例。
咱们经过ABTest运营进行工做方法效果验证。安卓平台FEC优化版本新策略（奇数房间）质量明显优于老策略（偶数房间）。好的系统和算法是要经过运营数据来验证和不断迭代的。
咱们云语音质量的数据到底怎么样？2分如下占比小于3%。10%的通话中断了，10%到15%的用户对质量不满意，这个数据能够作一下对比。
咱们的优化是永无止境的课题。WebRTC从M56到前两天发布的M66版本，WebRTC解决了1000多个Bug。
Q/A
Q：我想问一下，好比说在接入请求的时候，可能会有一些效率，你的软件、你的网络，还有一些其余硬件的缘由。我想了解一下，您这个优化的时候，都是会遇到什么样的问题点？怎么避免这些问题？问一下，好比说你硬件会有一些传输的效率，还有你的软件，或者各个系统之间的一个集成交互的时候，这些忧患点能不能分享一下？
A：我刚才讲到的，系统集成层面上，若是仅仅用浏览器，除了在后台作优化以外，没有太多的优化方法。可能更多的是优化你的流程层面的。若是你有从WebRTC内部层面作优化，那就太多了。音视频全部的领域均可以作，这个范围太大了。我讲的仅仅是网络传输这一个层面，有回升、有效率等等，太多方面了。