淘宝移动端统一网络库的架构演进和弱网优化技术实践

本文由大淘宝终端平台技术团队沈良炜(沛轩)分享，本文有修订和改动。

1、引言

自 2013 年 ALLIN 无线到今天，已经走过 10 个年头，淘宝终端统一网络库 AWCN (Ali Wireless Connection Network) 从淘内孵化，一路过来伴随着淘宝业务的发展，经历集团 IPv6 战役、协议升级演进等，逐步沉淀为阿里集团终端网络通用解决方案，是兼具高性能、多协议、可容灾、可观测的终端网络基础统一设施。

面对移动互联网络下复杂多变的网络环境，如何提供更稳定可靠的请求性能，保障用户的加载浏览体验、更好的支撑业务发展，是我们始终探索的命题。

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

* 推荐阅读：《百度统一socket长连接组件从0到1的技术实践》。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4470-1-1.html）

2、本文作者

本文由大淘宝终端平台技术团队沈良炜（沛轩）分享。

大淘宝终端平台技术团队，主要负责淘宝移动域中间件/原生技术挖掘/核心技术建设，包括不限于客户端体验/框架及创新体验/厂商与系统技术/用户增长及移动平台等，支撑亿万流量的移动网络接入。

3、MobileSDN 理念

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

SDN（Software Defined Network，软件定义网络）是一种将网络资源抽象到虚拟化系统中的 IT 基础架构，SDN 将网络转发功能与网络控制功能分开，其目标是创建可集中管理和可编程的网络，核心理念是希望应用软件可以参与对网络的控制管理，满足上层业务需求，简化使用和运维成本。

有一个较为形象的类比，如果说现在的网络系统是功能机，系统和硬件出厂时就被捆绑在一起，那么 SDN 就是 Android 系统，可以在很多手机设备上安装&升级，同时还能安装更多更强大的手机 App（SDN 应用层部署）。

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

4、AWCN 终端网络架构

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

AWCN Mobile-SDN 架构：

从 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 等网络时延探测诊断、用户网络诊断/请求抓包等工具建设。

5、市面上的同类方案分析

纵观行业内一些与之对标的移动网络框架，如腾讯维纳斯 WNS、微信 Mars（《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》）、Chromium cronet、Square Okhttp 等，AWCN 和它们在一些思路上可以说是殊途同归，通过提供更优的 IP 策略调度、多协议连接管理策略及请求超时等控制加速请求，建设网络诊断、网络质量监控等手段加强网络可观测能力。

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

微信 Mars 基础架构：

（图片引用自《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》）

6、淘宝统一网络库的应用情况

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

作为移动网络解决方案，网络请求的体验是重中之重。

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

7、网络加速体系概览

前面提到：网络控制器是作为整体架构上的大脑，承担着请求端到端链路的调度和优化决策，相当于掌舵手和发动机的角色。

一次完整的请求网络传输大致可以分为以下链路：即DNS->建连->发送数据->等待首包响应->接收数据。过程中 IP 策略调度、连接管理、请求管理及厂商全局调度加速子模块各承担着不同的作用，笔者将逐一介绍阐述。

各模块在一次调用过程的作用域：

具体解读就是：

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

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

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

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

8、网络加速体系之IP策略调度

8.1 概述

IP策略调度的目的是减少 DNS 耗时，选择更优 IP。

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

PS：关于HttpDNS的技术文章可详读：

《全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等》

《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》

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

8.2 IP 选取及缓存汰换策略

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

1）服务端下发：根据单元化/运营商/就近接入/网络协议栈等维度，下发一组可用的 IP 列表。同时具备通过端侧跑马算法，生成最优的策略 IP；
2）端侧动态排序：根据端侧 IP 策略使用记录（成功&失败&耗时等维度）进行优先级排序，建连错误次数多的策略在排序优先级上进行降权操作，与之相对应的，建连成功率高性能好的策略优先级提高。

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

1）淘汰机制：同一 IP 在 5min 中连续失败 xx 次，进入禁用淘汰的情况；
2）更新机制：域名粒度携带 TTL（Time To Live）下发，超过 TTL 的域名进行异步更新，同时更新机制按照域名的优先级也拥有不同的模式。

8.3 新态势下的挑战及升级

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 成本太高。

