Wireshark TS | confusion between fast retransmission and out of sequence

The problem background

Network packet analysis has been done for a long time , Habitually, there will be a pile of trace files , If it is not sorted out in time , The next time I see some trace files, I won't remember what it is . Dark eyes

This case is like this , Trace filename client-fast-retrans.pcapng, At first glance, the name is a case of fast retransmission , I opened it when I was ready to store it again , It's ok if you don't look , At a glance, I also found a Wireshark TCP Analysis The problem of , So share the record .

Problem information

The basic information of the packet trace file is as follows ：

$ capinfos client-fast-retrans.pcapng
File name:           client-fast-retrans.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   27
File size:           17 kB
Data size:           17 kB
Capture duration:    0.311468 seconds
First packet time:   2015-06-02 22:11:59.655051
Last packet time:    2015-06-02 22:11:59.966519
Data byte rate:      54 kBps
Data bit rate:       436 kbps
Average packet size: 629.70 bytes
Average packet rate: 86 packets/s
SHA256:              6ee7b5061a54bc22b44fe5bdbd10d7f0fcc2fdb63dd45f9bbf3327eefb15a191
RIPEMD160:           cd8614df4aa3316508290308c4b875459b9a9419
SHA1:                42704ab0674942a2cfcd77404784c7409b67283c
Strict time order:   True
Capture application: Editcap 2.6.13
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 27

1. The document should be tcpdump Captured , After the windows through editcap Modified ;
2. Number of packets 27 individual , Average rate 436 kbps;
3. Judging from the packet capture time, it is in 2015-06-02 .（ Note that the trace file is collected from the Internet ）

Because the total number of trace file packets is 27 individual , The number of problems such as retransmissions or fast retransmissions revealed by expert information is only 1 individual .

Problem analysis

Actual packet analysis ,TCP The three handshakes are mainly as follows

The complete packet information is as follows

The trace file is a HTTP Interaction , stay TCP After three handshakes and normal connection establishment , The client did HTTP GET Requested a size of 100MB Of bin file , Server response HTTP 200 OK , Then transfer the file normally .

First of all, let's talk about a common topic , How to determine the capture point of the trace file ？

1. IRTT,IRTT by 0.103362s , from TCP Three handshakes SYN-SYN/ACK-ACK The time difference between , It is preliminarily determined that the capture point is at or near the client ;
2. Length , The first thing you can see is pure ACK The length of the packet , But because the client and server pass through TCP The result of three handshake negotiations is that they all support TCP OPT Time stamp , So pure ACK The packet length is not 54 byte , Cannot be based on less than 60 Bytes are captured on the client , Auxiliary judgment is invalid ;
3. TTL, Second, look at TTL , Client's TTL by 64 , Still a Linux System starting value , Because it is possible to capture on the layer 2 access switch to which the client is connected （TTL It's also 64）, So the auxiliary judgment is invalid .

Finally, the trace file can only be judged to be captured on the client or the layer-2 switching environment close to the client .

How to determine the capture point of the trace file , Interested students can check the previous complete article 《 Capture point TCP Three handshakes 》.

Back to the packet fast retransmission problem , The main information is as follows

At first glance, it seems to be no different from the ordinary fast retransmission phenomenon , Preliminary analysis process ：

1. Packets sent by the server No.20 I lost one before TCP piecewise Seq 9577 , therefore No.20 Marked as TCP Previous segment not captured ;
2. The client responds to the first No.21 DUP ACK Confirm that Seq 9577 piecewise （ primary ACK stay No.19）;
3. Server next packet No.22 Still not TCP piecewise Seq 9577;
4. So the client responds to the second No.23 DUP ACK Confirm to continue Seq 9577 piecewise ;
5. At this time, the server seems to be because DUP ACK The reason for this triggered a fast retransmission , Sent No.24 Seq 9577 Data packets , therefore Wireshark Marked here as TCP Fast Retransmisson .

So it feels like Wireshark It is judged that fast retransmission is indeed reasonable , But think carefully , You will find some problems ：

1. IRTT,IRTT by 0.103362s , Explain the client and server side RTT about 103ms, If the capture point is on the client ,No.24 and No.23 The time difference between them is only 71ns. Try sending from the client No.23 Go to the server and receive No.23 Then trigger a fast retransmission , Then go to the client , This 71ns The time is completely out of line with reality ;
2. DUP ACK,DUP ACK The quantity of is only 2 individual , according to RFC 2581 describe , It takes three to trigger a fast retransmission DUP ACK Of , The only trace file here is 2 individual DUP ACK, Does not meet the conditions .

What is it for? Wireshark It will be judged as fast retransmission , This, of course, is Wireshark TCP The logic of analysis ,TCP Fast Retransmission Part of the explanation is as follows （ Interested students can also view the source code directly ）. When the following conditions are fully met ,Wireshark Will be marked as fast retransmission , To replace disorder or retransmission .

TCP Fast Retransmission
Set when all of the following are true:

This is not a keepalive packet.
In the forward direction, the segment size is greater than zero or the SYN or FIN is set.
The next expected sequence number is greater than the current sequence number.
We have more than two duplicate ACKs in the reverse direction.
The current sequence number equals the next expected acknowledgement number.
We saw the last acknowledgement less than 20ms ago.

Supersedes “Out-Of-Order” and “Retransmission”.

From the above conditions , One is Wireshark The problem of time difference of context packets is not considered , So ignore RTT problem ; Two is Wireshark Considering that there may be DUP ACK In case of loss , So in >=2 individual DUP ACK It will be judged as a fast retransmission , But this is definitely not true TCP Fast retransmission implementation （ Must satisfy 3 individual DUP ACK）.

that No.24 Packets are not The fast retransmission Words , What is it ？ Certainly not a timeout retransmission , Then it can only be Disorder . Take the disordered logic and re sort out the interaction process , It's absolutely right .

1. Packets sent by the server TCP piecewise Seq 9577 Out of order , Not in the No.20 Arrive before ;
2. Packets sent by the server No.20 Because there is no TCP piecewise Seq 9577 , therefore No.20 Marked as TCP Previous segment not captured ;
3. The client responds to the first No.21 DUP ACK Be sure to Seq 9577 piecewise （ primary ACK stay No.19）;
4. Server next packet No.22 Still not TCP piecewise Seq 9577;
5. So the client responds to the second No.23 DUP ACK Confirm to continue Seq 9577 piecewise ;
6. At this time, the data packets sent by the server TCP piecewise Seq 9577 Late arrival after disorder , therefore Wireshark The correct judgment should be marked here TCP Out-Of-Order.

You can also use IP.ID To corroborate ,No.24 Of IP ID by 49749 , stay No.20 and No.22 Before , Therefore, disorder is undoubtedly .

Let's take a look at how kolai analyzer judges again , The accurate judgment is Disorder . Light of China ~

The problem summary

at present Wireshark The version used is Version 3.6.3 (v3.6.3-0-g6d348e4611e2) , I haven't delved into whether it is a BUG, Or can we offer an enhancement to Wireshark, More likely Wireshark I think so TCP Analysis and implementation logic has its own reason . Because there are so many kinds of phenomena in the packet world , Anything is possible .

---

Thank you for reading , More technical articles can be concerned about official account numbers. ：Echo Reply , thank you .