小专栏文章列表：
正文
读者好，前面我们在和两篇文章中，讲解了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探测用户手机到服务器的整条网络链路上的情况，并将数据存储上报，用于分析用户的真实网络错误原因。
大家比较熟悉，目的是为了测试另一台主机是否可达，向目标主机发送Echo包并等待回包；而可以获取数据包在IP网络经过的路由器的IP地址，原理如下：
- 程序是利用增加存活时间（TTL）值来实现其功能的。每当数据包经过一个路由器，其存活时间就会减1。当其存活时间是0时，主机便取消数据包，并发送一个ICMP TTL数据包给原数据包的发出者。
- 程序发出的首3个数据包TTL值是1，之后3个是2，如此类推，它便得到一连串数据包路径。注意IP不保证每个数据包走的路径都一样。
在Android上一般有两种方式来实现这个诊断：
- 通过后台线程执行ping命令的方式，模拟traceroute的过程；
- 通过编译开源网络检测库
iputilsC代码的方式对traceroute进行了套接字发送ICMP报文模拟。
感兴趣的可以参考文末提供的开源项目LDNetDiagnoService，通过诊断可以把日志上报用于分析，并作出相关的调整和优化。
小结
本文针对如何提高网络连接的高可用性做了讲解和分析，线上方案最重要考虑的就是兜底，无论发生何种问题，都要保证网络服务可用。如果用户连我们的服务器都连接不上，那可能会带来非常严重的灾难；当然，我们也要考虑服务器负载，不能造成服务器压力过大，导致雪崩之类的问题。
有相关疑问欢迎随时留言。
谢谢。
wingjay
《亿级Android架构》小专栏介绍
业务的快速增长离不开稳定可靠的架构。小专栏会基于作者实际工作经验，结合国内大厂如阿里、腾讯、美团等基础架构现状，尝试谈谈如何设计一套好的架构来支持业务从0到1，甚至到亿，希望与大家多多探讨。
本专栏主要内容：
- 当前大厂有哪些Android架构；
- 这些架构能解决什么问题；
- 这些架构的原理是什么；
- 学习这些架构对我们自身的意义。
小专栏文章列表：