Linux网络栈基于了TCP/IP协议栈构建，在不同的层级，关注的网络性能不尽相同
在应用层，关注的是应用程序的并发数，每秒请求数，处理延迟，错误数利用wrk JMeter等，进行模拟负载，获得测试结果
传输层，则是TCP UDP等传输层的协议，TCP连接数等，使用iperf netperf等，进行测试
再到了下层，就是网络层，即为PPS，Linux自带的pktgen，进行测试这个指标
今天，我们拿DNS，来进行测试网络相关的问题
DNS相比不用说，域名系统，提供域名和IP之间的映射关系的查询服务
域名是全球唯一的，由一串用点分割的字符组成，用于区分互联网中某一台或者一组计算机的分别
比如time.geekbang.org
这里面org是顶级的域名，geekbang为二级域名 time为三级域名
DNS的解析基于UDP和TCP，多数为UDP，域名服务器舰艇在端口53上
既然域名以分层的结构进行管理，相对应的，域名解析其实也是递归的方式，每个层级的域名服务器进行递归解析，知道得到结果
对于本机去请求哪个域名服务器，获得结果，可以利用如下的命令
cat /etc/resolv.conf
nameserver 114.114.114.114
而且，DNS域名解析的结果，可以进行缓存，支持A CNAME MX NS PTR等多种类型
A记录，将域名转为IP
CNAME记录 创建别名
NS记录 表示域名对应的域名服务器地址
和实际场景一结合，就是查询这个域名的IP地址，然后通过IP进行访问Web
而NS记录，可以利用UNIX的uslookup命令进行拆线呢
|
$ nslookup time.geekbang.org
# 域名服务器及端口信息 Server: 114.114.114.114 Address: 114.114.114.114#53 # 非权威查询结果 Non-authoritative answer: Name: time.geekbang.org Address: 39.106.233.17 |
我们获取到了114返回的非权威结果
毕竟114并非权威域名服务器
如果想要查看递归结果，我们可以使用DNS的解析工具dig
|
# +trace表示开启跟踪查询
# +nodnssec表示禁止DNS安全扩展 $ dig +trace +nodnssec time.geekbang.org ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +trace +nodnssec time.geekbang.org ;; global options: +cmd . 322086 IN NS m.root-servers.net. . 322086 IN NS a.root-servers.net. . 322086 IN NS i.root-servers.net. . 322086 IN NS d.root-servers.net. . 322086 IN NS g.root-servers.net. . 322086 IN NS l.root-servers.net. . 322086 IN NS c.root-servers.net. . 322086 IN NS b.root-servers.net. . 322086 IN NS h.root-servers.net. . 322086 IN NS e.root-servers.net. . 322086 IN NS k.root-servers.net. . 322086 IN NS j.root-servers.net. . 322086 IN NS f.root-servers.net. ;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 1340 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. ;; Received 448 bytes from 198.97.190.53#53(h.root-servers.net) in 708 ms geekbang.org. 86400 IN NS dns9.hichina.com. geekbang.org. 86400 IN NS dns10.hichina.com. ;; Received 96 bytes from 199.19.54.1#53(b0.org.afilias-nst.org) in 1833 ms time.geekbang.org. 600 IN A 39.106.233.176 ;; Received 62 bytes from 140.205.41.16#53(dns10.hichina.com) in 4 ms |
从114中查询到根域名服务器的NS记录
然后选取一个根域名服务器，进行查询，然后递归往下走，基本流程如下
对于局域网的DNS解析，可以使用本地的host文件，或者在局域网中搭建DNS服务器
说完了这些基本示例
查看出现了问题之后，如何进行定位
第一个：
首先是尝试执行DNS查询命令，利用的还是nslookup命令
nslookup time.geekbang.org
发现timeout错误了
看到这里，是不是网络不通了吗，是没有连接到114.114.114.114吗
我们尝试ping一下114
发现是可以正常ping的通的
这是不是因为我们的域名解析没有正常的连接到114上呢？在 etc/resolv.conf文件，配上DNS就可以了
执行下面的命令，再执行nslookup命令，就可以查看正常解析了
|
/# echo “nameserver 114.114.114.114” > /etc/resolv.conf
/# nslookup time.geekbang.org Server: 114.114.114.114 Address: 114.114.114.114#53 Non-authoritative answer: Name: time.geekbang.org Address: 39.106.233.176 |
第二个，DNS的解析不稳定问题
我们查看第二个案例，就是先运行nslookup命令，解析ip地址，不过这次nslookup前面需要加上time命令，查看时间
|
/# time nslookup time.geekbang.org
Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: time.geekbang.org Address: 39.106.233.176 real 0m10.349s user 0m0.004s sys 0m0.0 |
这一次的解析，花费了10秒，这是为什么呢？
根据前面的讲解，我们现在明白，DNS的解析，就是一个UDP的包的发送和接收
那么解析不稳定的话，可能是DNS服务器本身有问题
客户端到DNS的服务器的网络延迟较大
或者是DNS请求到响应包，某些情况下，被链路的网络设备弄丢了
nslookup的输出，可以看出，客户端的连接DNS是8.8.8.8,是Google提供的DNS服务，那么首先排除DNS本身问题，那么是不是网络延迟
ping可以测试服务器的延迟，尝试ping一下
|
/# ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=31 time=137.637 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=31 time=144.743 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=31 time=138.576 ms — 8.8.8.8 ping statistics — 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 137.637/140.319/144.743/3.152 ms |
上面ping中的平均延迟高达140ms，这就是为何解析如此慢的原因了
我们尝试替换DNS服务器，再次进行解析nslookup解析命令
|
/# echo nameserver 114.114.114.114 > /etc/resolv.conf
/# time nslookup time.geekbang.org Server: 114.114.114.114 Address: 114.114.114.114#53 Non-authoritative answer: Name: time.geekbang.org Address: 39.106.233.176 real 0m0.064s user 0m0.007s sys 0m0.006s |
这样，解析的时候很快了
但是多次运行nslookup，由时候的运行时间会长达1s
这种原因，可能是DNS没有走本地的缓存，而是每次都去请求DNS服务器了
这就需要我们为DNS开启缓存，即使用dnsmasq
常用的DNS缓存服务，作为DHCP服务来使用，安装和配置都比较简单，性能也可以满足绝大多数应用程序对DNS缓存的需求
我们尝试启动dnsmasq
|
/# /etc/init.d/dnsmasq start
* Starting DNS forwarder and DHCP server dnsmasq [ OK ] |
然后将DNS服务器修改为dnsmasq的监听地址，比如127.0.0.1,进行执行nslookup命令
这样，就可以将DNS进行本地的缓存，方便快速的解析
今天，说明了DNS的基本原理，掌握了DNS的一些问题及分析思路
DNS提供了域名和IP间映射关系的查询服务，但是如果在请求的过程中，发现解析DNS需要等待至少1s，那么这就是实际应用上的一个维妮塔
对此，我们总结了几种常见的DNS优化方法
DNS结果进行缓存，但是需要注意缓存过期的问题，一旦过期，需要对DNS服务器继续重新获取，不过是可以接受的
DNS解析的结果进行预缓存，是浏览器等应用常用手段，可以不等用户点击超链接，而是后台默默的解析DNS
使用HTTPDNS取代常规DNS解析
基于DNS的全局负载均衡 GSLB，为服务提供了负载均衡和高可用功能