低延时直播与RTC融合架构设计②：直播与RTC低延时方案

本文整理自网易云信多媒体资深技术架构师吴桐在 QCon 全球软件开发大会上海站的演讲内容《超高清4K视频低延时直播与RTC融合架构设计》，为该系列的第二篇文章。

回顾该系列第一篇文章《超高清4K视频低延时直播与RTC融合架构设计①：5G与未来的网络格局》。

在本篇文章中，吴桐从传输协议、拥塞控制算法的选择说起，分享了网易云信对于BBR算法在低延时直播与RTC场景下的优化实践，以及网易云信低延时拓扑的设计方案。

 

直播火了，这是近几年大家最直观的感受。从2015年开始，各个平台风起云涌、百家齐放，到2016、2017年，大家开始寻求互动连麦直播的差异化体验。如今，直播已经进入下半场，低延时直播成为了新的突破口。

相信很多人都看过《疯狂动物城》，闪电虽然非常可爱，但是谁都不希望直播里的女主播，反应像他这么慢吧。

那么低延时由哪些因素决定呢?

1. 传输维度

• 传输协议
• 拥塞控制算法
• 服务器分发网络
• 第1公里：分配与选路

1. 其它维度

• 发送端采集、编码、前处理延时
• 接收端Jitterbuffer处理延时
• 接收端解码、后处理、渲染与播放延时

今天由于时间关系，我们主要来探讨一下传输维度的决定因素。

 

传输协议的选择

首先我们来看看传输协议的选择。

1. RTMP协议

RTMP协议是当前应用最广泛的直播推拉流协议，标准的RTMP协议传输层使用的是TCP，所以它的缺陷也是显而易见的：

1. 抗丢包能力差，丢包时发送窗口直接退避导致发送速率很慢；
2. 整体延时不可控，主要依赖于接收端的ACK的可靠传输；
3. 拥塞控制优化成本高，TCP算法拥塞控制策略是在操作系统内核层实现的，想要优化的成本很高，一般只有在服务端做内核层面TCP拥塞控制的相关优化，而客户端只能依赖各平台的操作系统自己做的拥塞控制优化。

综上，标准的RTMP不适用于低延时场景。

1. QUIC协议

想必大家对QUIC（Quick UDP Internet Connection）也不陌生，这两年随着大家对Google QUIC协议研究的深入，不少友商和项目开始用RTMP over QUIC替代传统的RTMP over TCP。

QUIC是一个非常优秀的协议，现在它已经成为HTTP3的标准协议。它的优势大家应该也都有所了解：

（1）0 RTT连接。QUIC底层使用了UDP，所以它可以非常灵活的重新设计一些协议特性，包括可以在首次以1RTT握手建连后，后续握手重连只需0RTT；

（2）支持HTTP2一样的多路复用，同时由于使用UDP协议，所以也