淘宝 APP 网络架构演进与弱网破障实践

▐  MobileSDN 理念

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

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

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

▐  AWCN 终端网络架构

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

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

▐  行业分析

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

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

▐  规模总览

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

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

网络加速体系详解

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

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

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

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

• IP 选取及缓存汰换策略

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

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

• 新态势下的挑战及升级

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

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

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

图：WIFI 存储升级改造流程

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

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

图：AMDC 存储数据迁移

▐  连接管理：更快建连，保障连接高可用

• 连接建立

除了常规的串行建连和并发建连方式，我们提供了热域名预建和复合连接的方式，应对各种复杂的场景。

热域名预建机制：启动场景下的关键请求加速

复合连接机制：IPv6 规模化背景下的体验保障

When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.

图：双栈复合连接

复合连接的两个核心目标：

数据上，针对 MTOP 和图片请求，双栈情况下其建连性能平均耗时降低 22.12%，99 分位性能降低60.19%，请求数据平均耗时降低1.23%，P99 分位耗时降低6.077%。

• 连接调度

按照不同的通道应用场景，连接可以区分为两种形态，保活连接与常规连接。

针对建立好的连接，不同形态的维护管理方式也不同。

面向保活可用：假连检测，动态心跳

通过对连接的多场景可用性检测，增强连接质量的感知，当出现连接异常时能够快速的恢复重建。

检测的手段基本为心跳 PING 包方式，分位定时心跳（前后台间隔不同）、分场景心跳（切换前台、业务上行超时等）。

面向空闲回收：闲时状态检查，及时关闭

对于不需要主动下行推送的场景，建连时刻保持对于用户带宽和功耗存在一定影响，因此针对此类连接增加了空闲状态的检查，当发现建连超过一定时间没有数据包传输时会进行连接的关闭回收，以减少资源占用，释放有限带宽。

▐  请求管理：弹性超时控制，请求补偿恢复

• 动态超时

• 多路竞争&择优选用

对于请求超时或慢的场景，AWCN 会通过多种方式进行择优选用和请求补偿，确保链路最优，保障体验：

传输协议：运营商对于 HTTP/3（UDP）的网络质量保证远不及 TCP，常常遇到各类 UDP 穿透性、请求超时等问题，因此必要时需快速决策，切回 HTTP/2、HTTP/1.1 的 TCP 传输链路；

底层框架：自研传输库(TNET)带来的好处是协议的自建和调优，但也因此导致协议非标(如 HTTP/2+SSSL 私有加密协议)，运营商拦截丢包、端到端链路稳定性等问题，必要时决策回退至系统原生库；

网络通道：以往对于用户网络不通导致的问题，优化的手段有限，但随着系统开放多通道选择的能力之后，上层也拥有了切换网络通道的能力，当检测 WiFi 不通环境下，会将请求切换至蜂窝网络通道恢复。

以传输协议择优选用为例，对于 H3 协议在手淘的规模化过程用户体验不受损，AWCN 网络库建立起完善的择优选用和补偿兜底机制。

▐  厂商加速：拥抱原生，系统级调度加速

近年来，国内几家厂商前后对上层应用开放了系统级的网络优化能力，包括网络带宽调度、数据流加速、QoE 状态反馈、弱网预测、双 WiFi 聚合能力等，从系统侧调度提升请求性能。

• 厂商能力融合的思考与决策

作为淘宝终端网络基础设施，一直以来我们都专精于应用策略及协议上，致力如何更好的调度、管理连接/协议让请求更快。随着国内厂商的发展，我们发现，脱离厂商的自研之路并不顺畅：

1. 一方面，不同厂商的限制和表现异同常让我们对各厂商做一些 hack 和兼容性的事情；

2. 另一方面，用户的网络资源有限，手淘作为单一应用，能调配和控制的资源有限。如何扩大我们的调度域得以让我们的应用内请求更好，是我们常在思考的事情。

因此我们选择拥抱厂商，通过系统赋予的调度加速能力，深度合作，为应用提供更好的网络体验。

为了屏蔽不同厂商之间的能力差异和接入方式不同，AWCN 提供厂商加速模块的通用能力抽象，通过运行期对不同设备和厂商能力的解决，动态组织支持的系统能力列表。

图：厂商加速接入架构

目前，我们已经和 OPPO 完成接入和上线工作，协同厂商侧紧锣密鼓的放量验证中。

▐  指标定义：明确弱网/卡顿请求

过往我们基于网络请求 1s 法则作为优化的指标衡量，目前业务请求秒出率超过 95%，当网络体验进入深水区，弱网/长尾等卡顿负向请求成为我们关注和突破重点。

图：请求全链路阶段

▐  诊断体系：更快识别、定位各类复杂网络问题

经常有一些线上用户反馈网络类的舆情：

1. 为什么 WIFI 下访问慢，切换到 4G 网络就恢复了？
2. 我的网络没问题，为什么手淘等淘系应用加载慢，其他 APP 正常？
3. 为什么 xx 页面加载很慢，其他页面没问题？
4. ......
   

