网络数据包抓取广泛用于故障诊断、安全审计等场景。本文介绍使用 tcpdump 或 Wireshark 抓包时的常见问题及其解决方法。
背景介绍
tcpdump和Wireshark是功能强大的网络协议分析工具。Wireshark支持大多数主流操作系统，包括Linux、Windows和macOS。在通常情况下，云环境中的Linux实例默认未安装图形用户界面，因此，当您需要在云环境的Linux实例中进行网络数据包抓取时，建议使用tcpdump工具。关于上述两种工具的安装及使用说明，请参见使用抓包工具进行网络数据包抓取。
tcpdump常见提示信息与处理方案
[Packet size limited during capture]
问题现象：全长有171字节，但只获取到前96个字节。
No. Time Source Destination Protocol Info
1 0.000000 Client Server TCP 48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PE
2 0.001482 Server Client TCP 443-48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1
3 0.001501 Client Server TCP 48113-443 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=4157
4 0.009432 Client Server SSL [Packet size limited during capture]
5 0.010923 Server Client TCP 443-48113 [ACK] Seq=1 Ack=106 Win=5792 Len=0 TSval=43
Frame 4: 171 bytes on wire (1368 bits), 96 bytes captured (768 bits)可能原因：此提示说明被标记的包信息没有完整的获取，一般是由于抓包方式引起。
处理方案：在某些操作系统中，tcpdump默认只抓每个帧的前96字节，可以通过-s参数指定想要抓取的字节数。示例命令如下所示。
sudo tcpdump -i eth0 -s 1000 -w tcpdump.capWireshark常见提示信息与处理方案
[TCP Previous segment not captured]
问题现象：抓包时出现丢包或者抓包工具漏包。具体示例如下所示。
No. Time Source Destination Protocol Info
1 0.000000 Client Server TCP 48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PE
2 0.001482 Server Client TCP 443-48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1
3 0.001501 Client Server TCP 48113-443 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=4157
4 0.009432 Client Server SSL [Packet size limited during capture]
5 0.010923 Server Client TCP 443-48113 [ACK] Seq=1 Ack=106 Win=5792 Len=0
6 0.011691 Client Server SSL [TCP Previous segment not captured]
Transmission Control Protocol, Src Port: 443, Dst Port: 48113, Seq: 1449, Ack: 106, Len: 667可能原因：此提示说明未捕获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]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
32 1.256720 Server Client TCP [Continuation to #26] 445-2199 [ACK] Seq=6889 Ack=885 Win=65535 Len=1448
33 1.256729 Server Client TCP 2199-445 [ACK] Seq=885 Ack=8337 Len=2920 Len=0
34 1.256961 Client Server TCP [TCP ACKed unseen segment] 2199-445 [ACK] Seq=885 Ack=11233 Win=2920 Len=0
35 1.257191 Server Client TCP [Continuation to #26] [TCP Previous segment not captured] 445-2199 [ACK] Seq=11233可能原因：该提示说明Acked的包未被捕获。根据上述示例第32行的信息，序列号（Seq）加上长度（Len）的值为6889加1448，等于8337。根据推测，服务器下一个包的序列号应为8337。然而，35行显示的序列号为11233，这表明在8337至11232这一段之间的信息未被捕获，即仅捕获到了后续的确认包，而未捕获到前面的数据包。8337至11232之间的信息理应在第34行之前出现。
处理方案：此提示可能是最常见的Wireshark提示，需分析抓包结果并参考上述示例进行分析判断。
[TCP Out-of-Order]
问题现象：抓包时出现[TCP Out-of-Order]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
3360 5.007813 Server Client TCP 49454-8888 [ACK] Seq=2712622 Ack=2761 Win=32768
3361 5.007813 Client Server TCP 8888-49454 [ACK] Seq=2761 Ack=2639576 Win=2457
3362 5.007813 Server Client TCP [TCP Out-of-Order] 49454-8888 [ACK] Seq=2685642
3363 5.007813 Client Server TCP 8888-49454 [ACK] Seq=2761 Ack=2664291 Win=2457可能原因：此提示说明数据包乱序，当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]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
3 0.007813 Client Server TCP [Continuation to #] 55448-445 [ACK] Ack=243 Len=888
4 0.007813 Client Server TCP [TCP Previous segment not captured] 55448-445 [ACK]
5 0.007813 Server Client TCP 445-55448 [ACK] Seq=243 Ack=1 Win=65535
6 0.007813 Client Server TCP 445-55448 [ACK] Seq=243 Ack=1 Win=885
7 0.007813 Server Client TCP [TCP Dup ACK] 8888-49454 Ack=1466 Win=1 Len=0
8 0.007813 Server Client TCP [TCP Dup ACK] 8888-49454 Ack=1466 Win=1 Len=0
9 0.007813 Server Client TCP [TCP Dup ACK] 8888-49454 [ACK] Seq=2185
10 0.007813 Server Client TCP [TCP Dup ACK] 443-33448 [ACK] Seq=2185可能原因：此提示说明出现重复的Ack。当乱序或者丢包发生时，接受方收到一些Seq比期望值大的包。每收到一个这种包就会回应一次期望的Seq值，依次提醒发送方，因此会产生重复的Ack。
处理方案：如果频繁出现此种情况，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
[TCP Retransmission]
问题现象：抓包时出现[TCP Retransmission]提示，具体示例如下所示。
Filter: tcp.seq == 1012852
No. Time Source Destination Protocol Info
1053 0.804688 Client Server TCP 49454-8888 [ACK] Seq=1012852 Ack=1105 Win=32768 Len=...
1225 0.937500 Client Server TCP [TCP Retransmission] 49454-8888 [ACK] Seq=1012852 Ack...可能原因：此提示说明数据包进行重传，如果一个包丢失，又没有后续包可以在接收方触发“Dup ACK”，就不会快速重传。这种情况发送方只能等到超时重传。如上述示例所示，客户端发了1053号原始包，一直等不到对应的Ack，于是只能在100多毫秒之后重传1225包。
处理方案：如果频繁出现此种情况，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
TCP为可靠传输，通过在发送时设置一个定时器来解决数据包确认问题。如果当定时器溢出时还没有收到确认，它就重传该数据。对于重传时间是如何计算的问题，在RFC2988中也提供了一种Linux至今都在使用的方案。详细介绍可以参考文档TCP-IP详解中的RTT和RTO。
[TCP Fast Retransmission]
问题现象：抓包时出现[TCP Fast Retransmission]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
1169 0.828125 Server Client TCP 49454-8888 [ACK] Seq=1098048 Ack=1105 Win=32768 Len=1448
...
1171 0.828125 Client Server TCP 8888-49454 [ACK] Seq=2761 Ack=991851 Win=2457 Len=0
...
1174 0.867188 Client Server TCP [TCP Dup ACK 1171#1] 8888-49454 [ACK] Seq=1105 Ack=991851
1175 0.867188 Client Server TCP [TCP Dup ACK 1171#2] 8888-49454 [ACK] Seq=1105 Ack=991851
1176 0.867188 Client Server TCP [TCP Dup ACK 1171#3] 8888-49454 [ACK] Seq=1105 Ack=991851
1177 0.867188 Server Client TCP [TCP Fast Retransmission] 49454-8888 [ACK] Seq=991851可能原因：此提示说明数据包快速重传，当发送方收到3个及3个以上的“TCP Dup ACK”时，就意识到之前发的包可能丢了，于是快速重传。如上述示例所示，当服务器端收到3个“TCP Dup ACK”，于是在1177号包重传了Seq等于991851。
处理方案：如果频繁出现此种情况，您可以结合MTR等工具进一步分析定位问题，或者查看中间设备，如交换机、路由器等的日志来进一步分析。
快速重传机制，实现了另外的一种丢包评定标准。当接收方一连收到三个重复的ACK，那么发送方不必等待重传定时器到期，尽早重传未被确认的报文段。
[TCP zerowindow]
问题现象：抓包时出现[TCP zerowindow]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
3258 3.140625 Server Client TCP Seq=467 Ack=11928601 Win=15872 Len=0
3259 3.140625 Server Client TCP Seq=467 Ack=11931449 Win=13025 Len=0
3260 3.140625 Server Client TCP Seq=467 Ack=11934174 Win=10300 Len=0
3261 3.140625 Server Client TCP Seq=467 Ack=11940137 Win=3517 Len=0
3262 3.140625 Server Client TCP [TCP ZeroWindow] Seq=467 Ack=11941327 Win=0 Len=0
3263 3.140625 Server Client TCP [TCP ZeroWindow] 8888-62758 Seq=467 Ack=... Win=0
3265 3.140625 Server Client TCP [TCP ZeroWindow] 8888-62758 [ACK] Win=0
3267 3.167969 Server Client TCP [TCP ZeroWindow] 8888-62758 [PSH, ACK] Seq=7743 Win=0可能原因：此提示说明接收窗口为0，缓存区已满，不再接受数据。“win=”表示这个包的发送方还有多少缓存区可以接受数据。“Win=0”表示缓存区已满，告知对方自己不再接收数据。如上述示例所示。
处理方案：导致出现该问题的可能原因有接收端处理能力不足，或网络带宽资源不足等，需要进一步分析定位具体原因。
[TCP window Full]
问题现象：抓包时出现[TCP window Full]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
71 3.392855 middle east britain TCP [TCP Window Full] 64560-12345 [ACK] Seq=202344 Ack=1
72 3.393142 middle east britain TCP 12345-64560 [ACK] Seq=1 Ack=142521 Win=5792 Len=0
73 3.395832 middle east britain TCP [TCP Window Full] 64560-12345 [ACK]
74 3.396350 middle east britain TCP 12345-64560 [ACK]
75 3.407549 middle east britain TCP [TCP Window Full]
76 4.002180 britain middle east TCP ...
78 4.004231 britain middle east TCP 64560-12345 Seq=1 Ack=51089
[Bytes in flight: 65535]
[iRTT: 0.04096000 seconds]可能原因：此提示说明发送窗口已满。如上述示例所示，表示包的发送方已经把对方所声明的接受窗口耗尽，暂时无法再发送数据。
处理方案：导致出现该问题的可能原因有接收端处理能力不足，或网络带宽资源不足等，需要进一步分析定位具体原因。
在途字节数（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]提示，具体示例如下所示。
No. Time Source Destination Protocol Info Length
86 5.011522 Client Server SMB Read AndX Request, FID: 0x00a4, 14215 bytes ...
87 5.014424 Server Client SMB Read AndX Response, FID: 0x004a, 14215 bytes ...
88 5.014024 Client Server TCP TCP segment of a reassembled PDU
89 5.014028 Client Server TCP TCP segment of a reassembled PDU
90 5.014028 Server Client TCP TCP segment of a reassembled PDU
91 5.014028 Server Client TCP TCP segment of a reassembled PDU
...
Frame 86: 1311 bytes on wire (10504 bits), 1311 bytes captured (10504 bits)可能原因：此提示说明重组PDU的TCP协议分段。表示Wireshark可以把属于同一个应用层PDU的TCP包虚拟的集中起来。
处理方案：需要在软件中设置，选择Edit>Preferences>Protocol>TCP，确认启用“Allow sub dissector to reassemble TCP streams”，ACK确认包号是相同的。
[Continuation to #X]
问题现象：抓包时出现[Continuation to #X]提示，具体示例如下所示。
No. Time Source Destination Protocol Info
38 5.011522 Client Server SMB Read AndX Request, FID: 0x00a4, 14215 bytes at offset D
39 5.014424 Server Client SMB Read AndX Response, FID: 0x004a, 14215 bytes
40 5.014019 Server Client TCP 445-2212 [ACK] Seq=1331 Ack=1913 Win=65535 Len=1448
41 5.014024 Server Client TCP [Continuation to #39] 445-2212 [ACK] Len=1448
42 5.014028 Server Client TCP [Continuation to #39] 445-2212 [ACK] Len=1448
43 5.014028 Server Client TCP [Continuation to #97] 445-2212 [ACK]
44 5.014032 Server Client TCP [Continuation to #97] 445-2212 [ACK]
45 5.014047 Server Client TCP [Continuation to #97] 445-2212 [ACK]可能原因：此提示表示关闭了"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)提示，具体示例如下所示。
No. Time Source Destination Protocol Info
... ... Beijing Shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded)
... ... Beijing Shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded)
...可能原因：此提示说明超出TTL生存时间，即超出碎片重组时间。表示这个包的发送方之前收到了一些分片，但是由于某些原因迟迟无法组装起来。由于上海发往北京的一些包被分片传输，且有一部分在链路上丢失，因此北京无法组装起来，只能使用这个ICMP报错告知对方。
处理方案：如果该问题长时间存在，您可以通过检查路由表、使用MTR工具排查网络环路、调整 TTL 初始值、调整 MTU、优化网络带宽等方式解决该问题。
相关文档
关于Wireshark的更多内容，请参阅Wireshark官方文档。
关于如何使用抓包工具进行抓包，请参见使用抓包工具进行网络数据包抓取。
关于能ping通实例但是端口不通的问题处理方法，请参见能ping通ECS实例但端口不通的排查方法。
关于使用MTR工具进行网络链路分析的相关操作，请参见使用MTR工具进行网络链路分析。