编者按：**近日，全球软件案例研究峰会在北京召开。全球软件案例研究峰会（简称TOP100Summit）是一年一度的科技领域案例研究榜单。梳理最佳学习路径，思考案例的长尾价值。在易白案例峰会上，以“架构演进/工程实践/开源实现”为主题，声网声网首席架构师刘勇发表演讲《QOE 驱动下的分布式实时网络构建：Agora SD-RTN 的演进》。他重点分享了SD-RTN和声网AgoraRTC系统如何保证系统的逐步升级、扩容和实时交互体验的持续完善，在线不停机、不发生重大故障，支持客户每天数十亿分钟的通信时长.刘勇2001年毕业于浙江大学，获学士学位；2013年毕业于清华大学，获博士学位；2014年加入声网，从事整体系统的设计与开发。提出、设计并主导开发了SD-RTN系统，构建了基于SD-RTN的声网RTC系统。C++语言的忠实粉丝，互联网领域的常驻新兵。摘要随着网络和视频技术的发展，基于实时音视频的实时交互应用对低时延、高可靠的远距离网络传输提出了新的挑战和要求。区别于传统网络架构和SDN技术，声学SD-RTN以overlay网络为主要思想构建低时延高可靠网络，配合基于UDP的复用传输协议AUT提供实时服务，如作为实时时钟。底层网络保障保证全球AgoraRTE用户的端到端体验。?通过对RTC服务和网络传输进行分层解耦，区别于RTP协议等传统RTC协议将音视频媒体流与网络传输协议严重耦合，提供可扩展、灵活、专业的系统架构，确保提高质量的服务?利用覆盖网络和SDN的思想来保证具有一定规模的全球组网的实时网络云的网络传输质量?提出了一种4层复用的实时传输协议AUT，基于该协议Agora最后一公里端RTC/RTE的体验质量，并为上层应用提供抽象灵活的控制机制SD-RTN和AgoraRTC服务架构EvolutionofRTCsystemarchitectureReal-TimeCommunication顾名思义，既然是通信，两方或多方必须通过通信发起连接或握手。在常见的两人场景下，通信双方可以通过信令服务发起P2P连接，直接建立数据通道。RTC系统架构演进（P2P/Mesh架构）优点：服务器负载轻，仅信令逻辑缺点：?依赖双方网络环境实现互联互通。渗透成功率低，可用性无法保证。双方处于不同的网络环境中。通信的质量取决于双方之间的互联网质量。跨区域、跨网络自治域时质量不稳定，无法提供稳定的QoE保证。多开会场景，需要建立2×2的P2P通道，可用性会显着降低；同时，会存在上行链路浪费和性能问题?系统架构扩展性差结论：综合以上因素，P2P架构不适合全球RTC基础服务提供商底层架构只能应用于小型和有限的特定区域，或作为提高特定场景覆盖质量的有益补充。RTC系统架构（MCU架构）的演进MCU（MultipointConferencingUnit）方案由一台服务器和多个终端组成星型结构。各终端将音视频流发送给服务器，服务器将同一房间所有终端的音视频流进行混合，最终生成混合音视频流发送给各终端。缺点：?流媒体服务器资源消耗大?延迟大?可扩展性差?灵活性差RTC系统架构（SFU架构）的演进SFU（SelectiveForwardingUnit）方案由一个服务器和多个终端组成。SFU不混合音频和视频。接收到某个终端共享的音视频流后，根据该终端的订阅结果，将音视频流直接转发给房间内的其他终端。利用这种发布-订阅模型，可以实现灵活的多人交互场景。上图的简化模型还存在两个问题：1）在多人场景下，如果使用服务器为地理分布较远的通信方提供服务，则无法保证覆盖质量。会话的并发参与人数有限，系统的可扩展性差。于是业界自然而然地想到了分布式多服务器协同方案，并尽量采用就近接入方式。它具有：?良好的可扩展性?良好的覆盖质量?但是，它对服务器之间的网络质量提出了挑战。具有以下优点：?离接入人近，避免了远距离接入对最后一公里的影响?由于RTC通信的地域性特点，该区域的通信会话汇聚到本区域的边缘服务中心区域，有助于降低通信延迟缺点：?不同边缘集群之间存在网间流量，增加成本?不同边缘集群之间的数据交互对网络质量提出挑战：如跨地区、跨国家、跨运营商等。利用架构对于分布式边缘计算，通过努力优化边缘计算中心之间的网络质量，可以将公共互联网的不稳定对用户体验的影响降到最低。基于这样的想法，SoundNet提出了SD-RTN的概念。AgoraSD-RTN提出的设计目标：区别于RTP/RTCP和webRTC等协议及其衍生服务器架构，在设计上，我们希望通过水平分层的系统设计来降低系统耦合的复杂度。通过一层独立于音视频媒体协议的网络传输协议和服务架构，音视频RTC服务可以专注于业务逻辑本身，让网络算法和协议设计以及网络硬件架构工程师利用各自的专长来满足上层服务的需求。QOS要求：?协议解耦?服务解耦?充分灵活利用现有网络基础设施，如公网、专线等?SecureAgoraSD-RTN抽象出RTC分布式架构下的网络传输需求（低时延、高可靠），采用协议分层设计，解耦RTC服务和网络传输，实现协议、模块和服务的分层和解耦：SD-RTN向上层Layer3接口呈现overlay网络SD-RTN是基于UDP的分布式运行在异构网络上，不依赖特定硬件和软件的网络系统。可以针对不同的qos需求进行实时路由选择和流量调度SD-RTN和Agora分层服务架构下图展示了整个Agora服务架构。我们可以看到，SD-RTN和4层传输协议AUT构成了声网实时云的网络基础：系统边缘节点信息采集系统路由调度系统管理系统?转发平面下面将详细介绍链路检测和容量评估系统以及路由调度系统。1、链路检测和容量评估系统：按照一定的调度策略，定期测试不同服务器集群之间的网络质量数据，分析网络模型，特别是有损网络下的质量，并进行总结和评估2、路由调度系统：路由分析和调度系统类似于SDN-Controller。SD-RTN调度系统是一组承担路由规划和负载均衡的实时智能并行计算服务。AgoraSD-RTN和SDNRTN系统在计算和传递网络中数据流路由的设计和持续演进方面，借鉴了现有网络设计实践，尤其是SDN架构的一些思想。相同点SD-RTN和SDN的设计思路大体相似，主要有：?将路由器复杂的控制平面逻辑与转发平面逻辑分离?将控制平面的路由策略计算由集中控制中心集中(SDN-controller)配置或计算差异?SDN转发平面需要依赖流表来控制转发逻辑，随着网络规模的增大，流表的查询、维护和更新变得复杂，尤其是在多跳的情况下；SD-RTN使用SR等技术简化转发逻辑SD-RTN在底层评估网络链路状态，根据需要的qos等级采用FEC或多路径冗余等技术实现实时性数据包级别的可靠交付?SD-RTN是一种覆盖网络设计，不依赖于特定的硬件和软件。可以同时使用公网和专线进行链路计算和流量分配。AgoraSD-RTN的演进过程分为三个阶段：?在初始阶段，SD-RTN和RTC服务耦合度很高。除了链路评估和路由算法，协议本身和服务都集成在RTCaccess和forwarder中服务解耦，为AgoraRTC提供专用服务当前和未来方向：面向服务的RTN，为Agora云业务提供面向服务的接口（inprogress)AgoraSD-RTN带来的好处开发效率SD-RTN和AUT（（见后文）介绍，让上层业务不再需要关心底层网络传输质量，可以专注于开发业务逻辑本身，降低系统复杂度，简化业务模型，缩短RTC业务开发迭代周期?传输质量针对不同的QOS需求，SD-RTN提供相应的不同传输策略，配合AUT协议完成相应的质量要求。SD-RTN关注并优化了网络质量的两个技术指标：?时延?数据包投递/投递效率重点关注以下指标并持续优化：1、包裹派送2秒内延误到达率99.9%以上的服务时间。该指标针对观众对一般直播业务的时延要求。当这个指标达标时，大部分直播观众都可以顺利运行，没有任何其他因素。（已经基本优于基于CDN的直播技术方案）2、800ms延迟内的包裹到达率超过标准服务时间的99.9%。该指标针对声网声网超快直播业务场景下观众的质量需求。3、200ms延迟以内的包传递到达率大于99.9%时的服务时间。该指标侧重于普通RTC的通信需求。当该指标达标后，通话双方即可畅通无延迟、无抢话感AgoraSD-RTN质量指标（抖动200ms到达率）AgoraSD-RTN面临的挑战和问题Scalability（通过和RTC系统协同实现水平扩展）?有损发散网络下的链路质量评估和容量评估?快速流量调度算法（NP问题）?安全（Ipsec）AgoraRTCoverRTN架构AgoraRTC系统在传输层有以下几个主要服务：?AP/LBS服务?RTCSFU服务1,Native2,webRTC3,RTMP?频道同步服务和订阅服务?能力协商和仲裁服务AgoraUniversalAgoraUniversalUDP-basedTransportProtocol(Aut)在RTC场景下，你需要：?一个可靠的发送和接收控制消息的网络通道?需要多个尽可能可靠的实时通道，以满足多个数据流（音频和视频等）的发送和接收?当带宽有限时，有必要解决上述流的优先级管理问题?在ToB场景下，需要客户自主灵活的决定流的优先级和传输降级策略。在RTC场景下，给网络传输带来的挑战。例如，当带宽受限时，往往需要保证控制顺序的高优先级发送；在基于场景的应用中，例如有保证的音频发送；确保教师优于学生。考虑到传统的实现方式，控制命令通过TCP通道；每个音频和视频流都经过RTP/RTCP解决方案。这种情况下，在多个流的竞争下：?如果RTP/RTCP通道采用TCP-friendly控制策略，音视频流与网络上的其他数据流一样，无法获得高优先级保证?如果激进拥塞控制策略，那么RTC控制命令通道可能会阻塞?多个RTP/RTCP通道的拥塞控制策略，如何调整保证高优先级流量这种场景下，我们需要一个复用的传输通道，在同一个拥塞控制下module,stream是按优先级排列的：?RTMP等逻辑复用使用TCP通道最大的问题是TCP的实现会导致head-of-the-line阻塞问题?Quic是针对webapplicationscenario，从协议层面实现了传输通道的复用、优先级管理和防头部阻塞，但不支持实时不可靠数据流。与可靠的数据流相比，实时流的用户对底层控制的要求更高，如何进行媒体和网络传输的分层设计和实现不是一个小问题?灵活性与大客户定制化需求的冲突：如果灵活性的设计做不好，那么很多大客户的需求将是变成了定制化的需求，不得不用大量硬编码的方法来解决设计目标。通用性：使用一套协议设计来满足不同场景的需求，不仅是RTC，还有可靠的数据通道。传输协议中的原生Stream支持：1.多路复用，灵活的优先级管理2.通过在流中搭载自定义StreamMeta信息，用户可以做出流管理决策。灵活的拥塞控制模块接口，可扩展实现不同的拥塞控制算法?底层网络接口，可支持SD-RTN、udpsocket和任意虚拟网络。Aut协议设计参考了QUIC的协议设计，但是进行了大量的重新设计。?删除了一些版本管理和协商机制?添加了StreamOption/Meta信息机制以支持实时流应用?设计了实时流接口并实现了Aut协议。除了支持实时流外，还包括：?加密?连接迁移?FEC支持?MultiPath(Experimental)Aut在RTC中的应用Aut协议作为底层传输技术在AgoraRTCSDKNasa2（目前3.0.0.18)版本，提供优质的传输保障和灵活的控制机制。灵敏的控制和反馈机制为上层引擎或应用优化提供了可能。Aut在RTM中的应用AutOverAut：点对点网络加速（RTNS服务）总结?系统架构逐步演进，灰度迭代方式要适应客户需求和生产规模。最合理、最具成本效益的解决方案，同时保证技术演进的连续性和一致性?系统设计应充分关注、调研现有系统和设计实现，并跟踪最新的技术演进（学术界和工业界）?在ToB行业，a要尽量满足客户和产品的需求，避免技术产品的立项和外包。与产品一起，尽量发现和提取客户的共性痛点和难点，兼顾系统的整体演进?在系统迭代过程中，需要对系统进行考察：1.迭代线性。控制在线系统的迭代复杂度2.可观察性。基于数据驱动的方法观察并确保系统改进ROI分析的有效性SD-RTN和AgoraRTC系统保持在线6年多无停机和重大故障，实现了系统逐步升级、扩容和实战-时间交互体验持续品质提升。支持客户每天数十亿分钟的通信时间?随着SD-RTN和AUT的逐步交付，为声网Agora云上业务构建系统提供了快速、一致的解决方案；并通过RTCSDK使用AUT协议能力为客户定制需要提供灵活的自助解决方案以上内容来自刘勇老师的分享。
