声网自研传输层协议 AUT 的落地实践丨Dev for Dev 专栏

 

本文为「Dev for Dev 专栏」系列内容，作者为声网大后端传输协议负责人 夏天。

针对实时互动应用对网络传输带来的新需求和新挑战，声网通过将实时互动中的应用层业务需求与传输策略的分层和解耦，于 2019 年自研内部私有的传输层协议 Agora Universal Transport（AUT），将异构网络下的各种传输控制能力汇聚起来，并于 2021 ~ 2022 年开始逐步大规模落地在各项业务中，用一套传输协议/框架解决各项业务不同的传输需求。

相关内容分为上下两篇，本文将详细介绍 AUT 传输协议的设计和演进过程。

 

01 纷繁复杂的传输场景

作为一家提供实时互动平台的公司，传输毫无疑问是所有互动的基石，随着网络的发展，互动的场景也越来越多样，传输的内容也越来越复杂，实时互动下的传输主要面临以下需求和挑战：

媒体数据传输

RTC 声网最主要的实时互动场景，实时音视频的传输也是和上层业务逻辑耦合最为紧密的传输场景，传输逻辑需要与媒体层面的信源编码紧密配合完成低延迟的互动。

● 需要有一个可靠的网络通道，来实现控制消息的收发。

● 需要有多个可靠的实时通道，来满足多路数据流（音视频等）的收发。

● 在带宽受限时，需要解决上述流的优先级管理问题（控制通道>音频>视频）。

● To B 场景下，要能让客户自主灵活地决定流的优先级和传输降级策略。

● 媒体中的相关策略，需要与当前的网络状况紧密配合。

● 在网内传输时，不同地区间和运营商间互通的网络质量迥异，各种网络 buffer、延迟及丢包相差巨大。

通用数据传输

声网推出的 FPA 全链路加速产品在全球范围为各类应用（包括 Web/游戏/音视频等）提供端到端的链路加速服务。

● 同时支持端到端的可靠传输通道和不可靠传输通道。

● 作为通用数据加速通道，数据流量变化范围较大。

● 低延迟。

低延迟可靠消息传输

RTM 是声网对外提供的稳定可靠、超低延时、高并发的全球信令与消息云服务。

● 消息体积小，消息频率较高，整体流量相对较低。

● 低延迟。

低优先级可靠数据传输

Report 是声网内部的埋点和事件数据上报，对内和对外提供问题排查的信息。

● 传输优先级和实时性要求低，要避免对其他业务数据产生影响。

● 与后端保持长连接，连接数量巨大，但绝大部分时间空闲。

各项业务网内传输

SD-RTN™是声网内部的全球覆盖网络，覆盖200多个国家和地区，承载着不同业务的流量。

● 跨区传输中长肥链路（亦即长肥网络，带宽延迟积大、丢包率高）的传输，大链路延迟下的带宽爬升/丢包要迅速恢复。

● 不同国家/运营商之间的网络质量难以保证，丢包/抖动十分常见。

● 不同业务/客户/场景的不同程度 QoS 保证。

 

02 解决之道--自研传输层协议

现有方案的不足

传输需求各有不同，我们首先 review 业界的各项产品，以求获得成熟的解决方案，但尽管调研发现均存在各种不满足的地方：

方案	优点	局限
RTP/RTCP	可以定制化传输策略	无优先级管理;缺少多路复用能力；
TCP/RTMP	通用性好	容易队头阻塞且无法多路复用；不能定制化传输策略，优化方案较少；
SRT	有部分弱网对抗机制	缺少独立的拥塞控制；缺少多路复用能力；
QUIC	具备多路复用、优先级管理和防排头阻塞	缺少对实时非可靠数据流的传输支持；缺少各种弱网对抗和网络适配能力；协议大而全，但相对于内部使用太重；

我们从业务需求整理发现，各业务之间的传输存在共性的同时也存在差异性，单独为一个业务的传输寻求已有的解决方案尚可满足，但是使用一种传输框架兼顾所有的业务场景绝非易事，这需求对各业务需求的深入理解和抽象提炼，业界的各项产品难也实现。

