如何使用 WebRTC 实现超低延迟？

在了解 WebRTC 解决超低延迟流媒体问题的方法之前，我们有必要讨论一下超低延迟的定义。什么才是实时视频流中的超低延迟？在过去十年中，什么被认为是 “超低延迟 “取决于你问的是谁，而且通常很难得到准确的答案。目前来说将 “超低延迟 “归类低于 1 秒的视频流会更恰当。

另一方面，WebRTC 尤其擅长在实时流中最大限度地减少视频延迟，始终保持亚秒级延迟。究其原因，WebRTC 最初是作为点对点流媒体视频通信协议，用于视频会议等使用案例，在这些案例中，亚秒级延迟至关重要。后来，WebRTC 被更广泛的广播行业采用，用于一对多的流式使用案例，如体育投注、现场拍卖和许多其他需要实时视频流的交互式应用。

由于本篇文章的主题是 WebRTC 如何实现低延迟，因此我们将重点讨论实时视频流类别。话不多说，让我们来了解一下 WebRTC 如何以及为什么能实现这些令人难以置信的低延迟流效果，以及它与其他视频流协议的比较。

UDP 与 TCP

TCP 和 UDP 是传输层协议，用于在互联网上发送比特数据（称为数据包）。在超低延迟流媒体直播中，我们发送的是视频数据包。这两种协议都使用 IP 协议，这意味着由 TCP 或 UDP 发送的数据包都将发送到一个 IP 地址。

但相似之处也仅此而已。TCP（传输控制协议）是一种面向连接的协议，具有内置的错误恢复和重传功能。所有来回通信都要对数据包重新排序，并确保其完整发送，这就带来了延迟。TCP 用于 HLS 和 DASH 等基于 http 的高延迟流协议，而 TCP 的开销正是这些视频流协议难以实现超低延迟直播流的原因之一。

WebRTC 使用 UDP（用户数据报协议），通过消除对每个数据包的错误检查来提供更快的信息流。视频数据包直接发送给接收方，无需正确排序和重传。发送方无需等待确认，而是继续发送数据包，无需错误恢复。如果数据包被丢弃，它们就会丢失，不会被重新发送（NACK 除外，但稍后会详细说明）。减少这些开销意味着设备可以更快地进行通信。

UDP 并不像 TCP 那样包含所有排序数据，而是依赖于应用级 RTP 协议对数据包进行正确排序，并知道哪些数据包不符合当前的时间框架而需要丢弃。下面将详细介绍 RTP。同样，WebRTC 被设计为使用更高效的 UDP 协议进行实时流媒体传输，以满足视频会议中双向通信的需求，在这种情况下，视频的低延迟传输是最重要的方面，而缓冲视频质量并不是一个选项。使用 WebRTC 进行低延迟视频流传输最重要的是效率，而 TCP 协议在这种情况下根本无法有效发挥作用。

RTP 效率

WebRTC 使用流协议 RTP 在互联网和其他 IP 网络上传输视频。

RTP 以小块的形式发送视频和音频数据。每个数据块之前都有一个 RTP 头；RTP 头和数据又包含在一个 UDP 数据包中。数据以数据包序列的形式组织，数据包较小，适合在服务器和客户端之间传输。RTP 流携带由音频或视频编解码器编码的实际媒体有效载荷。报头用于适应不同的网络条件，如单个参与者从低带宽连接加入。当应用程序播放一个数据包时，后面的数据包可能已经处于解压缩或解复用阶段。

互联网和其他分组网络一样，偶尔会丢失和重新排列数据包，并会延迟不同的时间。为了应对这些干扰，RTP 头包含定时信息和序列号，使接收器能够重建源产生的定时。这种定时重建对会议中的每个 RTP 数据包源分别执行，以适应实时条件。

调整是通过混音器进行的，混音器会重新同步传入的音频数据包，以重建发送方生成的恒定小块间距。然后，它将这些重建的音频数据流混合成一个数据流，将编码转换为相应的质量设置，并转发数据包流。这些数据包可以单播给一个收件人，也可以通过不同的地址多播给多个收件人。由于互联网不支持组播，WebRTC 利用的是 RTP 的单播版本。

通过整合基本信息，RTP 简化了媒体传输过程。与 UDP 协议本身一样，当 RTP 层叠在 UDP 上时，它的开销也更少，这使得它比其他流媒体解决方案（如 HLS 或 DASH，包括它们的低延迟变体）更快。RTP 不仅仅是一个轻量级协议，它还通过使用推送方法来发送流媒体来减少延迟。我们将在下一节详细讨论这一点。

