 | 1 | initial version |
From the 3-way-handshake I see that there is a RTT of ~150ms for this TCP connection. I also see that you are capturing on the client (192.168.0.105) as the delta between the SYN and the SYN/ACK is high and the delta between the SYN/ACK and the ACK is low. Also the ACK has a length of 54 bytes, which is lower than the minimum length of an ethernet packet. This usually means you capture on the client itself and the packet was captured before the NIC could add the padding.
Then between frame 531 and frame 532 a segment got lost and therefor you see DUP-ACKs for all the segments that are coming in. As there is a RTT of 150ms, it takes a while for the DUP-ACKs to reach the server to trigger a fast retransmission. If you look at the delta time between frame 539 (the third DUP-ACK) and frame 560 (the fast retransmission), you can see that ~146 ms have passed. This is in line with the iRTT of ~150ms. All the extra DUP-ACKs are for all the packets that were already on their way from the server to the client before it has received the first 3 DUP-ACKs.
