2

I'm just checking the network latency with different tools e.g. with hping3: 

sudo hping3 -A -n -p 80 www.google.ro
HPING www.google.ro (ppp0 172.217.20.3): A set, 40 headers + 0 data bytes
len=40 ip=172.217.20.3 ttl=59 id=14578 sport=80 flags=R seq=0 win=0 rtt=23.7 ms
len=40 ip=172.217.20.3 ttl=59 id=60364 sport=80 flags=R seq=1 win=0 rtt=23.2 ms
len=40 ip=172.217.20.3 ttl=59 id=28510 sport=80 flags=R seq=2 win=0 rtt=22.8 ms
len=40 ip=172.217.20.3 ttl=59 id=38493 sport=80 flags=R seq=3 win=0 rtt=22.4 ms
len=40 ip=172.217.20.3 ttl=122 id=35817 sport=80 flags=R seq=4 win=0 rtt=25.7 ms
len=40 ip=172.217.20.3 ttl=122 id=8842 sport=80 flags=R seq=5 win=0 rtt=20.5 ms
^C
--- www.google.ro hping statistic ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 20.5/23.1/25.7 ms

and with ping: 

ping www.google.ro
PING www.google.ro (172.217.20.3) 56(84) bytes of data.
64 bytes from bud02s28-in-f3.1e100.net (172.217.20.3): icmp_seq=1 ttl=56 time=16.3 ms
64 bytes from bud02s28-in-f3.1e100.net (172.217.20.3): icmp_seq=2 ttl=56 time=17.1 ms
64 bytes from bud02s28-in-f3.1e100.net (172.217.20.3): icmp_seq=3 ttl=56 time=16.9 ms
64 bytes from bud02s28-in-f3.1e100.net (172.217.20.3): icmp_seq=4 ttl=56 time=16.5 ms
64 bytes from bud02s28-in-f3.1e100.net (172.217.20.3): icmp_seq=5 ttl=56 time=16.3 ms
64 bytes from bud02s28-in-f3.1e100.net (172.217.20.3): icmp_seq=6 ttl=56 time=16.3 ms
^C
--- www.google.ro ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 16.365/16.613/17.105/0.341 ms

After a few series with these 2 commands I noticed that hping3 is always reporting a higher latency than ping. Why this happens and how could one fix it?

PS: using Ubuntu 16.04.5 LTS (directly connected to Internet) and UFW (ver. 0.35)

Adrian
  • 701
  • 1
  • 8
  • 29

1 Answers1

4

You're not seeing the same test run with different tools. hping3 is running a "ping" using the TCP protocol on port 80; ping is running an ICMP echo request which is a different test entirely.

ICMP is IP protocol 1 (see RFC792); TCP is IP protocol 6 (described in RFC793). TCP (as does UDP) has ports, ICMP has no ports, but rather types and codes.

In general, an ICMP echo request is going to be a "lighter lift" because it's a "lighter weight" protocol (e. g. addressing not needing to specify source or endpoint ports) which means that, all things being equal, it is more likely than not to have a shorter response time due to fewer processing requirements than a comparable TCP packet.

The size of the packet header alone for an ICMP packet is 52 bytes (24, 20, and 8 bytes each for Ethernet, IP, and ICMP respectively), while the size of the packet header alone for a TCP packet is 64 btyes (24, 20, and 20 bytes each for Ethernet, IP, and TCP respectively).

Community
  • 1
DopeGhoti
  • 76,081
  • So should I conclude that using ICMP is natural to have quicker responses? – Adrian Jan 08 '19 at 20:54
  • In this specific case, apparently yes. Other hosts' or networks' administrators may set the QoL on ICMP traffic to a lower priority than TCP, or disable it entirely. – DopeGhoti Jan 08 '19 at 21:42
  • Well, thank you for explaining why the result is different but in order for me to accept the answer you should also add the explanation about why it happens to report a higher latency. The question has this flavour / intent too. – Adrian Jan 08 '19 at 21:47
  • Thank you for explaining why higher but I don't agree that those slightly more bytes make the difference. Both values in bytes are really low, e.g. for TCP all bytes easily fit into a TCP Window so I see no delay because of that. – Adrian Jan 17 '19 at 09:45
  • 1
    It's not just that there are more data; the data in the packet headers are more fields which need to be processed which means more computation which means that, all things being equal, it will take more time to handle a larger, more complex packet than it will to handle a shorter, less complex one. – DopeGhoti Jan 17 '19 at 15:17