Android 网络性能优化（2）DNS优化

系列文章目录

1. Android 网络性能优化（1）概述
2. Android 网络性能优化（2）DNS优化
3. Android 网络性能优化（3）复用连接池
4. Android 网络性能优化（4）弱网优化

---

1. 概述

在Android 网络性能优化（1）概述中，我整理了部分网络会遭遇瓶颈的地方，并且提出了可以优化的做法或者思路。

而网络交互最初是的动作就是连接，所以我认为优化的方向先要从网络连接这个点切入。

而连接的最初的动作是DNS解释，在第一篇中，描述DNS的状况是：
域名换ip。这一步看似简单却充满陷阱，10分钟的DNS的Cache过期时间，200~2000ms不等的DNS耗时，坑了无数应用。
解决无非有三个策略：

• ip直连
• 域名重用（收敛）
• HttpDNS

不过仅仅用一段话来描述DNS的疼点还是比较生硬的，所以在学习ip直连和HttpDNS之前，我需要先弄懂DNS出现问题的具体原因。

2. DNS

2.1 DNS是什么

在网络世界中，我们如果想要访问某一个服务器的东西，我们需要知道它的ip地址是多少，这样才能去连接走Http。
但是 ip地址32位二进制的数字，它的常用格式： XXX.XXX.XXX.XXX 显然，我就是为了访问一个服务器，你让我记住这么一长串的数字，这不是在为难人吗？我每天都要访问数十个网站，一秒钟几亿上下，每个网站的ip都要记在小本子上，而且一个服务器可能还有好几个ip，然后在访问时还要很细心一个个敲在输入框中…

所以为了解决这种体验问题，DNS（Domain Name System）就这么出现了。服务器可以申请得到域名，比如说我们熟知的百度的域名就是 ： www.baidu.com。这样我们在浏览器的输入框只要输入这个域名，就能访问百度的服务器了。

那我们看到DNS出现，不用去记那么一长串的ip地址了，只用记住域名就可以了，域名一般来说都是英文加数字格式，很方便人类进行记忆。

那我们已经很清楚DNS的作用了，我们告诉DNS域名，DNS帮我们找到ip地址，即 域名换ip，来看下下图：

这样人类就可以很哈批的去访问各种网站了。

注：DNS大部分都是基于UDP的，所以DNS本身具有UDP连接的不可靠性

2.2 DNS服务器结构

每天都有成万上亿的人在互联网冲浪，这说明DNS没有一刻不在被使用，所以DNS服务器一定要保证高可用、高并发和分布式服务器。所以有必要了解DNS的结构。

我们先来看下域名的空间结构：

像 com、net、cn这些代表的就是顶级域名（也叫根域名），顶级域名前面的就是二级域名，二级域名前面的是三级域名。
比如 www.baidu.com ， .com就是根域名， .baidu就是二级域名， www就是三级域名。根据这个我们再来看看DNS的结构。

从理论上说，任何形式的标准域名要想被实现解析，按照技术流程，都必须经过全球“层级式”域名解析体系的工作，才能完成。所以DNS的服务器结构是根据官方的层级式来分类的，有下面四类：

• 根域名服务器（Root Name Server）
• 顶级域名服务器（Top-level Name Server）
• 权威域名服务器（Authoritative Name Server）
• 本地 DNS 服务器（Local DNS Server）

2.2.1 根域名服务器

根域名服务器是互联网域名解析系统（DNS）中最高级别的域名服务器，负责返回顶级域的权威域名服务器地址。
“层级式”域名解析体系第一层就是根服务器，负责管理世界各国的域名信息，在根服务器下面是顶级域名服务器，即相关国家域名管理机构的数据库。

一个域名必须首先经过根数据库的解析后，才能转到顶级域名服务器进行解析。

在根域名服务器中虽然没有每个域名的具体信息，但储存了负责每个域（如.com,.xyz,.cn,.ren,.top等）的解析的域名服务器的地址信息。

全世界域名的最高管理机构，是ICANN，在美国加州，它制定了根域名的规范，管理所有域名的顶级域名。它就是根域名服务器。

当然了，域名这么多，来自各个国家各个区域，所以为了便于管理，所有域都会被一些组织、群体所托管，比如 .cn域名的托管商就是中国互联网络信息中心（CNNIC），它决定了.cn域名的各种政策。而像Verisign管理着 .com、.net等，而这些服务器就是顶级域名服务器了，如下图所示：

