自 2013 年 ALLIN 无线到今天,已经走过 10 个年头,手淘终端统一网络库 AWCN (Ali Wireless Connection Network) 从淘内孵化,一路过来伴随着手淘业务的发展,经历集团 IPv6 战役、协议升级演进等,逐步沉淀为阿里集团终端网络通用解决方案,是兼具高性能、多协议、可容灾、可观测的终端网络基础统一设施。面对移动互联网络下复杂多变的网络环境,如何提供更稳定可靠的请求性能,保障用户的加载浏览体验、更好的支撑业务发展,是我们始终探索的命题。
本文将介绍淘宝 APP 统一网络库演进的过程,讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构,通过构建 NPM 弱网诊断感知能力,落地原生多通道技术/多协议择优调度手段,贴合厂商附能网络请求加速,实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡,为用户提供弱网更好、好网更优的 APP 加载浏览体验,支撑业务创造更多的可能性。
在介绍 AWCN 之前,笔者想先这里普及下 SDN 架构的概念。
SDN(Software Defined Network,软件定义网络) 是一种将网络资源抽象到虚拟化系统中的 IT 基础架构,SDN 将网络转发功能与网络控制功能分开,其目标是创建可集中管理和可编程的网络,核心理念是 希望应用软件可以参与对网络的控制管理,满足上层业务需求,简化使用和运维成本。有一个较为形象的类比,如果说现在的网络系统是功能机,系统和硬件出厂时就被捆绑在一起,那么 SDN 就是 Android 系统,可以在很多手机设备上安装&升级,同时还能安装更多更强大的手机 App(SDN 应用层部署)。
回到移动应用领域,我们的目标是搭建统一的终端网络解决方案,上层业务不需要关心内部的协议如何转发、请求超时降级等复杂逻辑,做到好用、易用、可观测、体验好。显然,这与传统 SDN 架构理念不谋而合。
因此,围绕以上理念和目标,我们进一步构建起南北向从监测到加速一体化的 MobileSDN 架构,以减少业务的接入/运维成本,提升用户的浏览体验。
从 MobileSDN 架构展开来,接下来简要介绍下各分层模块承担的角色与其中作用。
纵观行业内一些与之对标的移动网络框架,如腾讯维纳斯 WNS、微信 Mars、Chromium cronet、Square Okhttp 等,AWCN 和它们在一些思路上可以说是殊途同归,通过提供更优的 IP 策略调度、多协议连接管理策略及请求超时等控制加速请求,建设网络诊断、网络质量监控等手段加强网络可观测能力。
淘宝统一网络库作为基础组件在集团内被广泛应用,集团内涵盖千级以上规模应用支撑,包含且不限于手淘、闲鱼、优酷、天猫、Lazada、高德、UC浏览器、饿了么等 APP,同时通过阿里云 EMAS、友盟对三方应用开放接入,如海底捞/杭州银行等企业应用。
作为移动网络解决方案,网络请求的体验是重中之重,因此,笔者将重点讲述网络控制器如何围绕请求构建完整链路上的加速技术,介绍如何从节点调度/连接选择/请求管理/系统调度进行业务网络体验优化,确保请求在各类复杂网络状况下高可用。
前面提到,网络控制器是作为整体架构上的大脑,承担着请求端到端链路的调度和优化决策,相当于掌舵手和发动机的角色。一次完整的请求网络传输大致可以分为以下链路,即DNS->建连->发送数据->等待首包响应->接收数据,过程中 IP 策略调度、连接管理、请求管理及厂商全局调度加速子模块各承担着不同的作用,笔者将逐一介绍阐述。
众所周知,传统的 LocalDNS 方式存在各类隐患问题,如:解析慢/失败率高、更新不及时、域名劫持、缺少精准流量调度及容灾能力,AMDC(Ali Mobile Dispatch Center)是阿里自建的无线域名解析调度服务,在手淘和集团绝大多数应用中广泛应用。
依托 HTTPDNS 实现无线调度功能就够了吗?远没有那么理想化,如何在端侧处理好 IP 策略的选取/容灾/安全性/服务 QPS 压力等环节,都至关重要。
IP 选择机制上,基于服务下发+端侧动态排序的机制运行
缓存和汰换机制上,考虑到频繁 AMDC 调度带来服务压力、异步请求 AMDC 带来的生效率问题,端侧对策略进行了缓存,根据用户网络粒度进行独立存储,应用启动和网络事件切换情况下加载所需的策略记录;根据前面所提及的建连记录动态排序能力,自然也产生了对应的淘汰替换机制。
前面提及的端侧缓存策略基于用户网络粒度做独立存储,对于 WiFi 网络环境 BSSID 是端侧的标识主键,但随着系统升级带来的一系列用户权限收敛:
这意味着现有网络存储结构不再具备唯一标识用户网络的能力,无法正常获取 BSSID 信息的这些设备上存在着策略混用,甚至跨运营商的问题,从而导致请求性能变慢/出现异常,线上约有 20%+的用户受潜在影响。因此,对于端侧无法直接获取 BSSID 的设备,引入新的存储主 key,即用户无线接入点 AccessPoint 信息,流程涉及 AMDC 端到端协同升级,大致流程如图所示。
数据上,图片等 CDN 类请求平均耗时优化 4.439%,耗时分位 P90 优化1.932%,P99 优化 2.230%,P999 优化 2.668% 。
当现有协议结构无法满足日益复杂和精细的调度诉求,且无法在现有模型上持续长期迭代时,就需要对协议进行重构升级。我们在移动网络虚拟化项目中切实遇到如上的问题,协议重构对于端上来说,是对整个存储数据模型的改变,这意味着升级新协议的用户可能无法继续使用旧版本存储策略,直接丢弃老协议存储是最简单有效的手段,但这会导致升级后一段时间内用户出现降级 LocalDNS 的问题,这对我们不能容忍。
重新实现一个协议不难,难的是如何确保新老协议平稳升级过渡,避免请求出现 LocalDNS 降级。因此,方案的关键在于如何对新老协议做数据迁移,其中涉及升级链路和降级链路(如稳定性问题功能回退场景)。
除了常规的串行建连和并发建连方式,我们提供了热域名预建和复合连接的方式,应对各种复杂的场景。
当手淘作为 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.
复合连接的两个核心目标:
数据上,针对 MTOP 和图片请求,双栈情况下其建连性能平均耗时降低 22.12%,99 分位性能降低 60.19%,请求数据平均耗时降低了1.23%,P99 分位耗时降低 6.077%。
按照不同的通道应用场景,连接可以区分为两种形态,保活连接与常规连接。
针对建立好的连接,不同形态的维护管理方式也不同。
通过对连接的多场景可用性检测,增强连接质量的感知,当出现连接异常时能够快速的恢复重建。
检测的手段基本为心跳 PING 包方式,分位定时心跳(前后台间隔不同)、分场景心跳(切换前台、业务上行超时等)。
对于不需要主动下行推送的场景,建连时刻保持对于用户带宽和功耗存在一定影响,因此针对此类连接增加了空闲状态的检查,当发现建连超过一定时间没有数据包传输时会进行连接的关闭回收,以减少资源占用,释放有限带宽。
对于请求超时或慢的场景,AWCN 会通过多种方式进行择优选用和请求补偿,确保链路最优,保障体验:
以传输协议择优选用为例,对于 H3 协议在手淘的规模化过程用户体验不受损,AWCN 网络库建立起完善的择优选用和补偿兜底机制。
近年来,国内几家厂商前后对上层应用开放了系统级的网络优化能力,包括网络带宽调度、数据流加速、QoE 状态反馈、弱网预测、双 WiFi 聚合能力等,从系统侧调度提升请求性能。
作为淘宝终端网络基础设施,一直以来我们都专精于应用策略及协议上,致力如何更好的调度、管理连接/协议让请求更快。随着国内厂商的发展,我们发现,脱离厂商的自研之路并不顺畅:
因此我们选择拥抱厂商,通过系统赋予的调度加速能力,深度合作,为应用提供更好的网络体验。
为了屏蔽不同厂商之间的能力差异和接入方式不同,AWCN 提供厂商加速模块的通用能力抽象,通过运行期对不同设备和厂商能力的解决,动态组织支持的系统能力列表。
目前,我们已经和 OPPO 完成接入和上线工作,协同厂商侧紧锣密鼓的放量验证中。
过往我们基于网络请求 1s 法则作为优化的指标衡量,目前业务请求秒出率超过 95%,当网络体验进入深水区,弱网/长尾等卡顿负向请求成为我们关注和突破重点。
弱网作为广义的概念,有多方面的原因,一般来说我们把用户网络波动、信号强度弱、时延 RT 大称之为弱网环境。对于用户来说,最大的体感就是各类页面打开慢、加载久、图片空窗等问题,请求耗时久/异常是直接原因。我们从请求端到端全链路进行逐一分析,除了网络传输、后端服务处理耗时,也存在一些业务本地处理/回调等执行的耗时。
通过梳理完整请求的调用链路,我们在思考如何通过指标化的方式衡量出这部分对业务/用户体验有损的请求,在明确目前线上相关负向卡顿请求的规模的前提下,再进行进一步的优化及效果观测。
因此,基于用户/业务视角,将请求全链路阶段内出现异常报错、耗时长尾定义为卡顿请求:
经常有一些线上用户反馈网络类的舆情:
其中导致的原因很多,如用户路由器的配置、淘系域名被营商 IP 封禁、业务调用链路超时等,为了更好的定位/分析各类网络类问题, 我们针对移动互联网下用户网络类体验问题的复杂性,进一步建设 NPM 诊断技术体系,加强相关技术和数据的应用。
针对移动复杂网络环境,除了前面网络加速体系所提到的相关能力之外,这里笔者将重点对典型弱网靶向性优化技术展开。
当请求没有响应/接收慢的情况下,一般会触发超时机制进行请求重放。但在用户 WIFI 信号差&弱网环境下,我们反而要谨慎重试,一方面重试会加重系统上的负载,另一方面重试会导致请求重新开始,对弱网传输慢的情况不友好,反而加剧卡慢的情况。
因此,在寻求更友好的方式上,我们发现系统提供了一种多通道传输的能力,即允许设备在 WIFI 环境下将请求切换蜂窝网卡的能力,网络应用层可以利用该技术,减少请求的超时等一类错误,提升请求的成功率。
除了常规的技术应用,因为涉及到用户在 WIFI 网络下的流量损耗,我们遵从用户隐私等合规前提下,提供多通道能力生效的用户提示和功能授权。
目前多通道技术在手淘核心浏览链路上已规模化应用,严格按照AB 实验得出数据,双十一期间双端日对请求超时率减少 30%以上。
相对于 HTTP/1.1 协议,HTTP/2、HTTP/3 的协议性能优势不言而喻,HTTP/2 协议在手淘和集团内早已支持多年,HTTP/3 协议同样在持续规模扩量中,但目前手淘内仍然存有 10%左右 HTTP1.1 流量。
通过分析,主要有以下原因导致:
过往很多业务反馈,为什么域名在 chrome 浏览器上访问支持 HTTP/2,而手淘里是仍然是 HTTP/1.1 的原因就在于此。那么,如何在不需要服务端部署、不强依赖 AMDC 的前提下,让请求实现长连加速?标准 HTTP2 的实现是必经之路。
iOS 通过升级 URLSession 系统调用方式,可低成本的迁移到 H2/H3 协议上,但对于 Android 来说,系统侧提供的 HttpUrlconnection 仅支持到 HTTP/1.1 协议。因此,灵魂三问:
通过对系统源码的分析,我们发现 Android 系统 5.0 之后,系统 API HttpUrlconnection 底层已经通过 okhttp 进行托管实现,也就是说 Android 系统本身支持通过 okhttp 访问不需要额外引入三方库进行,只要找到可以 hook 的点。
进一步分析源代码,我们找到了 okhttp 在 android 系统侧的位置和包名,即com.android.okhttp
下。
虽然是隐藏 API,仍可以通过反射的方式进行,为了更友好的编码实现,在编译期通过空实现依赖的方式进行显式的调用,同时确保在使用前对设备 okhttp 的环境及兼容性做好检查。
灰度过程我们发现一些因为 Okhttp 导致的 IndexOutOfBoundsException
稳定性问题,bug 来源于特定场景下没有拿到证书列表且未对容器判空导致,详细记录在:https://github.com/square/okhttp/issues/4208。
官方在版本 3.12.2+上修复,但 android 源码仍使用 2.x 版本导致无法修复。
为了规避系统侧问题,我们摒弃 okhttp 提供异步调用的 api,改为同步调用+异常捕获+上层转异步的方式进行处理。
此外,针对不同应用,若存在三方 okhttp 依赖,会自动桥接到三方实现上,体验高版本 okhttp 的稳定性;对于手淘这种不依赖三方 okhttp 的应用,再桥接到系统版本实现。
标准 H2 升级率先在 Feeds 接口域名覆盖,农场整体舆情月环比下降 23%,请求耗时优化 21.4%,成功率提升 0.3pt。
截至目前,日改善卡顿请求(网络错误/耗时>x 秒) PV 10 亿+ ,达成全年目标 10 亿(统计口径严格按照 AB 实验桶对比计算),MOTP 请求超时率较去年 4 月优化了近50%。
对于移动网络体验的探索是无止境的,今年我们围绕弱网和体验加速做了一些工作,有些内容因为篇幅和侧重点考虑所以没有进一步展开讲述,后期再通过另外专题文章进行侧重讲解。
但即便如此,面对亿万用户各类复杂多变的环境,仍存在着加载慢、卡顿、空白的声音,作为淘宝和集团统一的终端基础网络设施,如何让用户浏览体验再更上一层楼,我们要做的还很多。
准确掌握用户的网络状态是一切手段的前提,以往我们围绕 NPM 搭建诊断体系,对端到端链路的连通性和质量进行检测,在实时性、准确度和可用性仍有提升空间。
针对不同网络类型和质量的环境,我们希望建设更适应性更动态智能的调度能力,基于不同场景做更适合有效的加速能力应用,一成不变,固化的优化策略无法在所有的环境下发挥更优的效果。前面提到,当我们能够更精准感知,甚至预测用户网络的变化,我们能够做的事情就更多。
我们发现手淘多业务在弱网交互下表现不一,存在着无法刷新重试、空白无提示、阻塞无法操作等问题,因此除了技术侧的能力强化,会进一步联合多方沉淀弱网体验规范,协同业务优化弱网场景下的表现与体验、提升交互性和可恢复性,并改善用户在弱网下的预期和感受。
RFC 6555: https://www.rfc-editor.org/rfc/rfc6555