弱网优化在支付宝的深度实践 | mPaaS 线下沙龙 CodeDay#1 分享实录

做者：凝睇，蚂蚁金服移动开发平台 mPaaS 技术专家。目前负责蚂蚁金服移动开发平台 mPaaS 服务端组件体系优化与架构设计。 内容采编自 CodeDay#1 杭州站现场分享，主题是《弱网优化在支付宝的深度实践》。

现场视频： tech.antfin.com/activities/…

0. 背景

随着 PC 端场景愈来愈重，其发展已日趋饱和，而随着智能移动设备的兴起，移动互联网呈现出了井喷式发展形态。相比于 PC 互联网时代的有线网络，无线网络通讯的稳定性却有着巨大的差异；所以，开发者总会面对用户反馈诸如 App “不通”、“不快”等各类“网络问题”。

做为国民级 App，支付宝须要服务在各类复杂的移动网络环境下的亿级用户，于是在网络优化的道路上也是一走就不少年，本文的目的便是将咱们遇到的问题作一个总结，并把在一些实际可行的优化和实践经验分享给各位开发者，指望能从某个角度能给各开发者提供一些灵感以帮助你们建设更好的移动 App。

问题归总

网络问题，从用户反馈过来的表象可分为“不通”或者“不快”，这两词虽然只有一字之差，但本质却彻底不一样：

• “不通”，通常为服务可用性的问题，好比：由服务器宕机引发的“网络异常”、“操做无响应”、“白屏”或者“彻底收不到消息”等问题；
• “不快”，则通常为真实的性能问题，好比：“转菊花”、“操做响应慢”、“消息接受慢”等。

对于“不通”的问题，主要缘由为客户端真实网络确实不可用或者服务端系统稳定性不足致使，从优化的角度，更偏向于优化服务端架构设计或者从交互角度让客户端在异常状况如何更友好的呈现给用户，而对于“不快”的问题，咱们则可从技术上作更多的优化和改进，于是也是本文的重点。

问题来源

首先咱们来看一下移动网络的链路：

1. 移动端经过无线网络协议，从运营商的基站得到无线链路分配用以知足跟网络进行通信；
2. 运营商的网络基站、控制器，给移动终端进行信号的分配以完成与终端的链接和交互；
3. 得到无线链路后，会进行网络附着、加密、鉴权，核心网络则会检查终端是否能够链接在这个网络上，是否有开通套餐，是否是处于漫游等。目前核心网络有 SGSN 和 GGSN，这一步主要目的是完成无线网络协议和有线以太网的协议的转换；
4. SGSN 和 GGSN 核心网络会根据终端的状况进行 APN 的选择、IP 分配、并启动计费；
5. 以后才是咱们所接触的传统网络的步骤：DNS 查询、响应，TCP 连接，HTTP GET 请求，RTTP RESPONSE 200，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA 和 UI 展示等等。

因而可知，移动网络自己链路上就相较有线网络复杂不少，同时终端由于其强烈的“移动”属性，在不少场景下网络状况确实不如人意，好比在地下室、电梯、偏远地区等等，总会带来带宽不足、频繁丢包、高延迟的问题。与此同时，在进入后端服务器应用网络以后还有一层层的防火墙、路由器、负载均衡、IDC 分机房部署。 再到客户端应用程序、服务端的系统设计、接口设计等问题也会极大的影响到在弱网环境下用户的体验，如：

1. 客户端启动时各类并发 RPC 请求致使网络或者线程拥塞
2. 服务端流程设计冗长，慢 SQL 等；
3. RPC 接口模型设计沉重，请求或相应模型大量冗余数据；
4. 静态未压缩，或者未分网络环境，不分用户使用场景进行资源拉取致使首屏堵塞，迟迟未响应等。

除此以外，传统网络协议在流程设计上限定，若是移动 App 自身没有进行改良和优化，在弱网环境下也可能会成为绊脚石。

如：

1. TCP 传输过程当中为防止过多的数据注入到网络中，会先探测一下网络的拥塞程度，会有由小到大逐渐增长拥塞窗口的大小；
2. 在绝大部分 App 中，均须要进行SSL链路加密，所以须要耗费 2 个 RTT 来作证书的交换；
3. 除此以外，不一样运营商、在不一样地区对于 DNS 域名解析的支持能力也有所不一样，绝大部分须要 1 秒以上，在某些状况下甚至可能超过7秒，而且此处也须要消耗 1 个 RTT。
4. 经过分析上面的几个可能产生问题的根源，咱们基本就能够知道在网络链路上、客户端&服务端流程设计上、以及网络协议上本都作一些事情来达到优化的效果。

1. 优化指标

作优化必定须要有可量化的指标来衡量和记录咱们的劳动成果和效果，所以，能够主要从如下几个指标入手：