也就是说，当我们输入 www.example.cn时，会先去找根域名服务器ICANN，然后它会翻列表，发现 .cn的解析是被CNNIC管的，那么你就要去找CNNIC做顶级域名解析。

一般来说，根域名列表很少变化，所以ISP会帮我们缓存这些列表，这样就可以省去找根域名服务器的时间了。

2.2.2 顶级域名服务器

所有顶级域名服务器的名称和IP地址是在根服务器注册的。它们的作用是 解析顶级域名。
比如上一节中：

• 用来解析 .cn 域名的服务器-------CNNIC
• 用来解析 .com、.net域名的服务器------Verisign

而顶级域名服务器里面解析好域名后，会得到该域名所在权威域名服务器地址：

2.2.3 权威域名服务器

权威域名服务器， 本质上是一个 Map表： K -> 域名 V -> ip列表
这样，权威域名服务器就会在这个表里面根据域名找到最终的ip，返回请求者这个ip地址。

2.2.4 本地DNS服务器

显然，本地服务器并不具备寻址能力，因为不可能所有的机器都做为DNS服务器来存储地址，所以本地DNS服务器的作用是 缓存DNS域名与ip地址的映射
一般来说，Local DNS服务器在运营商那里，而DNS劫持一般的目标都会在本地DNS服务器上。

2.2.5 为什么要这样分级？

看到这里，应该已经有很多同学把DNS服务器结构和 HTTPS的证书信任链联想在一起了…（可以看这篇：Android 深入Http（3）Https的工作机制）

那大家就知道为什么一个简简单单的 域名换ip的事情，要分成这么多级了。

因为根服务器不可能管理者成千上万个域名-ip映射表。所以它会把这个根据顶级域名交给下层，如果你是 .net你就交给谁管，你是 .cn你就交给谁管。
而 一个顶级域名服务器也不可能管理着所有的 域名-ip映射表，因为并发量太高了，所以它会在解析好后，交由下层处理。当到了由大量权威服务器支撑的映射表后，就能保证高并发量、高可用了。

2.3 DNS寻址过程

这里总结一下DNS的寻址过程，可以看下图：

1. 客户端输入一个网址即域名，到本地DNS服务器
2. 本地服务器DNS查找域名缓存，如果命中对应的ip地址，则返回该ip，如果没有命中，则发请求给根域名服务器请求解析
3. 根域名解析好后，返回 顶级域名服务器的地址
4. 本地DNS 向顶级域名服务器发送请求。
5. 顶级域名查看缓存，有没有对应ip，如果有直接返回，如果没有，则解析该域名，查找到目标 权威域名服务器的地址
6. 本地DNS 向 权威域名服务器发送请求
7. 权威域名服务器在数据库中查表，返回对应的ip地址
8. 本地DNS服务器 把 ip地址 返回给 客户端，并且缓存该地址。

2.4 DNS坑点

2.4.1 DNS劫持

DNS劫持又叫域名劫持，是指攻击者通过某种手段篡改了某个域名的解析结果，使得指向该域名的IP变成了另一个IP。

这里不过多讲解，因为内容很多，而且和本章没啥关联。

PS：你在看这篇文章时，左下角、右下角如果出现了广告，这很有可能能使DNS被劫持了，当然了，这也可能就是官方自己的广告= =。

2.4.2 DNS 服务器故障

每年都会经常出现 一些DNS服务器的故障，如果你恰好遇上，体验就很不好。这是因为DNS寻址是我们访问服务器的必要过程，DNS服务器故障直接导致寻不到址，或者寻址速度降低。

2.4.3 DNS 调度不准确

说不好一些DNS服务器里面的算法写的有点水，调度性能低下，这样会也会直接导致我们寻址速度变慢。

2.5 小结

总的来说，DNS寻址有下面几个缺点：

• 不稳定
  遭遇DNS劫持或DNS服务器宕机
• 不准确
  某些小运营商没有 DNS 服务器，直接调用其他运营商的 DNS 服务器，最终直接跨网传输
• 不及时
  运营商可能会修改 DNS 的 TTL(Time-To-Live，DNS 缓存时间)，导致 DNS 的修改，延迟生效。
  除了运营商，DNS服务器本身的索引算法也可能会有调度的问题（不过概率蛮小的）

所以看到DNS其实也有蛮多缺点的，那么我们该怎么去优化呢？

首先我们是开发App的，我们面向的问题是App在进行网络请求时，更快更稳定。那么最暴力的方法就是绕过DNS，我们使用DNS的原因是我们记不住冗长的ip地址，但在App开发中，App程序本身是可以记得住这些ip地址的，那就让它去记就行了，让它直接访问ip地址，就减少了DNS的寻址过程。

而 ip直连 就是以此为基础的实现方案。

3. ip直连

3.1 原理

客户端从服务器拉取配置文件，配置文件包含了域名和ip地址的映射，客户端在之后的网络请求中，在配置中根据域名找到ip，直接连接这个ip地址进行请求。

而最开始拉取配置文件这个动作是经过DNS的，而之后都是绕过DNS的。

ip直连有以下的优势：

• 在之后的连接中，都会绕过DNS，这样可以提高连接速率
• 可以降低DNS劫持的风险
• 一般都能拿到多个ip地址，所以可以进跑马比较，就快连接，这样可以提高连接质量

3.2 一个Http的直连demo

举一个最简单的直连的例子。假如我们需要直连百度，那我们先在cmd中，直接获取到百度的ip：

>ping www.baidu.com

正在 Ping www.a.shifen.com [14.215.177.39] 具有 32 字节的数据:
来自 14.215.177.39 的回复: 字节=32 时间=6ms TTL=50
来自 14.215.177.39 的回复: 字节=32 时间=6ms TTL=50
来自 14.215.177.39 的回复: 字节=32 时间=6ms TTL=50
来自 14.215.177.39 的回复: 字节=32 时间=6ms TTL=50

14.215.177.39 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 6ms，最长 = 6ms，平均 = 6ms

上面就已经拿到了百度的ip。接着在我们App中运用：

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        // 直接加载这个页面
        webview.loadUrl("http://14.215.177.39/")
    }
}

这就是最简单的ip直连，绕过了DNS的域名寻址。 但是实际上，我们也不会这样简单的用，有三点：

1. ip地址是会变的。比如人家服务器重启一下，就变了
2. 一个服务器下面是允许有多个子服务器的，所以这些子服务器对外的ip是一样的。在访问时，如果不带上Host，可能会找不到想要的服务器。
3. 现在基本都是使用 Https来访问了，而Https需要验证验证书，所以步骤会更加复杂。

3.3 Https的ip直连

Https应用到ip直连上，需要面临一个问题：证书的校验。

在Https建立连接中，有这么一步，客户端需要拿着操作系统的根证书列表去验证的域名的，而一般来说，这个动作都是由运营商DNS来做的。而ip直连没有了DNS，代表着我们需要手动去验证。

举个例子：当你打开Chrome，使用ip直连的方式访问某个网站，并且使用Https的形式，即: https://xxx.xxx.xx/，你会看到下面这个页面：

你需要在界面输入 "thisisunsafe"来绕过证书验证访问该界面。

3.3.1 使用HttpsURLConnection实现ip直连

为了解决上述问题，我们需要手动验证，所幸的是Android SDK提供api供我们去验证，看了下别的语言的情况，好像Dart就没有。

        Thread {
            val url = "https://140.205.160.59/"
            val hostName = "baidu.com"
            val connection = URL(url).openConnection() as HttpsURLConnection
            // 1
            connection.hostnameVerifier = HostnameVerifier { host, session ->
                HttpsURLConnection.getDefaultHostnameVerifier().verify(hostname, session)
            }
            
            connection.connect()
        }

来看看上面代码。
注释1：
SDK提供了 HttpsURLConnection.getDefaultHostnameVerifier().verify() 的接口来验证，我们将我们要访问的域名代入，走低层校验逻辑。这部分我没阅读过源代码，我的猜测就是使用操作系统的根证书来验证。

3.3.2 解决多域名ip直连问题（SNI技术）

在3.2节中，ip直连还面临了一个问题，即一个服务器下面是允许有多个子服务器的，所以这些子服务器对外的ip是一样的。在访问时，如果不带上Host，可能会找不到想要的服务器。

但是Https中存在一个问题：即TLS握手的建立是在Http请求之前的，这说明就算你在请求行中带上Host也没用，因为顺序先后的问题，服务器根本不知道你要访问的是哪个域名。

而SNI(Server Name Indication)技术则解决了这个问题：

SNI通过让客户端发送虚拟域名的名称作为TLS协商的一部分来解决此问题。这使服务器能够提前选择正确的虚拟域名，并向浏览器提供包含正确名称的证书。

而这个动作一般由运营商DNS来做的，所以绕过DNS，就需要自己手动连接。而SDK也提供了这些Api给我们。

下面是高于Api24的做法：

     // 拿到SSLSocket
     val ssl = SSLSocketFactory.getDefault().createSocket() as SSLSocket
     // 使用 SSLParameters来设置SNI技术
     val sslParameters = ssl.sslParameters
     // 设置SNI，该Api要高于24
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
          sslParameters.serverNames = listOf(SNIServerName(...))
     }

低于24的代码，则需要继承 SSLSocketFactory，重写 createScoekt来返回一个实现SNI的SSLSocket，大致代码如下：

/**
     * 创建一个SSLSocket，就是建立握手前协商通道，这个时候利用SNI，为服务器传入一个虚拟域名
     * 这样服务器根据可以根据虚拟域名，返回该域名的证书
     */
    override fun createSocket(s: Socket?, host: String?, port: Int, autoClose: Boolean): Socket {
        // 拿到设置的Host
        var peerHost = conn.getRequestProperty("Host")
        // 获取Socket连接的ip地址
        val address = s?.inetAddress
        if(peerHost == null){
            // 如果没有，则拿默认的
            peerHost = host
        }
        if(autoClose){
            // 原来的Socket可以不需要了
            s?.close()
        }

        // 获取一个 SSLCertificateSocketFactory
        val sslSocketFactory = SSLCertificateSocketFactory.getDefault(0) as SSLCertificateSocketFactory
        // 建立一个SSLSocket, 但是这时还没有带证书验证
        val ssl = sslSocketFactory.createSocket(address, port) as SSLSocket
        
        // 支持 TLS 1.1/1.2 版本
        ssl.enabledProtocols = ssl.enabledProtocols
        
        // 为该域名设置SNI
        sslSocketFactory.setHostname(ssl, peerHost)
        
        val session = ssl.session
        //获取低层默认证书验证器
        val hostnameVerifier = HttpsURLConnection.getDefaultHostnameVerifier()
        if(!hostnameVerifier.verify(peerHost, session)){
            // 如果验证失败，抛出错误
            throw SSLPeerUnverifiedException("Cannot verify hostname: $peerHost")
        }
        
        return ssl
    }

然后为 HttpsConnectionURL设置这个Factory：

connection.sslSocketFactory = SNISocketFactory(connection)

这大概就是ip直连的思路，当然了，在实际实战时，还是会有一些坑的，但是Android网络这方面的坑都被前人踩完了，所以大胆使用，不懂的可以直接百度、google就行了。

4. HttpDNS

4.1 原理

传统的DNS基本上都是基于UDP协议的，加上咱运营商参差不齐的管理Local DNS服务器，导致我们发出域名解析的那一瞬间，一切就变得不可控了。

而优化DNS的本质是让域名解析的过程变得可控，ip直连的本质做法是绕过DNS，直接不走DNS解析了，从根本上上解决问题。
而 Https另辟蹊径：既然udp不可靠，那么就换成可靠的tcp，既然运营商Local DNS容易被劫持，那就不用运营商的，用自己的服务器。

HttpDNS顾名思义，使用Http，去发出域名解析的请求，而请求的服务器是HttpDNS服务器集群，是云服务器，效率更优于运营商DNS，它利用算法优势查询最优域名，我们不需要了解其内部实现，只需要知道，它比传统Local DNS要强大就可以了。如下图所示：

而HttpDNS服务器集群，可以自己开发， 也可以使用现成的，比如腾讯云、阿里云、微信都有他们自己研发的HttpDNS，收费都不高，接入方便。

4.2 使用HttpDNS的优势

请看下表：

功能	HTTPDNS	传统DNS
防劫持	Http基于Tcp，具有一定防劫持功能，传输可靠	大部分基于Udp，容易被黑客篡改，防劫持能力垃圾的一批
调度算法	根据来源ip，就近、就快的接入业务节点	黑匣子，每个运营商都有自己的接入策略，调度策略参差不齐
解析延迟	对热点域名解析、缓存DNS解析结果、解析结果懒更新策略等方式实现0ms更新	无差别多重服务器查询，解析时长200~2000ms不等
快速生效	避免Local DNS不遵循权威TTL，解析结果长时间无法更新的问题	会自行修改DNS 的 TTL(Time-To-Live，DNS 缓存时间)，导致 DNS 的修改，延迟生效。
业务成功率优化	有效降低无线场景下解析失败的比率	未知

4.3 OkHttp接入HttpDNS

OkHttp组件允许我们接入HttpDNS，所以实现起来不是很难。 OkHttp默认是使用Android SDK的服务 InetAddress来解析域名，所以我们需要替换这个就行了。

步骤如下：

1. 在App init的时候根据域名去HttpDNS拉取ip地址，将这些ip地址存储在本地DnsCache列表中
2. 实现 DNS接口，重写lookup()，当OkHttp使用网络请求时，会走这个方法解析域名，那么让它去DnsCache列表中取就行了，如果没有的话，就走系统默认的DNS解析
3. 调用OkHttp的 .dns()方法，使用第二步中的对象，替换OkHttp的域名解析实现。

我们需要自己实现DNS接口，并实现 lookup方法：

class HttpDNS : Dns {

    // DNS cache
    val dnsCache: MutableMap<String, MutableList<InetAddress>>? = null

    /**
     * 寻址方法, 必须重写
     */
    override fun lookup(hostname: String): MutableList<InetAddress> {
        val ip = getIpByHost(hostname)
        // 如果读不到ip，则使用系统默认的 InetAdaaress 来解析地址
        return ip ?: Dns.SYSTEM.lookup(hostname)
    }

    /**
     * 查找缓存
     */
    private fun getIpByHost(hostname: String): MutableList<InetAddress>? {
        return dnsCache?.get(hostname)
    }

    /**
     * 获取dns方法，一般在打开App的时候根据域名去获取ip列表，放在缓存里面
     */
    private fun refresh(hostName: String): MutableList<String>? {
        val ipAddress: MutableList<String>? = null
        // 做网络请求, 这里是HttpDNS的服务器url, 拿着HostName去解析
        val reqUrl: String = HTTPDNS_SERVER_URL;
        val request = Request.Builder().url(reqUrl)
            .addHeader("domain", hostName)  // 在请求中代入hostname
            .build()

        OkHttpClient().newCall(request).enqueue(object : okhttp3.Callback {
            override fun onFailure(call: Call, e: IOException) {
                Log.w("Rikka", "解析失败")
            }

            override fun onResponse(call: Call, response: Response) {
                Log.d("Rikka", "解析成功")
                // 反正这里就是把解析的数据丢进cache中
                dnsCache?.put(hostName, call.xxxxx)
            }
        })
        return ipAddress
    }
}

最后在 OkHttp中加入这个dns：

        okHttpClient = new OkHttpClient().newBuilder()
                .dns(new HttpDNS())  // 加入这个DNS
                ...
                .build();

使用HttpDNS + OkHttp的话，通用性更强，因为OkHttp组件是可以加拦截器的，在SNI、Https的场景下都适用，而且规避了证书校验、域名检查环节。最重要的是使用非常的简单。

5. 域名收敛

在讲解域名收敛之前，需要先了解域名发散。

5.1 域名发散

PC时代，为了突破突破浏览器对于同一域名并发请求数的限制，使用域名发散为同一个服务申请多个域名，从而可以一定程度上提高并发量。简单的来说就是：

http 静态资源采用多个子域名

为什么浏览器会有并发限制呢？主要有两个原因：

• 服务器本身承载能力差，所以在高并发的场景下，一些服务器都会崩，所以为了克服，只能由浏览器进行限制了。
• 防止 DDOS 攻击。最基本的 DoS 攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。如果最大并发量不受限制，那么DoS攻击就可以使用大量的请求，直至服务器崩溃

5.2 域名收敛

emmm显然，在上面介绍了DNS和域名发散后，我们显然发现：如果同时请求多个域名，那么DNS的解析速度肯定严重影响着整个请求过程。

移动端时代，响应速度是App赖以生存的根本，如果因为并发请求导致DNS并发，会产生 速度、开销的严重消耗。

所以解决域名发散带来的问题的方案有是： 域名收敛

移动端的网络请求模式和PC浏览器不同，移动端一般一个页面请求1~3个接口，所以很少场景达到一个端的高并发，所以可以接口收拢，比如一个页面只用一个接口。减少DNS寻址

5.3 SPDY / Http2

我们都知道 spdy、http2，或者 http3，都会使用到多路复用技术：即以最少的连接做最多的请求。
这很符合域名收敛的观念，所以支持这些技术的场景下可以尝试的去进行优化~

6. 参考文章

《图解TCP/IP》
DNS入门：域名结构与域名服务器
Wiki：根域名服务器
根域名的知识
Android 网络优化，使用 HTTPDNS 优化 DNS，从原理到 OkHttp 集成
Wiki:服务器名称指示
HTTPS（含SNI）业务场景“IP直连”方案说明
【前端性能】浅谈域名发散与域名收敛