网络连接不良以及如何在 WebRTC 通话中检测它？

当您在在线视频/音频会议平台上进行通话时，是否曾遇到过 “网络连接不良 “指示灯，或断断续续或机械般的音频、冻结的视频？您是否想过浏览器是如何判断连接好坏的吗？在本文中，我将向您介绍在浏览器客户端测量连接质量的一种方法（本例将基于 WebRTC 统计）。

我所在的公司使用 WebRTC API 创建视频/音频会议应用程序。我们遇到的挑战之一是如何检测任何 WebRTC 连接问题。在完美的情况下，会议的每个参与者都拥有稳定的互联网连接，带宽宽、延迟低、不拥堵，并且最终拥有功能强大的个人电脑。

遗憾的是，在现实生活中，人们经常使用手机上的移动数据或 Wi-Fi 网络，坐在厚厚的墙壁后面或工作的微波炉旁边（是的，这有时也会影响您的连接），与来自地球另一个地方的人通话。在这种情况下，有相当一部分网络数据包可能会丢失或延迟，如果我们甚至不向用户发出入站或出站连接出错的信号，就会导致明显的不适。

在这里，MOS（平均意见分值）和 R 因子的计算开始发挥作用！简单地说，MOS 是表示电信会话主观质量的分数（顺便说一下，它不仅用于在线会议）。在这种情况下，R 因子是表示服务质量的数值。如果在视频会议中，您的音频很慢，您可能不需要任何视频，而您甚至听不懂您的对话者在说什么。评分应该给出连接质量的等级值，就像一个人根据自己的感知来评分一样。量表值通常基于 ACR（绝对类别排名）：

5 – 优秀
4 – 良好
3 – 一般
2 – 较差
1 – 差

测得的 MOS 值通常是分数，在现实世界中，优秀的质量介于 4.5-4.3 之间。当得分低于 3.5 时，会议听起来就会不舒服。当然，您也可以根据自己的应用程序调整音量。

要使用 R 因子计算 MOS，我们需要知道丢包情况（丢失了多少数据包：发送 100 个数据包，收到 95 个数据包，即丢包率为 5%）、往返时间（数据包到达目的地再返回所需的时间）和抖动（数据包到达时间的变化或延迟时间的变化）。

幸运的是，在现代浏览器中，使用 RTCPeerConnection:getStats() 方法调用 WebRTC 统计 API 就能获得所有必要的值（如果您使用的是其他技术栈，您可能知道如何在那里获得相同的统计数据）。下面我们来看看计算的伪代码：

ComputationTime = 10
EffectiveRoundTripTime = RoundTripTime + Jitter * 2 + ComputationTime

IF EffectiveRoundTripTime < 160:
    RFactor =  93.2 - (EffectiveRoundTripTime / 40)
ELSE
    RFactor = 93.2 - (EffectiveRoundTripTime / 120) – ComputationTime

LostPacketsImpactCoef = 2.5
RFactor = RFactor - (PacketLoss * LostPacketsImpactCoef)
MOS = 1 + (0.035) * RFactor + (0.000007) * RFactor * (RFactor - 60) * (100 – RFactor)

RoundTripTime、Jitter 和 PacketLoss 值取自 WebRTC 统计数据。在计算 EffectiveRoundTripTime(有效往返时间)时，我们将抖动的影响加倍，并增加了一些固定的计算时间，以补偿网络协议和计算延迟。RFactor 值取决于给定的 EffectiveRoundTripTime（或延迟）。连接质量越差，RFactor 值就越低。

接收到的 MOS 值可作为判断连接问题的方法之一。如果 MOS = 3.3，就可以开始显示一个指示器，让用户明白网络出现了问题。这种机制还可用于自动关闭视频或减少页面上的视频元素数量（优先显示会议音频）。

您可以查看名为 webrtc-issue-detector 的 Typescript 开源库的实际代码示例（它主要用于检测 WebRTC 连接质量问题，但也计算现有 RTCPeerConnections 的入站和出站网络连接的 MOS，这正是我们在此所需要的。它有一个特殊的类，可以通过我们之前描述过的公式计算平均意见分值（Mean Opinion Score）。互联网上有很多库供您选择，您可以自由使用其他库，甚至编写自己的库。