1.UDP丢包怎么控制？
- TCP是可靠的连接，它的可靠就是因为接收方在收到数据后会给发送方返回一个ACK，表示已经收到了，确保消息的可靠。
- NACK与ACK正好相反，表示我没有收到消息，那么问题来了，接受者怎么知道自己未收到消息？音视频数据包都是按时间顺序发送的，一般都带序号（升序排列的时间戳）。例如发送方按顺序发送了时间戳为60,120,180,240，320共五个包，接收者已经收到了60包，本来预期下一个接收的包的序号应该是序号120的包，但序号是120的包一直没收到，后面的包却收到了。那么接收者就可以判断，120这个包丢了，这时候接收方需要向发送方发出NACK消息（消息中带有丢包的序号，这里是120），让发送方重新发送丢失的包。
- 在RTC中，FEC（前向纠错）和NACK（丢包重传）是抵抗网络错误的重要手段，FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端发送缓冲区的支持。
2.Jitter Buffer
Jitter Buffer也叫做抖动缓冲区，它是实时音视频里面的一个重要模块，它对数据包丢失、乱序、延迟到达等情况进行处理，平滑的向解码模块输出数据包/帧，抵抗各种弱网情况对播放/渲染造成的影响，降低卡顿，提高用户的观看体验。
2.1 产生抖动的原因
- 网络传输路径改变。例如，当前的传输路径是A，但是下一刻路径A上的某个路由器出现了故障，这时候数据包的路径就会发生改变，导致端到端的传输时长发生变化。
- 网络自身的抖动。很多情况下网络有噪声，产生抖动是很正常的。
- 网络发生拥塞。拥塞发生的时候，数据包会在路由器上排队，导致端到端延迟变大。
- 抗丢包手段带来的额外抖动。网络出现丢包的时候，我们一般会使用nack/arq去重传数据，重传会带来额外的延迟。
2.2 Jitter Buffer原理
Jitter buffer的核心思想是用时间换空间，以增大端到端的延迟为代价来换取视频通话的流畅性。当网络不稳定时（抖动发生），增加buffer的长度，多缓存一些数据，以应对将来可能发生的抖动；当网络稳定下来时，减小buffer的长度，少缓存一些数据，降低视频端到端的延迟，提高实时性。因此jitter buffer的运行过程是一个根据抖动来动态调整buffer长度的过程。好的jitter buffer能够在保证尽量不卡的前提下降低端到端的延迟，即它能够在延迟和卡顿率之间取得较好的平衡。
- 接收侧收到数据包，开始组帧，这一步是必须的，帧不完整会导致花屏。
- 每个帧组好之后，放进buffer里，然后按照帧序号进行排序。
- 检查帧的参考关系。对于解码器来说，如果一个帧的参考帧丢失了，那么这个帧将解码失败或者花屏，所以参考关系必须要满足之后才能把数据送进解码器里。
- 根据每一帧的时间戳（采集时间戳或者发送时间戳）以及接收时间戳计算抖动。这里的难点在于如何精确计算抖动。
- 根据抖动计算buffer的长度。
- 根据抖动自适应的调整buffer长度。抖动越大，预留的buffer长度越大，这样可以利用增加延迟的方式来降低卡顿；抖动越小，预留的buffer长度越小，这样可以降低延迟。
2.3 计算抖动的方式
数据包传输时长的变化就是抖动，假设相邻的两个数据包packet1和packet2，它们发送时间戳是send_timestamp1和send_ timestamp2，接收时间戳是recv_ timestamp1和recv_ timestamp2，那么它们之间的抖动可以按照下面的方法计算：
3.RTC拥塞控制
3.1 GCC
Google congestion control， 是通过预测可用带宽来控制发送的速率，会结合发送端和接收端两端各自估测的带宽来综合计算，其中发送端的带宽估测主要依赖于丢包率(其实也有延迟)，接收端的带宽估测依赖于延迟(的变化)。GCC主要是依靠丢包、延迟、抖动等网络参数来预估当前的可用带宽进而控制发送的速率从而避免网络拥塞引起的丢包、延迟、抖动等现象。
3.2 BBR
BBR Congestion Control，传统的拥塞控制算法是计算cwnd值来规定当前可以发送多少数据，但是并不关注以什么样的速度发送数据。如果简单而粗暴地将窗口大小（send.cwnd、recv.cwnd的最小值）数据全部突发出去，这往往会造成路由器的排队，在深队列的情况下，会测量出rtt剧烈地抖动。bbr在计算cwnd的同时，还计算了一个与之适配的pacing rate，该pacing rate规定cwnd指示的一窗数据的数据包之间，以多大的时间间隔发送出去。
