什么是RTP和RTCP？它们如何在WebRTC中实现实时通信

近年来，通过 Internet 进行实时通信变得越来越流行，而 WebRTC 已成为通过 Web 实现实时通信的领先技术之一。WebRTC 使用多种协议，包括实时传输协议 (RTP) 和实时控制协议 (RTCP)。

RTP 负责通过网络传输音频和视频数据，而 RTCP 负责监视网络状况并向发送方提供反馈。RTP和RTCP在同一个网络上通信，RTP使用偶数端口，RTCP使用奇数端口。这允许两种协议使用相同的网络资源而不会相互干扰。

在本文中，我们将讨论什么是 RTP 和 RTCP，以及它们如何协同工作以在 WebRTC 中实现实时通信。

实时传输协议 (RTP)

实时传输协议 (RTP) 是一种旨在通过 Internet 传输音频和视频数据的协议。RTP 用于实时传输媒体流，例如语音和视频。

RTP 负责将媒体数据打包成小数据包并通过网络传输。每个 RTP 数据包都包含一个序列号和时间戳，用于确保数据包以正确的顺序和正确的时间交付。RTP 数据包通过 UDP 传输，延迟低，非常适合实时通信。

实时控制协议 (RTCP)

实时控制协议 (RTCP) 是一种旨在提供 RTP 流量服务质量 (QoS) 反馈的协议。RTCP 用于监控网络状况，例如数据包丢失和延迟，并向发送方提供反馈。定期发送 RTCP 数据包以提供有关 RTP 流质量的反馈。它们包含有关 RTP 流的统计信息，包括发送和接收的数据包数、丢失的数据包数以及数据包之间的延迟。此信息可用于调整 RTP 流以提高音频或视频的质量。

了解视频压缩

我们不会深入研究视频压缩，但我们将涵盖足够多的内容来理解为什么 RTP 是这样设计的。视频压缩将视频编码成一种新格式，这种格式需要更少的比特来表示相同的视频。

有损和无损压缩

视频可以编码为无损（没有信息丢失）或有损（信息可能丢失）。RTP 通常使用有损压缩来防止高延迟流和更多丢包，即使视频质量不太好。

帧内和帧间压缩

视频压缩有两种类型：帧内和帧间。帧内压缩减少了用于描述单个视频帧的比特。同样的技术也用于压缩静态图片，例如 JPEG 压缩方法。另一方面，帧间压缩寻找不发送相同信息两次的方法，因为视频由许多图片组成。

帧间类型

帧间压缩分为三种帧类型：

• I-帧 – 一张完整的图片，无需任何其他内容即可解码。
• P 帧– 仅包含与前一张图片相比发生变化的部分图片。
• B 帧– 部分图片，是对先前和未来图片的修改。

以下是三种帧类型的可视化。

很明显，视频压缩是一个有状态的过程，在通过互联网传输时会带来挑战。这让我们想知道，如果 I-Frame 的一部分丢失了会发生什么？P-Frame 如何确定要修改的内容？随着视频压缩方法变得越来越复杂，这些问题变得更加紧迫。尽管如此，RTP 和 RTCP 提供了一种解决方案。

RTP包结构

每个 RTP 数据包都具有以下结构，如RFC中所定义

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            Contributing Source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTCP包结构

每个 RTCP 数据包具有以下结构：

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |       PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

数据包类型 (PT)

这是 RTCP 数据包类型的唯一标识符。虽然 WebRTC 代理不一定需要支持所有这些类型，但代理之间的支持可能存在差异。一些常见的数据包类型包括：

• 192– 完整帧内请求 ( FIR)
• 193– 否定确认 ( NACK)
• 200– 发件人报告
• 201– 接收报告
• 205– 通用 RTP 反馈
• 206– 有效载荷特定反馈（包括PLI）

RTCP 数据包类型详解

RTCP 是一种灵活的协议，支持多种类型的数据包。下面详细介绍了一些最常用的数据包类型。

PLI（图片丢失指示）/FIR（完整帧内请求）

和消息服务于类似的目的，从发送者请求完整FIR的PLI关键帧。但是，PLI当解码器无法解码部分帧时专门使用，这可能是由于数据包丢失或解码器崩溃。

