读者好，前面我们在 《Android 架构之网络连接与加速》 和《Android 架构之长连接技术》两篇文章中，讲解了 Http 短连接、TCP 长连接、连接复用与速度优化、数据压缩 等方面的知识点。不过，真实的网络环境是很复杂的，存在各种各样的因素会导致网络服务不可用，比如 DNS 劫持、服务器宕机、弱网等。换言之，如果服务都不可用，那上面这些优化也就没有意义了。
因此，本文主要谈一下在真实的网络环境下，存在哪些常见的网络不可用原因，以及大多数公司是如何解决并兜底，从而达到 高可用连接 这个目标的。
文章会从下面几方面进行阐述：
- DNS 劫持与可靠 IP 获取
- HttpDNS
- 内置 IP 列表 + 自动测速
- IP 列表的缓存更新策略
- IP 列表可用性兜底策略
- 针对弱网的多 IP 复合连接测速
- 自主网络诊断
DNS 劫持与可靠 IP 获取
我们知道，大多数的网络请求第一步就是 DNS 过程，经过 1-RTT 的时间将域名转化为 IP 地址，然后再去发起请求。但是，有相关经验的开发者应该了解，DNS 过程不仅耗时不稳定（3G 下 200ms，4G 下 100ms），而且可能解析失败，甚至被劫持，将用户导入到了错误的 IP 地址。如果攻击者自己做一个仿冒的网站，劫持你的 DNS 并将 IP 转到这个假网站上，可能会造成很大的用户数据泄漏和公司品牌损失。
为了解决这个问题，获得可靠的 IP 列表，现有大厂会采用下面一些方案：
1. HTTPDNS
比如阿里云和腾讯云都推出了自己的 HttpDNS 服务，在全国多地部署相关的服务器提供安全解析 DNS 服务。
基本的原理就是通过发起 Http 请求到 HttpDNS 服务器，获取某个域名对应的可用 IP 列表。这个 IP 列表可以根据用户当前的地点进行返回，而且默认会进行 IP 测速，按速度排序。同时，伴随这 IP 列表，服务器还会下发一个缓存有效时间 TTL，有了这个时间，客户端可以放心的将 IP 列表缓存在本地，并在即将过期前及时去更新 IP 列表，保证每次网络请求都可以使用 当前最优 的 IP 地址。
2. 内置 IP 列表 + 自动测速
当然，自建 HttpDNS 服务需要一定规模的机房部署、大量的客户端测速数据上报、全球 IP 库收集等，需要不少的投入。因此，有些公司比如 携程 就采用了更加轻量一点的方案：内置 IP 列表。
具体原理如下：
在 APK 打包时会内置一份 IP 列表进去。当 App 启动时，这些 IP 的权重相同，此时会随机从里面获取 IP 来使用。但是这有个问题，对不同地区的用户而言，最优 IP 肯定是不同的。比如对于上海的用户而言，上海区服务器的 IP 肯定是最快的，而对于深圳的用户而言，华南区 IP 才是最快的。因此，在 App 运行过程中，我们会通过依次对 IP 列表逐个进行Ping 测速，根据测速结果动态变更 IP 的权重，然后提供给网络连接使用。
IP 列表的缓存更新策略
通过 HttpDNS 或内置 IP 列表 的方案，我们可以为网络层提供一份相对可靠的 IP 地址作为缓存，每次需要发起请求时，直接从缓存里读取这份 IP 列表即可建立 IP 直连。
那新的问题来了，移动网络是在不断变化的。最常见的场景，比如我们从 Wi-Fi 切换到了 4G，获取进入电梯后从 4G 降级成 3G，或者我们从 A Wi-Fi 换到了 B Wi-Fi，这都意味着我们的 网络链路变更 了。那么，之前缓存的 IP 列表是否仍然可用，或者仍然最优呢？
显然并不一定，比如从 Wi-Fi 切到了移动 4G，背后整条网络链路都不同了，之前的 IP 列表很有可能不是最优的了，极端情况下可能某些 IP 地址也不可用了。因此，我们需要最好 IP 列表的及时更新，保证无论网络如何切换，我们都能使用最优的 IP 地址列表。
具体有下面几种方式：
- 定时器监听 HttpDNS 返回的
TTL 过期时间。当 IP 列表即将过期前，发起请求获取下一轮的 IP 列表并进行更新； - 监控网络连接状态，网络链路切换，比如 Wi-Fi/3G/4G 转换，如果是 Wi-Fi，还可以监控 SSID 信息变更（针对不同的 Wi-Fi 热点），及时触发 IP 列表刷新；在异步更新过程中，可以仍然使用旧缓存 IP 提供服务；
- 配置中心下发，这种有时会用在服务器分流，比如某台服务器压力过大，可以通过配置中心系统下发新的 IP 列表给客户端访问。
另外，IP 列表缓存应该对不同网络类型、网络标识有对应的一份缓存，可以使用 网络类型（3G、4G、Wi-Fi 等）+ 网络标识（SSID、ispCode 等）作为 缓存 Key，当网络切换时，使用 Key 去查询缓存。
这些缓存可以持久化到多个文件，以 Key 作为文件名，同时可以基于当前网络状态，缓存一份 IP 列表到内存供使用，当网络状态变化，则刷新内存缓存。
IP 列表可用性兜底策略
通过更新机制，我们可以保证本地 IP 列表缓存动态更新的及时性。那么，如果 HttpDNS 服务器出现故障呢，或者首次打开 App，HttpDNS 还没有完成，或者大面积 DNS 劫持等，怎么办呢？
所以说，除了及时获取最优 IP 列表，我们还要考虑，如果获取不到 IP 列表，如何进行兜底？保证用户的网络请求不受影响。
在线上运行中，可以采取下面四组 IP 兜底策略，按优先级排列如下：
- HttpDNS IP：即大厂自建的 HttpDNS 服务获取动态 IP；
- DNS IP：即常规 Local DNS 获取 IP；
- Auth IP：通过配置下发的动态保底 IP 列表；
- Hardcode IP：本地写死的保底 IP 列表
前面两种动态 IP 不用多说，大家都清楚，这两者可以动态获取 IP，效果最好。但是，如果发生故障，导致这两个方案都不可用，比如大面积 DNS 劫持之类的，这时客户端必须能够自动降级到 静态兜底 IP，保证网络服务可用。
但这也可能存在一个问题，就是 静态兜底 IP对应服务器访问量可能会突然暴增，如果峰值太高可能造成更大的危害如 雪崩 。因此，除了内置静态兜底 IP，还需要为客户端提供一个可通过 配置动态下发 的兜底 IP 列表，可以做到负载均衡，将流量分散到不同机器上。而且这些静态 IP 贵精不贵多，并且要有高可用的后台服务保证，作为全局网络服务的兜底。
针对弱网的多 IP 复合连接测速
通过上面的几套方案，可以保证用户能够 高可用的获取最优 IP 列表，提高用户访问速度，而且能应对各种复杂的网络状态。
那么现在考虑这样一种情况，上面的 IP 列表我们能够正常的获取，但是，用户处于弱网状态下，IP 连接成功率很低，怎么办呢？
针对弱网一般有两种方式：
- 串行连接：先连接第一个 IP，直到发生了超时，再去对第二个 IP 建连；
- 并行连接：同时对多个 IP 建立连接，哪个连成功了就用哪个；
这两种方案的缺点是：串行连接可能需要很长时间的试错，才能找到可用的 IP，而且这里还取决于如何选择超时时间，如果超时时间较长，则需要很长时间才能找到可用 IP；如果很短，则可能会漏掉一些相对优质的 IP，不断去尝试新 IP，恶性循环；而并行连接则会对服务端造成极大的连接负载压力和一定程度的浪费，对于电量也有一定程度开销。
因此，这里我们介绍下 Mars 里的复合连接策略 作为学习参考：
在弱网状态下，依次发起对 5 组 IP+Port 的连接，10s 作为超时时间。当前一个连接发起了 4s 钟还未成功，则立即发起下一个连接，以此类推。当其中有一个连接建立成功，则立即停止其他连接。这样的方式可以兼备串行连接和并行连接的优势：较快找到可用 IP，同时对于服务器不会造成过大的连接压力。至于这个超时时间 10s，则可以通过上报数据来动态统计，找到一个合理的超时时间。
自主网络诊断
在真实的线上环境我们发现，即使 IP 和后台服务均有效，仍有一部分用户的网络连接会出现失败。而此时单纯从 IP 地址已经分析不出原因，很有可能是该用户的网络链路上存在问题导致连接失败。
这时就需要我们主动去探测这个用户的网络连接并诊断整条连接链路。
因此，为了准确了解线上网络错误的用户的真实情况，我们会在客户端里内置网络诊断策略，通过 Ping 或者 TraceRoute 探测用户手机到服务器的整条网络链路上的情况，并将数据存储上报，用于分析用户的真实网络错误原因。
Ping大家比较熟悉，目的是为了测试另一台主机是否可达，向目标主机发送 Echo 包并等待回包；而 TraceRoute 可以获取数据包在 IP 网络经过的路由器的 IP 地址，原理如下：
- 程序是利用增加存活时间（TTL）值来实现其功能的。每当数据包经过一个路由器，其存活时间就会减 1。当其存活时间是 0 时，主机便取消数据包，并发送一个 ICMP TTL 数据包给原数据包的发出者。
- 程序发出的首 3 个数据包 TTL 值是 1，之后 3 个是 2，如此类推，它便得到一连串数据包路径。注意 IP 不保证每个数据包走的路径都一样。
在 Android 上一般有两种方式来实现这个诊断：
- 通过后台线程执行 ping 命令的方式，模拟 traceroute 的过程；
- 通过编译开源网络检测库
iputilsC 代码的方式对 traceroute 进行了套接字发送 ICMP 报文模拟。
感兴趣的可以参考文末提供的开源项目LDNetDiagnoService，通过诊断可以把日志上报用于分析，并作出相关的调整和优化。
小结
本文针对如何提高网络连接的高可用性做了讲解和分析，线上方案最重要考虑的就是兜底，无论发生何种问题，都要保证网络服务可用。如果用户连我们的服务器都连接不上，那可能会带来非常严重的灾难；当然，我们也要考虑服务器负载，不能造成服务器压力过大，导致雪崩之类的问题。