这意味着现有网络存储结构不再具备唯一标识用户网络的能力，无法正常获取 BSSID 信息的这些设备上存在着策略混用，甚至跨运营商的问题，从而导致请求性能变慢/出现异常，线上约有 20%+的用户受潜在影响。

因此，对于端侧无法直接获取 BSSID 的设备，引入新的存储主 key，即用户无线接入点 AccessPoint 信息，流程涉及 AMDC 端到端协同升级，大致流程如下图所示。

WIFI 存储升级改造流程：

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

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

当现有协议结构无法满足日益复杂和精细的调度诉求，且无法在现有模型上持续长期迭代时，就需要对协议进行重构升级。

我们在移动网络虚拟化项目中切实遇到如上的问题，协议重构对于端上来说，是对整个存储数据模型的改变，这意味着升级新协议的用户可能无法继续使用旧版本存储策略，直接丢弃老协议存储是最简单有效的手段，但这会导致升级后一段时间内用户出现降级 LocalDNS 的问题，这对我们不能容忍。

重新实现一个协议不难，难的是如何确保新老协议平稳升级过渡，避免请求出现 LocalDNS 降级。

因此，方案的关键在于如何对新老协议做数据迁移，其中涉及升级链路和降级链路（如稳定性问题功能回退场景）。

AMDC 存储数据迁移：

9、网络加速体系之连接管理

连接管理的目的是更快建连，保障连接高可用。

9.1 连接建立

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

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

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

当淘宝作为 IPv6 示范性应用跑在最前面时，我们发现国内存在部分双栈网络 IPv6 质量差甚至不通的情况，Android 的舆情反馈尤为突出，原因在于 iOS 系统侧实现了 Happy Eyeballs 机制确保快速 rollback 回 IPv4 链路，而 Android 设备没有。

复合连接思路也因此来源于 IPv6 Happy Eyeballs 算法实现，详见RFC 6555。

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.

双栈复合连接：

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

1）双栈环境体验：从 IPv6 和 IPv4 中为用户选择一个最快的链接，且保证优先使用 IPv6；
2）减少后端压力：避免同时对两地址发起请求，造成网络破坏。

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

9.2 连接调度

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

具体是：

1）保活连接：需要时刻保证连接存活，随时可用，适用于上下行推拉结合的场景，如消息；
2）常规连接：不需要时刻保活，空闲及时回收减少资源占用，适用于仅主动上行调用的场景，如 RPC。

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

面向保活可用：

1）假连检测；
2）动态心跳。

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

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

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

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

PS：之前分享很多有关IM长接的心跳技术文章，技术原理都差不多，可以一并阅读：

《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》

《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》

《移动端IM实践：实现Android版微信的智能心跳机制》

《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》

《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》

《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》

《跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现》

《万字长文：手把手教你实现一套高效的IM长连接自适应心跳保活机制》

10、网络加速体系之请求管理

请求管理的目的是弹性超时控制，请求补偿恢复。

10.1 动态超时

具体是：

1）精细控制：在请求各个链路上，具有独立超时控制，每个阶段精细化控制，快速感知超时情况；
2）动态调配：针对不同域名请求/网络类型/不同质量的环境下动态超时时长处理。

请求各阶段超时控制：

10.2 多路竞争 & 择优选用

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

具体做法是：

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

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

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

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

H3 规模化过程中的体验保障：

11、网络加速体系之厂商加速

厂商加速的目的是拥抱原生，系统级调度加速。

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

以下是厂商能力融合的思考与决策。

作为淘宝终端网络基础设施，一直以来我们都专精于应用策略及协议上，致力如何更好的调度、管理连接/协议让请求更快。

随着国内厂商的发展，我们发现，脱离厂商的自研之路并不顺畅：

1）一方面，不同厂商的限制和表现异同常让我们对各厂商做一些 hack 和兼容性的事情；
2）另一面，用户的网络资源有限，手淘作为单一应用，能调配和控制的资源有限。

如何扩大我们的调度域得以让我们的应用内请求更好，是我们常在思考的事情。

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

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

厂商加速接入架构：

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

12、弱网优化指标定义

弱网优化指标定义的目的是明确弱网/卡顿请求。

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

网络请求 1s 法则：

