淘宝APP网络架构演变与弱网破解实践

最编程 2024-04-05 20:10:21

...

本文将介绍淘宝 APP 统一网络库演进的过程，讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构，通过构建 NPM 弱网诊断感知能力，落地原生多通道技术/多协议择优调度手段，贴合厂商附能网络请求加速，实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡，为用户提供弱网更好、好网更优的 APP 加载浏览体验，支撑业务创造更多的可能性。

引言

自 2013 年 ALLIN 无线到今天，已经走过 10 个年头，淘宝终端统一网络库 AWCN (Ali Wireless Connection Network) 从淘内孵化，一路过来伴随着淘宝业务的发展，经历集团 IPv6 战役、协议升级演进等，逐步沉淀为阿里集团终端网络通用解决方案，是兼具高性能、多协议、可容灾、可观测的终端网络基础统一设施。面对移动互联网络下复杂多变的网络环境，如何提供更稳定可靠的请求性能，保障用户的加载浏览体验、更好的支撑业务发展，是我们始终探索的命题。

终端架构介绍

▐ MobileSDN 理念

在介绍 AWCN 之前，笔者想先这里普及下 SDN 架构的概念。

SDN（Software Defined Network，软件定义网络）是一种将网络资源抽象到虚拟化系统中的 IT 基础架构，SDN 将网络转发功能与网络控制功能分开，其目标是创建可集中管理和可编程的网络，核心理念是希望应用软件可以参与对网络的控制管理，满足上层业务需求，简化使用和运维成本。有一个较为形象的类比，如果说现在的网络系统是功能机，系统和硬件出厂时就被捆绑在一起，那么 SDN 就是 Android 系统，可以在很多手机设备上安装&升级，同时还能安装更多更强大的手机 App（SDN 应用层部署）。

回到移动应用领域，我们的目标是搭建统一的终端网络解决方案，上层业务不需要关心内部的协议如何转发、请求超时降级等复杂逻辑，做到好用、易用、可观测、体验好。显然，这与传统 SDN 架构理念不谋而合。

▐ AWCN 终端网络架构

因此，围绕以上理念和目标，我们进一步构建起南北向从监测到加速一体化的 MobileSDN 架构，以减少业务的接入/运维成本，提升用户的浏览体验。

从 MobileSDN 架构展开来，接下来简要介绍下各分层模块承担的角色与其中作用。

网络应用：面向多种应用场景衍生出的网络组件，如统一 RPC 网关（MTOP）、消息 PUSH 通道（ACCS）、上传（AUS）、下载（TBDownloader）、图片加载（Phenix）、远程配置（Orange）等能力；
网络北向接口：上层调用和内部实现的桥梁，提供统一同步/异步对外 API 接口和无痕 Hook 方式，用于上层网络应用/业务场景接入调用网络基础能力；
网络控制器：请求策略管控中心，架构大脑，负责请求端到端链路的调度和优化决策，有着举足轻重的作用，控制器提供完备的网络加速能力，从节点调度/连接选择/请求管理多个环节进行网络请求加速；
网络南向接口：控制面与基础协议转发的桥梁，对协议及数据进行了通用抽象，以应对不同系统框架/不同协议的统一处理；
网络协议转发：多个基础协议和网络框架的统一适配实现，兼容各类请求场景下的最优选择调度，支持标准 HTTP/1.1、HTTP/2、HTTP/3，以及集团自研的 HTTP/2+SSSL 和 H3-XQUIC 协议；
网络性能管理：网络数据及性能观测中心，NPM（Network Performance Management），负责设备网络状态/质量/信号强度的感知、业务请求数据的统计上报、PING/TRACE/NSLookup 等网络时延探测诊断、用户网络诊断/请求抓包等工具建设。

▐ 行业分析

纵观行业内一些与之对标的移动网络框架，如腾讯维纳斯 WNS、微信 Mars、Chromium cronet、Square Okhttp 等，AWCN 和它们在一些思路上可以说是殊途同归，通过提供更优的 IP 策略调度、多协议连接管理策略及请求超时等控制加速请求，建设网络诊断、网络质量监控等手段加强网络可观测能力。

微信 Mars：STN 负责请求任务管理/IP 排序/网络策略等能力优化请求体验，SDT 为网络诊断模块，一定程度上与 AWCN 中网络控制器、网络性能管理两块部分承担角色相近。

图：微信 Mars 基础架构

▐ 规模总览

淘宝统一网络库作为基础组件在集团内被广泛应用，集团内涵盖千级以上规模应用支撑，包含且不限于手淘、闲鱼、优酷、天猫、Lazada、高德、UC浏览器、饿了么等 APP，同时通过阿里云 EMAS、友盟对三方应用开放接入，如海底捞/杭州银行等企业应用。

作为移动网络解决方案，网络请求的体验是重中之重，因此，笔者将重点讲述网络控制器如何围绕请求构建完整链路上的加速技术，介绍如何从节点调度/连接选择/请求管理/系统调度进行业务网络体验优化，确保请求在各类复杂网络状况下高可用。

