tcpdump 抓包常见问题处理方案

常见提示信息与处理方案

[Packet size limited during capture]

问题现象：如下图所示，全长有171字节，但只获取到前96个字节。

可能原因：此提示说明被标记的包信息没有完整的获取，一般是由于抓包方式引起。

处理方案：在某些操作系统中，tcpdump默认只抓每个帧的前96字节，可以通过-s参数指定想要抓取的字节数。示例命令如下所示。

sudo tcpdump -i eth0 -s 1000 -w tcpdump.cap

[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、优化网络带宽等方式解决该问题。

原文地址：https://www.alibabacloud.com/help/zh/ecs/user-guide/a-common-tip-of-wireshark