共计 4415 个字符，预计需要花费 12 分钟才能阅读完成。
本文为「Dev for Dev 专栏」系列内容，作者为声网大后端传输协定负责人 夏天。
针对实时互动利用对网络传输带来的新需要和新挑战，声网通过将实时互动中的应用层业务需要与传输策略的分层和解耦，于 2019 年自研外部公有的传输层协定 Agora Universal Transport（AUT），将异构网络下的各种传输控制能力汇聚起来，并于 2021 ~ 2022 年开始逐渐大规模落地在各项业务中，用一套传输协定 / 框架解决各项业务不同的传输需要。
相干内容分为高低两篇，在上一篇内容《声网自研传输层协定 AUT 的落地实际》中，咱们介绍声网 AUT 传输协定的诞生和在实时互动业务场景下的利用。本篇从协定的演进和落地过程中，抽象地总结 AUT 的教训，并对 AUT 以及将来实时互动网络传输进行瞻望。
01 AUT 自研经验总结
AUT 的研发到大规模落地历时 3 年，传输协定的设计与实现兼具工程与算法的双重挑战，同时作为一项底层且形象进去的技术，在实时互动的各场景落地的过程中又有着方方面面具体的问题，过程不堪称不艰苦。在此为咱们的过往工作做些复盘和整顿，抛砖引玉，为后续相似工作积攒教训。
1、传输管制中的算法设计与迭代思路
因为理论网络中的场景纷繁复杂，某个场景中的算法改变可能会导致在其余场景中不适配的问题，同时 AUT 因为服务于多个不同的业务，还须要防止业务之间产生影响。所以在 AUT 的算法设计中，咱们的次要思路是对于新发现的问题先 明确辨认 ，在辨认后再 针对性的解决 ，以防止影响其余场景；通过可配置的形式、用灰度试验和 数据驱动 剖析理论后果来评估算法设计的优劣。
在算法的设计中，因为 AUT 内的弱网反抗模块较多，各个模块如果都独立保护本人的状态和逻辑，会产生很多的冗余代码。一个典型场景是，某个模块正在剖析的数据也是其余很多模块须要用到的，但触发算法决策的机会却千奇百怪各不相同。通过对该问题的剖析后，咱们决定将算法模块拆分为主观的 数据统计模块 和主观的 决策解决模块，而后以事件驱动来触发各个不同的决策解决模块进行算法决策，这样数据统计能做到最大水平复用，各算法的关注点也变得清晰明确。
2、适配利用能力将传输成果做到极致
在没有 AUT 之前，传输和应用层的逻辑是严密耦合的，严密耦合尽管可移植性差，然而单从这一项业务的传输成果上来说却可能做到最好，因为很多业务信息能够十分不便共享互通。从 AUT 开始实现之初，咱们就在思考如何既可能做到独立进去传输层协定和框架，又可能与各应用层一起将传输成果做到最优。最终，咱们摸索进去的思路是 机制上深度耦合、工程上足够形象。
首先从业务登程，从后果上咱们依然要对一个传输机制的最优解决形式放弃不变，不能因为分层之后就疏忽一些先验的常识和信息：例如视频传输中一整个帧须要一起解决，如果帧两头少了一块数据，就不能解决；那么在独立进去传输层后，也不能失落这个整块信息，须要依据这个信息来决策如何传输块中的每一个包。所以从传输机制上，依然要尽可能多的利用应用层提供的信息，以便把最终后果做到极致。
与此同时，工程上独立进去的传输层，不应该去了解视频中的帧是什么，这时候就须要形象的去了解：对应用层是视频的帧，而对于传输层就是一个整块数据。传输层实现的事件就是如何将一整块数据的传输做到最优，那么由此对于“块数据”的传输策略就独立了进去──它能够被用在很多场景中，视频只是其中一个，其余例如传输加密的证书、图片、大段的信息，咱们都能够应用同样的策略，这便是工程实现中形象了解带来的益处。
3、依据场景特点针对性应用传输策略
如何做到在 AUT 落地在公司的各项业务中应用一套框架应答各个需要，是个很大的难题。在解决这个问题上，咱们逐渐摸索出场景化传输的思路：首先明确本身的各项能力，而后剖析并提取出典型应用场景（网络场景 + 业务需要）作为先验常识，再针对不同应用场景应用针对性能力实现传输需要。
例如典型的场景包含：
● 无线传输 / 有线传输；有线传输中的网络稳定总体而言较少，那么咱们能够简化很多传输策略、以进步性能；无线传输中多因为信道的竞争而体现出网络抖动较大、变动较为频繁，这时候须要依据具体的无线传输网络做特定的适配，例如依据网络抖动动静对发送策略进行弥补。
● 实时数据传输（RTC）/ 非实时数据传输（File/Report）；实时传输中更强调数据的时效性，对于谬误复原要更激进甚至提前防止；非实时传输则尽量避免过于激进而对用户的整体网络应用状况产生较大影响。
● 单连贯大流量传输（FPA）/ 多连贯稠密流量传输（S2S）；单连贯大流量传输能够做更多的聚合解决工作，而多链接稠密流量则应防止连贯闲暇状态带来的开销。
● 长链接继续数据传输（Proxy）/ 短链接申请应答式传输（LBS Request）；长链接传输能够开启 MTU 探测、附带发送局部额定信息、应用连贯的前后上下文等以缩小协定 overhead；而短链接申请应答式传输则能够对利用数据做更多额定传输保障，以防止数据失落导致连贯继续过长。
不同场景中对实时性 / 可靠性 / 弱网反抗能力的要求大不相同，咱们的传输策略针对场景，而一个场景又能可能映射到其余多个具备共性的业务中，那么针对这个场景的传输优化就可能做到复用，而不再是针对一个个具体的业务去做定向优化。
4、做好协定的传输品质保证体系
传输协定的演进离不开本身的品质保证体系，只有具备稳固无效的品质保证体系，能力让协定的演进持续保持高效，否则实现技术改良也无奈验证正确性，呈现了问题也无从考察。
1. 可视化外部逻辑的影响
传输协定的问题考察有其特殊性：传输中的包可能会很多，而每个包的发送和接管都可能会影响外部的状态和逻辑，同时外部模块和算法模块较多，逻辑链条可能会很长，跨模块的状态相互产生的影响光应用断点很难追踪长期的影响关系和后果。
这时一个比拟好的方法，就是提供 可视化工具，通过通用模块依据 log dump 外部信息，将外部各种状态做成可视化图表，可能极大不便对外部各变量的相互影响关系进行追踪，很多问题可能高深莫测。
2. 重现 / 自测各种网络场景
传输的网络状态转瞬即逝，对于各种网络状态的模仿和重现同样非常重要，咱们应用两个层面的工具对网络状态进行重现：
● 应用零碎层面相干工具（TC 等），对较为简单弱网场景进行模仿（具备简单的弱网模拟能力，同时从工夫 / 资源的开销上也更大）；
● 应用外部仿真模块（simulator），从单元测试层面对较为明确的弱网场景进行仿真（模拟能力较弱，然而开销较低）；
这两个层面的工具造成互补，从不同的维度对网络状态进行重现，为 AUT 进行外部调试提供了牢靠的根据。
3. 保障代码的健壮性
因为在公司内广泛应用，同时裸露在公网上接管各种不可预知的输出，代码的健壮性同样须要无效的保障。
● 应用 fuzz 测试自动化模仿各种配置 / 接口 / 网络包的失常或异样输出，确保稳定性。fuzz 测试对于传输协定而言是一个十分好的工具，机器的运算力和对代码门路的判断相比人为思考测试用例在覆盖面上可能做到更加全面；
● 极其场景笼罩，通过长时间和极其异样网络来进行压力测试。极其场景往往是最典型的 corner case，很多设计时漏掉的边界场景，在极其场景测试中都可能呈现，所以永远不要放过。
5、技术演进肯定与落地利用相结合
传输管制自身是一项十分底层的技术，能够说是很多下层利用的基石，在底层技术的研发中，因为遇到的问题十分多，时常陷入的一个怪圈就是容易本人给本人找一些问题去思考并花很多工夫解决，这其中有些问题是具备前瞻性和理论价值的，但也有很多可能是脱离实际或至多在以后阶段是脱离实际的。这导致的一个后果就是技术演技与理论落地齐全脱钩，技术演进的很好，然而在具体业务上很难产生理论价值，甚至可能做了一个齐全没有业务须要的性能，费时费力却不讨好。
在 AUT 的演进过程中咱们就有过相似的经验，后续咱们就十分重视其中每项技术在具体业务场景中产生的理论价值，确保做进去的货色肯定要放在具体利用场景中落地，这样有理论的利用场景，就会产生更理论的问题，这些问题的呈现反过来又更好地帮忙了技术的迭代，这样既能产生理论价值、又进行了技术演进，防止了闭门造车。
02 AUT 演进的瞻望
AUT 在各个场景的落地绝非完结，而是一个新的开始，后续对于网络和传输的相干工作仍有很多方向期待咱们摸索。
1、寰球区域网络数据收集和剖析
在各项业务中独立出传输层当前，使得咱们获取了更为纯正的各地用户网络数据，后果收取 / 剖析 / 建模之后，网络数据可能为业务上提供很多反对，例如：
● 传输管制：应用用户网络数据来改善传输中的算法；
● 用户调配：让用户接入到最合适的运营商 / 边缘中；
● 网络诊断：依据当地 / 当运营商典型的网络模型，剖析用户网络问题；
● 试验仿真：构建更贴近用户实在网络的弱网环境。
2、机器学习在 AUT 中的利用
近年来机器学习在实时音视频传输中的利用也是层出不穷──多在拥塞控制算法中有些尝试。下图是咱们外部的机器学习算法的试验后果，能够看到相比于 Paper 中的试验后果，咱们外部的算法的带宽预计后果更加迫近 Optimal：
机器学习的算法十分依赖数据集，在实现更充沛的数据收集工作后，咱们置信机器学习在网路传输中会施展出更大的价值。
3、多路径传输的继续演进和落地
多路径传输是将来的大势所趋，AUT 外部也同步在做相应的反对，目前正处在逐渐落地的阶段。下图是一个咱们目前在实验室测试：multipath 版本应用 Wi-Fi 和挪动数据两个进口进行传输，singlepath 版本仅应用 Wi-Fi，咱们仅在 Wi-Fi 链路下增加弱网。
结果显示，multipath 版本的视频提早根本不受影响，而 singlepath 版本的提早则随着弱网条件跌宕起伏。
4、泛化弱网反抗模块到私有协定
AUT 中的各个弱网反抗模块从一开始就思考到了通用性，做到足够模块化，输出也与协定自身齐全无关，使得这些弱网模块能够非常容易地移殖到其余协定。
例如咱们当初曾经在 WebRTC 服务中应用了 AUT 内的拥塞管制模块，以改良原生拥塞管制的很多问题；同时 QUIC 在标准化后利用场景也越来越宽泛，AUT 内的弱网反抗模块后续也会逐渐迁徙到公司外部的 QUIC 协定栈中，以加强 QUIC 的网络分析及弱网反抗能力。
综上所述，AUT 的诞生和迭代是一个从业务中来、到利用中去的过程。作为一个底层的协定，AUT 从声网繁冗的业务场景中形象出了共性的网络传输需要，同时在工程层面，让底层算法与下层利用的耦合逻辑更具普适性；在模块化的设计理念下，AUT 也更容易整合到宽泛应用的私有协定中，这也为 AUT 将来的倒退关上了设想之门。
对于 Dev for Dev
Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区独特发动的开发者互动翻新实际流动。
透过工程师视角的技术分享、交换碰撞、我的项目共建等多种形式，汇聚开发者的力量，开掘和传递最具价值的技术内容和我的项目，全面开释技术的创造力。
