1. tcp out-of-order（tcp有問題）

解答：

1）、 應該有很多原因。但是多半是網絡擁塞，導致順序包抵達時間不同，延時太長，或者包丟失，需要重新組合數據單元 因為他們可能是通過不同的路徑到達你電腦上面的。

2）、 CRM IT 同仁上禮拜來跟我反應一個問題，由他們客服系統藉由郵件主機要寄送給客戶的信件，常常會有寄送失敗的問題，查看了一下 Log，發現正常的信件在主機接收 DATA 完成后會記錄收到的郵件大小，然后開始進行后續寄送出去的處理，但這些有問題的寄送，都會發生 DATA 沒有傳送完，Server 就記錄已讀取到 EOF，然后結束連線，也因此這封信就不算順利的送到 Server 上來。

初步看了一下排除是 Timeout 問題，因為連線斷的時間都還未達設定的連線 Timeout 時間，由于 CRM 系統是外面廠商寫的，為了厘清問題我只好抓封包來看是不是用戶端送出來結束傳送的指令的。

抓了一下結果如下：

?

整封郵件的傳送過程，包含了大量的 TCP Retransmission 或是 Segment Lost，到后來還有跑出 TCP Out-Of-Order，看起來是網路的問題，網路上對于 TCP Out-Of-Order 的建議是說，有些 Packet 可能 Lost，所以重新傳送造成，另一個可能是因為 Client 到 Server 間有兩條網路路徑，像是 Load Balance 之類的架構，因此若兩個封包走不同路徑，晚送的封包卻比早送的到達，就會發生 Out-Of-Order。

因此在斷定有可能是網路造成，加上 CRM 系統上的網卡同事是把兩張做成一張 Virtual，再請他拿掉 Bonding 只用單一張跑以后，問題就不存在了，觀察流量還跑的比原本兩張合起來的 Virtual 單張跑的高，所以 M$ 在 Bonding 網卡上是不是還有什么需要調整的就不得而之了，至少找出造成大量寄送失敗的原因就好。

2. tcp segment of a reassembled PDU

解答：1）在連個連接建立的時候，SYN包里面會把彼此TCP最大的報文段長度，在局域網內一般都是1460.如果發送的包比最大的報文段長度長的話就要分片了，被分片出來的包，就會被標記了“TCP segment of a reassembled PDU”，可以參考下圖，看一下，被標記了的包的SEQ和ACK都和原來的包一致：

?

2）上周在公司里遇到一個問題，用wireshark抓系統給網管上報的數據發現里面有好多報文被標識為“TCP segment of a reassembled PDU”，并且每一段報文都是180Byte，當時看到這樣的標識，覺得是IP報文分片，以為系統的接口MTU值為設置小了，通過命令查詢發現是1500，沒有被重設過，當時有點想不通。

回來查了一下，發現自己的理解是錯的，“TCP segment of a reassembled PDU”指的不是IP層的分片，IP分片在wireshark里用“Fragmented IP protocol”來標識。詳細查了一下，發現“TCP segment of a reassembled PDU”指TCP層收到上層大塊報文后分解成段后發出去。于是有個疑問，TCP層完全可以把大段報文丟給IP層，讓IP層完成分段，為什么要在TCP層分呢？其實這個是由TCP的MSS(Maximum Segment Size，最大報文段長度)決定的，TCP在發起連接的第一個報文的TCP頭里通過MSS這個可選項告知對方本端能夠接收的最大報文（當然，這個大小是TCP凈荷的大小），以太網上這個值一般設置成1460，因為1460Byte凈荷+20Byte TCP頭+20Byte IP頭＝ 1500字節，正好符合鏈路層最大報文的要求。

至于收到一個報文后如何確定它是一個”TCP segment”？如果有幾個報文的ACK序號都一樣，并且這些報文的Sequence Number都不一樣，并且后一個Sequence Number為前一個Sequence Number加上前一個報文大小再加上1的話，肯定是TCP segment了，對于沒有ACK標志時，則無法判斷。