弱网作为广义的概念，有多方面的原因。

一般来说我们把用户网络波动、信号强度弱、时延 RT 大称之为弱网环境。

对于用户来说，最大的体感就是各类页面打开慢、加载久、图片空窗等问题，请求耗时久/异常是直接原因。

我们从请求端到端全链路进行逐一分析，除了网络传输、后端服务处理耗时，也存在一些业务本地处理/回调等执行的耗时。

请求全链路阶段：

通过梳理完整请求的调用链路，我们在思考如何通过指标化的方式衡量出这部分对业务/用户体验有损的请求，在明确目前线上相关负向卡顿请求的规模的前提下，再进行进一步的优化及效果观测。

因此，基于用户/业务视角，将请求全链路阶段内出现异常报错、耗时长尾定义为卡顿请求。

具体是：

1）异常报错：失败的请求，无论何种原因失败，网络超时、服务端未返回等；
2）耗时长尾：响应超过 xx 秒未返回、没有结束的请求。

PS：关于弱网的技术文章可以深入详读：

《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》

《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》

《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》

《美图App的移动端DNS优化实践：HTTPS请求耗时减小近半》

《百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇》

《爱奇艺移动端网络优化实践分享：网络请求成功率优化篇》

《美团点评的移动端网络优化实践：大幅提升连接成功率、速度等》

《IM开发者的零基础通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》

13、弱网优化诊断体系

弱网优化诊断体系的目的是更快识别、定位各类复杂网络问题。

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

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

其中导致的原因很多，如用户路由器的配置、淘系域名被营商 IP 封禁、业务调用链路超时等。

为了更好的定位/分析各类网络类问题，我们针对移动互联网下用户网络类体验问题的复杂性，进一步建设 NPM 诊断技术体系，加强相关技术和数据的应用。

比如：

1）领域模型：用户体验问题的技术面穷举拆解、沉淀；

2）能力构建：诊断原子能力及工具链，运维提效；

3）规模应用：多维用户网络数据，IPv6/MTU/UDP 大盘。

多场景网络体验类问题诊断体系：

14、弱网优化技术实践

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

14.1 网络多通道

当请求没有响应/接收慢的情况下，一般会触发超时机制进行请求重放。

但在用户 WIFI 信号差&弱网环境下，我们反而要谨慎重试，一方面重试会加重系统上的负载，另一方面重试会导致请求重新开始，对弱网传输慢的情况不友好，反而加剧卡慢的情况。

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

系统官方文档：

14.2 规模化方案

除了常规的技术应用，因为涉及到用户在 WIFI 网络下的流量损耗，我们遵从用户隐私等合规前提下，提供多通道能力生效的用户提示和功能授权。

多通道整体规模化方案：

14.3 优化数据

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

14.4 原生 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 的实现是必经之路。

14.5 如何支持标准 HTTP/2？

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

因此，灵魂三问：

1）标准协议的完整实现，必然要加入人力投入开发，稳定性验证和上线是一个较长的周期，如何减少支持的成本？考虑引入稳定的能力实现，如 Okhttp；
2）稳定库引入必定会增加包大小，这对目前严控包大小的现状有较大冲突，如何解决？需尽可能不增加包大小的情况下支持；
3）既要考虑成本和稳定性验证等规模化问题，又要避免给手淘包大小过大的增幅。既要马儿跑，又要马儿不吃草。如何实现？

14.6 源码突破

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

Android 网络托管 Okhttp 代理：

进一步分析源代码，我们找到了 okhttp 在 android 系统侧的位置和包名，即com.android.okhttp下。

Android Okhttp 源码实现：

虽然是隐藏 API，仍可以通过反射的方式进行，为了更友好的编码实现，在编译期通过空实现依赖的方式进行显式的调用，同时确保在使用前对设备 okhttp 的环境及兼容性做好检查。

Android Okhttp crash：

灰度过程我们发现一些因为 Okhttp 导致的 IndexOutOfBoundsException 稳定性问题，bug 来源于特定场景下没有拿到证书列表且未对容器判空导致，详细记录在：https://github.com/square/okhttp/issues/4208。官方在版本 3.12.2+上修复，但 android 源码仍使用 2.x 版本导致无法修复。

okhttp 导致 IndexOutOfBoundsException 代码：