如何减少 WebRTC 的延迟

探索 WebRTC 延迟的概念及其对实时通信的影响。探索最大限度减少延迟和优化应用程序的技术。

作者：Tsahi Levent-Levi
编译：小极狗
原文：https://bloggeek.me/reducing-latency-webrtc/

WebRTC 事关实时性。实时意味着低延迟、低延时、低往返——无论您想用什么指标来衡量（它们都大致相同）。

延迟和往返时间

让我们长话短说。延迟有时会与往返时间混淆。让我们快速理清两者：

• 延迟（或延时，有时也称滞后）是指发送的数据包在另一端接收到所需的时间。我们也将其称为 “半个往返”。
• 往返时间(rtt)是指从我们发出数据包到收到响应的时间 —— 一个完整的往返时间
• 抖动是指接收到的数据包之间的延迟差异。它不是延迟，但通常如果延迟高，抖动也可能高

延迟对 WebRTC 的健康不利

就 WebRTC 和一般通信而言，延迟并不是一件好事。延迟越高，媒体质量和用户体验就越差。

这是因为交互性需要低延迟 —— 它需要快速响应通信内容的能力。

以下是一些需要注意的“事实”：

1. 延迟越低，质量越高

• 对于交互性，我们需要低延迟
• 数据流越快，我们做出响应的速度就越快
• 因此，我们感觉联系越紧密

2. 如果往返时间足够短，我们可以增加重传

• 假设延迟为 20 毫秒
• 从我们发现数据包丢失、请求重传并恢复数据包开始，重传可能需要 30-40 毫秒
• 40 毫秒仍然很棒，因此我们现在可以更好地处理数据包丢失问题
• 因为我们会话的延迟非常低

3. 间接地，数据包丢失也会减少

• 低延迟通常意味着网络路由更短
• 更短的路由意味着更少的交换机、路由器和其他设备
• 数据包丢失的“时间 ”和“地点 ”更少
• 因此通常的预期是延迟越低，平均数据包丢失就越少

4. 您将丢弃更少的数据包

• 如果时间已过（以及其他原因），WebRTC 将丢弃数据包
• 数据包在网络上花费的时间越少，我们就越有时间来决定是否处理以及如何处理它们
• 数据包在网络上花费的时间越长，我们就越有可能无法使用它们（由于时间原因）

5. 较低的延迟通常意味着较低的抖动

• 抖动是指接收到的数据包之间的延迟差异
• 如果延迟普遍较低，那么数据包抖动的 “空间 ”就会减少
• 与数据包丢失或丢弃一样，这并不是什么残酷的事实，只是在延迟较低时往往会发生的事情

您应该监控并努力降低的主要事项之一是延迟。这通常通过查看往返时间指标（这是我们可以比延迟更好地测量的指标）来完成。

说到延迟，我们要测量什么？

您说的 “延迟 ”具体指什么？

• 我们可能指的是单个会话中的延迟——从一个设备到另一个设备的延迟
• 可能是 “端到端 ”的延迟——从一个参与者到另一个参与者，跨越沿线的所有网络设备
• WebRTC 统计与延迟相关的指标？它们主要关注和处理两个直接通信的 WebRTC 实体之间的网络延迟。
• 有时，我们对所谓的 “glass-to-glass ”延迟感兴趣——从摄像头的镜头（或麦克风）到另一方的显示屏（或扬声器）

延迟首先要定义我们测量的是会话的哪一部分。

在这个定义中，可能会有多个处理过程，我们需要对其进行单独测量。通常情况下，我们希望这样做，以决定在优化和减少延迟时应将精力集中在哪里。

您可以决定改善同一用例的延迟，并采取截然不同的路线来实现这一目标。

不同用例处理延迟的方式不同

延迟是个棘手的问题。我们无法克服某些物理限制。最明显的例子就是光速：无论你做什么，试图将一条信息从地球的一端传递到另一端都需要相当长的毫秒时间，甚至不考虑沿途处理数据的需要。

