编者按： 近日，全球软件案例研究峰会在北京召开。全球软件案例研究峰会（简称“TOP100Summit”）是科技界一年一度的案例研究榜单，每年甄选年度最值得借鉴的100个好案例，旨在揭幕优秀研发团队背后的做法、思考，为读者提炼最佳学习路径梳理、思考案例长尾价值。
在壹佰案例峰会的“架构演进/工程实践/开源落地”专题上，声网 Agora 首席架构师刘勇发表了《QOE 驱动下的分布式实时网络构建：Agora SD-RTN™ 的演进》的演讲。他重点分享了SD-RTN™ 和 Agora RTC 系统 如何在保持线上无停机无大故障的情况下保证系统逐步升级、扩容和实时交互体验的质量持续改进，支撑了客户每天数十亿分钟的通信时长。
刘勇2001 年浙江大学本科毕业；2013 年清华大学博士毕业；2014 年加入声网Agora，从事整体系统的设计和开发。提出并设计、主导开发了 SD-RTN™ 系统，基于 SD-RTN™ 搭建了 Agora RTC 系统等。C++ 语言的忠实粉丝，互联网领域永远的新兵。
摘要
随着网络和视频技术的发展，以实时音视频为主的实时互动应用对长距离网络传输的低延时和高可靠性带来了新的挑战和需求。与传统网络架构和 SDN 技术不同，声网 SD-RTN™ 构建了以覆盖网络为主要思想的低延时高可靠性网络，配合基于 UDP 的多路复用传输协议 AUT，为 RTC 等实时服务提供了底层网络保障，保证了 Agora RTE 用户在全球范围内的端到端体验。
• 通过将 RTC 服务和网络传输分层、解耦，不同于传统 RTC 协议如 RTP 协议等将音视频媒体流和网络传输协议重度耦合的方案，提供了可伸缩、灵活且专业的系统架构，保证了服务的质量
• 利用覆盖网络和 SDN 的思想，保证了一定规模的全球组网的实时网络云的网内传输质量
• 提出了 4 层多路复用实时传输协议 AUT，基于该协议增强了 Agora RTC/RTE 在 lastmile 端的体验质量， 并为上层应用提供了抽象灵活的控制机制
SD-RTN™ 与 Agora RTC 服务架构
RTC 系统架构的演进
Real - Time Communication 顾名思义，既然是通信 ，通信的双方或者多方必须要发起连接或者握手。在常见的2人场景中，通信双方可以通过信令服务来发起P2P连接，直接实现数据通道的建立。
RTC 系统架构的演进(P2P/Mesh 架构)
优点： 服务器负载轻，只做信令的逻辑
缺点：
• 依赖双方的网络环境，实现互联。穿透成功率低，可用性不能保证
• 双方处于不同网络环境下，通信质量依赖于双方间的互联网质量，在跨区域、网络自治域时的质量存在着不稳定，不能提供稳定的 QoE 保证
• 多人会议场景下，需要两两建立 P2P 通道，可用性将显著降低；同时存在着上行浪费和性能问题
• 系统架构可伸缩性差
结论： 综合以上因素，P2P 架构不适合全球范围内的 RTC基础服务提供商的底层架构，只能适用于小型受限特定领域，或者作为提升特定场景覆盖质量的有益补充。
RTC 系统架构的演进(MCU 架构)
MCU（Multipoint Conferencing Unit）方案由一个服务器和多个终端组成一个星形结构。各终端将音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端。
缺点：
• 混流服务器资源消耗大
• 延时大
• 伸缩性差
• 灵活性差
RTC 系统架构的演进(SFU 架构)
SFU（Selective Forwarding Unit）方案由一个服务器和多个终端组成，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流根据终端的订阅结果，来转发给房间内的其他终端。
利用这种发布-订阅的模式，就可以实现灵活的多人互动场景。在上图的简化模型中还存在着两个问题：1）多人场景下,用一台服务器去服务地理位置分布较远的通信方，覆盖质量就得不到保证，同时还存在着对单一会话的并发参与人数的限制，系统的伸缩性差。
于是业界自然想到了分布式多服务器协同方案， 尽量采用就近接入的方式，它具备：
• 伸缩性好
• 覆盖质量好
• 但 对服务器间网络质量构成了挑战
将SFU架构做分布式扩展，其具备如下 优点 ：
• 离接入者近，避免了远距离接入带来的对 lastmile 的影响
• 由于 RTC 通信具有区域性的特点，在本区域的通信会话汇聚到本区域的边缘服务中心中，有利于降低通信的时延
缺点:
• 不同边缘集群间存在着网间流量，带来了成本的上升
• 不同边缘集群间的数据交互对网络质量带来了挑战：如跨地域、国别和运营商等。
利用分布式边缘计算的架构，通过努力优化边缘计算中心间的网络质量，能够将公共互联网络的不稳定对用户体验带来的影响尽量减少。基于这种思想，声网便提出SD-RTN™的概念。
Agora SD-RTN™ 的提出
设计目标：
不同于 RTP/RTCP 等协议及webRTC 及其衍生的服务端架构，设计上，我们希望通过横向分层的系统设计，降低系统耦合带来的复杂度。通过一层独立于音视频媒体协议的网络传输协议及服务架构，让音视频 RTC 服务专注于业务逻辑本身，让网络算法和协议设计及网络硬件架构工程师发挥其各自专长的领域来满足上层服务对 QOS 的要求：
• 协议解耦
• 服务解耦
• 充分灵活利用已有的网络基础设施，如公共互联网、专线等的能力
• 安全
Agora SD-RTN™ 抽象了 RTC 分布式架构下对网络传输的需求（低延时、高可靠），采用协议分层设计，将 RTC 服务和网络传输解耦，实现了协议、模块和服务的层次化和解耦：
• SD-RTN™ 对上层呈现的是一个 overlay network 的 3 层接口
• SD-RTN™ 是基于 UDP 的运行在异构网络下不依赖特定硬件和软件的分布式网络系统，可以针对不同的 qos需求进行路由实时选择和流量调度
SD-RTN™ 与 Agora 层次化服务架构
下图是整个Agora的服务架构，我们可以看到SD-RTN 与 4 层传输协议 AUT 构成了 Agora 实时云的网络基础：
Agora SD-RTN™ 架构
SD-RTN™ 系统又包括控制面和转发面：
• 控制面
链路探测和容量评估系统
边缘节点信息收集系统
路由调度系统
管理系统
• 转发面
下面详述一下链路探测和容量评估系统、路由调度系统两部分。
1、链路探测和容量评估系统： 根据调一定的调度策略，来定期的测试不同服务器集群间的网络质量数据，分析网络的模型，尤其是有损网络下的质量，进行汇总和评估
2、路由调度系统： 路由分析和调度系统类似于 SDN-Controller。SD-RTN™调度系统是一组实时的智能化承担路由规划和负载均衡的并行计算服务，根据全网汇总来的链路质量、节点间的实时传输带宽、QOS 要求和转发节点的负载等，来计算和下发网内的数据流的路由
Agora SD-RTN™与 SDN
RTN系统在设计和持续演进上，从已有的网络设计实践中尤其是SDN的架构上借鉴了一些思想。
相同之处
SD-RTN™ 与 SDN 的设计思想总体相似，主要表现为：
• 将路由器的复杂控制面逻辑和转发面逻辑分离
• 将控制面的路由策略的计算由集中式的控制中心（SDN-controller）来配置或计算
不同之处
• SDN 转发面需要依赖流表来控制转发逻辑，而随着网络规模的增大，对流表的查询、维护和更新就变得复杂，尤其是多跳的情形；SD-RTN™ 利用 SR 等技术简化了转发的逻辑
• SD-RTN™ 在底层根据网络链路评估状况，根据所需的 qos 级别，采用 FEC 或多路冗余等技术，来实现包级别的实时可靠投递
• SD-RTN™ 是一个覆盖网络的设计，不依赖特定硬件和软件，能同时利用公共互联网和专有线路，进行链路计算和流量分发
Agora SD-RTN™ 的演进
演进的过程分三个阶段：
• 初始阶段
SD-RTN™ 和 RTC 服务重度耦合，除链路评估和路由算法外，协议本身和服务都集成在RTC 接入和转发器中
• 较成熟阶段
RTC/RTN™ 协议分层和模块化，大部分服务解耦，为 Agora RTC 提供专用服务
• 当前和未来方向：
RTN 服务化，对 Agora 云内业务提供服务化接口（进行中）
Agora SD-RTN™ 带来的收益
• 开发效率
SD-RTN™ 和 AUT（见后）的引入，使得上层业务不用再关心底层网络传输的质量问题，可以专注于业务逻辑本身的开发，降低了系统的复杂度，简化了业务的模型，缩短了 RTC 业务开发的迭代周期
• 传输质量
针对不同QOS 要求，SD-RTN™ 提供了相应的不同传输策略，配合 AUT 协议来完成相应的质量要求。
SD-RTN™ 关注和优化两个网络质量的技术指标：
• 时延
• 包投递/送达成功率
Agora SD-RTN™ 质量指标(时延)
而在包投递成功率这一指标则进行了进一步的细分，针对常见的 Agora RTC 需求，RTN 重点关注了以下几个指标并进行持续优化：
1、2s 时延内的包投递到达率在 99.9% 以上的达标服务时间。该指标针对一般直播类业务观众端的时延需求。该指标达标时，绝大部分直播观众端在无其他因素影响下，能够流畅无卡顿。（已经基本优于基于 CDN 的直播技术方案）
2、800ms 时延内的包投递到达率在 99.9% 以上的达标服务时间。该指标针对 Agora 极速直播业务场景下的观众端的质量要求
3、200ms 时延内的包投递到达率在 99.9% 以上的达标服务时间。该指标关注普通 RTC的通信需求。该指标达标时，通信双方可以流畅对话，而无延时感和抢话的情形
Agora SD-RTN™ 质量指标(jitter 200ms 到达率)
Agora SD-RTN™ 面临的挑战和问题
• 扩展性（通过和 RTC 系统配合，实现水平扩展)
• 有损发散网络下的链路质量评估和容量评估
• 快速流量调度算法（NP 问题）
• 安全性 (Ipsec)
Agora RTC over RTN 架构
Agora RTC 系统，在传输层上有以下几个主要服务：
• AP/LBS 服务
• RTC SFU 服务
1、Native
2、webRTC
3、RTMP
• 频道同步服务和订阅服务
• 能力协商和仲裁服务
Agora Universal Transport(AUT)
Agora Universal UDP-based Transport Protocol (Aut)
RTC 场景中，需要：
• 一个可靠的网络通道，来收发控制消息
• 需要多条尽量可靠的实时通道，来满足多路数据流（音视频等）的收发
• 在带宽受限时，需要解决以上流的优先级管理问题
• To B 场景下，要能让客户自己自主灵活的决定流的优先级和传输降级策略
RTC 场景下对网络传输带来的挑战
举例来说，在带宽受限时，往往需要保证控制指令的高优先级发送；场景化应用中，比如有保证音频的发 送；保证老师优于学生等。考虑一种常规实现，控制指令走 TCP 通道；而每条音视频流走一条 RTP/RTCP 的方案。这种情形下，多条流的竞争下：
• 如果 RTP/RTCP 通道采用的 TCP-friendly 控制策略，音视频流和网络上其他数据流一样，就获得不了高优先级保证
• 如果采用了激进的拥塞控制策略，那么可能会阻塞 RTC 控制指令通道
• 多个 RTP/RTCP 通道的拥塞控制策略，如何调整保证高优先级流
在这种场景下，我们需要一个多路复用的传输通道，在同一个拥塞控制模块下，对流进行优先级管理，进行统筹安排：
• 利用 TCP 通道进行逻辑上的多路复用如 RTMP的最大问题在于TCP 的实现会导致排头阻塞问题
• Quic 针对 web 的应用场景，从协议层面实现了传输通道的多路复用、优先级管理和防排头阻塞，但它对实时非可靠数据流则没有支持
• 实时流的使用者对于底层的控制要求要比可靠数据流要多，如何进行媒体和网络传输分层设计和实现不是一个无关紧要的问题
• 灵活性与大客户的定制化需求的矛盾: 如果不能很好的做好灵活性的设计，那么很多大客户的需求就变成 了定制化的需求，不得不通过大量的 hard code 方式来解决
设计目标
• 通用性：使用一套协议设计来满足不同场景的需求，不仅 RTC，也包括可靠数据通道
• 传输协议中原生的流支持：
1、多路复用，灵活的优先级管理
2、通过流中捎带自定义的 Stream Meta 信息，给使用者进行流的管理决策
• 灵活的拥塞控制模块接口，可扩展实现不同的拥塞控制算法
• 底层网络接口化，能够支持 SD-RTN™，udp socket 和任何虚拟网络等
Aut 协议设计参考了 QUIC 的协议设计，但进行了大量的重新设计。
• 删除了一些版本管理和协商机制
• 增加了如为支持实时流场景应用中的Stream Option/Meta 信息机制等
• 设计了实时流的接口和实现
Aut 协议除了对实时流的支持外，还包括了:
• 加密
• 连接迁移
• FEC 支持
• MultiPath （实验中）
Aut 在 RTC 中的应用
Aut 协议在 Agora RTC SDK Nasa2(当前 3.0.0.18) 版本中作为底层传输技术已经得到了技术验证，为上层应用提供了高质量的传输保证和灵活的控制机制。灵敏的控制和反馈机制为上层引擎或应用优化提供了可能。
Aut 在 RTM 中的应用
Aut Over Aut: 点到点的网络加速 (RTNS 服务)
总结
• 系统架构遵循逐步演进，灰度迭代的方式，要与客户需求及生产规模相适应，不同阶段采用最合理、合算的方案，同时保证技术方向演进的持续性和一致性
• 系统设计要充分关注、调研已有的系统和设计实现，跟踪最新的技术演进（学术界和工业界）
• To B 行业里，一要尽量满足客户和产品的需求，也要避免技术产品项目化、外包化。和产品一起尽量寻求讲将抽取客户的公共痛点难点，考虑进系统的整体演化中
• 系统迭代过程中，需要考察系统的：
1、迭代线性性。控制线上系统的迭代复杂程度
2、可观察性。基于数据驱动的方式来观察和保证系统改进的有效性
ROI分析
• SD-RTN™ 和 Agora RTC 系统 6 年多保持线上无停机无大故障的情况下实现了系统的逐步升级、扩容和实时交互体验的质量持续改进。支撑了客户每天数十亿分钟的通信时长
• 随着 SD-RTN™ 和 AUT 的逐步交付，为 Agora 云内业务搭建系统提供了快捷一致的方案；并利用 AUT 协议能力通过 RTC SDK 为客户的定制化需求提供灵活自助的解决方案
