精华内容
下载资源
问答
  • 文章目录案例准备再探 ...tcpdump 和 Wireshark 就是最常用的网络抓包和分析工具,更是分析网络性能必不可少的利器。 tcpdump 仅支持命令行格式使用,常用在服务器中抓取和分析网络包。 Wireshark 除了可以


    ping是一个最常用的测试服务延迟的工具,很多情况下ping 可以帮我们定位出延迟问题,不过有时候, ping 本身也会出现意想不到的问题。这时,就需要我们抓取 ping 命令执行时收发的网络包,然后分析这些网络包,进而找出问题根源。

    tcpdump 和 Wireshark 就是最常用的网络抓包和分析工具,更是分析网络性能必不可少的利器。

    • tcpdump 仅支持命令行格式使用,常用在服务器中抓取和分析网络包。
    • Wireshark 除了可以抓包外,还提供了强大的图形界面和汇总分析工具,在分析复杂的网络情景时,尤为简单和实用。

    在实际分析网络性能时,先用 tcpdump 抓包,后用 Wireshark 分析,也是一种常用的方法。

    案例准备

    本次案例还是基于 Ubuntu 18.04,同样适用于其他的 Linux 系统。使用的案例环境是这样的:

    • 机器配置:2 CPU,8GB 内存。
    • 预先安装 tcpdump、Wireshark 等工具,如:

    Wireshark 的图形界面,并不能通过 SSH 使用,在本地机器中安装。你可以到 https://www.wireshark.org/ 下载并安装 Wireshark。

    跟以前一样,案例中所有命令,都默认以 root 用户(在 Windows 中,运行 Wireshark
    时除外)运行。如果你是用普通用户身份登陆系统,请运行 sudo su root 命令切换到 root 用户。

    再探 ping

    ping 是一种最常用的网络工具,常用来探测网络主机之间的连通性以及延迟。

    不过,虽然 ping 比较简单,但有时候你会发现,ping 工具本身也可能出现异常,比如运行缓慢,但实际网络延迟却并不大的情况。

    打开一个终端,SSH 登录到案例机器中,执行下面的命令,来测试案例机器与极客邦科技官网的连通性和延迟。如果一切正常,你会看到下面这个输出:

    # 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 很快就结束了,那就执行下面的命令,再重试一下。至于这条命令的含义,稍后我们再做解释。

     禁止接收从 DNS 服务器发送过来并包含 googleusercontent 的包
    $ iptables -I INPUT -p udp --sport 53 -m string --string googleusercontent --algo bm -j DROP
    
    

    根据 ping 的输出,可以发现geektime.org 解析后的 IP 地址是 35.190.27.188,而后三次 ping 请求都得到了响应,延迟(RTT)都是 30ms 多一点。

    汇总的地方3 次发送,收到 3 次响应,没有丢包,但三次发送和接受的总时间居然超过了 11s(11049ms),这就有些不可思议了吧。

    这可能是 DNS 解析缓慢的问题。但到底是不是呢?

    再回去看 ping 的输出,三次 ping 请求中,用的都是 IP 地址,说明 ping 只需要在最开始运行时,解析一次得到 IP,后面就可以只用 IP 了。

    我们再用 nslookup 试试。在终端中执行下面的 nslookup 命令,注意,这次我们同样加了 time 命令,输出 nslookup 的执行时间:

    $ 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 在收发哪些网络包。

    我们再打开另一个终端(终端二),SSH 登录案例机器后,执行下面的命令

    $ tcpdump -nn udp port 53 or host 35.190.27.188
    

    当然,你可以直接用 tcpdump 不加任何参数来抓包,但那样的话,就可能抓取到很多不相干的包。由于我们已经执行过 ping 命令,知道了 geekbang.org 的 IP 地址是 35.190.27.188,也知道 ping 命令会执行 DNS 查询。所以,上面这条命令,就是基于这个规则进行过滤。

    我来具体解释一下这条命令。

    • -nn ,表示不解析抓包中的域名(即不反向解析)、协议以及端口号。
    • udp port 53 ,表示只显示 UDP 协议的端口号(包括源端口和目的端口)为 53 的包。
    • host 35.190.27.188 ,表示只显示 IP 地址(包括源地址和目的地址)为 35.190.27.188 的包。
    • 这两个过滤条件中间的“ or ”,表示或的关系,也就是说,只要满足上面两个条件中的任一个,就可以展示出来。

    接下来,回到终端一,执行相同的 ping 命令:

    $ ping -c3 geektime.org
    ...
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 11095ms
    rtt min/avg/max/mdev = 81.473/81.572/81.757/0.130 ms
    

    命令结束后,再回到终端二中,查看 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 的选项以及接口的基本信息;
    • 从第三行开始,就是抓取到的网络包的输出。这些输出的格式,都是 时间戳 协议 源地址.源端口 > 目的地址.目的端口 网络包详细信息(这是最基本的格式,可以通过选项增加其他字段)。

    但网络包的详细信息,本身根据协议的不同而不同。所以,要理解这些网络包的详细含义,就要对常用网络协议的基本格式以及交互原理,有基本的了解,这些内容都会记录在 IETF( 互联网工程任务组)发布的 RFC(请求意见稿)中。

    • 第一条就表示,从本地 IP 发送到 114.114.114.114 的 A 记录查询请求,它的报文格式记录在 RFC1035 中,你可以点击这里查看。在这个 tcpdump 的输出中,

      • 36909+ 表示查询标识值,它也会出现在响应中,加号表示启用递归查询。
      • A? 表示查询 A 记录。
      • geektime.org. 表示待查询的域名。
      • 30 表示报文长度。
    • 接下来的一条,则是从 114.114.114.114 发送回来的 DNS 响应——域名 geektime.org. 的 A 记录值为 35.190.27.188。

    • 第三条和第四条,是 ICMP echo request 和 ICMP echo reply,响应包的时间戳 14:02:31.539667,减去请求包的时间戳 14:02:31.508164 ,就可以得到,这次 ICMP 所用时间为 30ms。这看起来并没有问题。

    但随后的两条反向地址解析 PTR 请求,就比较可疑了。因为我们只看到了请求包,却没有应答包。
    仔细观察它们的时间,你会发现,这两条记录都是发出后 5s 才出现下一个网络包,两条 PTR 记录就消耗了 10s。

    再往下看,最后的四个包,则是两次正常的 ICMP 请求和响应,根据时间戳计算其延迟,也是 30ms。

    到这里,其实我们也就找到了 ping 缓慢的根源,正是两次 PTR 请求没有得到响应而超时导致的。

    PTR 反向地址解析的目的,是从 IP 地址反查出域名,但事实上,并非所有 IP 地址都会定义 PTR 记录,所以 PTR 查询很可能会失败。

    所以,在你使用 ping 时,如果发现结果中的延迟并不大,而 ping 命令本身却很慢,不要慌,有可能是背后的 PTR 在搞鬼。

    知道问题后,解决起来就比较简单了,只要禁止 PTR 就可以。还是老路子,执行 man ping 命令,查询使用手册,就可以找出相应的方法,即加上 -n 选项禁止名称解析。比如,我们可以在终端中执行如下命令:

    $ ping -n -c3 geektime.org
    PING geektime.org (35.190.27.188) 56(84) bytes of data.
    64 bytes from 35.190.27.188: icmp_seq=1 ttl=43 time=33.5 ms
    64 bytes from 35.190.27.188: icmp_seq=2 ttl=43 time=39.0 ms
    64 bytes from 35.190.27.188: icmp_seq=3 ttl=43 time=32.8 ms
     
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 32.879/35.160/39.030/2.755 ms
    

    你可以发现,现在只需要 2s 就可以结束,比刚才的 11s 可是快多了。

    到这里, 我就带你一起使用 tcpdump ,解决了一个最常见的 ping 工作缓慢的问题。

    案例最后,如果你在开始时,执行了 iptables 命令,那也不要忘了删掉它:

    $ iptables -D INPUT -p udp --sport 53 -m string --string googleusercontent --algo bm -j DROP
    
    

    不过,删除后你肯定还有疑问,明明我们的案例跟 Google 没啥关系,为什么要根据 googleusercontent ,这个毫不相关的字符串来过滤包呢?

    实际上,如果换一个 DNS 服务器,就可以用 PTR 反查到 35.190.27.188 所对应的域名:

     $ nslookup -type=PTR 35.190.27.188 8.8.8.8
    Server:	8.8.8.8
    Address:	8.8.8.8#53
    Non-authoritative answer:
    188.27.190.35.in-addr.arpa	name = 188.27.190.35.bc.googleusercontent.com.
    Authoritative answers can be found from:
    

    你看,虽然查到了 PTR 记录,但结果并非 geekbang.org,而是 188.27.190.35.bc.googleusercontent.com。其实,这也是为什么,案例开始时将包含 googleusercontent 的丢弃后,ping 就慢了。因为 iptables ,实际上是把 PTR 响应给丢了,所以会导致 PTR 请求超时。

    tcpdump

    tcpdump 也是最常用的一个网络分析工具。它基于 libpcap ,利用内核中的 AF_PACKET 套接字,抓取网络接口中传输的网络包;并提供了强大的过滤规则,帮你从大量的网络包中,挑出最想关注的信息。

    tcpdump 为你展示了每个网络包的详细细节,这就要求,在使用前,你必须要对网络协议有基本了解。而要了解网络协议的详细设计和实现细节, RFC 当然是最权威的资料。

    RFC 的内容,对初学者来说可能并不友好。如果你对网络协议还不太了解,推荐你去学《TCP/IP 详解》,特别是第一卷的 TCP/IP 协议族。这是每个程序员都要掌握的核心基础知识。

    再回到 tcpdump 工具本身,它的基本使用方法,还是比较简单的,也就是 tcpdump [选项] [过滤表达式]。当然,选项和表达式的外面都加了中括号,表明它们都是可选的。

    提示:在 Linux工具中,如果你在文档中看到,选项放在中括号里,就说明这是一个可选选项。这时候就要留意一下,这些选项是不是有默认值。

    为了帮你更快上手 tcpdump 的使用,我在这里也帮你整理了一些最常见的用法,并且绘制成了表格,你可以参考使用。

    在这里插入图片描述
    常用的过滤表达式

    刚刚用过的是 udp port 53 or host 35.190.27.188 ,表示抓取 DNS 协议的请求和响应包,以及源地址或目的地址为 35.190.27.188 的包。

    其他常用的过滤选项如下面这个表格。

    在这里插入图片描述
    最后,再次强调 tcpdump 的输出格式,我在前面已经介绍了它的基本格式:

    时间戳 协议 源地址. 源端口 > 目的地址. 目的端口 网络包详细信息
    

    网络包的详细信息取决于协议,不同协议展示的格式也不同。所以,更详细的使用方法,还是需要你去查询 tcpdump 的 man 手册(执行 man tcpdump 也可以得到)。

    tcpdump 虽然功能强大,可是输出格式却并不直观。特别是,当系统中网络包数比较多(比如 PPS 超过几千)的时候,你想从 tcpdump 抓取的网络包中分析问题,实在不容易。

    对比之下,Wireshark 则通过图形界面,以及一系列的汇总分析工具,提供了更友好的使用界面,让你可以用更快的速度,摆平网络性能问题。

    Wireshark

    Wireshark 也是最流行的一个网络分析工具,它最大的好处就是提供了跨平台的图形界面。跟 tcpdump 类似,Wireshark 也提供了强大的过滤规则表达式,同时,还内置了一系列的汇总分析工具。

    比如,拿刚刚的 ping 案例来说,你可以执行下面的命令,把抓取的网络包保存到 ping.pcap 文件中:

    $ tcpdump -nn udp port 53 or host 35.190.27.188 -w ping.pcap
    

    接着,把它拷贝到你安装有 Wireshark 的机器中,比如你可以用 scp 把它拷贝到本地来:

    $ scp host-ip/path/ping.pcap .
    
    

    然后,再用 Wireshark 打开它。打开后,你就可以看到下面这个界面:

    在这里插入图片描述
    Wireshark 的界面里,不仅以更规整的格式,展示了各个网络包的头部信息;还用了不同颜色,展示 DNS 和 ICMP 这两种不同的协议。你也可以一眼看出,中间的两条 PTR 查询并没有响应包。

    接着,在网络包列表中选择某一个网络包后,在其下方的网络包详情中,你还可以看到,这个包在协议栈各层的详细信息。比如,以编号为 5 的 PTR 包为例:

    在这里插入图片描述
    你可以看到,IP 层(Internet Protocol)的源地址和目的地址、传输层的 UDP 协议(Uder Datagram Protocol)、应用层的 DNS 协议(Domain Name System)的概要信息。

    继续点击每层左边的箭头,就可以看到该层协议头的所有信息。比如点击 DNS 后,就可以看到 Transaction ID、Flags、Queries 等 DNS 协议各个字段的数值以及含义。

    当然,Wireshark 的功能远不止如此。接下来我再带你一起,看一个 HTTP 的例子,并理解 TCP 三次握手和四次挥手的工作原理。

    这个案例我们将要访问的是 http://example.com/ 。进入终端一,执行下面的命令,首先查出 example.com 的 IP。然后,执行 tcpdump 命令,过滤得到的 IP 地址,并将结果保存到 web.pcap 中。

    $ dig +short example.com
    93.184.216.34
    $ tcpdump -nn host 93.184.216.34 -w web.pcap
    

    实际上,你可以在 host 表达式中,直接使用域名,即 tcpdump -nn host example.com -w web.pcap。

    接下来,切换到终端二,执行下面的 curl 命令,访问 http://example.com:

    $ curl http://example.com
    

    最后,再回到终端一,按下 Ctrl+C 停止 tcpdump,并把得到的 web.pcap 拷贝出来。

    使用 Wireshark 打开 web.pcap 后,你就可以在 Wireshark 中,看到如下的界面:
    在这里插入图片描述
    由于 HTTP 基于 TCP ,所以你最先看到的三个包,分别是 TCP 三次握手的包。接下来,中间的才是 HTTP 请求和响应包,而最后的三个包,则是 TCP 连接断开时的三次挥手包。

    从菜单栏中,点击 Statistics -> Flow Graph,然后,在弹出的界面中的 Flow type 选择 TCP Flows,你可以更清晰的看到,整个过程中 TCP 流的执行过程:
    在这里插入图片描述
    这其实跟各种教程上讲到的,TCP 三次握手和四次挥手很类似,作为对比, 你通常看到的 TCP 三次握手和四次挥手的流程,基本是这样的:
    在这里插入图片描述
    不过,对比这两张图,你会发现,这里抓到的包跟上面的四次挥手,并不完全一样,实际挥手过程只有三个包,而不是四个。

    之所以有三个包,是因为服务器端收到客户端的 FIN 后,服务器端同时也要关闭连接,这样就可以把 ACK 和 FIN 合并到一起发送,节省了一个包,变成了“三次挥手”。

    而通常情况下,服务器端收到客户端的 FIN 后,很可能还没发送完数据,所以就会先回复客户端一个 ACK 包。稍等一会儿,完成所有数据包的发送后,才会发送 FIN 包。这也就是四次挥手了。

    抓包后, Wireshark 中就会显示下面这个界面(原始网络包来自 Wireshark TCP 4-times close 示例,你可以点击 这里 下载):
    在这里插入图片描述

    总结

    我们一起学了 tcpdump 和 Wireshark 的使用方法,并通过几个案例,学会了如何运用这两个工具来分析网络的收发过程,并找出潜在的性能问题。

    • 当你发现针对相同的网络服务,使用 IP 地址快而换成域名却慢很多时,就要想到,有可能是 DNS 在捣鬼。DNS 的解析,不仅包括从域名解析出 IP 地址的 A 记录请求,还包括性能工具帮你,“聪明”地从 IP 地址反查域名的 PTR 请求。
    • 实际上,根据 IP 地址反查域名、根据端口号反查协议名称,是很多网络工具默认的行为,而这往往会导致性能工具的工作缓慢。所以,通常,网络性能工具都会提供一个选项(比如 -n 或者 -nn),来禁止名称解析。
    • 当碰到网络性能问题时,不要忘记 tcpdump 和 Wireshark 这两个大杀器。你可以用它们抓取实际传输的网络包,再排查是否有潜在的性能问题。
    展开全文
  • 不过要注意,DNS 解析受到各种网络状况的影响,性能可能不稳定。比如公网延迟增大,缓存过期导致要重新去上游服务器请求,或者流量高峰时 DNS 服务器性能不足等,都会导致 DNS 响应的延迟增大。 此时,可以借助 ...
    通常,需要暴露到公网的服务,都会绑定一个域名,既方便了人们记忆,也避免了后台服务 IP 地址的变更影响到用户。
    不过要注意,DNS 解析受到各种网络状况的影响,性能可能不稳定。比如公网延迟增大,缓存过期导致要重新去上游服务器请求,或者流量高峰时 DNS 服务器性能不足等,都会导致 DNS 响应的延迟增大。
    此时,可以借助 nslookup 或者 dig 的调试功能,分析 DNS 的解析过程,再配合 ping 等工具调试 DNS 服务器的延迟,从而定位出性能瓶颈。通常,你可以用缓存、预取、HTTPDNS 等方法,优化 DNS 的性能。
    上一节我们用到的 ping,是一个最常用的测试服务延迟的工具。很多情况下,ping 可以帮我们定位出延迟问题,不过有时候, ping 本身也会出现意想不到的问题。这时,就需要我们抓取 ping 命令执行时收发的网络包,然后分析这些网络包,进而找出问题根源。
    tcpdump 和 Wireshark 就是最常用的网络抓包和分析工具,更是分析网络性能必不可少的利器。
    • tcpdump 仅支持命令行格式使用,常用在服务器中抓取和分析网络包。
    • Wireshark 除了可以抓包外,还提供了强大的图形界面和汇总分析工具,在分析复杂的网络情景时,尤为简单和实用。
    因而,在实际分析网络性能时,先用 tcpdump 抓包,后用 Wireshark 分析,也是一种常用的方法。
    一起看看,怎么使用 tcpdump 和 Wireshark ,来分析网络的性能问题。

    案例准备

    本次案例还是基于 Ubuntu 18.04,同样适用于其他的 Linux 系统。我使用的案例环境是这样的:
    机器配置:2 CPU,8GB 内存。
    预先安装 tcpdump、Wireshark 等工具,如:
    # Ubuntu
    apt-get install tcpdump wireshark
     
    # CentOS
    yum install -y tcpdump wireshark
    由于 Wireshark 的图形界面,并不能通过 SSH 使用,所以我推荐你在本地机器(比如 Windows)中安装。你可以到 https://www.wireshark.org/ 下载并安装 Wireshark。
    跟以前一样,案例中所有命令,都默认以 root 用户(在 Windows 中,运行 Wireshark 时除外)运行。如果你是用普通用户身份登陆系统,请运行 sudo su root 命令切换到 root 用户。

    再探 ping

    前面讲过,ping 是一种最常用的网络工具,常用来探测网络主机之间的连通性以及延迟。关于 ping 的原理和使用方法,我在前面的 Linux 网络基础篇 已经简单介绍过,而 DNS 缓慢的案例中,也多次用到了 ping 测试 DNS 服务器的延迟(RTT)。
    不过,虽然 ping 比较简单,但有时候你会发现,ping 工具本身也可能出现异常,比如运行缓慢,但实际网络延迟却并不大的情况。
    接下来,我们打开一个终端,SSH 登录到案例机器中,执行下面的命令,来测试案例机器与极客邦科技官网的连通性和延迟。如果一切正常,你会看到下面这个输出:
    # 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 的输出界面, Linux 网络基础篇 中我们已经学过,你可以先复习一下,自己解读并且分析这次的输出。
    不过要注意,假如你运行时发现 ping 很快就结束了,那就执行下面的命令,再重试一下。至于这条命令的含义,稍后我们再做解释。
    # 禁止接收从 DNS 服务器发送过来并包含 googleusercontent 的包
    $ iptables -I INPUT -p udp --sport 53 -m string --string googleusercontent --algo bm -j DROP
    根据 ping 的输出,你可以发现,geektime.org 解析后的 IP 地址是 35.190.27.188,而后三次 ping 请求都得到了响应,延迟(RTT)都是 30ms 多一点。
    但汇总的地方,就有点儿意思了。3 次发送,收到 3 次响应,没有丢包,但三次发送和接受的总时间居然超过了 11s(11049ms),这就有些不可思议了吧。
    会想起上一节的 DNS 解析问题,你可能会怀疑,这可能是 DNS 解析缓慢的问题。但到底是不是呢?
    再回去看 ping 的输出,三次 ping 请求中,用的都是 IP 地址,说明 ping 只需要在最开始运行时,解析一次得到 IP,后面就可以只用 IP 了。
    我们再用 nslookup 试试。在终端中执行下面的 nslookup 命令,注意,这次我们同样加了 time 命令,输出 nslookup 的执行时间:
    $ 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 在收发哪些网络包。
    我们再打开另一个终端(终端二),SSH 登录案例机器后,执行下面的命令:
    $ tcpdump -nn udp port 53 or host 35.190.27.188
    当然,你可以直接用 tcpdump 不加任何参数来抓包,但那样的话,就可能抓取到很多不相干的包。由于我们已经执行过 ping 命令,知道了 geekbang.org 的 IP 地址是 35.190.27.188,也知道 ping 命令会执行 DNS 查询。所以,上面这条命令,就是基于这个规则进行过滤。
    我来具体解释一下这条命令。
    • -nn ,表示不解析抓包中的域名(即不反向解析)、协议以及端口号。
    • udp port 53 ,表示只显示 UDP 协议的端口号(包括源端口和目的端口)为 53 的包。
    • host 35.190.27.188 ,表示只显示 IP 地址(包括源地址和目的地址)为 35.190.27.188 的包。
    • 这两个过滤条件中间的“ or ”,表示或的关系,也就是说,只要满足上面两个条件中的任一个,就可以展示出来。
    接下来,回到终端一,执行相同的 ping 命令:
    $ ping -c3 geektime.org
    ...
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 11095ms
    rtt min/avg/max/mdev = 81.473/81.572/81.757/0.130 ms
    命令结束后,再回到终端二中,查看 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 的选项以及接口的基本信息;从第三行开始,就是抓取到的网络包的输出。这些输出的格式,都是 时间戳 协议 源地址.源端口 > 目的地址.目的端口 网络包详细信息(这是最基本的格式,可以通过选项增加其他字段)。
    前面的字段,都比较好理解。但网络包的详细信息,本身根据协议的不同而不同。所以,要理解这些网络包的详细含义,就要对常用网络协议的基本格式以及交互原理,有基本的了解。
    当然,实际上,这些内容都会记录在 IETF( 互联网工程任务组)发布的 RFC(请求意见稿)中。
    比如,第一条就表示,从本地 IP 发送到 114.114.114.114 的 A 记录查询请求,它的报文格式记录在 RFC1035 中,你可以点击 这里查看。在这个 tcpdump 的输出中,
    • 36909+ 表示查询标识值,它也会出现在响应中,加号表示启用递归查询。
    • A? 表示查询 A 记录。
    • geektime.org. 表示待查询的域名。
    • 30 表示报文长度。
    接下来的一条,则是从 114.114.114.114 发送回来的 DNS 响应——域名 geektime.org. 的 A 记录值为 35.190.27.188。
    第三条和第四条,是 ICMP echo request 和 ICMP echo reply,响应包的时间戳 14:02:31.539667,减去请求包的时间戳 14:02:31.508164 ,就可以得到,这次 ICMP 所用时间为 30ms。这看起来并没有问题。
    但随后的两条反向地址解析 PTR 请求,就比较可疑了。因为我们只看到了请求包,却没有应答包。仔细观察它们的时间,你会发现,这两条记录都是发出后 5s 才出现下一个网络包,两条 PTR 记录就消耗了 10s。
    再往下看,最后的四个包,则是两次正常的 ICMP 请求和响应,根据时间戳计算其延迟,也是 30ms。
    到这里,其实我们也就找到了 ping 缓慢的根源,正是两次 PTR 请求没有得到响应而超时导致的。 PTR 反向地址解析的目的,是从 IP 地址反查出域名,但事实上,并非所有 IP 地址都会定义 PTR 记录,所以 PTR 查询很可能会失败。
    所以, 在你使用 ping 时,如果发现结果中的延迟并不大,而 ping 命令本身却很慢,不要慌,有可能是背后的 PTR 在搞鬼。
    知道问题后,解决起来就比较简单了,只要禁止 PTR 就可以。还是老路子,执行 man ping 命令,查询使用手册,就可以找出相应的方法,即加上 -n 选项禁止名称解析。比如,我们可以在终端中执行如下命令:
    $ ping -n -c3 geektime.org
    PING geektime.org (35.190.27.188) 56(84) bytes of data.
    64 bytes from 35.190.27.188: icmp_seq=1 ttl=43 time=33.5 ms
    64 bytes from 35.190.27.188: icmp_seq=2 ttl=43 time=39.0 ms
    64 bytes from 35.190.27.188: icmp_seq=3 ttl=43 time=32.8 ms
     
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 32.879/35.160/39.030/2.755 ms
    你可以发现,现在只需要 2s 就可以结束,比刚才的 11s 可是快多了。
    到这里, 我就带你一起使用 tcpdump ,解决了一个最常见的 ping 工作缓慢的问题。
    案例最后,如果你在开始时,执行了 iptables 命令,那也不要忘了删掉它:
    $ iptables -D INPUT -p udp --sport 53 -m string --string googleusercontent --algo bm -j DROP
    不过,删除后你肯定还有疑问,明明我们的案例跟 Google 没啥关系,为什么要根据 googleusercontent ,这个毫不相关的字符串来过滤包呢?
    实际上,如果换一个 DNS 服务器,就可以用 PTR 反查到 35.190.27.188 所对应的域名:
    $ nslookup -type=PTR 35.190.27.188 8.8.8.8
    Server:    8.8.8.8
    Address:    8.8.8.8#53
    Non-authoritative answer:
    188.27.190.35.in-addr.arpa    name = 188.27.190.35.bc.googleusercontent.com.
    Authoritative answers can be found from:
    你看,虽然查到了 PTR 记录,但结果并非 geekbang.org,而是 188.27.190.35.bc.googleusercontent.com。其实,这也是为什么,案例开始时将包含 googleusercontent 的丢弃后,ping 就慢了。因为 iptables ,实际上是把 PTR 响应给丢了,所以会导致 PTR 请求超时。
    tcpdump 可以说是网络性能分析最有效的利器。接下来,我再带你一起看看 tcpdump 的更多使用方法。

    tcpdump

    我们知道,tcpdump 也是最常用的一个网络分析工具。它基于 libpcap ,利用内核中的 AF_PACKET 套接字,抓取网络接口中传输的网络包;并提供了强大的过滤规则,帮你从大量的网络包中,挑出最想关注的信息。
    tcpdump 为你展示了每个网络包的详细细节,这就要求,在使用前,你必须要对网络协议有基本了解。而要了解网络协议的详细设计和实现细节, RFC 当然是最权威的资料。
    不过,RFC 的内容,对初学者来说可能并不友好。如果你对网络协议还不太了解,推荐你去学《TCP/IP 详解》,特别是第一卷的 TCP/IP 协议族。这是每个程序员都要掌握的核心基础知识。
    再回到 tcpdump 工具本身,它的基本使用方法,还是比较简单的,也就是 tcpdump [选项] [过滤表达式]。当然,选项和表达式的外面都加了中括号,表明它们都是可选的。
    提示:在 Linux 工具中,如果你在文档中看到,选项放在中括号里,就说明这是一个可选选项。这时候就要留意一下,这些选项是不是有默认值。
    查看 tcpdump 的 手册 ,以及 pcap-filter 的手册,你会发现,tcpdump 提供了大量的选项以及各式各样的过滤表达式。不过不要担心,只需要掌握一些常用选项和过滤表达式,就可以满足大部分场景的需要了。
    为了帮你更快上手 tcpdump 的使用,我在这里也帮你整理了一些最常见的用法,并且绘制成了表格,你可以参考使用。
    首先,来看一下常用的几个选项。在上面的 ping 案例中,我们用过 -nn 选项,表示不用对 IP 地址和端口号进行名称解析。其他常用选项,我用下面这张表格来解释。
    接下来,我们再来看常用的过滤表达式。刚刚用过的是 udp port 53 or host 35.190.27.188 ,表示抓取 DNS 协议的请求和响应包,以及源地址或目的地址为 35.190.27.188 的包。
    其他常用的过滤选项,我也整理成了下面这个表格。
    最后,再次强调 tcpdump 的输出格式,我在前面已经介绍了它的基本格式:
    时间戳 协议 源地址. 源端口 > 目的地址. 目的端口 网络包详细信息
    其中,网络包的详细信息取决于协议,不同协议展示的格式也不同。所以,更详细的使用方法,还是需要你去查询 tcpdump 的 man 手册(执行 man tcpdump 也可以得到)。
    不过,讲了这么多,你应该也发现了。tcpdump 虽然功能强大,可是输出格式却并不直观。特别是,当系统中网络包数比较多(比如 PPS 超过几千)的时候,你想从 tcpdump 抓取的网络包中分析问题,实在不容易。
    对比之下,Wireshark 则通过图形界面,以及一系列的汇总分析工具,提供了更友好的使用界面,让你可以用更快的速度,摆平网络性能问题。接下来,我们就详细来看看它。

    Wireshark

    Wireshark 也是最流行的一个网络分析工具,它最大的好处就是提供了跨平台的图形界面。跟 tcpdump 类似,Wireshark 也提供了强大的过滤规则表达式,同时,还内置了一系列的汇总分析工具。
    比如,拿刚刚的 ping 案例来说,你可以执行下面的命令,把抓取的网络包保存到 ping.pcap 文件中:
    $ tcpdump -nn udp port 53 or host 35.190.27.188 -w ping.pcap
    接着,把它拷贝到你安装有 Wireshark 的机器中,比如你可以用 scp 把它拷贝到本地来:
    $ scp host-ip/path/ping.pcap .
    然后,再用 Wireshark 打开它。打开后,你就可以看到下面这个界面:
    从 Wireshark 的界面里,你可以发现,它不仅以更规整的格式,展示了各个网络包的头部信息;还用了不同颜色,展示 DNS 和 ICMP 这两种不同的协议。你也可以一眼看出,中间的两条 PTR 查询并没有响应包。
    接着,在网络包列表中选择某一个网络包后,在其下方的网络包详情中,你还可以看到,这个包在协议栈各层的详细信息。比如,以编号为 5 的 PTR 包为例:
    你可以看到,IP 层(Internet Protocol)的源地址和目的地址、传输层的 UDP 协议(Uder Datagram Protocol)、应用层的 DNS 协议(Domain Name System)的概要信息。
    继续点击每层左边的箭头,就可以看到该层协议头的所有信息。比如点击 DNS 后,就可以看到 Transaction ID、Flags、Queries 等 DNS 协议各个字段的数值以及含义。
    当然,Wireshark 的功能远不止如此。接下来我再带你一起,看一个 HTTP 的例子,并理解 TCP 三次握手和四次挥手的工作原理。
    这个案例我们将要访问的是 http://example.com/ 。进入终端一,执行下面的命令,首先查出 example.com 的 IP。然后,执行 tcpdump 命令,过滤得到的 IP 地址,并将结果保存到 web.pcap 中。
    $ dig +short example.com
    93.184.216.34
    $ tcpdump -nn host 93.184.216.34 -w web.pcap
    实际上,你可以在 host 表达式中,直接使用域名,即 tcpdump -nn host example.com -w web.pcap。
    接下来,切换到终端二,执行下面的 curl 命令,访问 http://example.com:
    $ curl http://example.com
    最后,再回到终端一,按下 Ctrl+C 停止 tcpdump,并把得到的 web.pcap 拷贝出来。
    使用 Wireshark 打开 web.pcap 后,你就可以在 Wireshark 中,看到如下的界面:
    由于 HTTP 基于 TCP ,所以你最先看到的三个包,分别是 TCP 三次握手的包。接下来,中间的才是 HTTP 请求和响应包,而最后的三个包,则是 TCP 连接断开时的三次挥手包。
    从菜单栏中,点击 Statistics -> Flow Graph,然后,在弹出的界面中的 Flow type 选择 TCP Flows,你可以更清晰的看到,整个过程中 TCP 流的执行过程:
    这其实跟各种教程上讲到的,TCP 三次握手和四次挥手很类似,作为对比, 你通常看到的 TCP 三次握手和四次挥手的流程,基本是这样的:
    (图片来自酷壳)
    不过,对比这两张图,你会发现, 这里抓到的包跟上面的四次挥手,并不完全一样,实际挥手过程只有三个包,而不是四个。
    其实, 之所以有三个包,是因为服务器端收到客户端的 FIN 后,服务器端同时也要关闭连接,这样就可以把 ACK 和 FIN 合并到一起发送,节省了一个包,变成了“三次挥手”。
    而通常情况下,服务器端收到客户端的 FIN 后,很可能还没发送完数据,所以就会先回复客户端一个 ACK 包。稍等一会儿,完成所有数据包的发送后,才会发送 FIN 包。这也就是四次挥手了。
    抓包后, Wireshark 中就会显示下面这个界面(原始网络包来自 Wireshark TCP 4-times close 示例,你可以点击 这里 下载):
    当然,Wireshark 的使用方法绝不只有这些,更多的使用方法,同样可以参考 官方文档 以及 WIKI。

    小结

    今天,我们一起学了 tcpdump 和 Wireshark 的使用方法,并通过几个案例,学会了如何运用这两个工具来分析网络的收发过程,并找出潜在的性能问题。
    当你发现针对相同的网络服务,使用 IP 地址快而换成域名却慢很多时,就要想到,有可能是 DNS 在捣鬼。DNS 的解析,不仅包括从域名解析出 IP 地址的 A 记录请求,还包括性能工具帮你,“聪明”地从 IP 地址反查域名的 PTR 请求。
    实际上, 根据 IP 地址反查域名、根据端口号反查协议名称,是很多网络工具默认的行为,而这往往会导致性能工具的工作缓慢。所以,通常,网络性能工具都会提供一个选项(比如 -n 或者 -nn),来禁止名称解析。
    在工作中,当你碰到网络性能问题时,不要忘记 tcpdump 和 Wireshark 这两个大杀器。你可以用它们抓取实际传输的网络包,再排查是否有潜在的性能问题。
    思考
    最后,我想请你来聊一聊,你是如何使用 tcpdump 和 Wireshark 的。你用 tcpdump 或者 Wireshark 解决过哪些网络问题呢?你又是如何排查、分析并解决的呢?你可以结合今天学到的网络知识,总结自己的思路。
    林沛满的书都看过,确实写的相当好,都是案例驱动。
    把协议讲的生动有趣就数他。
    wireshark的使用推荐阅读林沛满的《Wireshark网络分析就这么简单》和《Wireshark网络分析的艺术》
    老师,这个案例写的极其生动:D, 就是问一句,现在我们的项目都是https,那么如果抓包https,tcpdump或者wireshark是否可以解密?因为我看到wireshark解密需要private key,但是private key涉及安全问题,肯定都拿不到,那么你们遇到抓包https后解析是怎么做的呢?
    作者回复: 嗯,证书解密是最简单的方法,也可以使用 MitM(Man-in-the-middle)方法
    展开全文
  • 本文是通过学习倪朋飞老师的《Linux性能优化实战》 :怎么使用 tcpdump 和 Wireshark 分析网络流 量? 如何使用 tcpdump 和 Wireshark 分析网络流量

    本文是通过学习倪朋飞老师的《Linux性能优化实战》 :怎么使用 tcpdump 和 Wireshark 分析网络流 量?

    如何使用 tcpdump 和 Wireshark 分析网络流量?

    tcpdump 和 Wireshark 就是最常用的网络抓包和分析工具,更是分析网络性能必不可少的利器。

    • tcpdump 仅支持命令行格式使用,常用在服务器中抓取和分析网络包。
    • Wireshark 除了可以抓包外,还提供了强大的图形界面和汇总分析工具,在分析复杂的 网络情景时,尤为简单和实用。

    因而,在实际分析网络性能时,先用 tcpdump 抓包,后用 Wireshark 分析,也是一种常用的方法。

    安装 tcpdump、wireshark 工具,如:

    yum install -y tcpdump wireshark
    

    由于 Wireshark 的图形界面,并不能通过 SSH 使用,所以我推荐你在本地机器(比如 Windows)中安装。你可以到 https://www.wireshark.org/ 下载并安装 Wireshark。

    tcpdump

    tcpdump 也是最常用的一个网络分析工具。它基于 libpcap ,利用内核中的 AF_PACKET 套接字,抓取网络接口中传输的网络包;并提供了强大的过滤规则,帮你从 大量的网络包中,挑出最想关注的信息。

    tcpdump,它的基本使用方法,还是比较简单的,也就是 tcpdump [选 项] [过滤表达式]。当然,选项和表达式的外面都加了中括号,表明它们都是可选的。

    查看 tcpdump 的 手册 ,以及 pcap-filter 的手册,会发现,tcpdump 提供了大量的选项以及各式各样的过滤表达式。不过不要担心,我们只需要掌握一些常用选项和过滤表达 式,就可以满足大部分场景的需要了。

    # -nn ,表示不解析抓包中的域名(即不反向解析)、协议以及端口号。
    # tcp port 53 ,表示只显示 TCP 协议的端口号(包括源端口和目的端口)为 443 的包。
    # host 1.83.124.224 ,表示只显示 IP 地址(包括源地址和目的地址)为 1.83.124.224 的包。
    # 这两个过滤条件中间的“ or ”,表示或的关系,也就是说,只要满足上面两个条件中的 任一个,就可以展示出来。
    tcpdump -nn tcp port 443 or host 1.83.124.224
    
    dropped privs to tcpdump
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    16:31:45.315901 IP 1.83.124.224.56054 > 172.31.36.80.443: Flags [P.], seq 816:1595, ack 891, win 2048, options [nop,nop,TS val 2213015457 ecr 2327793360], length 779
    16:31:45.318687 IP 172.31.36.80.443 > 1.83.124.224.56054: Flags [P.], seq 891:1748, ack 1595, win 297, options [nop,nop,TS val 2327818282 ecr 2213015457], length 857
    16:31:45.405744 IP 1.83.124.224.56054 > 172.31.36.80.443: Flags [.], ack 1748, win 2034, options [nop,nop,TS val 2213015542 ecr 2327818282], length 0
    

    这次输出中,前两行,表示 tcpdump 的选项以及接口的基本信息;从第三行开始,就是抓取到的网络包的输出。这些输出的格式,都是 时间戳 协议 源地址. 源端口 > 目的 地址. 目的端口 网络包详细信息(这是最基本的格式,可以通过选项增加其他字段)

    为了帮我们更快上手 tcpdump 的使用,下面整理了一些最常见的用法,并且绘制成了表格,我们可以参考使用。
    在这里插入图片描述
    其他常用的过滤选项,也整理成了下面这个表格。
    在这里插入图片描述
    最后,再次强调 tcpdump 的输出格式:

    • 时间戳 协议 源地址. 源端口 > 目的地址. 目的端口 网络包详细信息

    tcpdump 虽然功能强大,可是输出格式却并不直 观。特别是,当系统中网络包数比较多(比如 PPS 超过几千)的时候,你想从 tcpdump 抓取的网络包中分析问题,实在不容易。

    对比之下,Wireshark 则通过图形界面,以及一系列的汇总分析工具,提供了更友好的使 用界面,让你可以用更快的速度,摆平网络性能问题。接下来,我们就详细来看看它。

    Wireshark

    Wireshark 也是最流行的一个网络分析工具,它最大的好处就是提供了跨平台的图形界面。跟 tcpdump 类似,Wireshark 也提供了强大的过滤规则表达式,同时,还内置了一 系列的汇总分析工具。

    比如,拿刚刚的 socket 案例来说,你可以执行下面的命令,把抓取的网络包保存到 ping.pcap 文件中:

    tcpdump -nn tcp port 443 or host 1.83.124.224 -w /home/socket.pcap
    

    接着,把它拷贝到你安装有 Wireshark 的机器中,比如你可以用 scp 把它拷贝到本地来:
    在这里插入图片描述

    展开全文
  • 用tcpdump 和 Wireshark 分析网络流量

    目录

    再探ping

    tcpdump

    Wireshark

    参考


     

    很多情况下ping可以帮助我们定位出延迟问题,不过ping本身也会出现想不到的问题,这时候就需要抓取ping命令执行的收发的网络包,然后进行找出问题根源
    tcpdump和Wireshark就是最常用的网络抓包和分析工具,更是分析网络性能必不可少的利器

    • tcpdump仅支持命令行格式使用,常用在服务器中抓取和分析网络包
    • Wireshark除了可以抓包外,还提供了强大图形界面和汇总分析工具,在分析复杂的网络情景时,尤为简单

    因为在实际分析网络性能时,先用tcpdump抓包,后用Wireshark分析,也是一种常用方法
    安装这两个工具

    yum install -y tcpdump wireshark

    Wireshark是图形界面,并不能通过SSH使用,一般推荐用于本地机器,如Windows中安装
     


    再探ping

    ping是一种最常用的网络工具,常用来探测网络主机之间的连通性以及延迟,前面案例中也讲过DNS缓慢的案例,多次用到了ping测试DNS服务器的延迟(RTT)
    不过有时候ping工具本身也可能出现异常,比如运行缓慢,但实际网络延迟却并不大的情况
    下面是一个案例

    ping -c 3 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=48 time=45.2 ms
    64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=2 ttl=48 time=45.2 ms
    64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=3 ttl=48 time=45.3 ms
    
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2048ms
    rtt min/avg/max/mdev = 45.202/45.268/45.309/0.250 ms
    [root@iz2zege42v3jtvyj2oecuzz ~]# 

    增加下面这行命令

    iptables -I INPUT -p udp --sport 53 -m string --string googleusercontent --algo bm -j DROP

    根据ping的输出,可以发现geektime.org解析后的IP地址是 35.190.27.188,而后三次ping请求都得到了响应,延迟RTT都是45ms,但汇总的地方显示3次发送,收到了3次响应,但3次发送和接受的总时间是2048毫秒
    可能是DNS及诶的问题
    再回去看ping的输出,3次ping请求中,用的都是IP地址,说明ping只需要在最开始运行时,解析一次得到IP,后面就可以只用IP了
    再用nslookup看看

    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.091s
    user    0m0.006s
    sys     0m0.003s


    折执行结果很快,比2秒快多了
    这时候用tcpdump抓包看看
    再打开一个终端输入下面命令

    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 -c 3 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=48 time=45.2 ms
    64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=2 ttl=48 time=45.3 ms
    64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=3 ttl=48 time=45.4 ms
    
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2049ms
    rtt min/avg/max/mdev = 45.281/45.353/45.429/0.253 ms

    再查看tcpdump的输出

    tcpdump -nn udp port 53 or host 35.190.27.188
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    09:51:19.574166 IP 172.17.6.131.49049 > 114.114.114.114.53: 34288+ A? geektime.org. (30)
    09:51:19.604440 IP 114.114.114.114.53 > 172.17.6.131.49049: 34288 1/0/0 A 35.190.27.188 (46)
    09:51:19.604754 IP 172.17.6.131 > 35.190.27.188: ICMP echo request, id 5591, seq 1, length 64
    09:51:19.650002 IP 35.190.27.188 > 172.17.6.131: ICMP echo reply, id 5591, seq 1, length 64
    09:51:19.650290 IP 172.17.6.131.47283 > 114.114.114.114.53: 27078+ PTR? 188.27.190.35.in-addr.arpa. (44)
    09:51:20.652404 IP 172.17.6.131 > 35.190.27.188: ICMP echo request, id 5591, seq 2, length 64
    09:51:20.697643 IP 35.190.27.188 > 172.17.6.131: ICMP echo reply, id 5591, seq 2, length 64
    09:51:21.653840 IP 172.17.6.131 > 35.190.27.188: ICMP echo request, id 5591, seq 3, length 64
    09:51:21.699106 IP 35.190.27.188 > 172.17.6.131: ICMP echo reply, id 5591, seq 3, length 64
    ^C
    9 packets captured
    9 packets received by filter
    0 packets dropped by kernel


    这次输出中,前两行,表示tcpdump的选项以及接口的基本信息
    从第三行开始,就是抓取到的网络包的输出
    这些输出格式,都是时间戳  协议 源地址 . 源端口 > 目的地址.目的端口 网络包详细信息
    网络包的详细信息,本身根据协议的不同而不同,所以要理解这些网络包的详细含义,就要对常用网络协议的基本格式以及交互原理,有基本的了解

    实际内容含义
    第一条表示,从IP发送到114.114.114.114的A记录查询请求,它的报文格式记录在RFC1035中

    • 34288+ , 表示查询标识值,它也会出现在响应中加号表示启动递归查询
    • A?     , 表示查询A记录
    • geektime.org,表示待查询的域名
    • 30     , 表示报文长度

    第二条是从114.114.114.114发送回来的DNS响应--域名geektime.org. 的A记录值为35.190.27.188
    第三第四条,是ICMP echo request和ICMP echo reply,响应包的时间戳,减去请求包的时间戳,就可以得到这次ICMP的响应时间
    但随后两条反向地址解析PTR请求,就比较可以可疑,发送和响应时间有1秒了
    再往下的四个包,都是两次正常的ICMP请求和响应
    到这里,就找到了ping缓慢的根源,正是这次PTR请求查询导致变慢的
    PRT反向地址解析的目的,是从IP地址反查出域名,但事实上,并非所有IP地址都会定义PTR记录,所以PTR查询可能会失败

    所以,在使用ping时,发现结果中的延迟并不大,而ping本身很慢,可能是背后的PTR在搞鬼
    解决办法是直接禁用PTR查询就可以了,加上 -n 选项禁止名称解析
    新的执行命令如下

    ping -n -c 3 geektime.org
    PING geektime.org (35.190.27.188) 56(84) bytes of data.
    64 bytes from 35.190.27.188: icmp_seq=1 ttl=48 time=45.2 ms
    64 bytes from 35.190.27.188: icmp_seq=2 ttl=48 time=45.3 ms
    64 bytes from 35.190.27.188: icmp_seq=3 ttl=48 time=45.2 ms
    
    --- geektime.org ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 45.277/45.298/45.326/0.246 ms
    
    
    #tcpdump中可以看到,已经没有PTR查询了
    tcpdump -nn udp port 53 or host 35.190.27.188
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    10:12:30.994062 IP 172.17.6.131.49396 > 114.114.114.114.53: 27899+ A? geektime.org. (30)
    10:12:31.026251 IP 114.114.114.114.53 > 172.17.6.131.49396: 27899 1/0/0 A 35.190.27.188 (46)
    10:12:31.026625 IP 172.17.6.131 > 35.190.27.188: ICMP echo request, id 5634, seq 1, length 64
    10:12:31.071886 IP 35.190.27.188 > 172.17.6.131: ICMP echo reply, id 5634, seq 1, length 64
    10:12:32.028093 IP 172.17.6.131 > 35.190.27.188: ICMP echo request, id 5634, seq 2, length 64
    10:12:32.073377 IP 35.190.27.188 > 172.17.6.131: ICMP echo reply, id 5634, seq 2, length 64
    10:12:33.029578 IP 172.17.6.131 > 35.190.27.188: ICMP echo request, id 5634, seq 3, length 64
    10:12:33.074812 IP 35.190.27.188 > 172.17.6.131: ICMP echo reply, id 5634, seq 3, length 64

    这样就解决了一个最常见的ping工作缓慢的问题
    最后删除iptables命令

    iptables -D INPUT -p udp --sport 53 -m string --string googleusercontent --algo bm -j DROP

    为什么案例中要根据googleusercontent过滤
    实际上,如果换一个DNS服务器,就可以用PTR反查到35.190.27.188所对应的域名

    nslookup -type=PTR 35.190.27.188 8.8.8.8
    Server:         8.8.8.8
    Address:        8.8.8.8#53
    
    Non-authoritative answer:
    188.27.190.35.in-addr.arpa      name = 188.27.190.35.bc.googleusercontent.com.
    
    Authoritative answers can be found from:

    虽然查到了PTR记录,但结果并非 geekbang.org,而是 188.27.190.35.bc.googleusercontent.com.
    这也就是为什么,案例开始将包含 googleusercontent 包丢弃,会导致超时,因为iptables把PTR响应丢弃了,所以会导致PTR请求超时,所以会慢

    根据IP地址反查域名,根据端口号反查协议名称,是很多网络工具的默认行为,而这往往会导致性能工具的工作缓慢,所以网络性能工具都会提供一个选项如-n或者-nn,来禁止名称解析

     

    tcpdump

    tcpdump也是最常用的一个网络分析工具,它基于 libpcap,利用内核中的AF_PACKET套接字,抓取网络接口中传输的网络包,并提供了强大的过滤规则
    tcpdump展示了每个网络包的详细信息,具体可以参考RFC
    tcpdump的基本用法就是 tcpdump [选项] [过滤表达式],这两个都是可选的

    tcpdump手册,以及pcap-filter手册,会发现tcpdump提供了大量的选项以及各式各样的过滤表达式,下面总结了一些常用的选项

    接下来,再看常用的过滤表达式,总结图表如下


    再次强调tcpdump的输出格式

    时间戳 协议 源地址.源端口 > 目的地址.目的端口 网络包详细信息

    网络包的详细信息取决于协议,不同协议展示的格式也不同,所以更详细的使用方法,需要去查tcpdump的man手册,虽然tcpdump功能强大,但输出格式并不直观,特别是网络包很多的时候,想从tcpdump中抓取网络包再分析就有难度了,这时候就需要借助Wireshark了
     

    Wireshark


    Wireshark最大的好处是提供跨平台的图形界面
    使用下面命令,将抓取的网络包保存到ping.pcap文件中

    tcpdump -nn udp port 53 or host 35.190.27.188 -w ping.pcap

    再把这个文件拷贝到本地机器,并用Wireshark打开

    打开编号为5的数据包


    用访问HTTP的例子,演示TCP三次握手和四次挥手
    访问 http://example.com
    先查出对应的ip,并执行访问,命令如下

    dig +short example.com
    93.184.216.34
    
    curl http://example.com
    
    tcpdump -nn host example.com -w web.pcap

    将web.pcap文件导出,并用Wireshark打开,可以看到三次握手,四次挥手,HTTP数据交互的过程

    在Wireshark中点击 Statistics->Flow Graph,然后选择TCP Flows,可以看到整个TCP流的执行过程

    作为对比,完整的TCP三次握手,四次挥手如下

    不过Wireshark中关闭连接只有三个包
    因为服务器收到客户端FIN后,服务器自己也要关闭连接,所以把ACK和FIN合并到一起发送,节省了一个包,就变成了三次挥手
    而通常情况下,服务器收到客户端的FIN厚,很可能还没发送完数据,所以就会先回复客户端一个ACK包,稍等一会,完成所有数据包的发送后,才会发送FIN包,这就是四次挥手了
     

     

    参考

    RFC

    RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION

    展开全文
  • 使用wireshark分析网络流量实例 转载于:https://blog.51cto.com/johnping/1661994
  • Wireshark流量分析

    2021-05-14 18:11:36
    Wireshark流量分析开始wireshark过滤器表达式wireshark着色规则数据流的追踪数据包的统计分析数据包的大致结构网络分析包头 开始包 打开wireshark后,按ctrl+K,勾选需要包的网卡 点击Start开始包 ...
  • wireshark分析带宽流量

    千次阅读 2020-09-18 18:01:11
    小鱼儿想通过wireshark分析一下某设备的网络传输特性,但是对wireshark没有那么熟悉,一度产生怀疑,希望这篇短文可以帮到你。 目标:1、设备A传输带宽分析; 2、设备A传输数据包速分析; 操作: 统计 --> I...
  • wireshark流量分析实战

    千次阅读 多人点赞 2020-04-10 16:18:18
    Wireshark(前称Ethereal)是一个网络封包分析软件。网络封包分析软件的功能是撷取网络封包,并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口,直接与网卡进行数据报文交换。 下面是在网上找...
  • Wireshark分析流量1

    2020-11-26 22:16:25
    大致浏览,发现是不同地址在访问192.168.10.5:80,设置过滤看看 ... 发现是不同的ip在用get在向服务器上传图片,量有点大,先把源ip设置一个 如上图,没有发现什么异常,get请求后没有参数,换个源ip ...
  • Wireshark分析流量包案例

    千次阅读 2021-03-08 10:39:34
    wireshark抓包工具常用筛选命令方法 测试文件:https://pan.baidu.com/s/1QuMdefZHSqlaLSHaMVGb4w 提取码:tmjs 使用Wireshark查看并分析attack.pcapng数据包文件,通过分析数据包attack.pcapng找出黑客的IP地址,...
  • -nn :不解析包中的域名(即不反向解析)、协议以及端口号。 udp port 53 :只显示 UDP 协议的端口号(包括源端口和目的端口)为 53 的包。 host 35.190.27.188:表示只显示 IP地址(包括源地...
  • 实验01使用网络协议分析Wireshark 1. 掌握安装和配置网络协议分析Wireshark的方法; 2. 熟悉使用Wireshark工具分析网络协议的基本方法,加深对协议格式、协议层次和协议交互过程的理解。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,436
精华内容 3,774
关键字:

wireshark分析网络流量