本文由得物技术厉飞雨、GavinX分享，原题“得物App白屏优化系列｜网络篇”，下文进行了排版和内容优化。

1、引言

图片加载作为重中之重的App体验指标，端侧的白屏问题则是其中最为严重、也是最为常见的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下，图片无法完成加载是多么糟糕的体验。

如上图所示，通过线上白屏问题归因，我们看到网络问题导致比例最高，占比达81.97%。除去常见的弱网/无网等问题外，还有很多各种各样的网络环境问题我们是可以进行优化的，例如设备不支持IPv6，CDN节点异常，证书超时等。

本文将要分享的是得物技术团队针对移动端最常见的图片加载导致的端侧白屏问题，而进行的的移动网络方向的技术优化实践，希望能带给你启发。

技术交流：

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

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

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

2、网络优化和监控概览

网络优化与监控体系：

3、网络监控能力

3.1概述

网络异常导致的图片白屏问题，往往和当时的环境有关，例如用户连的WIFI不支持IPv6但是DNS返回的大部分是V6的IP等，此时仅靠几条带有SocketTimeoutException的网络日志根本无法排查出问题的根因，就如同ANR问题需要火焰图一样，白屏问题同样需要一套完善的监控体系来记录问题现场的信息，从而分析问题根因。

3.2OkHttp基础监控

图片网络请求的阶段信息，可以通过实现OkHttp自带的EventListener来获取，在各个阶段开始和结束点记录下时间戳即可。

其中需要重点关注connectFailed、requestFailed和responseFailed这三个失败的回调，他们都会在失败之后重试，并重复执行阶段开始的回调（例如connectStart)，因此针对这些需要单独记录好每一次失败信息，避免被覆盖。

例如某个图片请求TCP建连失败的记录：

3.3APM流量监控

尽管我们有专门的网络诊断工具，但是考虑到网络异常的滞后性，故障往往是数十秒之前引入的（例如进电梯弱网），而发生问题之后才触发的网络诊断结果仅能作为参考，并不能作为最终问题归因的证据。

因此我们需要一个更直观的表达用户设备网络状况的数据，那就是通过系统API获取的当前App流量消耗，在排除了一些本地socket通信产生的干扰之后，最近N秒之内消耗的流量/N就可以认为是白屏问题发生时的网速。

我们以3秒为间隔分段计算并取最大值来排除波动，这样我们就得到了白屏问题发生前一段时间内的网速状态，过低的就可以判定为弱网/无网。

网速计算示意图：

3.4CDN异常记录

CDN厂商侧的异常，例如服务器IP跨省，节点挂了等问题相对少见，在网络日志中通常就表现为建连超时但是网络正常，因此需要收集多个Host的请求记录进行横向对比来确认是单个CDN厂商的问题。

为此我们记录了主站接口的域名，以及所有CDN域名在最近N分钟内的请求统计，包括了正常请求、慢请求、失败请求的数量和原因，以及失败请求使用的具体IP。

例如图中可以看到某CDN的请求全部都是建连失败，而其他CDN以及我们主站域名请求均正常，那么此问题可以归类为该CDN的单点问题，联系CDN服务商剔除该IP所在节点即可解决问题。

3.5网络库请求缓存

常规的网络监控方案为了节省内存，会在请求结束时将其从内存缓存队列中移除，而白屏问题因为其滞后性，只有在屏幕中大面积出现白图才会被判定，此时再去查询加载失败的图片网络请求日志自然早已被移出队列，因此需要单独使用一个LRU队列来缓存最近N条网络日志，图片库同理。

3.6网络诊断工具

在逐步解决用户问题的过程中，我们研发了网络诊断工具，实现了基础网络信息采集、Ping、TraceRoute等。

当检测到用户发生白屏时自动触发网络诊断：

1）单域名诊断流程：我们会依次进行DNS、Http、Ping（ICPM）与Ping（TCP）、TraceRoute诊断。如果是双栈客户端（同时返回了IPv4与IPv6），那么我们会选择首个IPv4与首个IPv6同时进行Ping/TraceRoute以确认不同IP类型的联通情况。

2）多域名诊断流程：同时对3个得物核心域名发起诊断。为了辅助判断，当得物核心域名诊断失败时，也会对一些主流三方域名稍微Ping一下。

3）诊断数据的上报：由于网络诊断可能耗时10秒以上，而如此长的时间内用户如果退出App那我们的诊断数据可能就丢失了。因此，任意一个小阶段的诊断完成时，我们就立即上报此结果，以避免此类情况的发生。

4、CDN质量监控

4.1概述

