踩了个DNS解析的坑，但我还是没想通

hello大家好，我是小楼。

最近踩了个DNS解析的小坑，虽然问题解决了，但排查过程比较曲折，最后还是有一点没有想通，整个过程分享给大家。

背景

最近负责的服务要置换机器。置换机器可能很多小伙伴不知道是干啥，因为大家平时接触不到，我简单解释一下什么是机器置换以及为什么需要机器置换。

机器置换通俗地讲就是更换机器，把服务从一台机器迁移到另一台上去。

为什么要机器置换呢？ 表面原因可能是机器硬件故障、或者机器过了保修期。

有些小伙伴可能就想问，我在公司也负责了很多服务，为啥从来没有置换过机器呢？原因可能是用了容器，没有直接部署在物理机上，置换机器的任务被转移给了云平台的运维人员；还可能是你们有专门的运维帮忙做了这件事，对开发人员来说几乎是透明的。

我负责的服务为啥要置换呢？因为机器过保了。服务为啥部署在物理机上呢？因为它是个基础服务，和一般服务不太一样，有一些限制，只能在物理机上部署。为啥没有运维人员帮忙呢？因为公司很多基础服务是自运维，开发者既做开发又是运维。

说完机器置换，再来聊聊这个基础服务，它是一个Go写的服务，不停地发送HTTP请求，记住这点就好，其他不重要。

这个服务在置换机器后，HTTP请求的耗时慢了不少，如下图，黄色为老机器，蓝色为新机器，指标的值就是HTTP请求的耗时（毫秒），大概1.5倍的差距。这就是今天要分享的问题，接下来说说我的排查过程。

问题排查

这种情况，先去看了机器的各项指标，如CPU、网络情况等等，看看是否有异常，确认是否被其他指标影响了。但看了一圈下来，发现新机器的各项指标甚至还优于老机器。

接着去询问了提供机器的同学，看看机器是否有异常，结果也是没有。

既然HTTP请求变慢，就想到看看是请求的哪个环节变慢了，用如下的命令来测试下，域名我用百度的域名来代替：

curl -o /dev/null -s -w %{time_namelookup}::%{time_connect}::%{time_total}“\n” http://www.baidu.com

这里的各个参数代表含义（还有一些其他参数也可用）：

• time_total 总时间，按秒计。精确到小数点后三位。
• time_namelookup DNS解析时间,从请求开始到DNS解析完毕所用时间。
• time_connect 连接时间,从开始到建立TCP连接完成所用时间,包括前边DNS解析时间，如果需要单纯的得到连接时间，用这个time_connect时间减去前边time_namelookup时间。以下同理，不再赘述。
• time_appconnect 连接建立完成时间，如SSL/SSH等建立连接或者完成三次握手时间。
• time_pretransfer 从开始到准备传输的时间。
• time_redirect 重定向时间，包括到最后一次传输前的几次重定向的DNS解析，连接，预传输，传输时间。
• time_starttransfer 开始传输时间。在client发出请求之后，Web 服务器返回数据的第一个字节所用的时间

这样能看到域名解析、连接、传输各个阶段的耗时情况，新老机器对比，如果有一项特别高，那么这项肯定有问题

• 新机器：0.001484::0.001743::0.007489
• 老机器：0.000681::0.000912::0.002475

简单计算一下：

• 新机器：DNS解析耗时0.001484秒，连接建立耗时0.000258秒，总耗时0.007489秒
• 老机器：DNS解析耗时0.000681秒，连接建立耗时0.000231秒，总耗时0.002475秒

虽然从这次的测试数据来看，新机器DNS解析似乎慢了一点，但你仔细看这个数值，几乎对请求的总体耗时没啥影响，而且多测试几次，发现这两台机器的DNS解析其实差不多。

但还是不放心，验证DNS是否存在问题，再用dig命令去试一下

dig www.baidu.com

执行时，明显感觉到了卡顿，确定是DNS有问题了。

问题解决

一开始，我去网上搜索了一下DNS慢的相关文章，找到了一篇文章《记一次Go net库DN