【网络排查】tcpdump和Wireshark
tcpdump
tcpdump 可以工作在各种 Unix 类的操作系统上，包括 Linux、FreeBSD、macOS、Solaris 等，也是目前使用最为广泛的抓包工具之一。但是 tcpdump 要过滤报文的话，还要依赖一个底层能力：BPF。
BPF
BPF 全称是 Berkeley Packet Filter（也叫 BSD Packet Filter），它是 tcpdump 等抓包工具的底层基础。它以一种新的基于寄存器的虚拟机方式，实现了高效稳定的报文过滤功能。从此以后，抓包技术这棵大树有了一个甚为强大的根基，而构建在 BPF 之上的 libpcap、tcpdump 等不断枝繁叶茂，进一步使得抓包工作变得方便、稳定。
libpcap
BPF 实现了抓包虚拟机，但它是如何被用户空间程序使用的呢？于是，libpcap 出现了，它提供了 API 给用户空间程序（包括 tcpdump、Wireshark 等），使得后者能方便地调用 BPF 实现抓包过滤等功能。也就是说，libpcap 是 BPF 的一层 API 封装。
WinPcap
Windows 上也可以做到类似 Linux 这样的抓包，其底层就是依赖 WinPcap，它是 libpcap 的 Windows 版本。
eBPF
Linux 从 3.18 版本开始支持 extended BPF，简称 eBPF。这是一个更加通用的内核接口，不仅能支持网络抓包，还能支持网络以外的内核观测点的信息收集等工作。所以事实上，eBPF 已经是一个通用工具，而不再局限在网络工具这个角色定位上了。
如何使用tcpdump
如何抓取报文
过滤IP地址
tcpdump host 10.10.10.10
过滤端口
tcpdump port 22
常用参数：
- -w 文件名，可以把报文保存到文件；
- -c 数量，可以抓取固定数量的报文，这在流量较高时，可以避免一不小心抓取过多报文；
- -s 长度，可以只抓取每个报文的一定长度，后面我会介绍相关的使用场景；
-
-n，不做地址转换（比如 IP 地址转换为主机名，port 80 转换为 http）；-n，不做地址转换（比如 IP 地址转换为主机名，port 80 转换为 http）；
- -v/-vv/-vvv，可以打印更加详细的报文信息；
- -e，可以打印二层信息，特别是 MAC 地址；
- -p，关闭混杂模式。所谓混杂模式，也就是嗅探（Sniffering），就是把目的地址不是本机地址的网络报文也抓取下来。
-w 文件名，可以把报文保存到文件；-w 文件名，可以把报文保存到文件；
如何过滤报文
过滤出TLS握手的报文
tcpdump -w file.pcap 'dst port 443 && tcp[20]==22 && tcp[25]==1'
- dst port 443：这个最简单，就是抓取从客户端发过来的访问 HTTPS 的报文。
- tcp[20]==22：这是提取了 TCP 的第 21 个字节（因为初始序号是从 0 开始的），由于 TCP 头部占 20 字节，TLS 又是 TCP 的载荷，那么 TLS 的第 1 个字节就是 TCP 的第 21 个字节，也就是 TCP[20]，这个位置的值如果是 22（十进制），那么就表明这个是 TLS 握手报文。
- tcp[25]==1：同理，这是 TCP 头部的第 26 个字节，如果它等于 1，那么就表明这个是 Client Hello 类型的 TLS 握手报文。
如何过滤后转存？
tcpdump -r file.pcap 'tcp[tcpflags] & (tcp-rst) != 0' -w rst.pcap
Wireshark
怎么知道抓包文件是在哪一端抓取的？
要搞清楚这一点也很简单，我们可以利用 IP 的 TTL 属性。显然，无论是哪一端，它的报文在发出时，其 TTL 就是原始值，也就是 64、128、255 中的某一个。而对端报文的 TTL，因为会经过若干个网络跳数，所以一般都会比 64、128、255 这几个数值要小一些。所以，我们只要看一下抓包文件中任何一个客户端报文（也就是源端口为高端口）的 TTL，如果它是 64、128 或 255，那说明这个抓包文件就是在客户端做的。反之，就是在服务端做的。
如何定位到应用层的请求和返回的报文？
我们只要选中请求报文，Wireshark 就会自动帮我们匹配到对应的响应报文，反过来也一样。从图上看，应用层请求（这里是 HTTP 请求）是一个向右的箭头，表示数据是进来的方向；应用层响应是一个向左的箭头，表示数据是出去的方向。
乱序一定会引起问题吗？
乱序（Out-of-Order），也是我们时常能在 Wireshark 里看到的一类现象。那么，乱序一定会引起问题吗？有一句话叫“脱离了剂量谈毒性就是耍流氓”。其实，乱序是否是问题，也取决于乱序的严重程度。那第二个问题随之就来了：乱序包达到什么程度，就会真的引起问题？这个问题，跟实际场景的具体情况也有很大的关系，不同的操作系统以及 TCP 实现细节，都可能有挺大的差异。不过，我还是想正面回答一下这个问题。我的经验是，如果乱序报文达到 10% 以上，就是严重的传输质量问题了，甚至可能导致传输失败，或者应用层的各种卡顿、报错等症状。所以，你可以统计一下乱序包的占比，如果它超过了 10%，就要重视了。
