[转帖]《Linux性能优化实战》笔记（20）—— 使用 tcpdump 和 Wireshark 分析网络流量

linux,性能,优化,实战,笔记,使用,tcpdump,wireshark,分析,网络流量 · 浏览次数 : 0

小编点评

**四、 Wireshark Wireshark 也是最流行的一个网络分析工具，它最大的好处就是提供跨平台的图形界面。** **使用案例** 接下来再看一个 HTTP 的例子，并理解 TCP 三次握手和四次挥手的工作原理。这个案例我们将要访问的是 http://example.com/ 。 进入终端一，首先执行dig查出 example.com 的 IP，然后执行 tcpdump 过滤得到的 IP 地址，并将结果保存到 web.pcap 中。也直接使用域名，即 tcpdump -nn host example.com -w web.pcap。 $ dig +short example.com93.184.216.34 tcpdump -nn host 93.184.216.34 -w web.pcap 接下来，切换到终端二，执行下面的 curl 命令，访问 http://example.com： curl http://example.com 最后，再回到终端一，按下 Ctrl+C 停止 tcpdump，并把得到的 web.pcap 拷贝出来。使用 Wireshark 打开 由于 HTTP 基于 TCP ，所以你最先看到的三个包，分别是 TCP 三次握手的包。接下来，中间的才是 HTTP 请求和响应包，而最后的三个包，则是 TCP 连接断开时的三次挥手包。 从菜单栏中，点击 Statistics -> Flow Graph，然后，在弹出的界面中的 Flow type 选择TCP Flows，你可以更清晰的看到，整个过程中 TCP 流的执行过

正文

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

tcpdump 仅支持命令行格式使用，常用在服务器中抓取和分析网络包。Wireshark 除了可以抓包，还提供了强大的图形界面和汇总分析工具，在分析复杂的网络情景时，尤为简单和实用。因而，在实际分析网络性能时，先用 tcpdump 抓包，后用 Wireshark 分析，也是一种常用的方法。安装方法如下：

  1. # Ubuntu
  2. apt-get install tcpdump wireshark
  3. # CentOS
  4. yum install -y tcpdump wireshark

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

一、 再探 ping

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

接下来，我们执行下面的命令测试案例机器与极客邦科技官网的连通性和延迟。如果一切正常，你会看到下面这个输出：

  1. # ping 3 次（默认每次发送间隔1秒）
  2. # 假设DNS服务器还是上一期配置的114.114.114.114
  3. $ ping -c3 geektime.org
  4. PING geektime.org (35.190.27.188) 56(84) bytes of data.
  5. 64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=1 ttl=43 time=36.8 ms
  6. 64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=2 ttl=43 time=31.1 ms
  7. 64 bytes from 35.190.27.188 (35.190.27.188): icmp_seq=3 ttl=43 time=31.2 ms
  8.  
  9. --- geektime.org ping statistics ---
  10. 3 packets transmitted, 3 received, 0% packet loss, time 11049ms
  11. rtt min/avg/max/mdev = 31.146/33.074/36.809/2.649 ms

假如你运行时发现 ping 很快就结束了，那就执行下面的命令后再重试一下。至于这条命令的含义，稍后我们再做解释。

  1. # 禁止接收从DNS服务器发送过来并包含googleusercontent的包
  2. $ 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 的执行时间：

  1. time nslookup geektime.org
  2. #输出
  3. Server:    114.114.114.114
  4. Address:  114.114.114.114#53
  5.  
  6. Non-authoritative answer:
  7. Name:  geektime.org
  8. Address: 35.190.27.188
  9.  
  10. real  0m0.044s
  11. user  0m0.006s
  12. sys  0m0.003s

可以看到，域名解析还是很快的，只需要 44ms，显然比 11s 短了很多。再往后该怎么分析呢？其实，这时候就可以用 tcpdump 抓包，查看 ping 在收发哪些网络包。

 

二、 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 命令：

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

命令结束后，再回到终端二中，查看 tcpdump 的输出：

  1. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  2. listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
  3. 14:02:31.100564 IP 172.16.3.4.56669 > 114.114.114.114.53: 36909+ A? geektime.org. (30)
  4. 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)
  5. 14:02:31.508164 IP 172.16.3.4 > 35.190.27.188: ICMP echo request, id 4356, seq 1, length 64
  6. 14:02:31.539667 IP 35.190.27.188 > 172.16.3.4: ICMP echo reply, id 4356, seq 1, length 64
  7. 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)
  8. 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)
  9. 14:02:41.551284 IP 172.16.3.4 > 35.190.27.188: ICMP echo request, id 4356, seq 2, length 64
  10. 14:02:41.582363 IP 35.190.27.188 > 172.16.3.4: ICMP echo reply, id 4356, seq 2, length 64
  11. 14:02:42.552506 IP 172.16.3.4 > 35.190.27.188: ICMP echo request, id 4356, seq 3, length 64
  12. 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 记录查询请求，它的报文格式记录在 RFC1035 中。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 选项禁止名称解析。

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

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

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

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