根据 RFC 5104，FIR当数据包或帧丢失时不应使用；那是的工作PLI。FIR用于出于其他原因请求关键帧，例如当新成员进入视频会议时需要完整的关键帧来开始解码视频流。解码器将丢弃帧，直到关键帧到达。

然而，在实践中，处理这两种情况的软件PLI都会FIR向编码器发送信号以在这两种情况下生成新的完整关键帧。

通常，接收器会在连接后立即请求完整的关键帧，以最大程度地缩短第一帧出现在用户屏幕上的时间。

PLI数据包是有效载荷特定反馈消息的一部分。

NACK（否定确认）

当接收方发出 时NACK，它请求发送方重新传输单个 RTP 数据包。这通常在数据包丢失或延迟时完成。这NACK比请求重新发送整个帧更可取，因为 RTP 将数据包分成小块，而接收方通常只丢失一小块。为了请求丢失的部分，接收方创建一个带有 SSRC 和序列号的 RTCP 消息。如果发送方没有请求的 RTP 数据包重新发送，它将简单地忽略该消息。

发件人和收件人报告

这些报告对于在代理之间传输统计信息至关重要。它们有效地传达了接收到的数据包的确切数量以及抖动级别。

此功能提供有价值的诊断信息并实现有效的拥塞控制。我们将在下面详细了解如何使用这些报告来克服不可靠的网络条件。

克服不可靠的网络

实时通信在很大程度上依赖于网络。在理想情况下，带宽是无限的，数据包会立即到达。不幸的是，网络是有限的，条件可能会发生意外变化，因此很难衡量和观察网络性能。此外，不同的硬件、软件和配置可能会导致不可预测的行为。

RTP/RTCP 运行在许多不同类型的网络上，因此在发送方和接收方之间丢失某些通信是很常见的。因为它建立在 UDP 之上，所以没有重传数据包或处理拥塞控制的内置方法。

测量和通信网络状态

RTP/RTCP 在各种网络类型和拓扑上运行，因此从发送方到接收方可能会发生通信中断。由于它们建立在 UDP 之上，因此没有用于数据包重传或拥塞控制的固有机制。

为了获得最佳用户体验，我们必须评估网络路径质量并适应它们随时间的变化。要监控的关键特征是可用带宽（在每个方向上，可能不对称）、往返时间和抖动（往返时间的变化）。我们的系统必须考虑数据包丢失，并随着网络条件的变化传达这些属性的变化。

这些协议有两个主要目标：

1. 估计网络支持的可用带宽（每个方向）。
2. 在发送方和接收方之间传达网络特征。

收件人报告/发件人报告

接收方报告和发送方报告通过 RTCP 发送，并在RFC 3550中定义。它们在端点之间传达网络状态。接收器报告传达网络质量，包括数据包丢失、往返时间和抖动。这些报告与根据网络质量估计可用带宽的其他算法配对。

发送方和接收方报告（SR 和 RR）共同描述了网络质量。它们按每个 SSRC 的时间表发送，并用于估计可用带宽。发送方收到RR数据后估计可用带宽，RR数据包含以下字段：

• Fraction Lost – 自上次 Receiver Report 以来丢失的数据包百分比。
• Cumulative Number of Packets Lost – 整个呼叫期间丢失的数据包数。
• 接收到的扩展最高序列号– 接收到的最后一个序列号及其翻转次数。
• 到达间隔抖动– 整个呼叫的滚动抖动。
• 最后发件人报告时间戳– 发件人的最后已知时间，用于计算往返时间。

这些统计数据被进一步输入带宽估计算法，例如 GCC（谷歌拥塞控制），该算法估计可用带宽，进而驱动编码比特率和帧分辨率。

结论

总之，RTP 和 RTCP 是在 WebRTC 中实现实时通信的基本协议。RTP 负责通过网络传输音频和视频数据，而 RTCP 负责监视网络状况并向发送方提供反馈。这些协议共同实现了 Internet 上的高质量实时通信。了解 RTP 和 RTCP 如何协同工作对于任何有兴趣使用 WebRTC 开发实时通信应用程序的人来说都是必不可少的。

参考

• RFC3550（RTP：实时应用程序的传输协议）
• RFC5104（带反馈的 RTP 视听配置文件中的编解码器控制消息）
• RFC8888（拥塞控制的 RTP 控制协议 (RTCP) 反馈）