推与拉

为了传送数据流，广播公司和订户之间必须建立连接。除此之外，广播公司还必须知道它需要向订户发送哪些内容。有两种不同的方法可以做到这一点：推和拉。

HTTP 协议（如 HLS 和 MPEG DASH）采用拉式方法，客户端不断请求视频片段。这就意味着，在广播公司和订阅客户端之间会不断有请求流来回流动。这基本上就像逐行发送电子邮件，而不是同时发送。这种持续的轮询会产生大量的开销，使整个过程效率低下。值得注意的是，这种方法也有优点，比如可以创建一个无状态系统；CDN 利用拉动的这一特性，可以在多个服务器（边缘）节点上分发视频块。不过，尽管这种方法更容易将视频流扩展到大量观众，但却大大增加了延迟。

另一种方法是 RTP 向客户端推送连续的数据流。无需等待确认，RTP 直接发送视频。RTP 知道第 2 行在第 1 行之后，因此它不会浪费时间询问下一个需要发送的数据包。与调用和响应的拉取方法相比，这种方法的效率要高得多。

浏览器原生支持 WebRTC

WebRTC 可在所有 Web 浏览器中本地运行。所有编码和解码都直接在本机代码中执行，而不是 JavaScript，从而提高了效率。

超低延迟流技术的一种方法是结合 MSE（媒体源扩展）和 WebSockets 等浏览器技术。在这种设置中，解决方案依靠 JavaScript 从视频流中提取所有数据。虽然 MSE 和 WebSockets 都是单独用本地代码编写的，但开发人员需要编写 JavaScript 才能使它们协同工作。由于 JavaScript 是一种解释型语言，这意味着它的效率不如本地代码。在 MSE WebSocket 方法中，JavaScript 用于推断正确传输流所需的信息。由于 JavaScript 的效率较低，这导致处理速度变慢，延迟增加，更何况 WebSocket 也是基于 TCP 的。

最近，另一种获得广泛关注的低延迟视频流方法是使用 Google 基于 UDP 的协议 QUIC 来传输视频。不过，目前利用 QUIC 进行视频流的版本还涉及使用 JavaScript API 来解码视频，从而增加了额外的开销，因此也增加了解决方案的延迟。这些 API（特别是 WebTransport 和 WebCodec）并不是所有浏览器都支持的，iOS 上的 Safari 就是一个主要的例外。尽管如此，我们认为 QUIC 在单向直播流方面还是有优势的。

基于 Web 标准

从技术角度看，WebRTC 作为流媒体编解码器保持超低延迟的能力并不直接归功于 WebRTC，但它最大的优势之一在于其作为 Web 标准的基础。作为万维网联盟（W3C）和互联网工程任务组（IETF）标准化和维护的协议，WebRTC 提供了对开发人员和企业都至关重要的可靠性、互操作性和持续改进。

作为一种实时流媒体网络标准，WebRTC 具有普遍的兼容性、持续的改进、强大的安全性和对开发人员友好的环境，使其在提供超低延迟流媒体方面具有得天独厚的优势。它的设计和不断改进都是为了最大限度地减少延迟，确保同步通信，并提供尽可能接近实时的交互式用户体验。

WebRTC 作为 Web 标准的地位不仅仅是可靠性的象征，它的核心功能是提供当今实时通信应用所需的超低延迟流体验。无论是用于实时拍卖、互动教育还是体育直播，WebRTC 的标准化都是其卓越性能和广泛应用的关键因素。

何去何从？

总之，WebRTC 是超低延迟直播流的首选，它提供的实时通信体验是 HLS 和 DASH 等传统视频流协议无法比拟的。这篇文章阐明了 WebRTC 技术的复杂性，从依靠 UDP 而不是 TCP 来提高速度和减少延迟，到使用 RTP 来实现高效的视频和音频数据传输。该协议的推送方法进一步简化了流式传输过程，消除了与 HLS 和 MPEG-DASH 拉动方法相关的开销。

WebRTC 日益强大。最近，WHIP 和 WHEP 等新网络标准为信令创建了单一的标准化方法。尤其是 WHIP，它现在开放了新的硬件编码器，如 Osprey 的 Talon 4k，这些编码器以前依赖于其他协议进行摄取。基于软件的 WHIP 客户端实现（如 OBS）正在快速推出，整个 WebRTC 实时流媒体生态系统正在快速发展。