技术解码 | 海外直播系统，推进直播全球加速

本文介绍了腾讯视频云海外直播系统在基础设施建设、分布式架构设计以及音视频传输优化等方面多年沉淀的音视频处理和分发技术。该系统为全球用户提供了高品质、高可用以及高性价比的直播流处理和分发服务。

为了服务于全球视频直播的开发者和用户，腾讯视频云团队从2017年开始建设海外直播系统，针对全球复杂多样的网络环境和终端分布，经过3年多时间真实环境的千锤百炼，目前已经构建了拥有8个中心源站、200多个边缘加速点、每天提供数以亿计访问请求的系统性平台。本文将从海外基础设施建设、系统架构设计以及传输优化等3个方面介绍海外直播系统。

直播系统本质上是音视频处理、传输技术与计算、网络等物理资源的深度融合。高质量的服务能力离不开基础资源能力的支撑。得益于腾讯云在海外IDC机房的建设投入以及CDN边缘机房的建设，海外直播系统在3年的时间里，快速部署了包括中国香港、新加坡、印度、德国、美国等多个中心源站点以及分布于南美、东亚、欧洲等地区的200多个边缘加速点。

1、IDC专线建设

面对全球数千家运营商、7W多AS自治域的复杂场景，我们选择的在用户较集中的区域采购主流运营商的接入带宽，构建区域核心机房。

在建设海外跨区互连专线的问题上，首先优选运营商专线进行流量传输，其次通过在Internet上创建一条虚拟隧道的方式构建冗余链路来备份，提升跨区传输的高可用性。为解决跨度较长的问题，我们采用数据专线->波分专线->波道资源->干路光纤的层次化模型，从逻辑链路到物理链路的构建多段电路拼接的方案打造稳定可靠的大洋跨区链路。

2 、 “最后1公里”网络建设

对于机房到用户最后一公里的建设，我们遵循主干运营商直连、区域运营商peer、长尾运营商走本地IX互连的思路，快速构建边缘节点的服务能力和服务质量。

1、去中心化、区域自治

海外直播系统架构

海外直播系统整体采用去中心化、区域自治的设计理念。默认接入的用户具备就近推流，就近转码、就近播放的体验。从直播流传输链路维度看：

用户通过dns或httpdns解析获取到最优的接入点
接入点将用户的请求在边缘机房进行集群收敛
非命中的直播流，会向上回源到就近的大洲中心点
每个大洲中心点包含了独立的调度中心、状态中心以及媒体处理中心，具备完整的接流处理、转码服务、录制截图、存储等媒体服务相关的能力
跨区访问通过IDC间的内网专线，实现全栈加速的能力，提升跨区访问的质量

2、状态同步

分布式状态系统的设计和实现一直是一个比较复杂的问题，在我们海外直播系统建设的过程中同样面临着这样的问题。主要需要解决两个问题：

单区域状态中心如何保证高可用性？

我们涉及的状态组件具备以下特性：

多机多活，跨机房部署
功能解耦，业务分层
接入路由，平滑扩容

全局状态如何同步？

IP Seq保证写一致，心跳同步修正，保证最终一致性。

IP Seq保证写一致，心跳同步修正，保证最终一致性
点线面结合，分层同步状态，全局状态统一

3、外网接入路由

腾讯云的用户覆盖全球上百个国家和地区，不同国家和地区的用户网络条件和网络质量的差异性很大，依托于腾讯云全球几十个数据中心和智能路由策略，我们实现了完整的“智能路由调度系统”

智能路由系统架构图

（1）通过海量的探测数据以及历史数据的积累，结合直播自身稳定、可靠的网络质量要求，我们对数据进行清洗、归一化处理，结合丢包率、rtt等影响因子计算技术质量得分，生成细化到地区、运营商粒度的调度路由表；

ASN维度网络质量监控

（2）通过实时的探测质量数据结合静态配置策略，保持最大30s粒度跟新调度路由表；

（3）对于单区不可用或业务突发等异常情况，能够实时禁用故障机房，更新路由策略，大区调度突发流量，保证平台整体的稳定性和质量；

某大客户突发40w 同时在线数

（4）构建完整、可视化、自动化程度高的运维平台，提升自动化运营能力。

在海外的系统设计上，往往我们需要解决的是复杂网络环境问题给传输带来的巨大挑战，主要分为IDC传输和边缘传输两部分。

1、IDC间传输加速优化

（1）多点中继，提升传输吞吐量

海外IDC传输存在着大量的跨国、跨大洲的长远距离外网传输路径，这种拥有长RTT、高网络带宽以及抖动丢包的链路通常称为“长肥管道”。“长肥管道”通常由于以下几个原因导致吞吐性能不佳。

a、慢启动周期过长

TCP是基于ACK来驱动窗口滑动以促进数据发送，当链路存在着比较大的RTT时，那么发送数据确认周期就会延长，导致启动周期过慢，影响直播的首屏效果。

b、丢包恢复慢

链路拥有大的RTT意味着ACK的周期和RTO值越大，往往“长肥管道”伴随着弱网表现，那么当出现丢包时，链路的传输速率会受到很大影响，同时收敛周期也会变长，导致直播用户的卡顿时长加大。

c、协议栈参数特殊要求

linux系统定义每个TCP链接的发送缓存区的大小的参数；默认为16k。由于TCP的可靠性机制，发送出去的数据需要收到ACK后才会促进滑动窗口移动，ACK的时间直接依赖于RTT值，当RTT较大、缓冲区较小时，由于确认周期较长，导致发送缓存区一致处于填充过满的状态，应用层一直无法写入数据，这样整体吞吐量会严重降低。

