WebRTC中不同类型的延迟测量

在构建 WebRTC 服务时，衡量用户体验的最重要指标之一是通信延迟。延迟很重要，因为它会影响会话交互性，还会影响使用重传（这是最常见的情况）时的视频质量，因为重传的有效性取决于您获得重传的速度。

公平地说，延迟是实时通信与其他类型的通信和协议（例如用于对延迟不太敏感的流媒体用例的通信和协议）的区别，因此很明显，延迟是一个重要指标追踪。

然而，没有单一的延迟测量方法，不同的平台、API 和人们通常测量不同类型的延迟。从我过去所见，我们可以看到下面描述的这四个轴的差异。

单跳延迟与端到端延迟

当对话中涉及多个服务器时，本机 WebRTC 统计信息仅提供有关第一跳（从客户端到服务器）的延迟信息。这并不能为您提供全貌，通常您更喜欢测量端到端延迟，包括从第一个客户端到第一个服务器的延迟，然后从每个服务器到下一个服务器，最后从最后一个服务器到其他客户端。

这可以从 webrtchacks 的这张很棒的图表中看出。

测量端到端的延迟要难得多，因为WebRTC协议栈并不自动提供，而且需要发送一些额外的ping-pong信息（例如使用数据通道）或在同步时钟中转的机制，这不是很实用。

另一种测量方法是测量每一跳的延迟，然后汇总每个来源和目的地区域的平均数。 这不能给你提供相同的东西，但它可以是一个近似值，足以检测特定区域的问题。

真实用户延迟与合成流量延迟

有些人使用综合测试来衡量他们平台提供的延迟。这对于提醒目的非常有用，但不能让您全面了解用户如何体验您的服务。例如，也许有一个特定区域的用户会遇到高延迟，但您没有测试客户端从该特定区域探测您的平台。

在测量真实用户的延迟时，您通常必须使用 WebRTC getStats API 或一些数据通道ping-pong消息传递，但在使用合成流量时，您可以更自由地使用特殊的自定义 RTP 数据包或带有时间戳水印的视频源。

网络延迟或捕获到渲染延迟

在测量延迟时，您通常会测量网络中数据包的延迟，但这并不是用户将体验到的语音和视频的全部延迟。除了网络延迟之外，执行捕获和渲染的软件也会引入延迟。这在接收方使用缓冲区来缓解抖动、数据包丢失或数据包重新排序等网络问题的情况下特别相关。

要测量整个延迟，包括在捕获和渲染端引入的延迟，您可以在计算中包括 WebRTC getStats API 提供的一些额外指标，如jitterBufferDelay、playoutDelay、packetSendDelay …

往返时间或单程延迟

另一个小区别是延迟是作为往返时间延迟（两个方向 A->B + B->A 的总和）还是仅以其中一种方式独立测量的。在大多数情况下，测量的是往返时间，然后将其除以二作为对单向延迟的良好估计。

结论

作为总结，下次您提供有关 WebRTC 解决方案延迟的数字时，请解释您正在测量的延迟类型以及您如何测量以使其更清楚 🙏。 

如果您可以的话，应该尝试测量端到端的延迟，但即使是逐跳的延迟对于监测和故障排除也是非常重要的。 如果有足够的流量，有可能您想测量的是真实用户的延迟，但如果没有足够的用户，或者想获得更多的数据，那么使用合成测试来估计延迟也是一个好办法。