每个用例或场景都有不同的方法来处理这些延迟。从定义什么是足够低的值，到处理管道中应重点优化的位置，再到用于优化延迟的技术。

以下是几个行业/市场，我们可以从中看到这些要求的差异。

会议

视频会议面临一系列独特的挑战：

• 你无法改变边缘的位置。让人们换个地方开会是不可能的
• 一切都是实时的。这些都是人与人之间的对话。它们需要互动

会议的延迟？低于 200 毫秒就很不错了。400 或 500 毫秒太高了，但如果必须的话，也可以忍受（尽管很勉强）。

流媒体

流媒体比视频会议更宽松。我们已经习惯了流媒体几秒钟的延迟。你点击 Netflix 开始播放一部电影，有时可能需要几秒钟。唠叨？是的。需要取消服务吗？不会。

话虽如此，但我们正在转向需要更多互动性的流媒体直播。从拍卖、体育，到网络研讨会和其他用例。以下是我们面临的一些挑战：

• 无法改变边缘的位置。广播是现场直播，因此信号源是固定的。观众也不会转移到其他地方
• 延迟取决于您所追求的互动水平。大多数情况下，1-2 秒（或更长）的延迟都没有问题。有些场景需要毫秒级的延迟

对于直播来说？500 毫秒很好。1-2 秒也不错，这取决于具体情况。

游戏

游戏中有许多使用 WebRTC 的场景。在此，我想重点介绍的是由云服务器渲染游戏并在设备上 “远程 ”玩游戏的情况。

这里的游戏也各不相同（这一点至关重要）。这些游戏可以是休闲游戏、棋盘游戏（回合制）、复古游戏、高端游戏、射击游戏……。

通常情况下，这些游戏都需要实时的高水平互动。在线游戏玩家会选择能降低游戏延迟的 ISP、设备和配置——只是为了获得更多的反应时间，以提高他们在游戏中的表现和得分。而这与在云端渲染整个游戏无关，只是为了传递游戏状态。这是 CenturyLink 为游戏玩家提供的一篇关于其网络延迟的文章，类似的文章还有很多。

云游戏，即游戏在服务器上完整渲染，视频帧通过 WebRTC 在网络上发送？这需要低延迟才能正常游戏。

在云游戏中，50-60 毫秒的延迟是可以忍受的。超过这个时间？游戏结束。哦，如果你的对手只有 30 毫秒？50毫秒时你还是死路一条。任何毫秒数都是越低越好

对话式人工智能

对话式人工智能是最近的热门话题。语音机器人、LLM、生成式人工智能。有很多令人兴奋的新技术。我最近已经介绍过 LLM 和 WebRTC，这里就不多说了。

我只想说，对话式人工智能所需的延迟与会议相同，但它带来了一系列新的挑战，因为语音机器人本身的媒体管道需要增加处理时间——机器需要倾听然后生成响应。

我知道这不能与会议的延迟时间相提并论（因为在会议中，我们没有加上人类参与者的时间，甚至没有加上他理解所发送内容的时间，但目前，大多数语音机器人的响应时间对于高水平的交互来说太慢了）。

在对话式人工智能领域，业界正在努力实现低于 500 毫秒的延迟。能达到 200-300 毫秒将是梦想成真。

减少 WebRTC 中的延迟

不同的用例有不同的延迟要求。它们具有不同的架构和基础设施。这就导致了一个简单的事实，即没有一种单一的方法可以减少 WebRTC 的延迟。这取决于用例和您构建应用程序的方式，它们将决定需要采取哪些措施来减少延迟。

如果将 WebRTC 中的媒体处理流管道拆分为粗略的组件，就能更容易地了解延迟发生在哪里，并由此决定在哪里集中精力进行优化。

浏览器和减少延迟

在浏览器中处理 WebRTC 时，在浏览器端您无法采取太多措施来减少延迟。这是因为浏览器控制并拥有整个媒体处理堆栈。

但在某些方面，您还是应该看看自己在做什么。以下是应该问自己的几个问题：

