Tcpdump在数据库中的使用实践

开工大吉，一篇高品质技术干货送给大家

一、概述

tcpdump就是dump the traffic ona network，根据使用者的定义对网络上的数据包进行截获的包分析工具。需要root用户或者有sudo权限的用户才可以执行tcpdump。

二、选项介绍

1、-i any: 监听所有的流量。这样你就知道是不是有流量产生。

2、-n: 不要解决主机名，以IP数字形式显示主机。

3、-nn: 不要解析主机名或端口名字。

4、-v, -vv, -vvv: 详细，更详细，再详细些! 冗余输出得到的包信息。

5、-c: 抓取 x 个包后就停下。

6、-s: 设置显示前多少个字节的包内容(snaplength)。

7、-w: 写入文件，把抓取到的内容存入该文件内。以后还可以用 -r 指定文件，把以前存入的内容再读回来。这是一个相当不错的方法，可以先抓取包，以后再用各种工具分析。

以这种形式抓到的流量是以tcpdump的格式储存的。这种格式在网络分析的工具之间非常通用。这意味着，像 Wireshark, Snort, 等工具也可以读取它。

三、使用实例

(1) 截获所有210.27.48.1 的主机收到的和发出的所有的分组：

# tcpdump host 210.27.48.1

(2) 截获主机210.27.48.1 和主机210.27.48.2或210.27.48.3的通信，使用命令（注意：括号前的反斜杠是必须的）：

# tcpdump host 210.27.48.1 and \(210.27.48.2 or 210.27.48.3 \)

(3) 截获主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包，使用命令：

# tcpdump ip host 210.27.48.1 and !210.27.48.2

(4) 截获通信协议为port 22，目标来源为192.168.1.100的数据包：

# tcpdump -nn port 22 and src host 192.168.1.100

四、Tcpdump解决实际问题

案例一

如果应用程序连接数据库，输入了错误的密码，在mysql 5.7的错误日志文件有对应log：

而mysql 5.6的错误日志文件没有类似信息，遇到这种情况，可以用tcpdump找到报错的主机和用户名。

首先在目标数据库主机，开始抓包

# 只抓3769端口的包，每个包最大为1520字节，最多抓40000个数据包，抓到的包写到tcpdump.pcap文件，方便后面做分析

tcpdump -i any tcp and port 3769 -s 1520 -c 40000 -w tcpdump.pcap

输入错误的mysql密码，登录报错后，停止抓包

可以看到一共抓到了82个包，过滤了171个包。

将pcap文件下载到电脑后，可以使用Wireshark进行分析。

Wireshark是一款支持多平台的包抓取分析开源软件，前身是ethereal。

用Wireshark打开pcap包，搜索密码错误报错的关键字"denied"，可以找到数据库给应用返回报错的数据包。

找到抓包时间内出现过密码错误的报错，抓包记录中有应用所在主机ip(Destination ip)，数据库所在主机ip(Source ip)，数据库端口(Source Port)，错误时间(Time)。

案例二

有时候，应用端慢sql日志抓到了一条sql语句，但是在数据库的慢sql日志却没有。这种情况怎么定位问题呢？如果简单的说数据库没有问题，是没有说服力的，还得拿真实数据说话。这个时候也可以通过tcpdump来定位问题。

1

在数据库210的主机上开始抓包

tcpdump -i any tcp and port 3769 -s 1520 -c 40000 -w tcpdump.pcap

应用程序抓到了一个慢sql，慢sql执行时间为700ms，执行的sql为：select count(0) from test_table1。此时停止抓包

2

下载tcpdump.pcap包

下载tcpdump.pcap包，用Wireshark打开进行分析

3

跟踪TCP流

搜索关键字test_table1，找一条记录，Time记录的时间跟sql实际执行时间一致。

在找到的记录上点击右键，跟踪TCP流

4

分析TCP流有四条记录

这条记录相关的TCP流有四条记录，下面详细分析一下这四条记录

第一条记录：

这条记录是211的应用机器给数据库发的执行sql，发送时间是2018-02-09 10:55:06 868076，右下角可以大概看到是我们执行的sql语句。

第二条记录：

这条记录是数据库210收到sql后，给应用主机211发的确认ACK，表明已收到sql，发送时间是2018-02-09 10:55:06 868081。右下角是一堆类似乱码的字符。

第二条记录减去第一条记录的时间为0.005ms，即应用发送执行sql到数据库接收到sql，耗时大约5微妙。

接下来看第三条记录：

这条记录是数据库执行完sql，把结果发给应用。发送时间是2018-02-09 10:55:07 547763。第三条记录的时间减去第二条sql的时间，为679.682ms，这是时间是数据库执行sql所需的时间。

第四条记录：

这条记录是应用给数据库返回确认ACK，表明应用已收到数据库发送的查询结果。

发送时间是2018-02-09 10:55:07 547849。第四条记录的时间减去第一条记录的时间，为679.773ms，这个时间是应用发出sql到接收到结果的时间。

应用记录的慢sql执行时间为700ms，跟679.773相差不大，可以判断整过过程中没有丢包重传，也没有其他耗时的操作，真正慢在了数据库端。查看数据库的慢sql日志阈值是1秒，自然是没有抓到慢日志的。

5

总结

以上是tcpdump解决的两个简单案例，tcpdump还可以诊断网络是否有丢包，网络延迟等问题。