最终，自研传输层协议/框架成为了最轻便、适配性最强，但也是最具有挑战的解决方案。

AUT 的设计目标

我们根据已有业务的传输需求和特性，梳理并总结了自研传输协议需要实现的几个目标，如下：

1、提供多路复用的传输通道以同时承载不同的数据类型，并对不同类型数据提供有效的描述方案。

2、提供足够的可扩展性，能够适配各种应用层的传输相关的逻辑和输入，例如整块数据/分块数据/零散数据等，实时传输往往和应用结合揭秘，对于底层传输控制的粒度也会要求更细。

3、对不同数据提供不同级别的传输质量保证，例如不同的优先级/可靠性/冗余力度。

4、灵活的传输控制模块接口，可扩展实现不同拥塞控制、丢包检测、网络检测等策略。

5、底层网络接口化，能够支持任何虚拟网络。

6、对上层提供有效的网络质量分析，方便上层针对不同网络质量应用不同业务逻辑。

7、适配不同的网络场景，适应异构网络下的乱序/抖动/长肥/限流等网络状况。

 

03 AUT 的演进过程

架构演进过程

● 最开始的原型验证阶段，我们使用最简模型完成传输层的抽象，并仅针对音视频媒体中的不可靠传输场景下应用。

● 在完成原型验证后，AUT 演进成为 Session 和 Connection 的分层设计：Session 主要负责 Stream 的管理，不同的 Stream 完成不同的业务需求，Connection 负责业务无关的纯粹传输控制，以此完成传输控制和业务需求的解耦；独立抽象出网络收发相关的接口，使得 AUT 可以 Overlay 在各种网络上；引入加密/认证等安全特性；引入 MTU 探测、Padding 等网络状态探测能力。

● 完成分层设计后，AUT 的分层进一步细化：在 Stream 中逐步演进出更细粒度的通用模块和专用模块，通过抽象实现 Writer/Reader 、组合流控制器和缓存等完成不同的信道编解码、流控和重传控制等操作，使得每条流的弱网对抗能力具备差异化以适配不同的业务数据；Connection 统筹管理多个 Path，每个 Path 作为独立的传输控制单元互不影响，从能够同时支持多调 Path 同时传输；在传输算法上，引入了流量模型检测、丢包类型检测等更深入的网络状态检测模块。

弱网对抗能力

伴随 AUT 的演进，我们对网络的分析评估的维度也逐步丰富，这些网络分析能力是 AUT 弱网对抗能力的基础：

● 乱序检测能力：检测网络中的乱序程度，并在乱序条件下对传输算法做对应的调整，例如调整丢包检测算法和拥塞控制算法以适配乱序场景；

● 带宽探测能力：具备多种不同维度的带宽探测算法，在不同的探测需求下进行优势互补：packet train 探测带宽上限，以极小的流量模糊探测较高的传输带宽；padding 探测实际带宽，在应用数据不足时，将实际流量填充到网络中，真实地验证网络的实际容量；

● 流量模型检测能力：对实际网络流量的模型进行检测，例如公网中典型的 traffic policing/shaping 等流量限制策略，并针对性的调整发送控制策略；

● 丢包类型检测能力：对真实丢包的模式进行分析，输入当前的丢包模型，例如随机丢包和拥塞丢包等，并根据丢包类型在其他模块中进行动态补偿。

在明确网络的当前状态后，AUT 内部的各种弱网对抗能力才能“对症下药”：

● Stream 级别的通用信道编码能力：Stream 内部实现了通用的分组编解码框架，针对 FEC 中的分组码能够非常容易集成，使得不同的 Stream 在重传、流控等差别之外，还具备不同编码力度的保护，对外提供的传输伸缩性更广泛；

● 动态反馈控制能力：AUT 的反馈主要是 Ack 包，有效的 Ack 反馈为内部算法逻辑的准确性提供保证：动态启用 AckAck 对抗 Ack 丢包；不同 Ack Delay 适配性能/延迟；Ack 链路抖动/突发检测，补偿发送控制；

