引言
自 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 架构，以减少业务的接入/运维成本，提升用户的浏览体验。
图：AWCN Mobile-SDN 架构
从 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 中网络控制器、网络性能管理两块部分承担角色相近。
▐ 规模总览
淘宝统一网络库作为基础组件在集团内被广泛应用，集团内涵盖千级以上规模应用支撑，包含且不限于手淘、闲鱼、优酷、天猫、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 降级。因此，方案的关键在于如何对新老协议做数据迁移，其中涉及升级链路和降级链路(如稳定性问题功能回退场景)。
图：AMDC 存储数据迁移
▐ 连接管理：更快建连，保障连接高可用
- 连接建立
除了常规的串行建连和并发建连方式，我们提供了热域名预建和复合连接的方式，应对各种复杂的场景。
热域名预建机制：启动场景下的关键请求加速
图：热域名预建
复合连接机制：IPv6 规模化背景下的体验保障
当淘宝作为 IPv6 示范性应用跑在最前面时，我们发现国内存在部分双栈网络 IPv6 质量差甚至不通的情况，Android 的舆情反馈尤为突出，原因在于 iOS 系统侧实现了 Happy Eyeballs 机制确保快速 rollback 回 IPv4 链路，而 Android 设备没有。
复合连接思路也因此来源于 IPv6 Happy Eyeballs 算法实现，详见RFC 6555[1]。
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.
复合连接的两个核心目标：
双栈环境体验：从 IPv6 和 IPv4 中为用户选择一个最快的链接，且保证优先使用 IPv6减少后端压力：避免同时对两地址发起请求，造成网络破坏；
数据上，针对 MTOP 和图片请求，双栈情况下其建连性能平均耗时降低 22.12%，99 分位性能降低60.19%，请求数据平均耗时降低1.23%，P99 分位耗时降低6.077%。
- 连接调度
按照不同的通道应用场景，连接可以区分为两种形态，保活连接与常规连接。
保活连接：需要时刻保证连接存活，随时可用，适用于上下行推拉结合的场景，如消息；常规连接：不需要时刻保活，空闲及时回收减少资源占用，适用于仅主动上行调用的场景，如 RPC。
针对建立好的连接，不同形态的维护管理方式也不同。
面向保活可用：假连检测，动态心跳
通过对连接的多场景可用性检测，增强连接质量的感知，当出现连接异常时能够快速的恢复重建。
检测的手段基本为心跳 PING 包方式，分位定时心跳（前后台间隔不同）、分场景心跳（切换前台、业务上行超时等）。
面向空闲回收：闲时状态检查，及时关闭
对于不需要主动下行推送的场景，建连时刻保持对于用户带宽和功耗存在一定影响，因此针对此类连接增加了空闲状态的检查，当发现建连超过一定时间没有数据包传输时会进行连接的关闭回收，以减少资源占用，释放有限带宽。
▐ 请求管理：弹性超时控制，请求补偿恢复
- 动态超时
精细控制：在请求各个链路上，具有独立超时控制，每个阶段精细化控制，快速感知超时情况；动态调配：针对 不同域名请求/网络类型/不同质量 的环境下动态超时时长处理。
- 多路竞争&择优选用
对于请求超时或慢的场景，AWCN 会通过多种方式进行择优选用和请求补偿，确保链路最优，保障体验：
传输协议：运营商对于 HTTP/3（UDP）的网络质量保证远不及 TCP，常常遇到各类 UDP 穿透性、请求超时等问题，因此必要时需快速决策，切回 HTTP/2、HTTP/1.1 的 TCP 传输链路；
底层框架：自研传输库(TNET)带来的好处是协议的自建和调优，但也因此导致协议非标(如 HTTP/2+SSSL 私有加密协议)，运营商拦截丢包、端到端链路稳定性等问题，必要时决策回退至系统原生库；
网络通道：以往对于用户网络不通导致的问题，优化的手段有限，但随着系统开放多通道选择的能力之后，上层也拥有了切换网络通道的能力，当检测 WiFi 不通环境下，会将请求切换至蜂窝网络通道恢复。
以传输协议择优选用为例，对于 H3 协议在手淘的规模化过程用户体验不受损，AWCN 网络库建立起完善的择优选用和补偿兜底机制。
图：H3 规模化过程中的体验保障
▐ 厂商加速：拥抱原生，系统级调度加速
近年来，国内几家厂商前后对上层应用开放了系统级的网络优化能力，包括网络带宽调度、数据流加速、QoE 状态反馈、弱网预测、双 WiFi 聚合能力等，从系统侧调度提升请求性能。
- 厂商能力融合的思考与决策
作为淘宝终端网络基础设施，一直以来我们都专精于应用策略及协议上，致力如何更好的调度、管理连接/协议让请求更快。随着国内厂商的发展，我们发现，脱离厂商的自研之路并不顺畅：
- 一方面，不同厂商的限制和表现异同常让我们对各厂商做一些 hack 和兼容性的事情；
- 另一方面，用户的网络资源有限，手淘作为单一应用，能调配和控制的资源有限。如何扩大我们的调度域得以让我们的应用内请求更好，是我们常在思考的事情。
因此我们选择拥抱厂商，通过系统赋予的调度加速能力，深度合作，为应用提供更好的网络体验。
为了屏蔽不同厂商之间的能力差异和接入方式不同，AWCN 提供厂商加速模块的通用能力抽象，通过运行期对不同设备和厂商能力的解决，动态组织支持的系统能力列表。
图：厂商加速接入架构
目前，我们已经和 OPPO 完成接入和上线工作，协同厂商侧紧锣密鼓的放量验证中。
手淘弱网破障实践
▐ 指标定义：明确弱网/卡顿请求
过往我们基于网络请求 1s 法则作为优化的指标衡量，目前业务请求秒出率超过 95%，当网络体验进入深水区，弱网/长尾等卡顿负向请求成为我们关注和突破重点。
图：网络请求 1s 法则
弱网作为广义的概念，有多方面的原因，一般来说我们把用户网络波动、信号强度弱、时延 RT 大称之为弱网环境。对于用户来说，最大的体感就是各类页面打开慢、加载久、图片空窗等问题，请求耗时久/异常是直接原因。我们从请求端到端全链路进行逐一分析，除了网络传输、后端服务处理耗时，也存在一些业务本地处理/回调等执行的耗时。
通过梳理完整请求的调用链路，我们在思考如何通过指标化的方式衡量出这部分对业务/用户体验有损的请求，在明确目前线上相关负向卡顿请求的规模的前提下，再进行进一步的优化及效果观测。
因此，基于用户/业务视角，将请求全链路阶段内出现异常报错、耗时长尾定义为卡顿请求：异常报错：失败的请求，无论何种原因失败，网络超时、服务端未返回等；耗时长尾：响应超过 xx 秒未返回、没有结束的请求。
▐ 诊断体系：更快识别、定位各类复杂网络问题
经常有一些线上用户反馈网络类的舆情：
- 为什么 WIFI 下访问慢，切换到 4G 网络就恢复了？
- 我的网络没问题，为什么手淘等淘系应用加载慢，其他 APP 正常？
- 为什么 xx 页面加载很慢，其他页面没问题？
- ......
其中导致的原因很多，如用户路由器的配置、淘系域名被营商 IP 封禁、业务调用链路超时等，为了更好的定位/分析各类网络类问题， 我们针对移动互联网下用户网络类体验问题的复杂性，进一步建设 NPM 诊断技术体系，加强相关技术和数据的应用。
领域模型：用户体验问题的技术面穷举拆解、沉淀；能力构建：诊断原子能力及工具链，运维提效；规模应用：多维用户网络数据，IPv6/MTU/UDP 大盘。
▐ 弱网技术：复杂网络下的网络体验
针对移动复杂网络环境，除了前面网络加速体系所提到的相关能力之外，这里笔者将重点对典型弱网靶向性优化技术展开。
- 网络多通道：手淘规模化应用
当请求没有响应/接收慢的情况下，一般会触发超时机制进行请求重放。但在用户 WIFI 信号差&弱网环境下，我们反而要谨慎重试，一方面重试会加重系统上的负载，另一方面重试会导致请求重新开始，对弱网传输慢的情况不友好，反而加剧卡慢的情况。
因此，在寻求更友好的方式上，我们发现系统提供了一种多通道传输的能力，即允许设备在 WIFI 环境下将请求切换蜂窝网卡的能力，网络应用层可以利用该技术，减少请求的超时等一类错误，提升请求的成功率。
图：系统官方文档
规模化方案
除了常规的技术应用，因为涉及到用户在 WIFI 网络下的流量损耗，我们遵从用户隐私等合规前提下，提供多通道能力生效的用户提示和功能授权。
图：多通道整体规模化方案
优化数据
目前多通道技术在手淘核心浏览链路上已规模化应用，严格按照AB 实验得出数据，双十一期间双端日对请求超时率减少 30%以上。
- 原生 HTTP/2：突破系统限制，实现 H2 协议支持
相对于 HTTP/1.1 协议，HTTP/2、HTTP/3 的协议性能优势不言而喻，HTTP/2 协议在手淘和集团内早已支持多年，HTTP/3 协议同样在持续规模扩量中，但目前淘宝内仍然存有 10%左右 HTTP1.1 流量。
通过分析，主要有以下原因导致：
- HTTP/2 协议非标准化实现，加密方式为私有 slight-ssl，域名支持需服务端部署，未明确知晓是否支持的域名只能走 HTTP/1.1 协议；
- 鉴于非标的影响，请求链路上需要强依赖 AMDC，必须通过 AMDC 配置明确支持 h2+sssl 方式的域名下发后才能支持；
- 非标协议的兼容性存在小概率问题，个别运营商针对非标协议会进行劫持处理导致请求失败降级到短连。
过往很多业务反馈，为什么域名在 chrome 浏览器上访问支持 HTTP/2，而手淘里是仍然是 HTTP/1.1 的原因就在于此。那么，如何在不需要服务端部署、不强依赖 AMDC 的前提下，让请求实现长连加速？标准 HTTP2 的实现是必经之路。
如何支持标准 HTTP/2？
iOS 通过升级 URLSession 系统调用方式，可低成本的迁移到 H2/H3 协议上，但对于 Android 来说，系统侧提供的 HttpUrlconnection 仅支持到 HTTP/1.1 协议。因此，灵魂三问：
- 标准协议的完整实现，必然要加入人力投入开发，稳定性验证和上线是一个较长的周期，如何减少支持的成本？考虑引入稳定的能力实现，如 Okhttp。
- 稳定库引入必定会增加包大小，这对目前严控包大小的现状有较大冲突，如何解决？需尽可能不增加包大小的情况下支持。
- 既要考虑成本和稳定性验证等规模化问题，又要避免给手淘包大小过大的增幅。既要马儿跑，又要马儿不吃草。如何实现？
源码突破
通过对系统源码的分析，我们发现 Android 系统 5.0 之后，系统 API HttpUrlconnection 底层已经通过 okhttp 进行托管实现，也就是说 Android 系统本身支持通过 okhttp 访问不需要额外引入三方库进行，只要找到可以 hook 的点。
图：Android 网络托管 Okhttp 代理
进一步分析源代码，我们找到了 okhttp 在 android 系统侧的位置和包名，即com.android.okhttp下。
图：Android Okhttp 源码实现
虽然是隐藏 API，仍可以通过反射的方式进行，为了更友好的编码实现，在编译期通过空实现依赖的方式进行显式的调用，同时确保在使用前对设备 okhttp 的环境及兼容性做好检查。
灰度过程我们发现一些因为 Okhttp 导致的 IndexOutOfBoundsException稳定性问题，bug 来源于特定场景下没有拿到证书列表且未对容器判空导致，详细记录在：https://github.com/square/okhttp/issues/4208。官方在版本 3.12.2+上修复，但 android 源码仍使用 2.x 版本导致无法修复。
图：okhttp 导致 IndexOutOfBoundsException 代码
为了规避系统侧问题，我们摒弃 okhttp 提供异步调用的 api，改为同步调用+异常捕获+上层转异步的方式进行处理。
此外，针对不同应用，若存在三方 okhttp 依赖，会自动桥接到三方实现上，体验高版本 okhttp 的稳定性；对于手淘这种不依赖三方 okhttp 的应用，再桥接到系统版本实现。
优化数据：标准 H2 升级率先在 Feeds 接口域名覆盖，农场整体舆情月环比下降 23%，请求耗时优化 21.4%，成功率提升 0.3pt。
▐ 小结
截至目前，日改善卡顿请求(网络错误/耗时>x 秒) PV 10 亿+ ，达成全年目标 10 亿(统计口径严格按照 AB 实验桶对比计算)，MOTP 请求超时率较去年 4 月优化了近50%。
后续方向与展望
对于移动网络体验的探索是无止境的，今年我们围绕弱网和体验加速做了一些工作，有些内容因为篇幅和侧重点考虑所以没有进一步展开讲述，后期再通过另外专题文章进行侧重讲解。
但即便如此，面对亿万用户各类复杂多变的环境，仍存在着加载慢、卡顿、空白的声音，作为淘宝和集团统一的终端基础网络设施，如何让用户浏览体验再更上一层楼，我们要做的还很多。
▐ 更精准的网络状态感知
准确掌握用户的网络状态是一切手段的前提，以往我们围绕 NPM 搭建诊断体系，对端到端链路的连通性和质量进行检测，在实时性、准确度和可用性仍有提升空间。
结合厂商系统侧更精准可靠的网络质量反馈：依托提供 QoE 网络质量能力，提供更实时的 WiFi/蜂窝网络信号质量和强度反馈;
提供用户更友好的网络感知手段：当用户出现“潜在”的网络问题，我们希望大部分情况用户可以自行知道哪里出问题、怎么解决。
图：用户网络诊断感知
▐ 更动态智能的调度加速能力
针对不同网络类型和质量的环境，我们希望建设更适应性更动态智能的调度能力，基于不同场景做更适合有效的加速能力应用，一成不变，固化的优化策略无法在所有的环境下发挥更优的效果。前面提到，当我们能够更精准感知，甚至预测用户网络的变化，我们能够做的事情就更多。
图：预测弱网环境的动态调优
▐ 更一致的弱网交互体验
我们发现淘宝多业务在弱网交互下表现不一，存在着无法刷新重试、空白无提示、阻塞无法操作等问题，因此除了技术侧的能力强化，会进一步联合多方沉淀弱网体验规范，协同业务优化弱网场景下的表现与体验、提升交互性和可恢复性，并改善用户在弱网下的预期和感受。
图：淘宝弱网交互表现不一
参考资料
[1]RFC 6555: https://www.rfc-editor.org/rfc/rfc6555
团队介绍