1. 建连成功率：可经过客户端端埋点的手段进行开展，并经过MAS的数据采集和数据分析等功能来记录、统计、分析；
2. 建连时⻓（耗时）：依然经过客户端端埋点的方式，来记录、统计、分析耗时信息；
3. 链接保持时长：此处能够在服务端和客户端分别进行实时，主要用以评估终端 TCP 链接的稳定性；
4. 移动网关 RPC API 方法的调用成功率（错误率）、包大小、耗时等；
5. MSS、MPS 数据同步推送成功率、耗时、包大小等。

其中各类指标均须要区分网络类型（WiFi、4G、3G等等）、机型等参数进行分别监控，至于其余的数据则可根据不一样场景继续延伸挖掘，并可针对诸如“当面付”等重点业务作专题分析。

2. 优化方向

在前面的章节已经有提到，根据移动网络的特性，咱们能够分别从网络链路上，客户端&服务端流程设计以及网络协议上下手，在实际的操做过程当中，则经过如下几方面开展：

1. 网络服务架构升级：主要组成部分为AccGW网络接入网关、MGS移动API网关、MPS消息推送服务、MSS数据同步服务以及MDC移动调度服务。
2. 定制网络协议：MMTP（蚂蚁移动传输协议）+MTLS（蚂蚁移动安全传输协议）；
3. 网络数据处理：HybridPB 序列化、gzip、zstd、hpack 等压缩方式升级；
4. 链接策略细化：建（断）连控制、链接保持、智能心跳、假链接侦测等；
5. 持续业务治理：接口设计优化、静态资源优化、监控体系建设等。

网络服务架构升级

如图中所示，客户端可拆分为主进程和 Service 进程，主进程主要承载具体的功能组件和业务模块，Service 进程则主要负责与服务端进行网络协议和网络数据对接，并负责进程保活。

在穿过公网、LVS、以及一系列防火墙、路由器以后，进入后端具体应用可直接感知 SLB，在这以后才正式进入咱们可操做和优化的后端架构：AccGW、ApiGW(MGS)、SyncGW(MSS)、PushGW(MPS)，并由 LinkMng 来统一管理终端的链接信息和链接生命周期，移动调度这使用 MDC 配合 HTTPDNS 来完成。

AccGW

接入网关目前由 Spanner 来承接：

Spanner 是蚂蚁集团基于 Nginx 二次开发的一套事件驱动型系统，其主要功能大体可分为：

1. 进行 SSL 卸载：可支持标准的 TLS1.0、1.一、1.二、1.3 以及 mtls；
2. 配置管控：可经过控制台动态的管理配置项、上线、下线，并提供一系列的API可供后端系统动态调用；
3. 动态 UPSTREAM 路由：因须要对接不一样的基于 mmtp 协议的后端基础组件，所以须要区分数据包渠道类型（upstream 路由到哪一个基础组件），并可实时、动态的挂载和下线后端服务器；
4. MMTP 协议处理：包括数据的序列化、反序列化、压缩、解压缩；
5. 链接保持：须要挂载全部终端的 TCP 链接，并经过智能心跳维持住链接；
6. 数据埋点：可在最上层进行数据包的埋点记录，并用户监控体系为后续流量管控及网络分析提供一手数据。
7. 流量管控：其核心目的是在大促场景下，可在最上层将业务流量进行限制和管理，以确保下游系统能安全存活。

MSS 消息同步服务

在基础服务架构升级中，MSS（SYNC）的出现一样扮演了及其重要的角色：

在以前的文章中已经有介绍 MSS 是经过一个安全的数据通道 TCP+SSL，及时、准确、有序地将服务器端的业务数据，主动的同步到客户端 App，其定位是一个客户端与服务端之间的消息中间件。

MSS 主体思想是：相似 MySQL 数据库 binlog 原理的基础上定义了一个 oplog 概念，服务器和客户端 SDK 之间传递的最小数据单元被称为一个 oplog，每当业务须要同步一个数据变动到指定的用户/设备的时候，业务调用MSS服务端的 SyncData 接口，MSS 会将业务须要同步的数据变动包装为一个 oplog 持久化到数据库，而后在客户端在线的时候把oplog 推送给客户端，若是当前则当即触发推送。每一个 oplog 拥有一个惟一的 oplog id，oplog ID 在肯定的用户、肯定的业务范围内保证惟一而且单调递增（按调用顺序）。MSS 按照 oplog ID 从小到大的顺序把每一条 oplog 都推送到客户端。经过 ACK 机制服务端和客户端均会记录客户端已同步数据的最大 oplog ID（亦可理解为数据版本），后续产生新数据时进行差量计算和差量同步。

经过 MSS 能够给客户端带来几大好处：

