开工大吉，一篇高品质技术干货送给大家
tcpdump就是dump the traffic on a 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
案例一
如果应用程序连接数据库，输入了错误的密码，在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还可以诊断网络是否有丢包，网络延迟等问题。
读码上万行
下键如有神
扫码关注
