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 以内，在网络条件差的情况下，如何实现这个目标？王浩宇说，这是声网愿意集中精力长期投入的事情。

同时，声网也并不认为现在推出网络加速服务“为时已晚”。产品负责人施政说：

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

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