▐  弱网技术：复杂网络下的网络体验

针对移动复杂网络环境，除了前面网络加速体系所提到的相关能力之外，这里笔者将重点对典型弱网靶向性优化技术展开。

• 网络多通道：手淘规模化应用

当请求没有响应/接收慢的情况下，一般会触发超时机制进行请求重放。但在用户 WIFI 信号差&弱网环境下，我们反而要谨慎重试，一方面重试会加重系统上的负载，另一方面重试会导致请求重新开始，对弱网传输慢的情况不友好，反而加剧卡慢的情况。

因此，在寻求更友好的方式上，我们发现系统提供了一种多通道传输的能力，即允许设备在 WIFI 环境下将请求切换蜂窝网卡的能力，网络应用层可以利用该技术，减少请求的超时等一类错误，提升请求的成功率。

图：系统官方文档

规模化方案

优化数据

目前多通道技术在手淘核心浏览链路上已规模化应用，严格按照AB 实验得出数据，双十一期间双端日对请求超时率减少 30%以上。

• 原生 HTTP/2：突破系统限制，实现 H2 协议支持

相对于 HTTP/1.1 协议，HTTP/2、HTTP/3 的协议性能优势不言而喻，HTTP/2 协议在手淘和集团内早已支持多年，HTTP/3 协议同样在持续规模扩量中，但目前淘宝内仍然存有 10%左右 HTTP1.1 流量。

通过分析，主要有以下原因导致：

1. HTTP/2 协议非标准化实现，加密方式为私有 slight-ssl，域名支持需服务端部署，未明确知晓是否支持的域名只能走 HTTP/1.1 协议；

2. 鉴于非标的影响，请求链路上需要强依赖 AMDC，必须通过 AMDC 配置明确支持 h2+sssl 方式的域名下发后才能支持；

3. 非标协议的兼容性存在小概率问题，个别运营商针对非标协议会进行劫持处理导致请求失败降级到短连。
   

过往很多业务反馈，为什么域名在 chrome 浏览器上访问支持 HTTP/2，而手淘里是仍然是 HTTP/1.1 的原因就在于此。那么，如何在不需要服务端部署、不强依赖 AMDC 的前提下，让请求实现长连加速？标准 HTTP2 的实现是必经之路。

如何支持标准 HTTP/2？

iOS 通过升级 URLSession 系统调用方式，可低成本的迁移到 H2/H3 协议上，但对于 Android 来说，系统侧提供的 HttpUrlconnection 仅支持到 HTTP/1.1 协议。因此，灵魂三问：

1. 标准协议的完整实现，必然要加入人力投入开发，稳定性验证和上线是一个较长的周期，如何减少支持的成本？考虑引入稳定的能力实现，如 Okhttp。

2. 稳定库引入必定会增加包大小，这对目前严控包大小的现状有较大冲突，如何解决？需尽可能不增加包大小的情况下支持。

3. 既要考虑成本和稳定性验证等规模化问题，又要避免给手淘包大小过大的增幅。既要马儿跑，又要马儿不吃草。如何实现？

源码突破

通过对系统源码的分析，我们发现 Android 系统 5.0 之后，系统 API HttpUrlconnection 底层已经通过 okhttp 进行托管实现，也就是说 Android 系统本身支持通过 okhttp 访问不需要额外引入三方库进行，只要找到可以 hook 的点。

图：Android 网络托管 Okhttp 代理

▐  小结

截至目前，日改善卡顿请求(网络错误/耗时>x 秒) PV 10 亿+ ，达成全年目标 10 亿(统计口径严格按照 AB 实验桶对比计算)，MOTP 请求超时率较去年 4 月优化了近50%。

▐  更精准的网络状态感知

准确掌握用户的网络状态是一切手段的前提，以往我们围绕 NPM 搭建诊断体系，对端到端链路的连通性和质量进行检测，在实时性、准确度和可用性仍有提升空间。

▐  更动态智能的调度加速能力

针对不同网络类型和质量的环境，我们希望建设更适应性更动态智能的调度能力，基于不同场景做更适合有效的加速能力应用，一成不变，固化的优化策略无法在所有的环境下发挥更优的效果。前面提到，当我们能够更精准感知，甚至预测用户网络的变化，我们能够做的事情就更多。

▐  更一致的弱网交互体验

我们发现淘宝多业务在弱网交互下表现不一，存在着无法刷新重试、空白无提示、阻塞无法操作等问题，因此除了技术侧的能力强化，会进一步联合多方沉淀弱网体验规范，协同业务优化弱网场景下的表现与体验、提升交互性和可恢复性，并改善用户在弱网下的预期和感受。

参考资料

团队介绍

我们是大淘宝终端平台技术团队，负责淘宝移动域中间件/原生技术挖掘/核心技术建设，包括不限于客户端体验/框架及创新体验/厂商与系统技术/用户增长及移动平台等，支撑亿万流量的移动网络接入，若你对我们的工作内容感兴趣，欢迎加入挑战。简历投递邮箱：liangwei.slw@alibaba-inc.com。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法