不过，删除后你肯定还有疑问，明明我们的案例跟 Google 没啥关系，为什么要根据googleusercontent ，这个毫不相关的字符串来过滤包呢？实际上，如果换一个 DNS 服务器，就可以用 PTR 反查到 35.190.27.188 所对应的域名：

  1. nslookup -type=PTR 35.190.27.188 8.8.8.8
  2. #输出
  3. Server:  8.8.8.8
  4. Address:  8.8.8.8#53
  5. Non-authoritative answer:
  6. 188.27.190.35.in-addr.arpa  name = 188.27.190.35.bc.googleusercontent.com.
  7. 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 [选项] [过滤表达式]，选项和表达式的外面都加了中括号，表明它们都是可选的

我在这里也帮你整理了一些最常见的用法，并且绘制成了表格，你可以参考使用。

接下来，我们再来看常用的过滤表达式。刚刚用过的是 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 的机器中，再用 Wireshark 打开它。打开后，你就可以看到下面这个界面：

它不仅以更规整的格式展示了各个网络包的头部信息，还用不同颜色展示 DNS 和 ICMP 这两种不同的协议。你也可以一眼看出，中间的两条 PTR 查询并没有响应包。

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

你可以看到，IP 层的源地址和目的地址、传输层的 UDP 协议、应用层的 DNS 协议的概要信息。继续点击每层左边的箭头，就可以看到该层协议头的所有信息。比如点击 DNS 后，就可以看到 Transaction ID、Flags、Queries 等 DNS 协议各个字段的数值以及含义。

 

使用案例

接下来再看一个 HTTP 的例子，并理解 TCP 三次握手和四次挥手的工作原理。

这个案例我们将要访问的是 http://example.com/ 。

进入终端一，首先执行dig查出 example.com 的 IP，然后执行 tcpdump 过滤得到的 IP 地址，并将结果保存到 web.pcap 中。也直接使用域名，即 tcpdump -nn host example.com -w web.pcap。

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

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

curl http://example.com

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

由于 HTTP 基于 TCP ，所以你最先看到的三个包，分别是 TCP 三次握手的包。接下来，中间的才是 HTTP 请求和响应包，而最后的三个包，则是 TCP 连接断开时的三次挥手包。

从菜单栏中，点击 Statistics -> Flow Graph，然后，在弹出的界面中的 Flow type 选择TCP Flows，你可以更清晰的看到，整个过程中 TCP 流的执行过

这其实跟各种教程上讲到的，TCP 三次握手和四次挥手很类似

不过，对比这两张图，这里抓到的包跟上面的四次挥手并不完全一样，实际挥手过程只有三个包，而不是四个。

其实，之所以有三个包，是因为服务器端收到客户端的 FIN 后，服务器端同时也要关闭连接，这样就可以把 ACK 和 FIN 合并到一起发送，节省了一个包，变成了“三次挥手”。而通常情况下，服务器端收到客户端的 FIN 后，很可能还没发送完数据，所以就会先回复客户端一个 ACK 包。稍等一会儿，完成所有数据包的发送后，才会发送 FIN 包。这也就是四次挥手了。

抓包后， Wireshark 中就会显示下面这个界面

当然，Wireshark 的使用方法绝不只有这些，更多的使用方法，同样可以参考 官方文档 以及 WIKI。

文章知识点与官方知识档案匹配，可进一步学习相关知识
CS入门技能树Linux实用命令tcpdump命令32624 人正在系统学习中
linux 性能 优化 实战 笔记 使用 tcpdump wireshark 分析 网络流量

与[转帖]《Linux性能优化实战》笔记（20）—— 使用 tcpdump 和 Wireshark 分析网络流量相似的内容：

[转帖]《Linux性能优化实战》笔记（20）—— 使用 tcpdump 和 Wireshark 分析网络流量

tcpdump 和 Wireshark 是最常用的网络抓包和分析工具，更是分析网络性能必不可少的利器。 tcpdump 仅支持命令行格式使用，常用在服务器中抓取和分析网络包。Wireshark 除了可以抓包，还提供了强大的图形界面和汇总分析工具，在分析复杂的网络情景时，尤为简单和实用。因而，在实际分

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（二）—— CPU 上下文切换（上）