1. 业务合并：一次初始化命令，推送多业务数据，减小冗余的请求数据；
2. 增量推送：增量数据相对较少，减小冗余数据的传输，下降网络成本；
3. 减小请求：没有增量数据时，将不会消耗请求成本，减小了无谓的请求；
4. 提升时效：当服务端发生数据变化，能够直接推送至客户端，无需等待客户端请求；
5. 提高体验：在渲染界面以前，数据已经到位，下降了用户等待的时间；

这些优点可很是有效的减小客户端 RPC 接口交互次数，减小须要传输的业务数据内容，并因为其主动推送的特性又可极大的提高用户的体验效果。

移动调度

在移动调度的升级上，采用的是 MDC 配合 HTTPDNS，传统的 DNS 有几大弊端：

1. 终端网络请求须要消耗 1 个 RTT 先进行域名解析，须要额外的网络和时间开支。
2. 运营商 DNS 良莠不齐：不一样的地区、环境、不一样的运营商 DNS 解析效率彻底不一样，快则1秒，满则 7~8 秒甚至因为缓存等问题解析失败。
3. 目前大型 App 均须要进行多机房、多中心部署，传统 DNS 没法在客户端直接路由到指定机房或中心，而且因为缓存等问题容灾效率也不高。
4. 没法知足自定义的调度需求：灰度、白名单、特殊业务场景指定到具体机房、中心或指定到某一个台服务器上。
5. 存在 DNS 劫持问题。

经过 MDC 配合 HTTPDNS 则能够完美的解决以上问题：客户端经过独立的网络请求到服务器拉取可用的 IP 列表，IP 列表信息中已包含了服务端的机房、中心以及白名单相关信息，客户端在获取到 IP 列表以后既可根据当前用户（设备）信息在后面的网络请求中直接路由到对应的机房、中心、某台具体服务器或者海外 POP 加速站点。IP 列表可长期的保存在客户端中，后续的请求中均只须要经过本地 DNS 解析便可以完成 IP 映射，用以节省 1 次 RTT 请求时间，也能够有效的防范 DNS 域名劫持，于此同时可结合 MSS 等服务来指定实际更新策略来确保第一时间更新 IP 列表。此外，客户端也可经过按期检测、定制质量模型等方式来计算、评估获取最优 IP 地址。

协议优化

• MMTP

MMTP：全称蚂蚁移动传输协议，是二进制的 TLV(类型、⻓度、值)结构的协议；是并驾于 HTTP、HTTP2.0、spdy 的私有化传输协议。

其主要优势为：

1. 打包解包效率高，省内存；
2. 可多路复用，并具备极高的扩展性；
3. 因为高度的自定义，引入了诸多的特性，如：数据包重发、Sequence 检测假链接、柔性断链并可作到精细管控等。

• MTLS

MTLS：全称蚂蚁移动安全传输协议是基于 TLS1.3 扩展的安全传输协议。

TLS1.3 可经过证书 cache、session Ticket 等机制支持 1RTT 握手，加密套件则可选用ECDHE，根据有关数据验证，160 比特 ECC 密钥和 1024 比特的 RSA 密钥的安全性至关，小数据量在速度、效率、带宽、存储上都会体现出明显优点，此外在某些特殊功能上，甚至可使用 0RTT 的方式直接完成数据交互。

数据优化

1. 序列化方式：目前在蚂蚁体现内已基本普及了 protobuf。Protobuf 全称 Google Protocol Buffer，是一种轻便高效的结构化数据存储格式，主要知足结构化数据串行化，或者说序列化。它很适合作数据存储或 RPC 数据交换格式。可用于通信协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。

   而经过 protobuf 官方工具生成的客户端文件较大，可能会引发安装包过大，函数方法过多等问题，蚂蚁内部在此基础上又从新定制了生产工具，最终产出物被定义成 HybridPB。

2. ZSTD 压缩算法：在上一代产品中业务数据 body 主要使用的 gzip 压缩，而在目前的产品中则主要采用了 ZSTD 压缩：

   ZSTD 全称 Zstandard，是一款免费的开源，快速实时数据压缩程序，具备更好的压缩比，由 Facebook 开发。 它是用 C 语言编写的无损压缩算法 （在 Java 中有一个从新实现） ， 所以它是一个本地 Linux 程序。在移动网络中，它能够须要将压缩速度交换为更高的压缩比率（压缩速度与压缩比率的权衡能够经过小增量来配置），它具备小数据压缩的特殊模式，称为字典压缩，能够从任何提供的样本集中构建字典。更高的压缩比意味着更小的网络传输成本消耗，而这也是在移动端被采用的主要缘由之一。

3. HPACK 压缩算法：网络协议上，压缩算法目前采用的是 HPACK。简单的说，HPACK 使用 2 个索引表（静态索引表和动态索引表）来把头部映射到索引值，对不存在的头部使用huffman编码，并动态缓存到索引，从而达到压缩头部的效果。

