客厅 TV:App HttpDNS 技术接入与实战

1 项目概况

域名劫持大家并不陌生,从PC时代到移动互联时代,网络安全愈发重要,劫持方式更是层出不穷。现在到了智能客厅时代(意淫一下),如果说移动互联时代由于开放性和竞争性,大的厂商还是有良知的,比较注重口碑二字,但客厅由于其封闭性,无良厂商只手遮天,各类监控、各类弹窗广告、各类精简系统、各类系统级封杀等,导致客厅开发异常复杂,只有把主动权把握在自己手中,才能感觉到一丝丝安全。

传统的域名解析是一个系统调用,解析的结果可以说控制在运营商手中,也可能控制在厂商手中(无良厂商改系统),现在我们要把域名解析的主动权收到自己的手中,于是HttpDNS技术应运而生。

1.1 数据会说话

我们把客厅接口数据分为两部分:一部分是客厅业务接口,一部分是客厅CDN图片接口。因为作为一个视频APP,图片量是极大的,图片的请求量要远超业务侧接口的请求量,请求量越大,接入HttpDNS技术的效果应该更好,话不多说看结论。

1.1.1客厅业务接口数据分析

图1展示了客厅业务接口返回码分布图,其中左图为未接入HttpDNS技术的接口返回码,右图为接入HttpDNS技术之后的接口返回码。我们重点关注错误码6和错误码7,错误码6是由于域名解析失败导致的接口错误返回码,错误码7是解析出的ip无法连接到主机导致的接口错误返回码,可以看出在接入了HttpDNS技术之后,由域名解析问题导致的错误(错误码6、7总和) 降低了61% ,效果非常明显。

客厅 TV:App HttpDNS 技术接入与实战

图1 客厅业务接口返回码分布图

再来看一下接口耗时,图2展示了客厅业务接口耗时分布图,其中左图为未接入HttpDNS技术的接口耗时,右图为接入HttpDNS技术之后的接口耗时。可以看出在接入了HttpDNS技术之后,接口耗时降低了40%,效果非常明显。

客厅 TV:App HttpDNS 技术接入与实战

图2 客厅业务接口耗时分布图

1.1.2 客厅CDN图片接口数据分析:

图3展示了客厅CDN图片接口返回码分布图,其中左图为未接入HttpDNS技术的接口返回码,右图为接入HttpDNS技术之后的接口返回码。可以看出在接入了HttpDNS技术之后,由域名解析问题导致的错误(错误码6、7总和)降低了82%,比业务接口的接入效果更加明显。

客厅 TV:App HttpDNS 技术接入与实战

图3 客厅CDN图片接口返回码分布图

再来看一下接口耗时,图4展示了客厅CDN图片接口耗时分布图,其中左图为未接入HttpDNS技术的接口耗时,右图为接入HttpDNS技术之后的接口耗时。可以看出在接入了HttpDNS技术之后,接口耗时降低了43%,比业务接口的接入效果更加明显。

客厅 TV:App HttpDNS 技术接入与实战

图4 客厅CDN图片接口耗时分布图

1.2   什么是HttpDNS技术?

首先看一下什么是 域名劫持 。图5简单示意了域名劫持流程:当用户向Local DNS去请求某个域名的真实ip时,运营商的Local DNS服务器回复了一个假网站或内容缓存服务器的ip,最终导致用户访问无法访问到真实ip,从而出现异常。

客厅 TV:App HttpDNS 技术接入与实战

图5 域名劫持流程图

是不是非常简单明了!而HttpDNS技术正是为了解决域名劫持应运而生的。下面就来看一下HttpDNS技术的实现原理。

客厅 TV:App HttpDNS 技术接入与实战

图6 HttpDNS技术原理图

图6展示了 HttpDNS技术的实现原理 ,主要分两步:

1.客户端向HttpDNS服务器发起请求(该请求为ip直连请求),获取与域名对应的一系列ip列表;

2.客户端从ip列表中选取访问延迟最优的ip,直接用此ip代替域名发送请求,这样就避免了Local DNS域名解析这一步骤。

总结HttpDNS技术的优势:

1.根治域名解析异常:由于绕过了运营商的LocalDNS解析,客户端的请求通过ip直连,彻底解决了域名劫持问题;

