GA（Global Accelerator）亚洲地区快速，是个让人觉得“既熟识又孤单”的金融行业。

“熟识”是指，GA 不是个新名词，你几乎能在所有公有云供应商的产品介绍下，看见 GA 此项服务。做出海、游戏类业务的人都太熟识 GA 了，没有它 ，基本的互联网相连接都将成为问题。

“孤单”则是说，即便在禽流感的催化剂下，GA 金融行业依然极少再次出现在开发人员社区的主流视线中。在禽流感爆发的这两年间，我们频繁说起网络化转型、智能数据平台、RTC，可就是极少说起 GA。

为什么会再次出现这样怪异的情况呢？有一类可能是：虽然 GA 服务非常关键，但它属于基础公共设施，在技术层面暂时没有太多的想象空间，缺少宏伟目标发展，因而讨论关注度较高。

前不久，声网发布了 FPA 全链路快速产品，貌似与 GA 相差无几，又存有南辕北辙不同的技术特征，分外让人疑惑。因此，InfoQ 特别采访了 FPA 的产品负责人执政者与声网基础平台技术负责人王浩宇，希望能在构架和产品的视点对 FPA 展开阐释，从中寻找关于亚洲地区快速服务的捷伊启迪。

为什么“最终一千米”问题乏人问津？

要更好地理解声网 FPA ，首先要了解 GA 的工作原理。简单而言，GA 服务一般由公有云供应商提供，会为用户分配少数互联网连接 IP，保证用户设点互联网连接公有云快速互联网，再透过各个节点间的快速链路，配合动态的运维策略，同时实现网络层的互联网快速。

GA 快速计划是开拓性的，它将单一用户纳入公有云庞大的基础公共设施资源里，进行跨地域性跨运营商快速，并以云的方式，自自顶向下融合了多种不同快速技术，包括CDN、直通车互联网。而在此前，无论是 CDN 快速计划还是直通车快速计划，彼此都是孤立无援存有的，而且都是主要在物理层面几下，忽视了软件层面，显得有点硬朗。

但 GA 快速计划也不是轻松的，它存有许多天然下风，其中之一即是“最终一千米”问题：以 IP协议互联网连接快速互联网，意味着在互联网连接前，没有端侧 QoS 保障。具体而言，如果用户如果透过 Wi-Fi 互联网连接，将面临 Wi-Fi 设备操控性差异、链路竞争等多种不同问题；如果透过 4G、5G 信号互联网连接，则会因环境不同，造成信噪比不同，再次出现互联网操控性波动。

声网 FPA 的一个重要技术特点即是解决终端产品互联网连接问题，而这种解决计划主要是透过在终端产品、服务端软件系统 FPA SDK 来同时实现的。透过 SDK， FPA 构筑了一类覆盖任一起新任一端全链路快速通道，这也是 FPA（Full-Path Accelerator）名字的来源。SDK 软件系统后，从端侧到宽带，弱网对付、智能互联网连接、独立自主重大决策、输入输出互联网连接等多种不同技术计划都可以有所作为，这是此种计划为用户体验带来的最简单的改善。

弱网对付不以是说，这是所有视频会议、RTC 金融行业专业人士都必须解决且保持长期关注的问题。智能互联网连接、独立自主重大决策是指 SDK 会向运维中心请求一份路由列表，已获知最近入口，并根据路由列表独立自主重大决策在何处互联网连接，避免与运维中心反复通信增加延迟。

输入输出互联网连接是指 SDK 会和多个入口建立连接，传输相同的数据包，保证高可用，减少重传延迟。

听起来，软件系统 SDK 对整体快速操控性的提升，还是非常有益处的。但此前，无论是 CDN 服务提供商，还是 GA 服务提供商，都无法提供成熟的 SDK 软件系统服务。不是大家不想，而是因为不能。

FPA 产品负责人执政者说：“因为大家一直以来提供的都是一类标准的 web 服务。在这个场景下，对开发人员或者对于用户来讲，端侧软件系统是不能接受的。”

“但在声网的实时互动领域，”他补充道，“开发人员已经接受了声网使用 SDK 的方式作为他们的开发组件。”

情况也确实如此，SDK 一直是声网长期以来的主要服务模式。2020 年 10 月， 声网 Agora 创始人兼 CEO 赵斌在RTE大会上宣布，客户主动调用 API 次数突破 100 亿次/日。而声网最捷伊财报也显示，截至 2021 年 6 月 30 日，声网亚洲地区注册应用超 33.7 万个。这些无疑都是非常惊人的数据。

SDK 软件系统的计划对业务的侵入性很强。如果 SDK 不稳定，且业务模块没有做好边界测试和限制，相关故障很容易殃及整个系统。且与云服务不同，SDK 的代码是暴露的，当系统故障时，可能会让问题变得更复杂。

但任何计划都有两面性，SDK 计划的问题，同样也促使声网在软件研发层面，构筑出了自身的技术壁垒——

“声网 SDK 的崩溃率是 0.5 ?（万分之零点五），在金融行业内是最低的，没有经过洗礼是达不到这种程度的。”执政者说。

一个“异类”：基于 SD-RTN? 的宽带传输优化

除了端侧的覆盖问题，FPA 在宽带层面的快速策略，也与传统 GA 服务完全不同。

FPA 的宽带快速能力是基于声网 SD-RTN? 构筑的。SD-RTN? 在构架层面分为三层：

