介绍
近年来，通过互联网进行实时通信变得越来越流行，而 WebRTC 已成为通过网络实现实时通信的领先技术之一。WebRTC 使用多种协议，包括实时传输协议 (RTP) 和实时控制协议 (RTCP)。
RTP负责通过网络传输音频和视频数据，而RTCP负责监控网络状况并向发送方提供反馈。RTP和RTCP在同一网络上通信，RTP使用偶数端口，RTCP使用奇数端口。这允许两种协议使用相同的网络资源而不会互相干扰。在这篇文章中，我们将讨论 RTP 和 RTCP 是什么以及它们如何协同工作以在 WebRTC 中实现实时通信。
实时传输协议 (RTP)
实时传输协议（RTP）是一种设计用于通过互联网传输音频和视频数据的协议。RTP 用于实时传输媒体流，例如语音和视频。
RTP 负责将媒体数据打包成小数据包并通过网络传输。每个RTP数据包都包含一个序列号 和时间戳，用于确保数据包以正确的顺序和在正确的时间传送。RTP 数据包通过 UDP 传输，延迟低，非常适合实时通信。
实时控制协议 (RTCP)
实时控制协议 (RTCP) 是一种旨在提供 RTP 流量服务质量 (QoS) 反馈的协议。RTCP 用于监视网络状况，例如数据包丢失和延迟，并向发送方提供反馈。RTCP 数据包定期发送，以提供有关 RTP 流质量的反馈。它们包含有关 RTP 流的统计信息，包括发送和接收的数据包数量、丢失的数据包数量以及数据包之间的延迟。此信息可用于调整 RTP 流以提高音频或视频的质量。
了解视频压缩
我们不会深入研究视频压缩，但我们会足够了解为什么 RTP 是这样设计的。视频压缩将视频编码为一种新的格式，需要更少的比特来表示相同的视频。
有损和无损压缩
视频可以编码为无损（没有信息丢失）或有损（信息可能丢失）。RTP 通常使用有损压缩来防止高延迟流和更多丢包，即使视频质量不太好。
帧内和帧间压缩
视频压缩有两种类型：帧内压缩和帧间压缩。帧内压缩减少了用于描述单个视频帧的位数。相同的技术也用于压缩静态图片，例如 JPEG 压缩方法。另一方面，帧间压缩寻找不两次发送相同信息的方法，因为视频是由许多图片组成的。
帧间类型
帧间压缩共有三种帧类型：
- I 帧- 无需任何其他内容即可解码的完整图片。
- P 帧- 仅包含与前一张图片相比的变化的部分图片。
- B 帧- 部分图片，是对先前和未来图片的修改。
以下是三种帧类型的可视化。
显然，视频压缩是一个有状态的过程，在通过互联网传输时会带来挑战。这让我们想知道，如果 I 帧的一部分丢失会发生什么？P 帧如何确定要修改的内容？随着视频压缩方法变得更加复杂，这些问题变得更加紧迫。尽管如此，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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`Version (V)
Version始终设置为2。
Padding (P)
Padding是一个布尔值，用于确定有效负载是否有填充。
有效负载的最后一个字节指示添加的填充字节数。
Extension (X)
如果设置，RTP 标头将包含扩展。
CSRC Count (CC)
指的是有效负载之后和之前的标识符CSRC Count的数量。CSRC``SSRC
Marker
该Marker位没有预定含义，可以根据用户的需要使用。
在某些情况下，它可能指示用户何时说话，或者可能指示关键帧。
Payload Type (PT)
这Payload Type是该数据包携带的编解码器的唯一标识符。
对于 WebRTC，Payload Type是动态的，这意味着Payload Type一次调用中 VP8 的 可能与另一次调用中的 VP8 不同。Payload Types调用中的提供者确定到编解码器的映射Session Description。
Sequence Number
用于Sequence Number对流中的数据包进行排序。每发送一个数据包，Sequence Number就会加一，RTP 是被设计为在有损网络上有用，这为接收方提供了一种检测数据包何时丢失的方法。
Timestamp
Timestamp是该数据包的采样时刻。它不是一个全局时钟，而是代表媒体流中已经过去了多少时间。例如，如果多个 RTP 数据包都是同一视频帧的一部分，则它们可以具有相同的时间戳。
Synchronization Source（SSRC）
An SSRC是该流的唯一标识符。这允许多个媒体流在单个 RTP 流上运行。
Contributing Source (CSRC)
这是一个列表，用于传达哪些 SSRC 对此数据包做出了贡献。
这通常用于谈话指标。例如，如果多个音频源在服务器端组合成单个 RTP 流，则该字段可用于指示哪些输入流在给定时刻处于活动状态。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`Version (V)
Version始终是2。
Padding (P)
Padding是一个布尔值，用于控制有效负载中是否包含填充。
有效负载的最后一个字节包括添加的填充字节的计数。
Reception Report Count (RC)
这表示此数据包中包含的报告数量。单个 RTCP 数据包可能包含多个事件。
Packet Type (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（Negative Acknowledgement）
当接收方发出 时NACK，它会请求发送方重新传输单个 RTP 数据包。这通常是在数据包丢失或延迟时完成的。++NACK比请求重新发送整个帧更好，因为 RTP 将数据包分成小块，并且接收方通常只丢失一小块++。为了请求丢失的片段，接收器创建带有 SSRC 和序列号的 RTCP 消息。如果发送方没有重新发送所请求的 RTP 数据包，它将简单地忽略该消息。
发送者和接收者报告
这些报告对于在代理之间传输统计数据至关重要。它们有效地传达接收到的数据包的确切数量以及抖动级别。
此功能提供有价值的诊断信息并实现有效的拥塞控制。我们将在下面详细了解如何使用这些报告来克服不可靠的网络条件。
克服不可靠的网络
实时通信严重依赖网络。在理想的情况下，带宽将是无限的，并且数据包将立即到达。不幸的是，网络是有限的，并且条件可能会发生意外变化，因此很难测量和观察网络性能。此外，不同的硬件、软件和配置可能会导致不可预测的行为。
RTP/RTCP 运行在许多不同类型的网络上，因此发送方和接收方之间的某些通信丢失是很常见的。由于它建立在 UDP 之上，因此没有内置方法来重传数据包或处理拥塞控制。
测量和传达网络状态
RTP/RTCP 在各种网络类型和拓扑上运行，因此发送方到接收方可能会发生通信丢失。由于它们建立在 UDP 之上，因此没有数据包重传或拥塞控制的固有机制。
为了获得最佳的用户体验，我们必须评估网络路径质量并适应其随时间的变化。要监控的关键特征是可用带宽 （在每个方向上，可能不对称）、往返时间 和抖动（往返时间的变化）。我们的系统必须考虑数据包丢失，并随着网络条件的变化传达这些属性的变化。
该协议有两个主要目标：
- 估计网络支持的可用带宽（在每个方向）。
- 在发送方和接收方之间传达网络特征。
接收者报告/发送者报告
接收方报告和发送方报告通过 RTCP 发送，并在RFC 3550中定义。它们在端点之间传递网络状态。接收器报告传达网络质量，包括数据包丢失、往返时间和抖动。这些报告与根据网络质量估计可用带宽的其他算法配合使用。
发送方和接收方报告（SR 和 RR）共同描绘了网络质量。它们按每个 SSRC 的时间表发送，并用于估计可用带宽。发送方收到RR数据后估计可用带宽，其中包含以下字段：
- 丢失分数- 自上次接收器报告以来丢失的数据包百分比。
- 丢失数据包的累积数量- 整个呼叫期间丢失的数据包数量。
- 接收到的扩展最高序列号- 最后接收到的序列号以及已滚动的次数。
- 到达间隔抖动- 整个呼叫的滚动抖动。
- 最后发件人报告时间戳- 发件人的最后已知时间，用于计算往返时间。
这些统计数据进一步输入带宽估计算法，例如 GCC（Google 拥塞控制），该算法估计可用带宽，进而驱动编码比特率和帧分辨率。
结论
总之，RTP 和 RTCP 是 WebRTC 中实现实时通信的基本协议。RTP负责通过网络传输音频和视频数据，而RTCP负责监控网络状况并向发送方提供反馈。这些协议共同实现了互联网上的高质量实时通信。对于任何有兴趣使用 WebRTC 开发实时通信应用程序的人来说，了解 RTP 和 RTCP 如何协同工作至关重要。
参考
关于转载
转载此文请注明出处，"引用于新睿云.弘电脑"，否则请回避。