既然收到的TCP報文都是180Byte的segment，那么應該是協商的時候PC端告知了MSS為180Byte，至于為什么這樣，只能等抓包后確認是MSS的問題再排查了。另外，有一種情況也可能導致這個問題：被測系統因為MTU為220Byte而設置MSS為180Byte，但是這種情況現在可以排除，因為前面講過，已經查詢過MTU值為1500。

3. Tcp previous segment lost（tcp先前的分片丟失）

解答：

（1）、“TCP Previous segment lost” errors are not “fatal” errors. They simply indicate that the sequence number in the arriving packet is higher than the next-expected sequence number, indicating that at least one segment was dropped/lost. The receiving station remedies this situation by sending duplicate ACKs for each additional packet it receives until the sender retransmits the missing packet(s). TCP is designed to recover from this situation, which is why the image is downloaded correctly despite having a (briefly) missing packet.

If you are getting a large number of lost packets, then there is likely a communication problem between the sender and receiver. A common cause of this is un-matched duplex settings between the PC and the switch.

We (our lab) recently upgraded to Ethereal 0.10.14 with WinPCap 3.1. If I remember correctly, we had previously been using 0.10.2 with WinPCap 3.0. However, since the upgrade we have been noticing several issues.

The first issue is with “TCP Previous segment lost” and “TCP CHECKSUM INCORRECT” messages appearing in the Packet Listing window. We do not remember seeing these in the previous version of Ethereal, or at least not nearly as many as we are seeing now. For example, one task for the student instructional part of the lab involves visiting a website containing two images and observing the network activity. After the two GET requests are sent for the images, it is not uncommon for one image to be returned with a typical 200 OK response packet, but the response packet for the other image will be displayed as “TCP Previous segment lost.” However, both images are downloaded and displayed perfectly fine in the browser. I would think that the segment lost error would mean the object wasn’t returned correctly and shouldn’t be able to be displayed, but apparently that is not the case. (The cache had been cleared when this was performed, so it was not defaulting to a local copy of the image.)

Another problem we’ve been noticing is that some packets simply aren’t displayed in the Packet Listing window, even when they are obviously received. Using the same example as above, after the two GET requests are sent for the images, it is not uncommon for one image to be returned with a typical 200 OK response, but the other response will not appear. Yet both images are successfully displayed in the browser. Is this a problem with Ethereal not detecting the packets?

I’m not sure how typical this is, but we seem to be experiencing these issues often with 0.10.14 while we never did with 0.10.2. Could it also be an issue with WinPCap, and not necessarily Ethereal? I’m just trying to find some answers as to why we are seeing a sudden abundance of TCP related errors and uncaptured packets. Thanks.

（2）、I have a network client application that runs fine while I am debugging (no TCP errors),

but when I run the release version, it runs incredibly slow. It runs as a series of

transactions, where each transaction is a separate connection to the server. Wireshark

analysis has determined that about 50% of all transactions involve the series:

TCP Previous Segment Lost

TCP Dup ACK

RST

The RST consumes 3 seconds per transaction, which is a Big Deal. So to prevent it, I must

prevent the initial “TCP Previous Segment Lost” (which seems, on the surface, to merely be

a time-out on a particular segment).

In the following clip, the SYN packet suffers from the “TCP Previous Segment Lost” condition.

0.000640 seconds seems like too short of a time to declare this condition, as many previous

successful transactions took much longer to be successfully SYN-ACK’ed.

Can somebody explain “TCP Previous Segment Lost” in this context to help me troubleshoot my

problem?

Any help would be appreciated.

Here is a clip of a problem transaction:

fffgs

4. Tcpacked lost segment（tcp應答丟失）

5. Tcp window update（tcp窗口更新）

6. Tcp dup ack（tcp重復應答）

