Wireshark TS | 虚惊事件之 TCP 大量重传

问题背景

某天某研发中心同事拉群呼唤，反馈说是业务系统所使用的 Linux 机器每个 TCP 报文都有重传的现象，无论是业务系统内的业务通信数据包还是像是 SSH、SFTP 数据包都有重传现象，询问网络层面是否有问题？

第一反应自然是不可能，如果这样，肯定业务早就有问题，但话不能说的太满，毕竟打脸事件嘛，还是可能发生的，万一呢 🤣

问题分析

既然说是看到了数据包重传现象，从数据包分析角度，自然需要眼见为实，进一步沟通一些基本信息，业务系统负责人提供了些端到端 IP 通讯对，并得知该业务系统部署在多数据中心，多个机器都有同样问题现象。

至此心中已大定，再怎么样肯定和网络无关，要不公司业务早炸锅了。

但数据包重传现象还是在的，既然有，那么还是要就问题原因给出一番合理的解释的，还是具体看包才能清楚问题。

3 台服务器跟踪文件如下，首先文件大小实在太大，最大的一个文件别说压缩前 3.8G 了，压缩后的 434 M 对于 Wireshark 解析都已经很吃力了，加载再加载~

数据包捕获

从我个人经验上来说，还是那句话，如果能不用捕获过滤，就不用 原因是除非捕获性能问题或是你对协议120%精通，否则不要使用捕获过滤器，这里所面临的性能问题就是跟踪文件太大，Wireshark 并不能很好的加载并分析，每次操作都会面临加载再加载的情况。

通过 capinfos 查看最大的一个跟踪文件相关信息，文件大小约 4GB，持续时间 37 分钟，抓取了 4.7M 个数据包，难怪 ~ 能不大嘛。。。

$ capinfos 20220226.cap
File name:           20220226.cap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Linux cooked-mode capture v1
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 262144 bytes
Number of packets:   4770 k
File size:           4097 MB
Data size:           3944 MB
Capture duration:    2220.841404 seconds
First packet time:   2022-02-26 10:09:51.557310
Last packet time:    2022-02-26 10:46:52.398714
Data byte rate:      1776 kBps
Data bit rate:       14 Mbps
Average packet size: 826.73 bytes
Average packet rate: 2148 packets/s
SHA256:              5271fd07c06415eb5ced163bd8365ca8d24855368e7adea9105ad009c683d76f
RIPEMD160:           45a8177d1de968bf22edf66fda39a8bc9baab736
SHA1:                33457cb2fd4d4c15248101e2c7d345878e70b64c
Strict time order:   False
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Linux cooked-mode capture v1 (25 - linux-sll)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 4770992

数据包分析

如此大的跟踪文件，自然不可能直接打开进一步分析。考虑到业务系统负责人所反馈的问题现象，每个 TCP 报文都有重传，那么可以使用editcap 取 1000 个数据包简单分析下。

$ editcap -r 20220226.cap test.pcapng 1-1000

经过处理之后的 test 跟踪文件大小仅为 786 KB，其实打开文件就已经知道大概是什么问题了，跟踪文件数据包重复。

原因其实在 capinfos 信息中也有提示，Linux cooked-mode capture v1 (25 - linux-sll) ，说明 tcpdump 所抓取的接口为 any，意味着有重复网卡。进一步询问业务系统负责人，确实运行的命令为 tcpdump -i any xxx ，而服务器网卡是做了 bond，也就是说物理网卡抓取了一份数据包，逻辑网卡 bond 也抓取了同样一份数据包，自然在 Wireshark 中会显示为大量重复。

$ capinfos 20220226.cap
Interface #0 info:
                     Encapsulation = Linux cooked-mode capture v1 (25 - linux-sll)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 4770992

如何去重？仍然使用 editcap 达到目的。可以看到原始文件 test.pcapng 1000 个数据包中检查出有 517 个重复数据包，去重后 test1.pcapng 剩余 483 个数据包。

$ editcap -d test.pcapng test1.pcapng
1000 packets seen, 517 packets skipped with duplicate window of 5 packets.

$ capinfos -c test1.pcapng
File name:           test1.pcapng
Number of packets:   483

再次打开跟踪文件后，数据包一切正常，自然实际业务也是一切正常。

问题总结

采用正确的捕获方式，并善用 CLI 工具，再加上合理的判断分析，问题自然迎刃而解。

---

感谢阅读，更多技术文章可关注个人公众号：Echo Reply ，谢谢。