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