在处理前言阴影视频网络通信的过程中，我们经常遇到以下几个问题，今天围绕以下几个问题谈谈我的个人优化心得：
为什么TCP传输延迟大于UDP？ 直播延迟容易达到1s以上，最根本的原因是哪里？ RTC实时通信的延迟要求在400ms以内，怎么做？ 以举个栗子网上购物、快递从发货到送货的时间优化为例。
快递入住和停留时间太长了吗？ ——例如，每件快递入库半天，堆积一天后再发货。 哪些因素可能影响快递从商家a到达消费者b的时间？ 如上图所示：
快递数量不均，有的时候很多(如山)的时候很少(零散)，各个节点的资源利用率不能充分发挥，中途发生了快递丢失。 需要重新发行((总体时间基本上是两倍) ) ) ) )运输路线太拥堵，道路上时间太短
是否要提高各快递站的吞吐量，减少各中转站的缓存，加快快递流程？ 快递的寄送、寄送、寄送，从“天”的粒度，分为时间的粒度等更细的粒度，追求资源的安排更加动态顺畅吗？ 每个快件同时发两份吗？ 丢一个也可以再送一个吗？ ——当然负面影响是带来运力资源增长，动态选择合适的中转运输通道，哪里没有堵塞？ ——运输线路动态规划避免拥堵。 这是艺术。从上面的探索可以看出，优化延时，我们关注的点主要是：减少中间环节的缓存，最大化提高资源的利用率，通过冗余对抗丢失，动态地规划传输路径。如果你能理解这几个抽象的点，那么恭喜，下面你就不难理解如何降低音视频的网络传输延时了。
3358 www.Sina.com/http://www.Sina.com/TCP保证了“可靠的传输”，因此在发生数据丢失后，一定会进行重传，造成重传延迟(类似快递丢失、重新发行)
由于TCP具有“缓存队列”(类似于快递站)，因此数据到达后不再立即发送，而是缓存一次，通过“滑动窗口”控制发送频率，上一次数据发送结束后通过ACK进行确认另一方面，UDP没有这个机制，闭着眼睛分发。 因为TCP是“君子”，如果丢失了数据，发现网络不好，就自己“逃”，减少自己的“扫码窗口”的大小。 “把快递员让给地区其他公司”自己的数据发送晚了http://www。 Sina.com/现场中继基础的传输协议(RTMP )默认使用TCP，引入了TCP的上述延迟较大的特性。 由于TCP不丢失数据的特性，无论播放方因网络原因卡住多少秒，如果播放器不追赶帧，那么，之后重新开始播放会有多少秒的延迟？ 由于这些网络堵塞而未立即发送的数据不会轻易消失，因此为了实现播放秒开启，通常实时的流式服务器会缓存最近的GOP，导致播放器不逐帧而产生一定的延迟。 （
如果播放端使用的HLS延迟较大，则需要知道服务端HLS片的最小间隔(官方推荐10s ) 3358www.Sina.com/的以下关键字。分析原因
为什么 TCP 传输的延时比 UDP 大 ？
直播的延时往往在 1s 以上，根本原因在哪里 ？
音视频传输首先“授权”部分不重要的数据，以满足低延迟。 对丢失的数据，在接收侧和再现侧进行PLC (语音分组丢失的智能补偿)、跳过GOP尾部的B/P帧的视频等兼容处理
FEC冗馀(类似于快递，但更高级)可以在UDP上“恢复”接收方丢失的数据，而无需传输。 有关详细信息，请参阅本文。 详细科普： 《谈谈网络通信中的 FEC 基础》
当然，在UDP上，也有时依然使用重发进行驱动。 由于FEC冗馀增加了对带宽的资源消耗，因此在RTT网络延迟较小时，重传仍然是一个很好的选择。 关于重发的详细情况请参考我的这篇文章： 《认识网络通信中的 ACK、NACK 和 REX》
RTC 实时通信的延时要求在 400ms 以内，是怎么做到的 ？
当然。 因此，可以在UDP之上添加控制流量的机制，整体上更顺利地发送。 详情请参考我的这篇文章： 《认识网络通信中的流量整形》
但是，发送的数据量(快递一样的数量)自身爆炸的情况下)，比现在的网络能够搭载的能力高)，无论在传输侧如何平滑
，都解决不了拥堵的问题的，因此，RTC 最最核心的降低延时的方法之一就是：带宽探测及配套的数据量调节手段有哪些带宽探测及配套的数据量调节手段 ？
带宽探测，就是动态地预估当前的网络带宽，如何做到实时地对带宽进行准确地预测，是一门值得深挖和长期研究的艺术，本文就不展开讲了，可以搜索了解 BBR、GCC 等关键词
数据量调节：当探测到网络带宽不足时，可以调节数据量以防止拥塞带来的延时，通常可调节的内容包括：音视频的帧率/码率、FEC 的冗余比例、大小流等
那既然 UDP 也有重传，自然也会存在网络抖动的情况下，接收和播放端被动产生被动的 buffer 数据，RTC 是如何消除掉这些被动 buffer 的呢 ？
核心原理：动态 jitter buffer + TSM 时域压扩（变速不变调）算法
接收端的 buffer，往往是用来抵抗网络抖动的，固定的 buffer 则带来的是固定的延时（如：必须缓冲到 500ms 的数据再输出播放），而动态的 jitter buffer 则会根据网络好坏动态调节 buffer 大小
TSM 时域压扩（变速不变调）：则是一种不影响用户听感体验的音频播放追帧策略，类似可以做到 0.9/1.1 倍数播放，用于加快或者减慢 buffer 数据的消耗达到追帧或者降速的作用，算法科普文章可参考： 《TSM时域压扩(变速不变调)算法总结》
有了一系列客户端层面的延时优化，最后就剩下整体服务端流转发网络的调度和级联了，这也是一门值得深挖和长期研究的方向，这里也不长篇大论了，用一张图大致表达一下：