CDN作为整体白屏问题中重要的一环。在白屏排查过程中，经常遇到接口正常，但CDN访问异常的case。而多云CDN的质量问题往往依赖于云厂商，如何衡量和监控云厂商的CDN情况成为了关键，故我们自定义了端侧的CDN质量指标体系以及配合云厂商推进云端策略的优化。

4.2CDN质量大盘

在白屏监控平台侧，我们经常能够发现用户侧的CDN单点问题，往往存在跨省、跨运营商调度的情况，或者是单节点的高负载响应超时。故我们基于此情况记录了端侧的本地IP&CDN远端IP，建设了CDN质量大盘。

核心指标如下:

依赖CDN质量大盘，我们可以横向、纵向对不同云厂商服务进行CDN质量评估工作，由于端侧实际发起的总请求数量统计成本高、到CDN侧的请求存在丢失等情况，我们采用了端侧采样上报、统计还原的思路，将得物侧的整体CDN指标大盘采样放大比例为1 / 千分之三（当前采样比例）。过程指标的确会收到采样用户质量的影响，但整体CDN趋势、各厂商CDN的横向对比还是有很大的参考意义的。

平台截图展示:

4.3CDN云端监控

如果说端侧CDN指标是对CDN质量抽象评估的长周期指标，那么云端监控则是CDN质量的精确告警的短时效指标。

这部分就是一些较为常见的策略与手段了，如CDN节点拨测、CPU负载监控、异常错误码监控等，并协同SRE团队将其同飞书通知打通，实现及时告警。

4.3.1）节点拨测：

CDN节点拨测整体指定的图片拨测阈值当前限制在200ms。

4.3.2）节点监控：

关于到节点后的请求监控，主要依赖于云厂商的监控能力，我们也协同云厂商对核心指标的告警阈值等进行了调优，核心主要为:

此处思考一个问题，如果建连请求无法抵达CDN节点，那么即使CDN厂商开启了TCP级日志，也无法监测到此异常，也就无法及时进行调度调整。

故对于非到节点的建联问题，基于TCP建连进行监控是很有必要的，我们基于客户端建连的监控数据，以用户网络环境（网络运营商，地域）视角，分析建连过程是否正常，及时发现异常连接线路，并通过推动CDN服务商调整区域DNS返回来恢复正常。

监控指标如下：

建联失败、异常率：

建联p50、p99耗时分布：

5、网络问题优化治理1：DNS策略优化

5.1概述

从网络监控、白屏监控中我们可以清楚的观察到DNS错误是网络阶段导致白屏的最大因素。此外，DNS错误是所有网络错误中最多的，甚至可以占比80%以上。

连续DNS错误导致白屏：

5.2LocalDNS行为

为什么DNS阶段如此脆弱，是我们使用不当，还是其本身性能如此？我们首要做的是观察下Android平台下LocalDNS的行为逻辑以确认性能较差的原因。

5.2.1）按照TTL缓存：

通过不停的向系统进行查询DNS，在抓包中，我们很容易观察到DNS的查询逻辑。其中一个重要参数是TTL（Time to Live），这个参数表明当前查询结果的有效时间。比如说TTL=7，表明在7秒钟内当前结果是有效的、可被缓存的，即使7秒钟内再次查询，依然是此结果。

Android平台严格遵守了此协议，按照TTL进行缓存。而较短的有效时间，也意味着我们需要进行域名查找时（冷热启动），大概率系统内没有缓存可用。

DNS TTL与查询频率：

通常TTL设置为120秒以内，这是因为要考虑到节点故障，能够快速切换。而到端侧查询时，TTL会在0~120之间。低于120是因为我们查询此结果的DNS server自身已经缓存了一定的时间。

5.2.2）双栈客户端同时查询：

双栈客户端上，同时发起A类（IPv4）、AAAA类（IPv4）查询。

某运营商5G网络下DNS查询及响应：

当两类查询都成功响应时，Android会将两类结果组合起来排序后返回给应用层。无论是A类地址先返回，还是AAAA类地址先返回，Android都会将IPv6地址放在前面（划重点，后面要考）。

-- app.dewu.com 的DNS查询结果

[app.dewu.com/2405:e000:1004:1::f3ff:4b49, app.dewu.com/203.107.32.125]

可以看到电信的LocalDNS服务器并未遵守TTL时间（app.dewu.com 的 TTL为60），而是进行了额外的缓存。这是部分运营商为了降低客户端的查询频率（降成本）而搞出的小把戏，不在我们的讨论范围内。

5.2.3）DNS数据包错误与重试：

我们将DNS服务器设置为一个虚假的DNS服务器，来观察Android平台在DNS未返回时的重试逻辑。