中继加速示意图

面对这样的问题，我们提出了“分段中继”，提升链路吞吐量的方案。在全球骨干网络分布的地点建设中继节点，构建智能路由，根据探测的质量数据包括丢包、延迟以及容量等因素，决策路由表，根据路由表转发数据下一跳以实现链路中继加速，提升链路整体的吞吐量，同时也提升了点到点的传输质量。

（2）QUIC传输组件化，对抗弱网

QUIC（Quick UDP Internet Connection）是谷歌制定的一种互联网传输层协议，它基于UDP传输层协议，同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性，可以有效减少连接与传输延迟，更好地应对当前传输层与应用层的挑战。

在IDC传输中，我们使用了QUIC进行加速优化，主要在以下两个方面做了优化：

a、协议栈插件化，网络传输的相关参数从QUIC中提取出来，根据不同的链路模型进行配置化处理，针对性调优。

b、优化协议栈算法本身，比如对bbr也进行了针对性调优，比如Startup阶段起始窗口的调整；比如ProbeRtt部分，对探测周期、影响因子、启动策略也都进行了针对性优化，使其更适应IDC这种场景下的传输。

比如在针对启动窗口部分，对比优化前后，发现在大RTT场景下，首屏数据的突发能力意义很大，部分场景下，能够降低一半的传输延时。

下载同一个ts优化前后吞吐量对比图

比如针对BBR中ProbeRTT状态导致链路吞吐量抖动的问题，我们也提出了优化探测周期、随机化不同连接进入探测阶段等方案来提升链路整体的吞吐量。

优化前后吞吐量对比

目前我们在现网已经支持了包括39、43、46等稳定版本的HTTP/3推拉流服务。针对特定的客户，我们也支持私有协议透传以及定制化的明文QUIC传输通道，欢迎体验并提出宝贵意见。

（3）SRT实践实现跨州低延时稳定传输加速

SRT（Secure Reliable Transport）是新一代低延迟视频传输协议，是一种开源、免费和应用灵活的规范，它的性能与专用的协议一样优秀，同时能够在不同制造商生产的产品之间工作。

针对SRT技术的应用，视频云团队做了一些优化和改造：

a、改造原生IP 端口的推流方式，和Haivision官方合作推出了streamid的功能，用于携带vhost、streamname等信息。使其更适应现有的通用直播平台。

b、优化SRT的握手耗时，从默认的2个RTT缩减为1个RTT，减少建联时间，提升推流体验。

c、更精细的Qos策略，优化在不同程度丢包场景下的选择性有损丢帧策略，保证低延时的情况下，优化传输体验。

d、结合实际直播使用场景，目前在SRT媒体协议上支持将默认的MPEGTS封装格式转换成直播平台更加通用的RTMP协议、HTTP-FLV等，使其和现有直播平台更加契合。

鉴于SRT优异的传输体验以及在融媒体制作领域的特定价值，视频云团队成功孵化出适合跨境实时低延时传输的TencentMediaConnect产品，欢迎体验，并提出宝贵意见。

2、边缘传输优化

（1）丢包对抗

丢包是传输技术优化过程中碰到最常见问题之一。导致链路丢包的因素有很多种，从场景来看通常分为以下几类：

信躁丢包，往往出现在用户的接入wifi、4G网络环境中，这种通常是由于无线信道传输复杂的环境导致。
错误丢包，传输网络设备异常引起的错误丢包，通常占比较小。
拥塞丢包，运营商链路拥塞，通常分为深队列、潜队列、尾部丢包的表现形态。
限速丢包，限速的算法通常使用令牌桶、漏桶等，通常出现在社区网络的环境下。

优化丢包的思路通常分为3类：

ARQ（Automatic Repeat-reQuest，ARQ），自动重传请求机制，这是一种通过接收方请求发送方重传丢失数据报文来达到数据恢复能力的方案，也是现用对抗丢包中使用最多的方案。
FEC（Forward Error Correction），前向纠错机制，通过在发送数据包里面增加冗余数据包，在接收端再使用冗余数据包讲丢失的数据包恢复出来进行丢包对抗。需要额外占用比较多的带宽，整体带宽浪费率较高。
PLC（Packet Loss Concealment），丢包补偿机制，是一种纯接收端的丢包对抗技术，依赖于接收到的数据帧，预测丢失帧，不占用额外的带宽。但局限性明显，修复的范围有限，当丢失的数据值延时较大，就无法恢复了，整体恢复率较低。

以上几种方案往往都是跟音视频技术产生了深度绑定或依赖于定制化的交互逻辑，并不适合在CDN边缘传输这种单向TCP传输场景下使用。

我们结合这些技术的优秀思想以及实际链路场景情况设计实现了一种基于场景识别带宽探测重传优化平滑发送能力的自定义TCP协议栈QTCP。

QTCP模块结构图

针对拥塞控制，本方案兼顾了基于BDP探测以及丢包探测的一些算法优点，以RTT为采样周期，主动控制数据量进入发送队列尝试抢占带宽，并根据周期内的带宽以及丢包情况决定带宽探测影响因子的方向和幅度，保证连接尽可能逼近极限点，充分利用链路带宽。
针对重传机制，本方案摒弃原有完全基于客户端ACK反馈的机制，采用更加积极的周期探测的方案来提升确认信号的稳定性。对于重传逻辑，结合时间序概念进一步进行了完善。
针对不同场景，本方案结合用户RTT、丢包等相关因子，设计实现了预测用户类别的能力，同时引入了机器学习算法，加强拥塞模型对网络的适应性，能够根据不同的场景，适配不同的传输参数进行自适应调优，整体架构如下: