笔记： 移动互联网时代 , 如何优化你的网络 —— HttpDNS
-
1.域名解析是什么？
- 域名通过DNS（Domain Name System）系统转化为服务器的IP地址，以方便机器通过IP 进行寻址和通信
-
2.专用名词
-
根域、顶级域、二级域 :DNS系统一般采用树状结构进行组织，以ru.wikipedia.org为例，org为顶级域名，wikipedia为二级域名，ru为三级域名
-
权威DNS:权威DNS即最终决定域名解析结果的服务器，开发者可以在权威DNS上配置、变更、删除具体域名的对应解析结果信息。阿里云云解析（https://wanwang.aliyun.com/domain/dns ）即权威DNS服务提供商。
-
递归DNS：递归DNS又称为Local DNS，它没有域名解析结果的决定权，但代理了用户向权威DNS获取域名解析结果的过程,递归DNS上有缓存模块(结果缓存的时间超过TTL，即过期)，递归DNS会一级一级地查询各个层级域名的权威DNS直至获取最终完整域名的解析结果
-
公共DNS：公共DNS是递归DNS的一种特例，它是一种全网开放的递归DNS服务，而传统的递归DNS信息一般由运营商分发给用户。一个比较典型的公共DNS即Google的8.8.8.8，我们可以通过在操作系统配置文件中配置公共DNS来代替Local DNS完成域名解析流程
-
-
3.解析流程
-
以访问www.taobao.com为例，一次完整的域名解析流程包括：
- 终端向Local DNS发起域名解析请求；
- Local DNS在获取到域名解析请求后首先从Root hints获取根域名服务器的地址（Root hints包含了互联网DNS根服务器的地址信息）；
- 获取了根域名服务器地址后Local DNS向根域名服务器发起DNS解析请求，根域名服务器返回com顶级域名服务器地址；
- 随后Local DNS向com域名服务器发起解析请求，并得到taobao.com二级域名服务器的地址；
- Local DNS向taobao.com二级域名服务器发起解析请求，并最终获得了www.taobao.com的IP地址信息；
- Local DNS将递归查询获得的IP地址信息缓存并返回给客户端；
-
-
4.传统的域名解析面临的问题
-
域名劫持
-
例如域名A应该返回的DNS解析结果IP1被恶意替换为了IP2，导致A的访问失败或访问了一个不安全的站点,常见的域名劫持场景
-
黑客侵入了宽带路由器并对终端用户的Local DNS进行篡改，指向黑客自己伪造的Local DNS，进而通过控制Local DNS的逻辑返回错误的IP信息进行域名劫持
-
由于DNS解析主要是基于UDP协议，攻击者还可以监听终端用户的域名解析请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户，进而控制终端用户的域名访问行为
-
最常碰到的域名劫持现象是缓存污染
- 在接收到域名解析请求时，Local DNS首先会查找缓存，如果缓存命中则返回缓存结果，不再进行递归DNS查询。如果Local DNS针对部分域名的缓存进行更改，比如将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上
-
备注: Https并不能避免域名劫持的问题，域名解析是发生在网络加密请求交互之前，得先进行域名解析，之后才会有网络加密请求交互， https = http + ssl，SSL只是对服务端进行身份确认，而域名解析是发生在ssl握手之前，所以https并不能解决域名劫持的问题
-
-
-
调度不精准
-
解析转发
- Local DNS供应商将请求到自己Local DNS的域名解析请求转发给其他供应商的Local DNS节点，而最终的权威DNS在进行域名解析时会根据Local DNS的IP信息进行智能调度(分配于请求方最近最优相同运营商的CDN节点)，导致Local DNS分配的不是最佳的CDN节点,由于请求是被转发的，从而也延迟用户业务访问时间
-
Local DNS的布署情况
- 由于Local DNS的资源有限，Local DNS的分配甚至并非遵循就近原则。比如有实际案例显示西藏的用户甚至被分配了北京的Local DNS节点C，导致西藏的用户在进行CDN资源访问时被调度到了北京的CDN节点C上，类似的由于调度精度的缺失带来的访问体验的影响是非常严重的
-
-
解析生效滞后
- 权威DNS变更的解析结果生效滞后: Local DNS的部署是由各个地区的各个运营商独立部署的, 因此各个Local DNS的服务质量参差不齐. 在对域名解析缓存的处理上，各个独立节点的实现策略也有区别，比如部分节点为了节省开支忽略了域名解析结果的TTL时间限制，导致用户在权威DNS变更的解析结果全网生效的周期非常漫长。这类延迟生效可能直接导致用户业务访问的异常
-
延迟大
- DNS首次查询或缓存过期后的查询，需要递归遍历多个DNS服务器以获取最终的解析结果，这增加了网络请求的前置延时时间。特别在弱网环境下，往往导致解析超时、解析失败
-
-
5.HTTPDNS
通过HTTPDNS服务，我们可以实现包括防止域名劫持、精准调度、实时解析生效等功能，但在DNS解析开销的优化上，我们需要客户端一起配合
-
防域名劫持
-
HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS
-
商业化的HTTPDNS服务（https://www.aliyun.com/product/httpdns）缓存管理有严格的SLA保障，避免了类似Local DNS的缓存污染的问题
-
-
精准调度
- HTTPDNS在递归解析实现上优化了与权威DNS的交互，通过edns-client-subnet协议（https://datatracker.ietf.org/doc/rfc7871）将终端用户的IP信息直接交付给权威DNS，这样权威DNS就可以忽略Local DNS IP信息，根据终端用户的IP信息进行精准调度，避免LocalDNS的座标干扰
-
实时生效
商业化的HTTPDNS服务上不会存在解析变更全网生效滞后的问题
- HTTPDNS在快速生效方面有专有的方案，配合阿里云的权威DNS服务云解析（https://wanwang.aliyun.com/domain/dns），用户在权威DNS变更的解析结果将快速同步给HTTPDNS，覆盖原有的缓存记录，帮助用户实现秒级的域名解析切换
-
备注： 在DNS解析延迟方面，由于HTTPDNS基于HTTP协议，而HTTP基于TCP协议，对比传统的UDP传输多了一些冗余的握手环节，因此从原理上而言网络请求方面的开销并没有降低。但在实际使用过程中，我们可以通过端上的策略来实现一个零延迟DNS解析的方案,下面从客户端角度实现零延迟DNS解析
-
-
6.域名解析最佳实践
-
预解析
在App启动时，针对业务的热点域名在后台发起异步的HttpDNS解析请求，这部分预解析结果在后续的业务请求中可以直接使用，进而消除首次业务请求的DNS解析开销，提升APP首页的加载速度
-
智能缓存
通过预解析获取的IP有一定的TTL有效时间，我们需要合理地缓存下来进行管理。操作系统本身的DNS缓存粒度比较粗，在客户端我们可以应用更细粒度的缓存管理来提升解析效率.
比如当手机网络切换不同的运营商时(比如移动/联通/电信)，对CDN域名的解析结果会发生变化(返回就近的运营商CDN节点IP). 由于本地有缓存，可以避免在网络切换时减少DNS解析带来的额外开销. 当下一次APP启动时直接读取缓存用于网络访问，以提升首屏加载的速度
-
懒加载
-
核心的实现思路: 业务层的域名解析请求只和缓存进行交互，不实际发生网络解析请求。如果缓存中存在记录，不论过期与否，先返回业务层缓存中的记录,如果缓存中的记录已过期，则异步网络请求进行HttpDNS解析结果并刷新缓存
-
业务场景： 后端IP是固定的若干个节点，因此连续的解析结果在环境不变的情况下有很大概率是保持一致的
-
不适用场景：业务场景下IP变化频繁，并且TTL过期的IP访问不可用，是不建议应用懒加载策略的
-
提个问题，如何快速将权威DNS变更的解析结果同步给HttpDNS
HTTPDNS在快速生效方面有专有的方案，配合阿里云的权威DNS服务云解析（https://wanwang.aliyun.com/domain/dns），用户在权威DNS变更的解析结果将快速同步给HTTPDNS，覆盖原有的缓存记录，帮助用户实现秒级的域名解析切换( 查看上面HttpDNS功能 ---- 实时生效 )
-
-
-
7.HttpDNS接入的注意点
- 客户端接入HttpDNS的过程中，要注意手动设置http请求头的host值，原因是HttpDNS中需要将请求的URL的Host值替换为HttpDNS解析获得的ip,而一般网络库(例如HttpUrlConnection)都会将URL中的Host值赋值给Http请求头中的host头，由于服务端会将http请求头的host值作为请求的域名信息进行处理，这将导致服务器解析出现问题
-
8.学习链接: