从WebRtc学习RTP协议

1、TCP为何不适用于实时音视频

可靠性是以牺牲实时性为代价的。按照TCP原理，当出现极端网络情况时，理论上每个包的时延可达到秒级以上，而且这种时延是不断叠加的。这对于音视频实时通信来说是不可接受的。

TCP为了实现数据传输的可靠性，采用的是“发送→确认→丢包→重传”这样一套机制。而且为了增加网络的吞吐量，还采用了延迟确认和Nagle算法(将多个小包组成一个大包发送，组合包的大小不超过网络最大传输单元)

为了增加网络的吞吐量，接收端不必每收到一个包就确认一次，而是对一段时间内收到的所有数据集体确认一次即可。为了实现该功能，TCP通常会在接收端启动一个定时器。定时器的时间间隔一般设置为200ms，即每隔200ms确认一次接收到的数据。这就是延迟确认机制。‘

除此之外，TCP在发送端也启动了一个定时器，不过该定时器的功能不是发送确认消息，而是用来判别是否有丢包的情况。发送端定时器的时长为一个RTO(RTO（Retransmission Timeout），重传超时时长。其值约等于RTT的平均值，每次超时后以指数级增长。RTT表示一个数据包从发送端到接收端，然后再回到发送端所用的时长)如果在定时器超时后仍然没有收到包的确认消息，则认为包丢失了，需要发送端重发丢失的包。这就是TCP的丢包重传机制。

假如接收端发送的确认消息丢失了，按TCP的协议规则，通信双方会怎么做呢？首先，发送端只有等到定时器超时后，才能发现该包丢失了。确认丢包后，发送端会将前面所有未确认的包重发一遍。如果在收到数据后，接收端发送的确认消息又丢失了，那么发送端还要等到定时器超时后才能知道包丢失了。因此，在遇到这种极端网络的情况下，TCP传输的时延要累加很多，这种时延是不可控的。

2、UDP->RTP

UDP没有这套逻辑，所以实时性最高。WebRTC通过NACK、FEC、Jitter Bufer以及NetEQ技术既可以解决丢包和抖动问题，又不会产生影响服务质量的时延。

UDP传输一些有前后逻辑关系的数据时有缺陷，所以在UDP之上的应用层上使用RTP传输音视频数据

3、RTP协议结构

保持有序:Sequence Number

我们希望在使用RTP传输音视频数据时，一旦有数据丢失，可以快速定位是哪个数据包丢失了。

如果给每个发送的数据包都打上一个编号，并且编号是连续的，那么，接收端就可以很容易地判断出哪些包丢失了。在RTP头中，有一个专门记录该编号的字段，称作Sequence Number。在发送端，每产生一个RTP包，其Sequence Number字段中的值就被自动加1，以保证每个包的编号唯一且连续。当接收端收到RTP包时，会对Sequence Number字段进行检查，如果发现Sequence Number不连续了，就说明有包丢失或乱序了。

区分不