• 是否应该将播放延迟降为零？Chrome 浏览器支持此功能，通常用于云游戏用例，对话用例较少使用。
• 是否使用可插入流？如果是，那么用于重塑接收和/或发送帧的代码可能会很慢。检查一下

浏览器中最重要的是收集与延迟相关的测量数据。您以后可以用它们来监控和优化它。这些数据包括我们前面提到的 rtt、抖动和丢包。

Mobile 和减少延迟

移动应用程序、桌面应用程序、嵌入式应用程序。任何不在浏览器上运行的设备端应用程序都能得到更多控制。

这意味着您有更大的空间来优化延迟。尽管如此，这通常需要专业的知识和更多的资源，很多人都不愿意投入。

需要注意的地方？

• 从麦克风和摄像头获取原始音频和视频的代码
• 向扬声器和显示器播放传入媒体的代码
• 编解码器的实现。特别是如果这些可以被硬件变体“替换”
• 媒体管道本身的数据传递和处理。现在，您可以决定不再等待谷歌对其进行改进，而是尝试自己进行改进（祝您好运！）。

在采用这种方法时，请记住这里的大多数优化都是针对设备和操作系统的。这就意味着，您需要在多个平台上进行优化。

减少基础设施延迟

这就是网络延迟，WebRTC 统计中的大部分 rtt 指标都来自于此。

基础设施与用户的位置对延迟有很大影响。

我几乎经常使用的例子是什么？法国的两个用户通过美国的媒体或 TURN 服务器连接。

弄清用户在哪里，他们使用什么 ISP，在哪里放置自己的服务器，通过哪个运营商将服务器连接到用户，需要时如何将服务器相互连接，所有这些都是可以优化的。

首先，看看您的 TURN 服务器和媒体服务器托管在哪里。将其与用户的来源进行比较。确保两者保持一致。还要确保分配给用户的服务器离他们最近（就延迟而言，不一定是地理位置）。

看看是否需要在更多地点部署基础设施。

反复进行，随着服务的增长，可能需要改变重点和基础设施的位置。

其他可改进的地方包括使用 Anycast 或网络加速，目前大多数大型 IaaS 供应商都提供这种服务（网络传输价格较高）。

媒体服务器处理和延迟

然后是媒体服务器本身。大多数服务都需要它们。

媒体服务器主要是负责路由和混合媒体的 SFU 和 MCU。此外，还有各种形状和大小的网关。

这些媒体服务器处理媒体并拥有自己的内部媒体处理管道。与其他管道一样，它们也有固有的延迟。

减少这种延迟将减少应用的端到端延迟。

生成式人工智能、对话式人工智能和……LLM 的美丽（新）世界

还记得我们从哪里开始的吗？我讨论延迟是因为 WebRTC-LLM 用例必须专注于减少自己管道中的延迟。

这让业界再次关注延迟问题，试图找出如何以及在哪里可以减少几毫秒的延迟。

坦率地说？这需要在整个管道中进行，从设备到基础设施和媒体服务器，当然还有 TTS-LLM-STT 管道本身。我相信这将是未来一两年内的一项持续性工作。

了解 WebRTC 的延迟

没有测量，就无法优化。

第一步是测量。

以下是一些建议：

测量延迟（显而易见）

• 将延迟分解为管道的各个部分，并对每个部分进行独立测量
• 决定每次重点优化哪些部分

科学对待

• 创建一个易于设置和操作的测试平台(或者用作者推荐的testRTC)
• 可以在 CI/CD 中运行测试以快速获得结果的测试平台
• 这将使您更容易了解您引入的优化措施是有效还是适得其反

大规模进行测试

• 不要只在实验室中进行。直接在生产环境中运行
• 这将使您能够发现用户的瓶颈和延迟问题，而不仅仅是合成场景

最后，关于延迟的问题，如果您有音视频相关业务需要，可以测试即构的实时音视频SDK，实现最低79ms 的通话、直播等场景。4 行代码接入SDK，海量功能，全链路自研，无需重复造轮子，感兴趣的可以注册免费试用。