如何优化传输机制来实现直播源码的超低延迟？

要在直播源码SDK 中实现超低延迟，实时的语音视频传输机制是必不可少的，而 FEC 和 ARQ 的智能结合是实时直播源码系统传输机制的基石。

在语音社交、视频社交、游戏语音和互动直播等领域，关于在直播实时传输中实现低延迟这个议题，已经有不少的文章提出各种方案。绝大部分方案的思路都是“优化”，比如说，优化编码、推流、传输和播放等各个环节。

要在实时语音视频传输中获得超低延迟，是不能单靠挖空心思去“优化”的，而是要依靠实时的传输机制。就像高铁和火车有着本质的区别一样，火车不管如何优化，也只是跑得更快的火车，永远达不到高铁的速度。没有一套实时的传输机制，再怎么在各个环节“优化”，也无法获得真正超低的延迟。

要实现超低延迟，信道 QoS 十分关键。首先要选择合适的网络传输协议，采用基于 UDP 的私有协议还是标准 RTMP 协议？然后根据网络环境采用合适的 QoS 技术，采用 FEC，ARQ，还是双管齐下? 如果采用 FEC 和 ARQ 双管齐下，那么一套智能的 QoS 策略就必不可少。没有任何一种 QoS 技术能解决所有问题，实时语音视频传输机制必须是多种 QoS 技术的有机结合。

传输层协议的选择

如果是视频直播 SDK，一般会选择 RTMP 协议，因为要能够普遍兼容 CDN 分发网络，从而向围观的广大用户进行直播。如果是音频社交 SDK、视频社交 SDK 或者游戏语音 SDK，一般会选择 RTP/RTCP 协议（或者类 RTP 的私有协议），因为不需要通过 CDN 网络向围观用户广播媒体流。是否要考虑兼容 CDN 网络，是语音视频通话 SDK 和视频直播 SDK 的重大区别。

RTMP 协议是基于 TCP 协议的，RTP 协议或者私有协议是基于 UDP 协议的，因此 RTMP 协议和 RTP 协议之争，本质就是 TCP 协议和 UDP 协议之争。

TCP 协议的特点：

1) 是通用的 IP 网络协议，不是为实时媒体传输而设计的，在弱网网络环境下延迟会增大；

2) 有内嵌的 ARQ，但没有 FEC，不允许开发者对 ARQ 策略进行控制，不能实现 FEC；

3) 不是从实时语音视频的角度进行设计的，更多考虑网络传输的公平性，内嵌的传输控制策略比较温和。

UDP 协议的特点：

1) 适合实时直播通讯，允许端到端全链条进行信道策略控制，在弱网环境下可控性更强；

2) 延迟时间的大小取决于丢包时候的 ARQ 和 FEC 策略，允许开发者深度控制 ARQ 和 FEC 策略；

3) 适合设计直播的通讯机制，根据网络状况自适应地选取 ARQ 和 FEC 策略，以及调整传输码率和报文的数量。

在网络环境好的情况下，只要语音视频编解码器相同，RTMP 协议和基于 UDP 的私有协议的传输效率是相当的，都可以实现低延迟、不卡顿和高品质的实时通讯效果。

在网络环境较差的情况下，特别是在跨网甚至跨国的情况下，基于 UDP 的私有协议对端到端全链条可控，包括流控码控、ARQ、FEC 和抖动缓冲等，对抗恶劣网络环境会更有保障。

信道保护

IP 网络是“尽力而为”地提供数据传输服务的，尽最大的可能性来发送报文，但对时延、可靠性等性能概不负责效果，传输的数据出错是避免不了的，因此对信道进行保护是必须的。

信道 QoS 技术主要包括前向纠错 FEC，丢包重传 ARQ 和混合型 ARQ。这几种算法都是成熟的技术，在最基础的算法上又衍生出多个变种，而且在实现的过程中也可以进行定制化。

在 FEC 和 ARQ 的基础上，为了更好地适应弱网环境，需要让码率自动适应网络环境的波动，这样能够更好地保障实时直播的可用性和流畅性。

直播源码要获得超低延迟，不能仅仅依靠在各个环节不断地优化，而是要通过 FEC、ARQ 和码率自适应构建实时通讯机制。在这个基础上，还要充分考虑网络情况、实时要求和成本因素，以及需要大量经验数据的支撑（比如说，PLR 和 RTT 的关键阈值等）。