2.精准调度:HttpDNS能直接获取到用户ip,避免了DNS出口ip和业务出口ip不同网段问题;

3.减少网络延迟:通过本地缓存ip,可以有效减少域名解析时间,降低用户网络请求的平均耗时;

4.提升网络请求可控性和可靠性:我们采用的HttpDNS服务器依托腾讯庞大的ip地址库,利用腾讯公网交换平台的BGP Anycast网络,大大提高了网络请求的可靠性,同时是否走HttpDNS以及BGP IP的选择均由后台控制,增加了可控性。

2 实施方案

说起来容易做起来难!任何一种技术的尝鲜都不是一蹴而就的,我们也是从无数的坑里面爬出来,才最终打造了一套适合客厅TV的HttpDNS技术架构。曾几何时在第一版上线的时候就遇到了线上问题,也经历了暂停升级、通宵处理,历经多个版本的不断完善,才从带血的坑里爬出来。

这儿分成三部分来介绍客厅TV-APPHttpDNS技术的接入过程:HttpDNS技术核心架构层、HttpDNS技术业务逻辑层和HttpDNS技术客户端容错处理。

2.1 HttpDNS技术核心架构层

无图无真相,图7展示了客厅HttpDNS技术核心实现流程图:

1.客户端接收到域名请求,查询是否已有该域名历史解析结果缓存,如果已有解析结果缓存则转步骤2,否则转步骤3;

2.检查该缓存是否过期,如果没有过期,则返回查询结果,域名解析成功,否则转步骤3;

3.如果没有解析结果或缓存已过期,则向HttpDNS服务器(119.29.29.29)发起域名查询请求,如果请求成功则转步骤4,否则赚步骤5;

4.域名查询请求成功,得到一组ip列表,通过ip优化选择最优ip并返回查询结果,同时更新解析结果缓存;

5.域名查询请求失败,为了容错,必须再用Local DNS请求一遍,无论是否成功均返回,完成整个查询流程。

客厅 TV:App HttpDNS 技术接入与实战

图7 客厅HttpDNS技术核心实现流程图

整个查询流程定下之后,开始设计各个客户端模块,图8展示了客厅HttpDNS技术模块结构图,包括查询模块、数据模块、IP优选模块、BGP-IP更新模块以及其他模块等。

客厅 TV:App HttpDNS 技术接入与实战

图8 客厅HttpDNS技术模块结构图

  1. 查询模块

    主要包括本地缓存查询和网络查询。查询本地是否有相应的域名缓存,如果有缓存且缓存未过期则直接返回IP;如果本地没有缓存或缓存过期,则从HttpDNS服务器查询IP,并更新域名-IP对应关系记录;如果向HttpDNS服务器查询IP失败则采用LocalDNS解析域名并返回IP,不做域名-IP对应关系更新。

  2. 数据模块

    主要包括两块数据:利用SharedPreferences缓存HttpDNS服务器的ip信息、优先级、标志位;记录每次请求的“域名-ipList”对应关系以及相关缓存数据。这儿建立的缓存非常重要,我们不可能每次都直接网络请求域名对应的ip列表,这样非常耗时。事实上,请求域名对应ip列表的接口返回数据会自带一个生存期(TTL),在该生存期内ip是有效的,可以直接访问 http://119.29.29.29/d?dn=tv.aiseet.atianqi.com&ttl=1 , 其中ttl=1代表返回带生存期字段,这样我们通过缓存“域名-ipList”对应数据,如果发现在生存期内再次请求该域名对应ip时,可以直接使用缓存,避免再次的网络请求。

  3. ip优选模块

    一个域名可能对应多个ip,提供ip优选是必要的。根据ipList中每个ip被选中次数,以及该ip连接耗时综合选择一个平均耗时最短的ip。图9示例了请求tv.aiseet.atianqi.com域名对应ipList的结果示例图。

客厅 TV:App HttpDNS 技术接入与实战

图9 域名请求示意图

  1. BGP-IP更新模块

    即HttpDNS服务器ip更新模块,如果某一天119.29.29.29这个ip不可用了,换成了另外一个ip,则我们的APP也需要支持ip更换。图10为BGP-IP更新流程图,客户端提供一个默认BGP IP: 119.29.29.29,并通过全局配置下发更新的BGP IP和是否走HttpDNS的标志位。