● 深度优化的拥塞控制/丢包检测算法：内部对典型的拥塞控制/丢包检测算法在各种场景下进行深度优化和探索，在保持算法本身特性的同时，适配实时传输中各种传输控制的需求。

传输效果对比

作为传输层协议，我们同样于其他传输层协议对于部分真实业务场景进行了效果的对比，一些结果如下：

可以看到无论在高低带宽限制（100Mbps 和 4Mbps）、0-50% 的单独上行和同时上下行的随机丢包、20ms 和 200ms 的 RTT 场景下，AUT 相比 lsquic 能够做到更接近实际带宽的吞吐量。

落地场景综述

截至目前，AUT 逐步落地在了声网以下的业务场景：

RTC

AUT 在声网 RTC 业务中的整体所在位置如下图所示，可以看到，在用户接入声网边缘节点的 Lastmile，和声网边缘节点之间基于 SD-RTNTM 的网内传输，都使用 AUT 作为 4 层传输协议。

Lastmile 使用 AUT 协议，让我们整体重构了媒体和传输的协作关系，实现了更快的网络状态跟踪（码率爬升从 20+ 秒提升到 3 秒左右）、更好的音频优先体验（无卡顿），并有效降低了卡顿和时延、对硬件编码的支持更好从而大幅提升了弱网的用户体验。

在不同网络条件下，使用 AUT 后视频的部分指标如下：

FPA

FPA 中 AUT 的所在位置和 RTC 类似，FPA 内的传输数据不再局限于音视频，但由于复用 AUT，各种场景下的传输能力也得到了大幅提升，我们在不同地区测试 FPA 与公网的传输速率，相关数据如下：

RTM

在接入 RTM 的边缘节点中，RTM 使用 AUT 替换 TCP，使用 AUT 接入 RTM 在各种弱网下的到达率和时延大幅度领先于 TCP 接入。通过发送1000个消息数据并记录其到达时间，对比测试 AUT 和由 TCP 代表的公共互联网传输协议在三种情况下的测试效果显示，使用 AUT 相比 TCP 在限速 100Kbps 条件下平均消息到达延迟下降 53%，丢包 20% 的条件下平均消息到达延迟下降 67%，限速+丢包条件下平均消息到达延迟下降 55%。

Reort

我们在连接 Report 和 RTC 边缘同时使用 AUT，并在 Report 的 AUT 连接中使用 LEDBAT 算法，假如此时各连接存在共享的瓶颈带宽时，Report 连接能够以极地竞争性参与传输，保证对其他业务数据产生最小的影响。

SD-RTN™

在声网 SD-RTN™ 网内使用 AUT 协议，使得网内传输具备提供不同 QOS 的能力，进一步提高了业务数据的传输效率，在长肥网络下使用 FEC 减少重传次数，进一步降低弱网下的网内延迟，对公网的中的 Traffic Policing/Traffic Shaping 能明确检测并适配，避免超发导致的丢包，网络质量评估更明确、实现了更好的网内路径规划，Metadata 机制极大简化了业务的控制面逻辑。

针对 RTC 网内传输结果，我们抽取了 40 个机房进行对比，结果如下：

方案	AUT使用前	AUT使用后
到达率不达标时间	00.00709%	00.00489%
抖动率不达标时间	00.00577%	00.00564%

由于之前的 RTC 网内传输质量已经十分优秀，在到达率和抖动相关指标都已经做到 4 个 9 的达标前提下，引入 AUT 后进一步降低不达标时间，使得 SD-RTN™ 的质量向专线进一步看齐。

 

关于 Dev for Dev

Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区共同发起的开发者互动创新实践活动。

透过工程师视角的技术分享、交流碰撞、项目共建等多种形式，汇聚开发者的力量，挖掘和传递最具价值的技术内容和项目，全面释放技术的创造力。

标签：丢包,声网,网络,Dev,传输,场景,AUT,传输层
来源： https://www.cnblogs.com/Agora/p/16425282.html