Android架构之高可用移动网络连接

作者 : 开心源码 本文共4334个字,预计阅读时间需要11分钟 发布时间: 2022-05-12 共168人阅读

《亿级Android架构》小专栏文章列表:

《亿级 Android 架构》专栏随谈》

《Android 架构之网络连接与加速》

《Android 架构之长连接技术》

《Android 架构之高可用移动网络连接》

《Android 架构之网络安全演进》

《Android 架构之高性能手机端日志系统》

正文

读者好,前面我们在《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的权重,而后提供给网络连接使用。

image

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地址列表。

具体有下面几种方式:

  1. 定时器监听HttpDNS返回的TTL过期时间。当IP列表即将过期前,发起请求获取下一轮的IP列表并进行升级;
  2. 监控网络连接状态,网络链路切换,比方Wi-Fi/3G/4G转换,假如是Wi-Fi,还可以监控SSID信息变更(针对不同的Wi-Fi热点),及时触发IP列表刷新;在异步升级过程中,可以依然使用旧缓存IP提供服务;
  3. 配置中心下发,这种有时会用在服务器分流,比方某台服务器压力过大,可以通过配置中心系统下发新的IP列表给用户端访问。

另外,IP列表缓存应该对不同网络类型、网络标识有对应的一份缓存,可以使用网络类型(3G、4G、Wi-Fi等)+网络标识(SSID、ispCode等)作为缓存Key,当网络切换时,使用Key去查询缓存。

这些缓存可以持久化到多个文件,以Key作为文件名,同时可以基于当前网络状态,缓存一份IP列表到内存供使用,当网络状态变化,则刷新内存缓存。

image

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里的复合连接策略作为学习参考:

image

在弱网状态下,依次发起对5组IP+Port的连接,10s作为超时时间。当前一个连接发起了4s钟还未成功,则立即发起下一个连接,以此类推。当其中有一个连接建立成功,则立即中止其余连接。这样的方式可以兼备串行连接和并行连接的优势:较快找到可用IP,同时对于服务器不会造成过大的连接压力。至于这个超时时间10s,则可以通过上报数据来动态统计,找到一个正当的超时时间。

image

自主网络诊断

在真实的线上环境我们发现,即便IP和后端服务均有效,仍有一部分客户的网络连接会出现失败。而此时单纯从IP地址已经分析不出起因,很有可能是该客户的网络链路上存在问题导致连接失败。

这时就需要我们主动去探测这个客户的网络连接并诊断整条连接链路。

因而,为了精确理解线上网络错误的客户的真实情况,我们会在用户端里内置网络诊断策略,通过Ping或者者TraceRoute探测客户手机到服务器的整条网络链路上的情况,并将数据存储上报,用于分析客户的真实网络错误起因。

Ping大家比较熟习,目的是为了测试另一台主机能否可达,向目标主机发送Echo包并等待回包;而TraceRoute可以获取数据包在IP网络经过的路由器的IP地址,原理如下:

  • 程序是利用添加存活时间(TTL)值来实现其功能的。每当数据包经过一个路由器,其存活时间就会减1。当其存活时间是0时,主机便取消数据包,并发送一个ICMP TTL数据包给原数据包的发出者。
  • 程序发出的首3个数据包TTL值是1,之后3个是2,如此类推,它便得到一连串数据包路径。注意IP不保证每个数据包走的路径都一样。

在Android上一般有两种方式来实现这个诊断:

  1. 通过后端线程执行ping命令的方式,模拟traceroute的过程;
  2. 通过编译开源网络检测库iputilsC代码的方式对traceroute进行了套接字发送ICMP报文模拟。

感兴趣的可以参考文末提供的开源项目LDNetDiagnoService,通过诊断可以把日志上报用于分析,并作出相关的调整和优化。

小结

本文针对如何提高网络连接的高可用性做了讲解和分析,线上方案最重要考虑的就是兜底,无论发生何种问题,都要保证网络服务可用。假如客户连我们的服务器都连接不上,那可能会带来非常严重的灾难;当然,我们也要考虑服务器负载,不能造成服务器压力过大,导致雪崩之类的问题。

有相关疑问欢迎随时留言。


谢谢。

wingjay

《亿级Android架构》小专栏详情

业务的快速增长离不开稳固可靠的架构。《亿级Android架构》小专栏会基于作者实际工作经验,结合国内大厂如阿里、腾讯、美团等基础架构现状,尝试谈谈如何设计一套好的架构来支持业务从0到1,甚至到亿,希望与大家多多讨论。

本专栏主要内容:

  1. 当前大厂有哪些Android架构;
  2. 这些架构能处理什么问题;
  3. 这些架构的原理是什么;
  4. 学习这些架构对我们自身的意义。

《亿级Android架构》小专栏文章列表:

《亿级 Android 架构》专栏随谈》

《Android 架构之网络连接与加速》

《Android 架构之长连接技术》

《Android 架构之高可用移动网络连接》

《Android 架构之网络安全演进》

《Android 架构之高性能手机端日志系统》


参考文章

《微信终端跨平台组件 Mars 系列(三)连接超时与IP&Port排序》

《海量之道系列文章之弱联网优化》

《LDNetDiagnoService_Android》

《美团点评移动网络优化实践》

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » Android架构之高可用移动网络连接

发表回复