上一篇的最后一个例子，在多个进程竞争CPU时，我们看到每个进程实际上%usr部分只有20%多，70%多是在wait，但是load远远高于单个进程使用CPU达到100%。 这让我想到之前看的RWP公开课，里面有一篇连接池管理。为什么相同的业务量，起6千个连接（进程）远远要慢于200个连接，因为绝大多数

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（一）—— 平均负载

最近在看极客时间的《Linux性能优化实战》课程，记录下学习内容。 一、 平均负载（Load Average） 1. 概念 我们都知道uptime命令的最后三列分别是过去 1 分钟、5 分钟、15 分钟系统的平均负载，到底平均负载是什么？ 简单来说，平均负载是指单位时间内，系统处于可运行状态和不可中

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（八）—— 内存是怎么工作的

一、 内存映射 我们通常所说的内存容量，指的是物理内存。物理内存也称为主存，大多数计算机用的主存都是动态随机访问内存（DRAM）。只有内核才可以直接访问物理内存。那么，进程要访问内存时，该怎么办呢？ Linux 内核给每个进程都提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样，进程就可以

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（22）—— 网络丢包问题分析

所谓丢包，是指在网络数据的收发过程中，由于种种原因，数据包还没传输到应用程序中，就被丢弃了。这些被丢弃包的数量，除以总的传输包数，也就是我们常说的丢包率。丢包率是网络性能中最核心的指标之一。丢包通常会带来严重的性能下降，特别是对 TCP 来说，丢包通常意味着网络拥塞和重传，进而还会导致网络延迟增大、

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（23）—— 内核线程 CPU 利用率过高，perf 与 火焰图

在排查网络问题时，我们还经常碰到的一个问题，就是内核线程的 CPU 使用率很高。比如，在高并发的场景中，内核线程 ksoftirqd 的 CPU 使用率通常就会比较高。回顾一下前面学过的 CPU 和网络模块，你应该知道，这是网络收发的软中断导致的。 要分析 ksoftirqd 这类 CPU 使用率比

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（24）—— 动态追踪 DTrace

使用 perf 对系统内核线程进行分析时，内核线程依然还在正常运行中，所以这种方法也被称为动态追踪技术。动态追踪技术通过探针机制来采集内核或者应用程序的运行信息，从而可以不用修改内核和应用程序的代码就获得丰富的信息，帮你分析、定位想要排查的问题。 以往，在排查和调试性能问题时，我们往往需要先为应用程

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（25）—— 总结：Linux 性能工具速查

一、 性能工具速查 在梳理性能工具之前，首先给你提一个问题，那就是，在什么情况下，我们才需要去查找、挑选性能工具呢？ 其实在我看来，只有当你想了解某个性能指标，却不知道该怎么办的时候，才会想到，“要是有一个性能工具速查表就好了”这个问题。如果已知一个性能工具可用，我们更多会去查看这个工具的手册，找出

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（21）—— 网络性能优化思路

一、 确定优化目标 优化前，我会先问问自己，网络性能优化的目标是什么？实际上，虽然网络性能优化的整体目标，是降低网络延迟（如 RTT）和提高吞吐量（如BPS 和 PPS），但具体到不同应用中，每个指标的优化标准可能会不同，优先级顺序也大相径庭。 拿NAT 网关来说，由于其直接影响整个数据中心的网络出

linux 性能 优化 实战
0
[转帖]《Linux性能优化实战》笔记（十九）—— DNS 解析原理与故障案例分析

一、 域名与 DNS 解析 域名主要是为了方便让人记住，而 IP 地址是机器间的通信的真正机制。以 time.geekbang.org 为例，最后面的 org 是顶级域名，中间的 geekbang 是二级域名，而最左边的 time 则是三级域名。点（.）是所有域名的根，所有域名都以点作为后缀。 把域

linux 性能 优化 实战
0
# 热门排行
微软 New Bing AI 申请与使用保姆级教程（免魔法） ChatGPT API使用介绍 ChatGPT开发实战 一篇带你了解如何使用纯前端类Excel表格构建现金流量表 手把手教你玩转 Excel 数据透视表 为什么 C# 可能是最好的第一编程语言 .NET 入门到高级路线 提高工作效率的神器：基于前端表格实现Chrome Excel扩展插件 React + Springboot + Quartz，从0实现Excel报表自动化 用Echarts实现前端表格引用从属关系可视化
© PmDaddy. 2023 PmDaddy教程网 All rights reserved.