海量并发低延时 RTC-CDN 系统架构设计（下）

上半部分内容：海量并发低延时 RTC-CDN 系统架构设计（上）

低延时 RTC-CDN 系统的架构

传统 CDN 直播发展多年，为了优化延时，业界基本上朝两大优化方向：优化传输层协议和在传输层协议的基础上优化应用层协议。

RTMP 和 HTTP with FLV 以及 HLS 底层均使用 TCP 作为传输层协议。针对 TCP 协议的优化在一定程度上可以达到降低延时的效果，比如使用全链路 TCP 加速方案以及替换使用 BBR 在内的更好的拥塞控制算法。

苹果在 2019 年推出了 LL-HLS（Low-Latency HLS），采用 chunk 编码传输模式，将延迟降低到 3 秒左右。目前基于 TCP 方案的 LL-HLS 和 LL-DASH 方案的极限延迟在 2-3 秒左右。

为了优化 TCP 协议，业界在可靠 UDP 协议上做了很多探索。随着大家对 Google QUIC 协议研究的深入，有不少项目和开发者，开始用 RTMP over QUIC 替代传统的 RTMP over TCP。QUIC 是一个非常优秀的协议，现在它已经成为 HTTP3 的标准协议。但 QUIC 作为一种通用协议，它对音视频媒体不友好，也就是它没办法理解音视频媒体数据的具体含义，它以一视同仁的角度来对待这些媒体数据，这也是它不能彻底解决流媒体传输难题的根本原因。

这几年 SRT 也得到了广泛的应用， SRT 底层使用 UDT 协议，UDT 协议也是一个老牌的基于 UDP 的可靠传输协议，当然原生的 UDT 传输延迟是比较高的，SRT 在此基础上做了不少的拥塞控制策略的相关优化以降低传输延时。

近两年随着 WebRTC 成功推广，利用 RTC 技术实现的低延时直播技术越来越成熟，我们来看看云信 RTC 低延时核心技术要点。

网易云信 RTC 低延时核心技术

• 首先是抗弱网，为了对抗极限场景下 80% 的丢包，像业界常用的 FEC RED 以及 HARQ 技术大家都很熟悉，云信除此之外还利用基于机器学习的 PLC 算来进一步提高音频丢包后处理，并使用长参考帧 LTR 技术进一步降低视频的单帧丢失后连续参考导致的卡顿。

• 在去抖动部分，利用 Jitterbuffer和NetEQ 技术也是非常成熟的方案，我们花了很多的精力在做 Jitterbuffer 和 ARQ 以及音画同步模块的配合策略，在抗住 2000ms 的抖动情况下，还需要保证音画通话还是有不少工程方面的挑战。

• 在智能流控部分，首先一定要有优秀的带宽估计和拥塞判断算法，云信这几年对 GCC、BBR 和 PCC 等算法深入研究，融合各算法的优势，自研了一套稳定可靠的拥塞控制算法，可以保证带宽利用率在限制网络下达到 90%+；同时流控要做好必须做好全链路的反馈和源侧的响应，云信利用多层 Simulcast 和 SVC 技术增加了增加了调控的维度，同时利用全链路 VQC 技术保证视频全链路的效果。