I use the Wireshark captured the packages:

enter image description here

in there you see the number 1594-1596, the three-way hankshake only use 0.0002s(0.2ms) it complete it.

but when I in the server( ping the client IP(, there get 200ms+.

Why the three-way handshake use so short time accomplish it?

  • 2
    ICMP replies are a fairly low priority process, so I would expect them to take longer than connections.
    – Ron Trunk
    Commented Sep 6, 2019 at 11:50
  • -^ is likely the correct answer and should be posted as such even if it is assumption based (i.e. without a LOT more detail, there is likely no better answer).
    – YLearn
    Commented Sep 6, 2019 at 19:32
  • I checked it, the and are not in one area, they are far with each other, there should take a long time to communicative with each other. Commented Sep 18, 2019 at 3:58
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin
    Commented Dec 15, 2019 at 18:46

2 Answers 2


The device you are pinging with ICMP could be a different device from the one replying to your SYN packets. There are typically two scenarios when that happens in a corporate network:

  1. You have a transparent HTTP proxy / IPS device that replies to your TCP 80 packets but passes through the ICMP packets.
  2. You have a WAN accelerator that replies to your SYN packets but passes through the ICMP packets.

Both behaviours can be confirmed by looking at the TTL values of the returning packets. Typically the ICMP packets returned from the actual device have TTL much lower than the replies you are getting from proxy/IPS/WAN accelerator.

  • and are not in one area, they are far with each other, so I don't understand why the TCP three-way shake take so short time. Commented Sep 18, 2019 at 6:43
  • Please add a "Time to live" column to Wireshark view and post the same screenshot you did in the original question, but with TTL visible. Commented Sep 18, 2019 at 8:07

It is due to the location of the packet capture.

hostA --------C- hostB

If you capture at point C the initial Syn from hostA will be seen after the majority of time has already passed and the Syn/Ack will be seen right away. You do see the increase on the Ack which would be expected.

  • This still doesn't explain the (round trip) difference between the SYN/ACK -> ACK time of 0.2ms shown by the capture versus the reported (round trip) time for the ICMP Echo -> Echo Reply of 200ms.
    – YLearn
    Commented Sep 6, 2019 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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