Why there is a big difference in the time elapsed between the SYN and SYN-ACK and then a much lesser difference between the time elapsed from SYN-ACK and the last ACK during the TCP 3-way Handshake?


That's because you're capturing on the part of the initiator. The device that issues the first and third packets. Because of this, the time delta between the 2nd and 3rd packets should be sub-milisecond. The time between the 1st and 2nd packet will be determined by network latency.

A better thing to compare would the the 1/2 and 3/4 time deltas. They would be measuring the same thing.

  • +1, if only I'd had his comment when posting my initial answer, I'd have led with that. – Jed Daniels Jan 2 '12 at 20:13

There are many reasons this might be the case. How large of a difference are you measuring? What devices are you measuring to and from? One reason might be that the first packets are triggering the establishment of VPN tunnels in the network. Another reason might be that the receiving application takes longer to process the initial SYN than subsequent packets.

And while the above are reasons that things might be the case, based on the answer in your comment, @sysadmin1138's answer is correct in this case: you are capturing on the initiator, which is tilting the measurement in that direction. If you were to capture on the receiver, you'd see different results: mainly the time between the SYN-ACK and ACK would be the long one.

  • I'm just checking when I access a normal website and capture the 3 way handshake packets with Wireshark, for example The SYN packet was sent from my NIC on 0.00, the SYN-ACK was then received on 0.123 and then the ACK packet was sent at almost the same timings at 0.123 – StefanGrech Jan 2 '12 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.