网络加速体系详解

前面提到，网络控制器是作为整体架构上的大脑，承担着请求端到端链路的调度和优化决策，相当于掌舵手和发动机的角色。一次完整的请求网络传输大致可以分为以下链路，即DNS->建连->发送数据->等待首包响应->接收数据，过程中 IP 策略调度、连接管理、请求管理及厂商全局调度加速子模块各承担着不同的作用，笔者将逐一介绍阐述。

IP 策略调度：负责 IP/节点的选择和调度，职责是选择最优的 IP 策略，减少 DNS 带来的耗时，同时具备切流容灾的能力；

连接及协议管理：负责连接池生命周期的管理和各类协议的选择，职责是连接择优且高可用；

请求管理：负责请求的调度，涵盖超时、降级、重试恢复等流程控制，职责是让请求更快的被执行；

厂商加速：负责对接各大厂商系统侧的网络能力，结合系统赋予的网络加速能力（如更精准的网络质量状态/双频 WiFi 聚合加速/流加速等），进一步优化复杂网络下请求调度的策略决策，是自研与厂商原生网络能力之间的沟通枢纽。

▐ IP 策略调度：减少 DNS 耗时，选择更优 IP

众所周知，传统的 LocalDNS 方式存在各类隐患问题，如：解析慢/失败率高、更新不及时、域名劫持、缺少精准流量调度及容灾能力，AMDC（Ali Mobile Dispatch Center）是阿里自建的无线域名解析调度服务，在淘宝和集团绝大多数应用中广泛应用。

依托 HTTPDNS 实现无线调度功能就够了吗？远没有那么理想化，如何在端侧处理好 IP 策略的选取/容灾/安全性/服务 QPS 压力等环节，都至关重要。

IP 选取及缓存汰换策略

IP 选择机制上，基于服务下发+端侧动态排序的机制运行：

服务端下发：根据单元化/运营商/就近接入/网络协议栈等维度，下发一组可用的 IP 列表。同时具备通过端侧跑马算法，生成最优的策略 IP。

端侧动态排序：根据端侧 IP 策略使用记录（成功&失败&耗时等维度）进行优先级排序，建连错误次数多的策略在排序优先级上进行降权操作，与之相对应的，建连成功率高性能好的策略优先级提高。

缓存和汰换机制上，考虑到频繁 AMDC 调度带来服务压力、异步请求 AMDC 带来的生效率问题，端侧对策略进行了缓存，根据用户网络粒度进行独立存储，应用启动和网络事件切换情况下加载所需的策略记录；根据前面所提及的建连记录动态排序能力，自然也产生了对应的淘汰替换机制。

淘汰机制：同一 IP 在 5min 中连续失败 xx 次，进入禁用淘汰的情况

更新机制：域名粒度携带 TTL（Time To Live）下发，超过 TTL 的域名进行异步更新，同时更新机制按照域名的优先级也拥有不同的模式。

新态势下的挑战及升级

CASE 1：高版本设备对于 WiFi 网络唯一标识的获取限制

前面提及的端侧缓存策略基于用户网络粒度做独立存储，对于 WiFi 网络环境 BSSID 是端侧的标识主键，但随着系统升级带来的一系列用户权限收敛：

Android 8 及以上版本开始，需要用户授权定位等权限，才可以拿到 Wi-Fi SSID/BSSID 等相关信息，否则返回 02:00:00:00:00:00 默认值
iOS 14 起，必须接入 network extension，否则无论通过任何手段都无法获取到 wifi 相关信息，对接 NE 成本太高。

这意味着现有网络存储结构不再具备唯一标识用户网络的能力，无法正常获取 BSSID 信息的这些设备上存在着策略混用，甚至跨运营商的问题，从而导致请求性能变慢/出现异常，线上约有 20%+的用户受潜在影响。因此，对于端侧无法直接获取 BSSID 的设备，引入新的存储主 key，即用户无线接入点 AccessPoint 信息，流程涉及 AMDC 端到端协同升级，大致流程如图所示。

图：WIFI 存储升级改造流程

数据上，图片等 CDN 类请求平均耗时优化 4.439% ，耗时分位 P90 优化 1.932% ，P99 优化 2.230% ，P999 优化 2.668% 。

CASE 2: 应对更复杂协议/更精细化调度诉求下的协议演进

当现有协议结构无法满足日益复杂和精细的调度诉求，且无法在现有模型上持续长期迭代时，就需要对协议进行重构升级。我们在移动网络虚拟化项目中切实遇到如上的问题，协议重构对于端上来说，是对整个存储数据模型的改变，这意味着升级新协议的用户可能无法继续使用旧版本存储策略，直接丢弃老协议存储是最简单有效的手段，但这会导致升级后一段时间内用户出现降级 LocalDNS 的问题，这对我们不能容忍。

重新实现一个协议不难，难的是如何确保新老协议平稳升级过渡，避免请求出现 LocalDNS 降级。因此，方案的关键在于如何对新老协议做数据迁移，其中涉及升级链路和降级链路(如稳定性问题功能回退场景)。