我们学习了DNS的基本概念，
DNS一般为了暴露到公网，都会绑定对应的域名，方便了人们的记忆，避免了后台的Ip修改带来的影响
但是DNS本身会有一定的性能问题
这种时候，我们可以借助nslookup和dig的调试，可以分析DNS的调用过程，配合ping工具进行调试，可以定位出性能瓶颈，
在上节中，我们在定位DNS的问题的时候，还用了一个常用的测试工具，ping可以帮助我们抓取延迟的问题，除此之外，还有的常见工具有tcpdump和Wireshark
两者中tcpdump支持命令行格式使用，常用于服务器端的抓取和分析网络包
另外的Wireshark除了支持抓包外，还提供了强大的图形界面和汇总分析工具，适合dump后进行慢慢的分析
实际生产中，我们也是先用tcpdump进行抓包，然后使用Wireshark进行分析
基本的操作如下
首先建议，在Win端进行安装Wireshark
然后，我们那一个ping工具的问题，来讲解tcpdump
我们先执行一个iptables的命令，获取信息如下
| # 禁止接收从DNS服务器发送过来并包含googleusercontent的包
$ iptables -I INPUT -p udp –sport 53 -m string –string googleusercontent –algo bm -j DROP |
然后进行ping，获取结果如下
| # ping 3 次（默认每次发送间隔1秒）
# 假设DNS服务器还是上一期配置的114.114.114.114 $ ping -c3 geektime.org PING geektime.org (35.190.27.188) 56(84) bytes of data. 64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=1 ttl=43 time=36.8 ms 64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=2 ttl=43 time=31.1 ms 64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=3 ttl=43 time=31.2 ms — geektime.org ping statistics — 3 packets transmitted, 3 received, 0% packet loss, time 11049ms rtt min/avg/max/mdev = 31.146/33.074/36.809/2.649 ms |
ping的输出中，每次的请求响应都是30ms，并没有什么问题，但是总时间却是超过了11s，有点不可思议
这样，我们按照上一次的思路，查看是否是DNS服务器缓慢问题？
这样我们使用nslookup进行查看
time nslookup geektime.org进行查看
| $ time nslookup geektime.org
Server: 114.114.114.114 Address: 114.114.114.114#53 Non-authoritative answer: Name: geektime.org Address: 35.190.27.188 real 0m0.044s user 0m0.006s sys 0m0.003s |
整体看出，域名解析还是很快的，只需要44ms，比11s更短
那么域名服务器没有问题，还可以怎么分析呢？
这时候考虑请出来 tcpdump了，进行抓包，查看ping如何收发网络包
命令如下
| $ tcpdump -nn udp port 53 or host 35.190.27.188 |
这条命令的具体解释如下：
-nn 不解析抓包中的域名 协议 以及 端口号
udp port 53 只显示UDP协议的端口 和端口为53的包
host 35.190.27.188 只显示IP地址为35.190.27.188的包
中间的or，表示或的关系，满足任一一个，就进行展示
然后我们继续进行ping
ping -c3 geektime.org
并查看tcpdump的输出
| tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:02:31.100564 IP 172.16.3.4.56669 > 114.114.114.114.53: 36909+ A? geektime.org. (30) 14:02:31.507699 IP 114.114.114.114.53 > 172.16.3.4.56669: 36909 1/0/0 A 35.190.27.188 (46) 14:02:31.508164 IP 172.16.3.4 > 35.190.27.188: ICMP echo request, id 4356, seq 1, length 64 14:02:31.539667 IP 35.190.27.188 > 172.16.3.4: ICMP echo reply, id 4356, seq 1, length 64 14:02:31.539995 IP 172.16.3.4.60254 > 114.114.114.114.53: 49932+ PTR? 188.27.190.35.in-addr.arpa. (44) 14:02:36.545104 IP 172.16.3.4.60254 > 114.114.114.114.53: 49932+ PTR? 188.27.190.35.in-addr.arpa. (44) 14:02:41.551284 IP 172.16.3.4 > 35.190.27.188: ICMP echo request, id 4356, seq 2, length 64 14:02:41.582363 IP 35.190.27.188 > 172.16.3.4: ICMP echo reply, id 4356, seq 2, length 64 14:02:42.552506 IP 172.16.3.4 > 35.190.27.188: ICMP echo request, id 4356, seq 3, length 64 14:02:42.583646 IP 35.190.27.188 > 172.16.3.4: ICMP echo reply, id 4356, seq 3, length 64 |
前两行是tcpdump的选项以及接口的基本信息，第三行开始，就是抓取的网络包的输出，输出的格式，都是时间戳 协议 源地址 源端口 目的地址 目的端口 网络包
第一条，就是从本地IP发到114.114.114.114的A记录查询请求，其中 36909+ 查询表示值，出现在响应中，加号代表启用递归查询
A？ 是查询A,域名转换
geektime.org 待查询的域名
30是报文长度
第二条，是114.114.114.114的响应，返回至为35.190.27.188
接下来两条，就是ICMP的请求和响应，加一起一共为30ms，没有问题
但是后两条，是PTR的反向解析请求，比较可疑，消耗了一共10s
看来，这就是ping的缓慢根源，就是PTR请求没有得到响应导致的，PTR是为了根据IP地址反查询域名的请求，但有些IP没有定义PTR，所以PTR可能失败
那么禁用ptr就可以了，只需要在ping上面加上-n,就可以禁止名称解析了
而实际导致的问题，是iptables拒绝了PTR的响应
接下来，我们看一下tcpdump的详细使用
tcp利用AF_PACKET套接字，提供了强大的过滤规则
对应的常见选项，基本如下
我们看下常见的过滤表达式，我们曾使用过 udp port 53 or host 35.190.27.188
抓取DNS的请求和响应，源地址或者目的地址为35.190.27.188的包
最后是tcp的输出格式，基本格式为
时间戳 协议 源地址.源端口 > 目的地址.目的端口 网络包详细信息
然后是Wireshark
Wireshark是流行的一个网络分析工具，提供了跨平台的图形界面
Wireshark也提供了强大的过滤规则表达式，还内置了一系列的汇总分析
我们在win端之前安装过Wireshark
于是我们可以利用tcpdump进行抓取，基本的命令如下
tcpdump -nn udp port 53 or host 35.190.27.188 -w ping.pcap
将其拷贝到安装Wireshark的机器，可以用scp将其拷贝到本地来
并使用Wireshark进行打开
就可以进行查看了
那么，我们学习了tcpdump和Wireshark两个使用方法
并讲解了如何利用这两个工具进行网络分析，找到潜在的问题
并说明了DNS的解析中还包括了PTR的请求
对应的，如果不想要出现PTR，一般网络工具也提供了对应的选项