DNS重试（主、备、隐藏款）：

可以看到，0秒时向主DNS服务器发起查询，5秒向备DNS服务器发起查询，8秒向114发起查询。

现在我们想一下，在我们DNS查询时，只要0秒的第一次查询向主没有正常返回（比如丢包），即使备选正常，能成功查询到结果也是5秒钟后的事情了，而这意味着用户在5秒内无法正常的请求网络。然后，用户熟练的打开设置、点击用户反馈、选择白屏、输入些表达欣喜的文字、提交！（嘿，来活了）

那么我们能否通过多次查询来触发系统来同时发起多个查询请求呢？

不行。当前Android内有一个同步栅栏，多个线程同时查询一个Host，只会允许一个通过。如果成功时，全部被阻拦的查询一同返回结果；如果失败时，再允许一个查询。也就是说，在这5秒内，我们只能静静的等着，让用户也等着。

主/备DNS服务器我们可以通过在设置中修改，而114这个隐藏款只出现在部分国产品牌上，不同品牌内置的隐藏备用DNS服务器也并不相同。

5.2.4）iOS平台的DNS行为：

众所周知，iOS平台下的DNS异常率远远低于Android，甚至差了一个数量级。

iOS为何如此优秀？

1）较长的缓存时长：当DNS的TTL较低时（比如3秒），iOS会忽略TTL值，直接缓存1分钟以上；
2）积极的重试逻辑：只要1秒内未收到响应立即进行多次重试，其中主DNS 6次，备DNS 8次。

5.3DNS优化

通过对LocalDNS的行为分析，我们看到Android平台下的LocalDNS查询极其不可靠，好在我们并非只能通过LocalDNS来解析IP。任何将域名转换为IP的手段都可以使用，比如通过http获取、磁盘缓存等。

在LocalDNS的基础上，我们增加了HttpDNS，磁盘缓存来优化DNS问题。其中HttpDNS在第60ms异步启动，磁盘缓存在第6秒钟时异步启动。三种查询方式任意一个返回，则DNS结束。

5.3.1）HttpDNS：

我们实现Http进行DNS查询，并将其作为备用DNS使用。在LocalDNS 60ms未成功返回时，异步启动HttpDNS进行查询。这将能解决LocalDNS下主DNS失败5秒后才会进行下一次重试的弊端。

HttpDNS的实现方式，我们暂时选择接入成熟的三方HttpDNS，快速解决用户在DNS方面的困境是主要原因之一。

当然，也并非全部域名通过HttpDNS查询都会有效果，比如localhost、IP地址等就需要从HttpDNS的查询中排除。

同步栅栏：当存在单个host的多个查询线程时，仅允许第一个线程查询，其他全部等待查询结果。（类似于Android系统对多线程同时查询时的处理）

5.3.2）磁盘缓存：

DNS查询成功时，我们将查询结果缓存到磁盘上。在LocalDNS、HttpDNS都未如期返回时，将磁盘上缓存的结果返回给应用层。如此以来，只要历史上这个用户查询成功过，我们始终不会失败在DNS阶段。

需要注意的是：在磁盘上缓存IP时，需要按照网络类型、运营商进行缓存。原因是不同网络下的最佳IP往往不同，比如同一个CDN域名中国移动的CDN节点与中国电信的CDN节点会在各自的机房里。如果我们不分开存储，那么用户网络切换后，我们磁盘缓存出的IP或许可用，但可能不是最佳（延迟更高）。

此外，我们的磁盘缓存也完全忽略了DNS TTL。原因是我们将磁盘缓存作为其他DNS查询全部失败后的兜底手段使用，而非主要手段。即使TTL过期的IP可能会存在一些问题，但也不会有更坏的结果了。

5.2.3）收益情况：

通过线上实验观察到，DNS异常率降低了60%以上。

不同配置下的DNS异常率对比：

6、网络问题优化治理2：IPv6故障修复

6.1概述

前文提到对于双栈客户端，Android会将IPv6地址放在前面返回给应用层。本意上，IPv4地址即将枯竭而向IPv6过渡的方式，而这恰恰是Android平台在TCP建连阶段时遇到的最大问题。

用户A-DNS结果：

我们来看一个例子：用户A访问 cdn.poizon.com 是DNS共响应了10个IPv6、10个IPv4，然而此用户IPv6无法访问，且给个IPv6都是建连10秒后超时，最终导致用户在第100秒时才在第11个IPv4地址上成功。

RFC6555 摘要：

