網路資料包抓取廣泛用於故障診斷、安全審計等情境。本文介紹使用 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工具進行網路鏈路分析。