音视频服务质量监控体系建设
2020 年疫情的爆发以及此后全球的疫情防控常态化趋势，让各类云服务快速完成了大规模客户教育，整个社会加速推进数字化进程。作为人们远程交互的主要手段，音视频的应用场景越来越广泛。音视频业务的持续增长态势，吸引着各方力量争相入局，市场竞争日益加剧。
无论是应对海量用户涌入带来的挑战，还是为了在日益激烈的竞争中保持优势，音视频服务商都需要围绕服务质量、用户体验不断迭代优化。卡顿、延迟、花屏、宕机、丢包、画质……所有可能影响用户体验的问题都需要被精准定位、快速分析。
作为实时音视频领域的第一梯队服务商，融云的 RTC 实时音视频技术应用广泛且好评不断。这一方面源于其对技术的不断追求，另一方面也得益于其搭建了一套有效的服务监控体系。
监控体系可以对产品质量和性能进行实时监控，分析影响客户使用体验的原因，为研发人员提供更加详细的位置信息、准确的参数信息、实际的场景情况等，最终方便研发人员快速定位根本问题、准确制定优化方案，从而保证优质用户体验，提升产品竞争力。
本文将通过融云音视频服务架构及质量监控点拆解，分享用大数据的方式解决音视频质量监控问题的实践思路。
融云 RTC 服务架构
客户端接入服务的选择点非常关键，客户端接入距离自己最近、链路跳转最少的服务集群，数据到服务器的延迟最小，链路最稳定，这是第一道保障。
客户端首先接入的不是最终的服务，而是管理接入点的服务，会根据用户接入的 IP，识别出用户所在区域、网络线路的运营商、用户到服务之间的跳转。比如，根据距离的划分，一位山西的用户归属于北京音视频服务集群；这个用户使用的是移动网络，则下发移动接入点的 IP，以确保客户端接入距离自己最近的、链路跳转最少的服务集群。
用户的分布不可控，不同用户接入不同的服务集群，集群之间需要级联。一般而言，服务之间拓扑结构有如下几种：
星型网络拓扑结构：星型，像星星发光，就是具有控制中心，即采用集中式的方式，使得各点之间的联系均和中心站连接，这就是星型网络拓扑模型。
优点：很容易增加节点，容易实现网络监控，在保证连通完备下网络延迟时间短。
缺点：中心控制点有问题，则会导致整个网络的停工；网络共享能力差。
核心：要对中心节点配置性能强、可靠性高、容错性好、性价比高的计算机器系统。
树状拓扑结构：像一棵树，可看作总线型的扩充，但是传输介质不封闭的分支网络。
优点：网络分级，可共享数据。
缺点：介质故障容易出现个别或整体停工，安全性能低。
核心：分级逻辑结构，传输介质容错机制。
网状拓扑结构：像一张网，上面有很多节点，他们之间不一定有严格的规则，各点之间可有多条线路连接。
优点：可靠性高，故障率低，共享数据方便。
缺点：管理复杂，硬件成本高。
核心：降低成本，保证完备情况下尽可能减少路径。
融云选择的是网状拓扑结构+星型网络拓扑结构，相对灵活、方便部署、易于扩展，能有效降低服务之间的延迟，每个服务集群之间搭建多条链路确保服务之间的稳定性。
除了三大运营商，国内还有一些小型网络运营商，他们的网络建设有自建局域网、不同出口带宽有限、出口延迟性比较高、丢包率不可控、网络抖动明显等问题。针对这类情况，我们选择边缘节点，拉近与客户的距离，避免因客户的网络问题影响使用体验。
音视频服务监控点
音视频服务质量监控，要以用户接入点、接入数据的监控、服务之间的接入、服务之间的数据监控以及整体服务的状态为监控点。
用户接入点是否正确，决定着用户的使用体验能否得到第一道保障。至于是否需要接入边缘节点，以及分发的接入信息是否正确等问题，需要通过持续不断的检测和监控来判断。客户端不断探测不同的接入点，系统若发现接入点需要优化，会给出端上当前实际链路调整的通知。然后，客户端根据通知及当时实际情况，选择最佳时间切换链路。
上面所说的链路是通常意义的硬件链路，影响着用户的通道是否稳定、数据延迟程度、丢包率、网络抖动情况。大部分情况下，用户到服务的所有链路都无法保证稳定。无论是就近接入，还是选择不同运营商，都难以保障网络稳定，这是公网环境决定的。
针对网络不可控情况的优化，是所有音视频服务商投入最多人力和财力的部分。而这些努力和投入，都不是为了改善网络情况，而是降低弱网对音视频通话的影响程度。
通过对用户接入数据的监控，可以查看用户的通道稳定情况、数据延迟范围、丢包率情况、网络抖动评估。通过对这些数据的监控和分析，可以大概评估用户的音视频使用体验（客户端同样有监控，不在本文介绍范围）。在这些大数据的帮助下，研发人员可以分析问题并提出优化方案，进而不断提升服务的性能和稳定性。
视频延迟和人感官的关系：
- 0 ~ 400 毫秒：人感觉不到视频在通信过程中的延迟
- 400 ~ 800 毫秒：人能感觉到轻微延迟，但不影响通信互动
- 800 毫秒以上：人能感觉到延迟而且影响通信互动
640 x 480 分辨率每秒 24 帧的 H264 编码情况下，视频码率和人感官之间的关系：
- 800kbps 以上：人对视频清晰度满意，感觉不到视频图像中的信息丢失
- 480 ~ 800kbps：人对视频清晰度基本满意，有时能感觉到视频图像中的信息丢失
- 480kbps 以下：人对视频清晰度不满意，大部分时候无法辨认图像中的细节信息
客户端选择其中一个落点之后，需要通过 ice 的 STUN 探测所有最优链路，以及每个链路的保活。
ice 到达时间和间隔的收集，有助于我们分析用户通话过程中基础通道的稳定性、网络抖动情况，因为 ice 不涉及音视频的采集、编码、发送平滑、拥赛控制等逻辑。即使用户每次实际接入的 IP 没有发生变化，也不一定表示用户的网络没有任何调整。判断用户网络的变化情况需要结合具体端口，这有助于我们分析客户情况，并帮助客户了解使用他们应用的用户所处的网络环境。
音视频的传输通道建立完成之后，就开始传输音视频数据，每个音视频包的到达时间可以计算出来 jitter（也称为等待时间或延迟）。每个音视频流的 jitter 的收集和分析，有助于我们分析这道音视频流的平滑情况、是否抖动、是否拥塞等。
视频关键帧因为是最完整的帧画面，通常远远大于MTU（最大传输单元），为了正确传输，通常会将关键帧切分为多个 RTP 包进行传输，但是传输过程中乱序和完整性都没办法保证。
所以，每道视频流的关键帧的发送情况，结合用户实际应用场景，可以帮助我们分析客户端上行采集视频、编码视频、发送视频、链路中整体情况。比如，上图可以看出每个完整的关键帧发送到达的服务间隔平均，没有发生明显的变化，这表明用户的网络状态较好。
对比之下，图 7 这个关键帧的接收情况波动较大，几个关键帧的接收有延迟。造成这种情况的原因，可能是采集或者编码卡顿，也可能是传输过程中有丢包。因为关键帧相对来说比较大，在网络传输过程中需要切分成较小的数据大小。
服务之间的接入，是我们服务部署方案、运营商选择、加速通道的最终验证。一两次验证不足以检测部署方案的好坏，也无法说明一个网络运营商的稳定性，以及是否选择了有效的加速链路。
借助对音视频服务的监控、网络的探测、级联发送和接受等产生的大数据进行分析，可以综合得出服务出现问题的多种情况，比如服务的落点、服务自恢复情况、数据延迟情况、数据丢失情况、数据拥塞情况。
音视频服务的监控和大数据检测、分析有其复杂性，未来，我们还将不断增加监控维度、细化颗粒度，提升数据准确性、计算能力、动态调节能力、响应速度、问题定位时效，同时结合人工智能分析模型，为音视频监控体系注入更多的智能化力量，在节约人力的同时，提升准确性。