正如 RFC6555 摘要中描述的那样，当服务器的 IPv4 路径和协议正常，但IPv6 路径和协议不工作时，相对于IPv4单栈客户端，双栈客户端会经历显着的连接延迟。而这个延迟通常是10秒以上（IPv6的个数和建连超时时间的乘积）。

那么如何优化？

最简单的方式是禁用IPv6，简单到甚至只需要运维动动小手即可。但是由于众所周知的原因，我们国内对于推动IPv6十分积极，对于IPv6的浓度动不得。

最合理的方式自然是按照RFC6555描述的那样实现快乐眼球算法，但是开发成本和风险都较大。而线上时而有类似反馈。因此我们决定分两步走，先上线低风险的IPv6探测&重排序解压此困境，再实现快乐眼球算法。

OkHttp5.x 已支持RFC6555，但是目前尚未正式发布。且得物历史上对源码的修改较多，整体迁移到5.x成本较高。

6.2IPv6探测 & 重排序

此实现的思路是既然IPv6可能故障，那么提前探测潜在故障。通过调整即将建连的IP列表的顺序来解决客户端建连到IPv4的延迟问题。

此实现在DNS查询成功之后，建连之前。因为不涉及修改OkHttp源码修改所以风险可控。

1）IPv6探测：如果IP列表中同时包含IPv6&IPv4，则对第一个IPv6地址同步进行Ping探测。如果250ms内探测成功或曾经探测成功，则认为IPv6正常。

2）重排序：如果IPv6畅通，则按照IPv6优先进行交叉排序。如果IPv6故障，则按照IPv4优先进行交叉排序。

# 重排序前

[

"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:13",

"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:10",

"imagex-cdn.dewu.com\/183.240.183.19",

"imagex-cdn.dewu.com\/183.240.183.15"

]

# 重排序后（IPv6探测失败）

[

"imagex-cdn.dewu.com\/183.240.183.19",

"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:13",

"imagex-cdn.dewu.com\/183.240.183.15",

"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:10"

]

# 重排序后（IPv6探测成功）

[

"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:13",

"imagex-cdn.dewu.com\/183.240.183.19",

"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:10",

"imagex-cdn.dewu.com\/183.240.183.15"

]

IPv6探测 & 重排序流程图：

6.3快乐眼球（HappyEyeball）

当前DNS返回的IP地址数量超过一个时，每250ms异步启动一个新的TCP建连，任意一个TCP建连成功，则断开其他TCP并开始同步TLS建连。

1）TLS 建连成功则返回此Connection，流程结束；
2）TLS 建连失败时，如果是可恢复的TLS失败（部分SSLException），则立即重试；
3）如果是不可恢复失败，则再次启动其他TCP的竞速。

核心修改点是原流程的建连部分。原流程中，在网络线程中同步的、依次进行TCP、TLS建连。新流程中，将TCP与TLS建连分开，竞速建连TCP，TCP建连完成后建连TLS。

1）OkHttp3.x 建连流程：

注：OkHttp3.x 的nextRoute之间的循环在RetryAndFlow实现

2）OkHttp-HappyEyeball建连流程：

具体实现方式可以参考OkHttp5.x 代码。

收益情况：自IPv6优化上线后，再无相关IPv6相关用户反馈。

7、CDN质量问题治理概述

从白屏监控大盘中可以看到，CDN的问题可能只占据1%~2%，但是不同于通用网络问题，用户凭持着其他App可以用，但是得物App为什么白屏的疑问，是极容易引起线上反馈的一种case。

故我们也是协同SRE团队、云厂商一起做了一些优化手段，力争在现有条件下将端侧的图片CDN质量调整到最优。

8、CDN质量问题治理1：返回IP策略优化

从网络优化来看，DNS优化以及IPv6探测&重排序为我们解决了双栈IPv6问题、单IP不可用等问题，但CDN问题本身由于不同省份、不同区域等节点数量、网络硬件质量均存在差异，这部分是端侧无法弥补的，故我们想到了优化CDN返回IP策略的思路来规避以上问题。

返回IP优化策略：

过程中考虑到得物IPv6浓度问题，最早期是返回了3个v4 IP、3个v6 IP的策略，但发现v6 IP数量变多后，由于LocalDNS天然会把v6 IP排放在v4 IP前面。此举在没有建连竞速优化的老版本下，会导致v6不通的建连时间被逐步拉长30s。故我们在尽可能保证v6浓度的情况下，将返回的v6 IP数量降低到了2个。

由于v6 IP优先请求的情况，我们考虑优先保证v6 IP的本省同大区覆盖，故对v6 IP的本省的大区返回粒度会比v4 IP更细些。

跨省调度问题：