第一层：数据层。数据层负责数据的实时传输和转发，并负责将当前的状态数据上报给控制层。

第二层：控制层。控制层类似一个互联网操作系统，完成的是传统 Internet 的工作，包括寻址、计算并下发路由地址、控制传输的拓扑结构等。

第三层：应用层。应用层面向业务逻辑，同时会针对实时音视频场景做特别的优化。比如更改关键帧的处理策略、展开协议适配等。

这样的构架在 2019 年具备雏形，于 2020 – 2021 的两年间逐渐成熟。与传统的直通车互联网不同，SD-RTN?构筑在公共互联网上，使数据中心、企业内部以外的任何用户的终端产品都可以访问，对硬件的依赖很小；另外，SD-RTN?的数据中心分布在亚洲地区数百个节点，保证了通讯的舒畅。同时，声网也在探索自建机房，以此解决复杂的运营商问题，更好的控制成本。

SD-RTN? 无论在 RTC 领域还是在互联网快速领域，都算的上是一个“异类”。发展至今，业内最主流的互联网快速和低延时解决计划，还是基于 CDN 构筑的，与 SD-RTN? 在构架设计上几乎背道而驰。

作为历史悠久的内容分发解决计划，CDN 采用多级缓存的机制，依靠部署在各地的边缘服务器，透过中心平台的负载均衡、内容分发、运维等功能模块，使用户设点获取所需内容，降低互联网拥塞，提高用户访问响应速度和命中率。更为重要的一点是，运行在 CDN 之上的传输协议，大多基于TCP。

而 SD-RTN? 在建立之初就把网络层协议确定为 UDP，以规避 TCP 因握手、超时重传机制带来的高延迟。同时 SD-RTN? 在对缓存的控制非常谨慎。用声网基础平台技术负责人王浩宇的话说，就是“如何用最小的缓存去同时实现最优的效果”。

他也补充道：“FPA 很难对数据做缓存，这个跟 CDN 做静态快速完全是不一样的效果。你会发现有的时候缓存没啥用，比如最近有一个从 CDN 切到声网的用户，应用场景是上传课件，上课马上就要用。他们发现，基于 CDN 的快速效果很差。”

“为什么呢？”他说，“因为要建立缓存，其实需要付出很大的代价，而且如果没有一些预热，可能这个缓存的效果根本就不尽如人意。CDN 分发非常便宜，但它有使用前提，就是你一定得高频击中缓存，否则效果不好。”

当然，SD-RTN? 和 CDN 在资源侧没有隔阂，声网的思路是基于用户需求，定向的增加某个地区的节点覆盖。

究竟 CDN 和 SD-RTN? 哪种计划效果更好？这里不好下定论，CDN 也在不断针对低延时场景展开优化。但从新东方、陌陌等企业的实际使用效果来看，SD-RTN? 确实能够解决问题，并且在构架设计和未来扩展层面，可能更适合实时互动场景。

自研 AUT 协议：网络层的优化更有想象空间

声网 FPA 的另一个技术特点在于其自研的 AUT 协议，构架示意如下：

在发布会上，声网也发布了，AUT 协议和以 TCP 为代表的公共协议，在三种情况下的抗弱网效果数据。实验方法是发送 1000 个消息数据并记录其到达时间，实验结果如下图。

可以看出，对比 TCP 类公共协议，AUT 协议在限速和丢包场景中，平均消息到达延迟分别下降 53% 和 67% ，在同时限速与丢包的极端场景下，平均消息延迟下降 55%。数据表现非常不错。

AUT 协议的开放，同时给 FPA 带来了另一个与传统 GA 计划不同的特性。GA 虽然是基于公有云展开链路快速的，但所涉及的一般不止是“一朵云”或一个运营商，跨云、跨运营商是常见场景，这依赖于 BGP Anycast （边界网关协议 + 泛播），也往往导致快速效果再次出现大幅波动。

而 FPA 运行在 SD-RTN? 之上，首先避免了多云场景。更重要的是 AUT 是网络层协议，优化空间大于基于 IP 协议通信的 GA 服务。王浩宇在采访中说：

“我们相信这样是对开发人员最友好，对于整个互联网传输过程而言，也是最可控的形式。我们透过起新端传输能控制如何组包、协议怎么重传、怎么做编码侧地优化，以及协议里怎么做连接的关闭和迁移，这些全都是我们可以去深入优化的细节。”

无止境的质量问题

关于未来的产品迭代方向，王浩宇认为还有大量的工作需要做：

“从产品视点来看，我们还是专注于开发人员，思考能不能在更多的场景下，提供更易用的方法，比如代码软件系统就可以获得 FPA 的各项能力。另外从质量上来讲，如何在各种互联网异常再次出现的情况下，还能保证用户业务得到简单处理？包括资源布局、资源上的补充和替换，都是我们需要继续加强的。”

5G 和云游戏也是一个场景上的挑战。云游戏要求延时在 5ms 以内，在互联网条件差的情况下，如何同时实现这个目标？王浩宇说，这是声网愿意集中精力长期投入的事情。

同时，声网也并不认为现在推出互联网快速服务“为时已晚”。产品负责人执政者说：

“以前大家总觉得，在互联网层做好管道，让管道尽量靠近用户就够了，但从开发人员的视点来看，真的是这样吗？开发人员面对的起新端保障问题，有没有人帮他解决？”

“质量这个事情是无止境的。”