介绍
近年来，通过互联网进行实时通信变得越来越流行，而 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的数量。CSRCSSRC
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 如何协同工作至关重要。
参考
关于转载
转载此文请注明出处，“引用于新睿云.弘电脑”，否则请回避。