客厅 TV:App HttpDNS 技术接入与实战

图10 BGP-IP更新流程图

  1. 其他模块

    由于篇幅有限,很多地方没能详述,如果你对某一块感兴趣,可以联系作者。

    • 域名过滤功能:可以指定特定域名走HttpDNS;

    • 日志与数据上报功能:分析相关数据,确定域名解析的正确性和有效性;

    • 网络抖动监听:网络变化时需要刷新网络参数,清除内存缓存。

简而言之,上面描述了,给我一个域名,还你一个ip这个过程。那如何给我一个域名呢?这也是一件很有趣的事,详见业务逻辑层分析。

2.2 HttpDNS技术业务逻辑层

一切抛弃业务谈技术的都是耍流氓。几乎所有的APP都涉及网络数据传输,这就需要有多个业务接口进行网络请求,如请求首页数据、请求列表数据、请求图片资源等,无论你是采用系统网络请求或是建有自己的网络库进行网络请求,想把域名直接替换为ip,无外乎以下方式:

  • 如果你的业务异常独立,都采用同一个域名,那你可以通过预埋ip的方式完成这一过程;

  • 如果你是自建网络库,所有的网络请求都由同一网络库发出,那么你可以在网络库中集中处理,通过提取接口中的域名,利用前面介绍的HttpDNS技术,把域名转换为ip,利用ip替换接口中的域名进行请求;

  • 如果你的业务比较分散,网络请求没有集中整理,那就很难统一给HttpDNS一个域名,于是就有了DNS HOOK技术。

DNS HOOK技术通过拦截Android系统域名解析调用getaddrinfo请求,将其拦截到我们的HttpDNS方案之中,利用HttpDNS技术解析域名对应ip,再把解析出的ip作为返回值返回给getaddrinfo系统调用,从而完成域名解析过程。

我们的客厅APP就采用了DNS HOOK技术,主要有以下原因:

  • 视频APP是一个庞大而复杂的APP,除了我们的主业务之外,我们还要接入播放器jar包、下载组件jar包、广告jar包、MTA数据上报jar包等等一堆外部jar包,每一个外部jar包都有自己的网络请求,请求方式也比较分散;

  • 客厅业务是要受牌照方管控的,意思就是你不能采用自己的.qq.com域名,必须采用牌照方的域名,目前我们与多个牌照方都有合作,域名都不一样,如”.gitv.tv”,  “.ottcn.com”, “.cibntv.net”, “.atianqi.com”,对于同一份APP而言,很难进行拆解处理;

  • 网络请求不一,最开始客厅APP有两套网络库,一套是java侧的采用Volley,一套是Native侧的采用CURL,逻辑分散。当然现在已经合一了,统一采用java侧请求。

这儿再单独介绍下客厅业务为啥如此复杂:

  • 牌照管控:广电总局发布的181号文件,提出要对互联网电视进行管控:电视盒子、智能电视等产品所提供的内容,必须在CNTV、华数、上海文广(东方明珠)、南方传媒、湖南电视台、中国国际广播电台以及中央人民电台这7家国有广电系牌照商的集成播控平台上呈现,并接受上述机构的监管。我们客厅的产品就和南方传媒、CNTV、中国国际广播电台、中央人民电台4家牌照方建立了合作关系。既然要接受他们的监督,我们就无法直接使用自己的域名,必须经过他们的服务器进行中转,再通过我们的接入层接入到自己的后台之中。

  • 合作厂商:客厅这个业务和移动端不一样,移动端的大头在于应用分发,而客厅的大头却要靠软件预装实现。与咱们有合作关系的厂商超过了25家,包括主流的电视厂商,如乐视、康佳、创维、TCL等,主流的智能盒子提供商,例如京东、泰捷、微鲸、VST等。这些合作厂商都有自己的特殊需求,例如京东想把京东商城通过单独的频道展现,接口数据通过他们的后台下发,这都对我们业务的多样性和包容性提出了更高的挑战。

于是Android侧发起的网络请求经过系统调用getaddrinfo,被拦截到HttpDNS技术方案之中,通过2.1介绍的HttpDNS技术核心架构层解析出域名对应的ip并返回给系统调用,从而完成整个HttpDNS技术的接入。