链接策略

TCP 建连行为由移动终端发起：目前主要在终端启动时、先后台切换时、网络超时、链接错误或者网络类型切换时会发生建连动做，而建联的策略上主要由如下几种：

1. 并行建连：当客户端串行建连失败必定次数后、则会进入并发建联模式，期目的是为了并发争取信道，增长创建成功率。
2. 短频建连：在弱网状况下可加快创建链接的频率，以踩中一闪而过的可用间隙，第一个连接还没建上，也可开始第二个。
3. 柔性断连：因并发建联引发，某些场景业务可作重连重发，所以对可能并存的多条链接，须要作延迟回收，以等待在这条即将被回收的链接上的可能存在的回包。
4. 长短链接并存：在某些场景下，由于tcp没法长久保持，则可经过http短链接来提升请求瞬间冲击能力，快速完成业务请求，并释放资源。

对于链接的保持，传统的作法就是心跳，心跳包可由客户端发起，也可由服务端发起。因为移动端终端的运营商、手机厂商等各类定制、非定制的因素干扰，对于 TCP 链接保持能力上各不相同，所以恒定的心跳时间未必能知足各类状况，过快、过慢都会带来问题，所以支付宝采用的是动态心跳的方式来维持链接，客户端经过必定的质量模型来评估某一心跳周期的链接维持质量，并在过程当中逐步增长或减小心跳周期，在到一个最优的模型质量以后记录下最优心跳时间，并用改周期时间来维持以后的一段时间。

链接超时控制上：除了传统的业务请求超时和建连超时，还引入了包 sequence 概念，每一个上行包发送时，加入递增序号，服务端收到带序的包后，若是有下行包，就把当时收到的最大序号返回给客户端。客户端收到后，既可确认全部小于等于这个序号的上行包都已被服务端接受；若是某个上行包的序号在一段时间尚未收到确认，可怀疑出现“假链接”，须要进入回收评估阶段，服务端下行包亦然。

3. 业务治理：持久战

在上面的内容中，咱们一直在基础服务上作文章，而实际的生产过程当中，业务接口的设计也极大的影响着用户的真实网络体验，而且因为业务在持续发展，人员也持续的迭代，对于优化的规范和设计的思路上并不是都在同一水平上，所以业务治理绝对是一个须要持续坚持不懈战斗的过程。在业务治理过程当中也可总结为几个方面：

1. 接口设计优化：主要为接口数据模型设计须要在知足业务功能的基础尽可能精简、减小没必要要的数据传输；客户端并发请求优化，区分优先级，让客户端在合适的场景作合适的事情，千万不可大量并发争抢资源而影响用户核心流程的使用，服务端接口流程优化，好比采用异步、缓存、减小慢 SQL 等；
2. 资源拉取策略优化：使用更快捷的图片格式、在不一样网络环境使用不一样缩放程度的图片、资源合并、图片压缩等；
3. 减小数据量、数据包大小：推广各业务方接入例如 PB 等更高效的序列化方式，推荐业务接入 MSS，SYNC 服务，经过增量推送的方式减小客户端请求次数与服务端返回数据的大小；
4. 监控体系持续完善：全链路数据打通，问题剖析一杆子到底；多维评价模型，监控预警，数据化研发；作到管控决策有依据，结果有数据，推进有根据；
5. 大户专项治理：针对重大业务、核心业务，网络同窗直接深刻业务流程设计，协助业务方发现问题并推进不断改善。

最后： 锲而不舍。不管是性能优化、网络优化，都是一个长期的过程，这也将伴随着整个终端和服务端的生命周期，所以锲而不舍的优化改进才是重中之重。

*注（更多详细内容）：

• 进一步学习「protobuf」：

  developers.google.com/protocol-bu…

• 进一步学习「ZSTD」：

  facebook.github.io/zstd/

• 进一步学习「HPACK」：

  www.rfc-editor.org/rfc/pdfrfc/…

| 移动开发平台 mPaaS 三款组件重磅上线蚂蚁金服开放平台：

• 公测期，欢迎体验试用。支付宝扫码或登陆开放平台

往期阅读

《开篇 | 蚂蚁金服 mPaaS 服务端核心组件体系概述》

《蚂蚁金服 mPaaS 服务端核心组件体系概述：移动 API 网关 MGS》

《蚂蚁金服 mPaaS 服务端核心组件：亿级并发下的移动端到端网络接入架构解析》

《支付宝 App 构建优化解析：经过安装包重排布优化 Android 端启动性能》

《支付宝 App 构建优化解析：Android 包大小极致压缩》

关注咱们公众号，得到第一手 mPaaS 技术实践干货

钉钉群：经过钉钉搜索群号“23124039”

期待你的加入～