首先，需要说明下，webrtc的核心音视频传输是通过RTP/RTCP协议实现的，源码位于src/modules/rtp_rtcp目录下：
下面让我们对相关的内容基础进行简要分析与说明：
一、TCP与UDP协议
1.1、TCP协议
TCP为了实现数据传输的可靠性，采用的是"发送→确认→丢包→重传"这样一套机制。而且为了增加网络的吞吐量，还采用了延迟确认和Nagle算法（Nagle算法，将多个小包组成一个大包发送，组合包的大小不超过网络最大传输单元）。这套机制就是TCP产生延迟的根本原因。
为了增加网络的吞吐量，接收端不必每收到一个包就确认一次，而是对一段时间内收到的所有数据集体确认一次即可。为了实现该功能，TCP通常会在接收端启动一个定时器。定时器的时间间隔一般设置为200ms，即每隔200ms确认一次接收到的数据。这就是延迟确认机制。除此之外，TCP在发送端也启动了一个定时器，不过该定时器的功能不是发送确认消息，而是用来判别是否有丢包的情况。发送端定时器的时长为一个RTO（Retransmission Timeout，重传超时时长。其值约等于RTT的平均值，每次超时后以指数级增长。RTT表示一个数据包从发送端到接收端，然后再回到发送端所用的时长）。如果在定时器超时后仍然没有收到包的确认消息，则认为包丢失了，需要发送端重发丢失的包。这就是TCP的丢包重传机制。
1.2、UDP协议
UDP属于不可靠传输协议。在传输数据时，它不保证数据能可靠到达，也不保证数据有序，但它最大的优点就是传输速度"快"。由于UDP没有TCP那一套保证数据可靠、有序的控制逻辑，所以它不会被"人为"地变慢，因此它的实时性是最高的。
争对UDP丢包和抖动的问题，WebRTC给出了一套比较完美的解决方案，通过NACK、FEC、Jitter Bufer以及NetEQ技术既可以解决丢包和抖动问题，又不会产生影响服务质量的时延。通过上面的分析可以知道，由于TCP在极端网络情况下无法控制传输的时延大小，所以在做实时通信传输时，应该首选UDP。
二、RTP/RTCP协议
2.1、RTP协议
2.1.1、RTP协议概述
RTP---实时传输协议，它是基于UDP协议进行传输的，其在多点传送（多播）或单点传送（单播）的网络上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不保证QoS（服务质量）。
RTP的数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传输（多播）网络，并提供最小限度的控制和鉴别功能。RTP 和 RTCP 被设计成和下面的传输层和网络层无关。
总结：
RTP 只是简单数据的封装，基于UDP。没有任何的QoS 的支持。
RTCP 是对RTP 的扩展，也就是为解决了RTP 只是数据传输，没有管理的问题。
2.1.2、 RTP协议格式概述
RFC3550_RTP协议中文版
rfc3550
RTP协议报文
RTP报文主要由两部分组成，head和payload，head最小12个字节，可扩展。
版本( V )：2 比特 此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用，值 0 用在最初"vat"语音工具使用的协议中。)
填充( P )：1 比特 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比 特不算作负载的一部分。 填充的最后一个字节指明可以忽略多少个填充比特。 填充可能用于某些 具有固定长度的加密算法，或者用于在底层数据单元中传输多个 RTP 包。
扩展(X)：1 比特 若设置扩展比特，固定头(仅)后面跟随一个头扩展。
CSRC 计数(CC)：4 比特 CSRC 计数包含了跟在固定头后面 CSRC 识别符的数目。
标志(M)：1 比特 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如 帧边界。
负载类型(PT)：7 比特 此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载 类型码和负载格式之间一个默认的匹配。 其他的负载类型码可以通过非 RTP 方法动态定义。 RTP 发送端在任意给定时间发出一个单独的 RTP 负载类型；此域不用来复用不同的媒体流。
序列号（sequence number）：16 比特 每发送一个 RTP 数据包，序列号加 1，接收端可 以据此检测丢包和重建包序列。 序列号的初始值是随机的(不可预测)，以使即便在源本身不加密 时(有时包要通过翻译器，它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。
时间戳（timestamp）： 32 比特时间戳反映了 RTP 数据包中第一个字节的采样时间。时 钟频率依赖于负载数据格式，并在描述文件（profile）中进行描述。也可以通过 RTP 方法对负 载格式动态描述。时间戳可用来实现不同媒体流的同步
×××C：32 比特 用以识别同步源。标识符被随机生成，以使在同一个 RTP 会话期中没有 任何两个同步源有相同的 ×××C 识别符。尽管多个源选择同一个 ×××C 识别符的概率很低，所 有 RTP 实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址，必须选择新的 ×××C 识别符，以避免被当作一个环路源。
小结：
其实rtp 没有什么，只是在udp 发送数据的基础上，增加head 封装数据。来标识数据的类型和属性
序列号 ， 未来解决丢包和乱序问题
负载类型，音视频类型
时间戳，做音视频同步用的
唯一标识， 由于是udp 端口可以接收多个源数据，要区分开哪一个发送源发送的数据
RTP包主要由两部分组成，head和payload，head最小12个字节，可扩展。
2.2、RTCP协议
由于rtp 太过于简单，只是在UDP 做了一些简单的封装，很多的功能无法支持，例如：重传等机制。那如何扩展呢，就是我们接下来要讲的rtcp 协议
RTCP功能
在使用 RTP 包传输数据时，难免会发生丢包、乱序、抖动等问题，下面我们来看一下使用的网络一般都会在什么情况下出现问题：
网络线路质量问题引起丢包率高；
传输的数据超过了带宽的负载引起的丢包问题；
信号干扰（信号弱）引起的丢包问题；
跨运营商引入的丢包问题 ;
RTCP 的作用，收集当前网络质量状态；
1、服务质量的监视与反馈
在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包。每个RTCP信息包不封装音频数据或者视频数据，而是封装发送端或接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息反映了当前的网络状况，对发送端、接收端或者网络管理员都非常有用。
2、确定 RTP用户源
RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonical Name)标志符 CNAME，接收者使用它来追踪一个RTP进程的参加者。当发现冲突或程序重新启动时，RTP中的同步源标识符SSRC可能发生改变，接收者可利用CNAME来跟踪参加者。同时，接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。当 RTP需要进行音视频同步的时候，接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。
3、控制 RTCP传输间隔
由于每个对话成员定期发送RTCP信息包，随着参加者不断增加，RTCP信息包频繁发送将占用过多的网络资源，为了防止拥塞，必须限制RTCP信息包的流量，控制信息所占带宽一般不超过可用带宽的 5%，因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包，因此终端的总数很容易估计出来，应用程序根据参加者总数就可以调整RTCP包的发送速率。
4、传输最小进程控制信息
这项功能对于参加者可以任意进入和离开的松散会话进程十分有用，参加者可以自由进入或离开，没有成员控制或参数协调。
RTCP 报文的种类
根据所携带的控制信息不同，RTCP信息包可分为五类
官方文档参考：RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
SR（Sender Report 源报告报文）
发送端报告，向接收端发送，包含发送端的统计信息，如发送的数据包数量、字节数、丢包数量等。
RR（Receiver Report 接收者报告报文）
接收端可以使用RTCP的RR报文向发送端发送接收报告，报告中记录着从上一次报告到本次报告之间丢失了多少包、丢包率是多少、延时是多少等一系列信息。
SEDS（Source Description 源描述报文）
源描述报文，包含有关参与会话的参与者的信息，如CNAME（参与者的标识符）、名称、电话号码等。
BYE（离开申明报文）
结束会话报文，用于说明哪些（音视频）媒体源现在不可用了。当WebRTC收到该报文后，应该将SSRC所对应的通道删除。
APP（特殊应用包报文）
给应用预留的RTCP报文，应用可以根据自己的需要自定义一些应用层可以解析的报文。
RTPFB（反馈报文）
RTP的反馈报文，是指RTP传输层面的报文。该报文可以装入不同类型的子报文。该报文中可以包含多个子报文，其中WebRTC使用到的报文只有4项。
NACK，接收端用于通知发送方在上次包发送周期内有哪些包丢失了。在NACK报文中包含两个字段：PID和BLP。PID（Package ID）字段用于标识从哪个包开始统计丢包；而BLP（16位）字段表示从PID包开始，接下来的16个RTP包的丢失情况。
TMMBR和TMMBN是一对报文，TMMBR表示临时最大码流请求报文，TMMBN是对临时最大码流请求的应答报文。这两个报文虽然在WebRTC中实现了，但已被WebRTC废弃，其功能由TFB和REMB报文所代替。
TFB是WebRTC中TCC算法的反馈报文，该报文会记录包的延迟情况，然后交由发送端的TCC算法计算下行带宽。
PSFB（负载相关的反馈报文）
RTP中与负载相关的反馈报文。同样，该报文也可以装入不同类型的子报文。
PLI报文与FIR报文很类似，当发送端收到这两个报文时，都会触发生成关键帧（IDR帧），但两者还是有一些区别的。PLI报文是在接收端解码器无法解码时发送的报文。FIR报文主要应用于多方通信时后加入房间的参与者向已加入房间的共享者申请关键帧。通过这种方式，可以保障后加入房间的参与者不会因收到的第一帧不是关键帧而引起花屏或黑屏的问题。
REMB报文是WebRTC增加的反馈报文，用于将接收端评估出的带宽值发给发送端。不过，由于最新的WebRTC已全面启用基于发送端的带宽估算方法，即TCC，因此目前REMB仅用于向后兼容，不再做进一步更新。
为了对网络更加准确完善的描述，在出现了205、206 也是目前webrtc 在使用的的内容。
RTCP 有两个最重要的报文：RR 和 SR 。通过这两个报文的交换，各端就知道自己的网络质量到底如何了。
总结
三、总结
RTP是一个非常轻量的传输协议，特别适合传输音视频数据，或者说它就是专门为传输音视频数据而开发的。RTP控制协议RTCP对于传输服务质量起着关键的作用，WebRTC的服务质量系统中的大量控制参数都是通过RTCP获取的。