上面介绍了Android业务侧接口的域名解析实现部分,你可能会产生疑问,那WebView和CURL又该何去何从呢?

客厅 TV:App HttpDNS 技术接入与实战

图11 三种域名解析过程对比图

图11展示了Android原生域名解析、WebWiew和CURL域名解析过程,从解析过程可以看出,Android原生域名解析和WebWiew域名解析,只是调用到的系统库不同,一个是Libjavacore.so库,一个是libchromium_net.so库,都可以通过DNS HOOK技术实现解析过程。

CURL方式比较尴尬,无法拦截到,可能水平有限没找到系统库。但方法是思考出来的,对于Native层的网络请求CURL,我们通过jni调用java侧域名解析方法InetAddress,该方法会调用到Android原生域名解析过程,通过DNS HOOK技术,采用自建的HttpDNS技术方案,把解析到的ip结果返回到Native层,再通过域名替换,从而完成CURL接入HttpDNS技术的方案。这种方案的优点是只用维护一份java侧的HttpDNS解析,不用在Native层又另外实现一套解析方案。

至此,我们解答了”如何给我一个域名?“这个问题,总结下这一实现方案的优点:

  • Java层利用DNS HOOK技术拦截域名解析请求,Http报文结构和不使用HttpDNS技术一样,对后台完全透明。透明这个词很关键,因为如果是通过域名替换这一方式,报文结构有所差别,可能造成部分请求失败。

  • 不仅无缝完成了主业务的HttpDNS技术接入,相关依赖的业务,如播放器、广告等也都完成了无缝接入HttpDNS技术,只要是Android侧的请求,无论是自建网络库,还是系统网络调用,均直接支持。

  • CURL请求的HttpDNS技术接入也开辟了新的方式,Native层的网络请求通过jni调用Android原生域名解析来实现HttpDNS技术接入。

2.3 HttpDNS技术客户端容错处理

网络请求是APP的根本,一旦出现网络不通,整个APP就像失去了联系一样,无声的消失在开发人员的世界之中。而域名解析又是网络请求的一个根本所在,一旦域名解析出现问题,就会导致网络请求出现错误,从而失去一个用户。为此,在接入HttpDNS技术的过程中我们做了多重容错处理。

1. 全局配置是否走HttpDNS技术

这是整个HttpDNS技术是否接入的总开关,以防止出现特殊情况时我们可以整体关闭该技术的接入,走入系统处理流程之中。特殊情况如我们使用的腾讯公网BGP-IP出现不可用又没有备用IP时,这时候HttpDNS的解析一定是出错的,虽然技术本身可以保证最后一定走入到系统处理流程之中,但却浪费了一些解析的时间成本,故直接关闭整个HttpDNS技术的接入。

2.全局配置BGP-IP更新

一旦BGP-IP(HttpDNS服务器ip)不可用,HttpDNS的解析一定是出错的,这时候就需要有一个备用的BGP-IP来进行替换,从而走入正常流程之中。

3.预埋ip

通过预埋一些重要域名对应的ip列表,当解析出现错误的时候可以直接查找该域名是否有对应的预埋ip,如果查找到则采用预埋ip进行网络请求。预埋ip作为兜底处理,可以提高域名解析的正确率,但有可能出现该ip不可用或延时很长的情况。

4.域名自动过滤

我们的APP有需要外部依赖jar包,这些jar包中可能包含非常多的域名,然而有些域名我们可能不希望其也走入HttpDNS解析之中,于是提供了一个域名过滤的功能,只处理我们明确需要处理的域名解析。

5.特定域名解析失败一段时间内自动屏蔽功能

如果HttpDNS服务器出现对某个特定域名一直解析出错的情况,我们会缓存该域名的出错次数,一旦该域名解析出错三次,则禁止其在1个小时内再通过HttpDNS服务器进行解析,转而使用系统原生解析流程,从而消减解析耗时。

如果您觉得我们的内容还不错,就请转发到朋友圈,和小伙伴一起分享吧~ 客厅 TV:App HttpDNS 技术接入与实战

原文 

http://mp.weixin.qq.com/s/BVF24W6pyfhtoZo9cTbtpA

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 客厅 TV:App HttpDNS 技术接入与实战

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址