2

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(103.215.9.27) ping the client IP(103.215.200.242), 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 Sep 6 '19 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 Sep 6 '19 at 19:32
  • I checked it, the 103.215.9.0/24 and 103.215.200.0/24 are not in one area, they are far with each other, there should take a long time to communicative with each other. – fanhualuojin154873 Sep 18 '19 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 Dec 15 '19 at 18:46
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.

| improve this answer | |
  • 103.215.9.0/24 and 103.215.200.0/24 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. – fanhualuojin154873 Sep 18 '19 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. – NetworkMeister Sep 18 '19 at 8:07
1

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.

| improve this answer | |
  • 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 Sep 6 '19 at 19:29

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.