网络数据包抓取广泛用于故障诊断、安全审计等场景。本文介绍使用 tcpdump 或 Wireshark 抓包时的常见问题及其解决方法。
背景介绍
tcpdump和Wireshark是功能强大的网络协议分析工具。Wireshark支持大多数主流操作系统，包括Linux、Windows和macOS。在通常情况下，云环境中的Linux实例默认未安装图形用户界面，因此，当您需要在云环境的Linux实例中进行网络数据包抓取时，建议使用tcpdump工具。关于上述两种工具的安装及使用说明，请参见使用抓包工具进行网络数据包抓取。
tcpdump常见提示信息与处理方案
[Packet size limited during capture]
问题现象：如下图所示，全长有171字节，但只获取到前96个字节。
可能原因：此提示说明被标记的包信息没有完整的获取，一般是由于抓包方式引起。
处理方案：在某些操作系统中，tcpdump默认只抓每个帧的前96字节，可以通过-s参数指定想要抓取的字节数。示例命令如下所示。
sudo tcpdump -i eth0 -s 1000 -w tcpdump.capWireshark常见提示信息与处理方案
[TCP Previous segment not captured]
问题现象：抓包时出现丢包或者抓包工具漏包。具体示例如下图所示。
可能原因：此提示说明未捕获TCP协议之前的分段，抓取的数据段缺失。一般是由于丢包或者抓包工具漏掉导致。
处理方案：具体情况需分析抓包结果并参考上述示例进行分析判断。
在使用TCP协议进行数据传输的过程中，同一主机发送的数据段应当是连续的。具体而言，后一个数据段的 Seq 应等于前一个数据段的 Seq + 数据负载长度（即 Seq + Len - TCP头部长度），而接收方的 Ack 字段值等于发送方数据段的 Seq + 数据负载长度，表示期望收到的下一个字节的序号（三次握手或四次挥手的情况除外）。若后一个数据段的 Seq 大于前一个的 Seq + 数据负载长度，且未观察到中间数据段，则可能存在以下情况：
抓包遗漏（TCP Previous segment not captured）：若后续
Ack包含未捕获的Seq范围（如发送方发送Seq=1000和Seq=2000，接收方返回Ack=2000），说明中间数据已被接收方确认，但抓包工具漏掉。丢包：若后续
Ack未覆盖未捕获的Seq范围（如发送方发送Seq=1000和Seq=2000，接收方返回Ack=1000），说明中间数据未被接收方确认，可能已丢包。网络中可能出现数据段乱序（后续段先于前面段到达），此时接收方会通过
Ack重复确认已接收的连续Seq，直到收到缺失段。
对于乱序与窗口机制的处理逻辑如下：
若数据段
Seq超出接收窗口（Window）范围，接收方会丢弃该段，需依赖超时重传或快速重传机制恢复。网络中可能出现数据段乱序（后续段先于前面段到达），此时接收方会通过 Ack 重复确认已接收的连续 Seq，直到收到缺失段。若数据段 Seq 超出接收窗口（Window）范围，接收方会丢弃该段，需依赖超时重传或快速重传机制恢复。
[TCP ACKed unseen segment]
问题现象：抓包时出现[TCP ACKed unseen segment]提示，具体示例如下图所示。
可能原因：该提示说明Acked的包未被捕获。根据上图第32行的信息，序列号（Seq）加上长度（Len）的值为6889加1448，等于8337。根据推测，服务器下一个包的序列号应为8337。然而，35行显示的序列号为11233，这表明在8337至11232这一段之间的信息未被捕获，即仅捕获到了后续的确认包，而未捕获到前面的数据包。8337至11232之间的信息理应在第34行之前出现。
处理方案：此提示可能是最常见的Wireshark提示，需分析抓包结果并参考上述示例进行分析判断。
[TCP Out-of-Order]
问题现象：抓包时出现[TCP Out-of-Order]提示，具体示例如下所示。
可能原因：此提示说明数据包乱序，当Wireshark发现后一个包的Seq小于前一个包的Seq加Len，则会被认为是乱序。小跨度的乱序影响不大，比如原本1、2、3、4、5被打乱成2、1、3、4、5。但跨度大可能会触发快速重传，比如打乱成2、3、4、5、1，就会触发足够多的“Dup ACK”，从而导致包重传。
处理方案：参考上述示例进行分析，如果偶发的小跨度乱序可以予以忽略，但若频繁发生跨度较大的乱序，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
[TCP Dup ACK]
问题现象：抓包时出现[TCP Dup ACK]提示，具体示例如下所示。
可能原因：此提示说明出现重复的Ack。当乱序或者丢包发生时，接受方收到一些Seq比期望值大的包。每收到一个这种包就会回应一次期望的Seq值，依次提醒发送方，因此会产生重复的Ack。
处理方案：如果频繁出现此种情况，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
[TCP Retransmission]
问题现象：抓包时出现[TCP Retransmission]提示，具体示例如下所示。
可能原因：此提示说明数据包进行重传，如果一个包丢失，又没有后续包可以在接收方触发“Dup ACK”，就不会快速重传。这种情况发送方只能等到超时重传。如上图所示，客户端发了1053号原始包，一直等不到对应的Ack，于是只能在100多毫秒之后重传1225包。
处理方案：如果频繁出现此种情况，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
TCP为可靠传输，通过在发送时设置一个定时器来解决数据包确认问题。如果当定时器溢出时还没有收到确认，它就重传该数据。对于重传时间是如何计算的问题，在RFC2988中也提供了一种Linux至今都在使用的方案。详细介绍可以参考文档TCP-IP详解中的RTT和RTO。
[TCP Fast Retransmission]
问题现象：抓包时出现[TCP Fast Retransmission]提示，具体示例如下所示。
可能原因：此提示说明数据包快速重传，当发送方收到3个及3个以上的“TCP Dup ACK”时，就意识到之前发的包可能丢了，于是快速重传。具体示例如下图所示。当服务器端收到3个“TCP Dup ACK”，于是在1177号包重传了Seq等于991851。
处理方案：如果频繁出现此种情况，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
快速重传机制，实现了另外的一种丢包评定标准。当接收方一连收到三个重复的ACK，那么发送方不必等待重传定时器到期，尽早重传未被确认的报文段。
[TCP zerowindow]
问题现象：抓包时出现[TCP zerowindow]提示，具体示例如下所示。
可能原因：此提示说明接收窗口为0，缓存区已满，不再接受数据。“win=”表示这个包的发送方还有多少缓存区可以接受数据。“Win=0”表示缓存区已满，告知对方自己不再接收数据。具体示例如下图所示。
处理方案：导致出现该问题的可能原因有接收端处理能力不足，或网络带宽资源不足等，需要进一步分析定位具体原因。
[TCP window Full]
问题现象：抓包时出现[TCP window Full]提示，具体示例如下所示。
可能原因：此提示说明发送窗口已满。如上图所示。表示包的发送方已经把对方所声明的接受窗口耗尽，暂时无法再发送数据。
处理方案：导致出现该问题的可能原因有接收端处理能力不足，或网络带宽资源不足等，需要进一步分析定位具体原因。
在途字节数（Bytes in flight）等于对方的接收窗口，表示发送方已经发送数值，减去对方最近的一次确认数值，等于确认了多少数值。也就是等于Seq加上Len等于Ack，即最近的一次Ack。以下2个字段意味着传输暂停，都需引起重视。
在途字节数（Bytes in flight）等于接收方的接收窗口，这表明发送方已发送的字节数减去接收方最近一次确认的字节数，等于已确认的字节数。即Seq加上Len等于Ack，亦即最近一次的Ack。以下两个字段表示传输已暂停，需引起高度重视。
[TCP segment of a reassembled PDU]
问题现象：抓包时出现[TCP segment of a reassembled PDU]提示，具体示例如下所示。
可能原因：此提示说明重组PDU的TCP协议分段。表示Wireshark可以把属于同一个应用层PDU的TCP包虚拟的集中起来。
处理方案：需要在软件中设置，选择Edit>Preferences>Protocol>TCP，确认启用“Allow sub dissector to reassemble TCP streams”，ACK确认包号是相同的。
[Continuation to #X]
问题现象：抓包时出现[Continuation to #X]提示，具体示例如下所示。
可能原因：此提示表示关闭了"Allow sub dissector to reassemble TCP streams"，按照实际情况开启即可。
处理方案：需要在软件中设置，选择Edit>Preferences>Protocol>TCP，确认启用“Allow sub dissector to reassemble TCP streams”。
Time-to-live exceeded (Fragment reassembly time exceeded)
问题现象：抓包时出现Time-to-live exceeded (Fragment reassembly time exceeded)提示，具体示例如下所示。
可能原因：此提示说明超出TTL生存时间，即超出碎片重组时间。表示这个包的发送方之前收到了一些分片，但是由于某些原因迟迟无法组装起来。如上图所示，由于上海发往北京的一些包被分片传输，且有一部分在链路上丢失。因此北京无法组装起来，只能使用这个ICMP报错告知对方。
处理方案：如果该问题长时间存在，您可以通过检查路由表、使用MTR工具排查网络环路、调整 TTL 初始值、调整 MTU、优化网络带宽等方式解决该问题。
相关文档
关于Wireshark的更多内容，请参阅Wireshark官方文档。
关于如何使用抓包工具进行抓包，请参见使用抓包工具进行网络数据包抓取。
关于能ping通实例但是端口不通的问题处理方法，请参见能ping通ECS实例但端口不通的排查方法。
关于使用MTR工具进行网络链路分析的相关操作，请参见使用MTR工具进行网络链路分析。