TCP may generate an immediate acknowledgment (a duplicate ACK) when an out- of-order segment is received. This duplicate ACK should not be delayed. The purpose of this duplicate ACK is to let the other end know that a segment was received out of order, and to tell it what sequence number is expected.

當收到一個出問題的分片，Tcp立即產生一個應答。這個相同的ack不會延遲。這個相同應答的意圖是讓對端知道一個分片被收到的時候出現問題，并且告訴它希望得到的序列號。

Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. TCP then performs a retransmission of what appears to be the missing segment, without waiting for a retransmission timer to expire.

7. Tcp keep alive（tcp保持活動）

在TCP中有一個Keep-alive的機制可以檢測死連接，原理很簡單，TCP會在空閑了一定時間后發送數據給對方：

1.如果主機可達，對方就會響應ACK應答，就認為是存活的。

2.如果可達，但應用程序退出，對方就發RST應答，發送TCP撤消連接。

3.如果可達，但應用程序崩潰，對方就發FIN消息。

4.如果對方主機不響應ack, rst，繼續發送直到超時，就撤消連接。這個時間就是默認

的二個小時。

uses WinSock2;

procedure TForm1.IdTCPServer1Connect(AThread: TIdPeerThread);

type

TCP_KeepAlive = record

OnOff: Cardinal;

KeepAliveTime: Cardinal;

KeepAliveInterval: Cardinal

end;

var

Val: TCP_KeepAlive;

Ret: DWord;

begin

Val.OnOff:=1;

Val.KeepAliveTime:=6000; //6s

Val.KeepAliveInterval:=6000; //6s

WSAIoctl(AThread.Connection.Socket.Binding.Handle, IOC_IN or IOC_VENDOR or 4,

@Val, SizeOf(Val), nil, 0, @Ret, nil, nil)

end;

——————————————————–

KeepAliveTime值控制 TCP/IP 嘗試驗證空閑連接是否完好的頻率。如果這段時間內沒有活動，則會發送保持活動信號。如果網絡工作正常，而且接收方是活動的，它就會響應。如果需要對丟失接收方敏感，換句話說，需要更快地發現丟失了接收方，請考慮減小這個值。如果長期不活動的空閑連接出現次數較多，而丟失接收方的情況出現較少，您可能會要提高該值以減少開銷。缺省情況下，如果空閑連接 7200000 毫秒（2 小時）內沒有活動，Windows 就發送保持活動的消息。通常，1800000 毫秒是首選值，從而一半的已關閉連接會在 30 分鐘內被檢測到。

KeepAliveInterval值定義了如果未從接收方收到保持活動消息的響應，TCP/IP 重復發送保持活動信號的頻率。當連續發送保持活動信號、但未收到響應的次數超出TcpMaxDataRetransmissions的值時，會放棄該連接。如果期望較長的響應時間，您可能需要提高該值以減少開銷。如果需要減少花在驗證接收方是否已丟失上的時間，請考慮減小該值或TcpMaxDataRetransmissions值。缺省情況下，在未收到響應而重新發送保持活動的消息之前，Windows 會等待 1000 毫秒（1 秒）。

KeepAliveTime根據你的需要設置就行，比如10分鐘，注意要轉換成MS。

XXX代表這個間隔值得大小

8. Tcp retransmission（tcp重傳）

作為一個可靠的傳輸協議，傳輸控制協議（TCP）在發送主機需要從目標主機收到一個包時確認。If the sender does not receive that acknowledgment within a certain amount of time, it acts under the assumption that the packet did not reach its destination and retransmits the packet.如果發件人沒有收到的時間內一定之金額，確認，它的行為假設下，該數據包沒有到達其目的地，以及轉發數據包。

?

原文鏈接：http://www.xianren.org/net/wireshark-q.html

轉載于:https://www.cnblogs.com/amwuau/p/8317270.html

總結

以上是生活随笔為你收集整理的Wireshark抓包常见问题解析（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。