音视频网络通信中的延时优化

前言

在处理影视频网络通信的过程中，我们经常会遇到如下几个问题，今天就围绕如下几个问题讲讲我个人的优化心得.

1. 为什么 TCP 传输的延时比 UDP 大 ？
2. 直播的延时往往在 1s 以上，根本原因在哪里 ？
3. RTC 实时通信的延时要求在 400ms 以内，是怎么做到的 ？

举个栗子
我们就以网上购物，一份快递从发货到送达这一过程的耗时优化为例子：

在快递站入库和逗留的时间太长 ？—— 比如，每个快递件入库半天堆积 1 天再才转派发，看看，有哪些可能的因素会影响快递从商家 A 传递到消费者 B 的手中的时间 ？如上图所示：

1. 快递数量不均匀，有时候特别多（堆积如山），有时候特别少（零零散散），各节点的资源利用率未能充分发挥出来
2. 中途发生快递丢失了，需要重新补发一份（整体时间基本上要翻倍）
3. 运输的路线太堵，导致在路上耗费太多时间
4. 有什么思路，一一解决上述的延时因素，以提高快递的送达速度呢 ？

提高每个快递站的吞吐量，减少每个中转站的缓存，加速快递的流转 ？

1. 快件的揽件、传输与派送，从 “天” 的粒度拆分到更细的粒度，比如小时粒度，以追求资源的调度更动态和平滑一点 ？
2. 每个快件同时发 2 份 ？丢了一个还可以派送另一个 ？—— 当然，负面影响是带来运力资源的增加
3. 动态选择合适的中转运输路线，哪里不堵走哪里 ？—— 运输路线动态规划避开拥堵，这是一门艺术。

从上面的探索可以看出，优化延时，我们关注的点主要是：减少中间环节的缓存，最大化提高资源的利用率，通过冗余对抗丢失，动态地规划传输路径。如果你能理解这几个抽象的点，那么恭喜，下面你就不难理解如何降低音视频的网络传输延时了。

分析原因
为什么 TCP 传输的延时比 UDP 大 ？
因为 TCP 保证了 “可靠传输”，当数据发生丢失后，一定会进行重传，重传带来延时（类似快递丢失补发），并且非常影响后续数据的持续及时发送：

因为 TCP 有个 “缓存队列”（类似于快递站），它不会来一个数据就立马发送出去，而是先缓存起来，通过一个 “滑动窗口” 来控制发送频率（类似快递站的派送人力），在上一波数据发送完毕得到 ACK 确认后，再发送下一波数据（类似一箱快递的派送结束后再投入下一箱）；而 UDP 则没有该机制，闭着眼睛发（需要抢占整个地区更多的快递员）
因为 TCP 是一个 “君子”，一旦发现有丢数据或者网络不好，则主动去 “退让”，减少自己的 “滑动窗口” 大小（让出快递人力给地区其他公司），导致自己的数据发得更慢了
直播的延时往往在 1s 以上，根本原因在哪里 ？
直播底层的传输协议（RTMP）默认使用了 TCP ，引入了 TCP 上述延时大的特性
由于 TCP 不丢数据的特性，会导致播放端一旦因为网络原因卡住多少秒，在播放器不追帧的情况下，后续恢复播放后就有多少秒的延时（因为这些因为网络卡住没有及时发送过来的数据不会凭空消失）
为了实现播放秒开，通常直播的流媒体服务器，会缓存最近的 GOP，在播放器不追帧的情况下，会带来一个固定的延时（取决于推流端配置的 GOP 大小）

4.如果播放端使用的 HLS 延时，那就更大了，取决于服务端 HLS 切片的最小间隔（官方推荐 10s）

本文福利， 免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

RTC 实时通信的延时要求在 400ms 以内，是怎么做到的 ？

关于这一点，需要知道如下几个关键词：UDP、FEC、拥塞控制、数据量调节、jitter buffer、服务的端调度和级联

底层使用 UDP 代替 TCP —— 相比于 TCP 滑动窗口 “君子退让” 的特性，UDP 可以不讲武德，最大化地发送数据，提高吞吐量（提高带宽利用率）

底层使用 UDP 协议，如何解决丢包重传的问题呢 ？

音视频传输，为了满足低延时，首先是 “允许” 丢部分不重要的数据的，针对丢失的数据，在接收和播放端会做一些兼容性处理，如：PLC（音频包丢失的智能补偿）、视频跳过 GOP 尾部的 B/P 帧等

在 UDP 之上，使用 FEC 冗余（类似多发一份快递，但更高级），可以在不重传的情况下，在接收端把丢失的数据 “恢复” 回来。

当然，在 UDP 之上，依然也有使用重传来兜底的，因为 FEC 冗余会带来对带宽的资源消耗变大，因此在 RTT 网络延时较小的场合，重传依然是一个不错的选择。

底层使用 UDP 不讲武德地发送数据，不会让网络爆掉么 ？

当然会，因此，我们可以在 UDP 之上，加一些控制流量的机制，让整体地发送更加平滑，详细细节可以参考我的这篇文章： 《认识网络通信中的流量整形》

但是，如果要发送的数据量（类似快递的数量）本身就爆掉了（高于当前网络所能承载的能力），无论怎么在传输端加平滑，都解决不了拥堵的问题的，因此，RTC 最最核心的降低延时的方法之一就是：带宽探测及配套的数据量调节手段

有哪些带宽探测及配套的数据量调节手段 ？

带宽探测，就是动态地预估当前的网络带宽，如何做到实时地对带宽进行准确地预测，是一门值得深挖和长期研究的艺术，本文就不展开讲了，可以搜索了解 BBR、GCC 等关键词

数据量调节：当探测到网络带宽不足时，可以调节数据量以防止拥塞带来的延时，通常可调节的内容包括：音视频的帧率/码率、FEC 的冗余比例、大小流等

那既然 UDP 也有重传，自然也会存在网络抖动的情况下，接收和播放端被动产生被动的 buffer 数据，RTC 是如何消除掉这些被动 buffer 的呢 ？

接收端的 buffer，往往是用来抵抗网络抖动的，固定的 buffer 则带来的是固定的延时（如：必须缓冲到 500ms 的数据再输出播放），而动态的 jitter buffer 则会根据网络好坏动态调节 buffer 大小

TSM 时域压扩（变速不变调）：则是一种不影响用户听感体验的音频播放追帧策略，类似可以做到 0.9/1.1 倍数播放，用于加快或者减慢 buffer 数据的消耗达到追帧或者降速的作用

6.有了一系列客户端层面的延时优化，最后就剩下整体服务端流转发网络的调度和级联了，这也是一门值得深挖和长期研究的方向，这里也不长篇大论了，用一张图大致表达一下：