hping3 reports higher latency than ping
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)
ping
add a comment |
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)
ping
add a comment |
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)
ping
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)
ping
ping
asked Jan 8 at 17:39
adrhcadrhc
240110
240110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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).
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 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 8 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.
– adrhc
Jan 8 at 21:47
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493292%2fhping3-reports-higher-latency-than-ping%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 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 8 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.
– adrhc
Jan 8 at 21:47
add a comment |
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).
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 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 8 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.
– adrhc
Jan 8 at 21:47
add a comment |
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).
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).
edited Jan 8 at 21:59
answered Jan 8 at 17:49
DopeGhotiDopeGhoti
43.8k55382
43.8k55382
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 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 8 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.
– adrhc
Jan 8 at 21:47
add a comment |
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 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 8 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.
– adrhc
Jan 8 at 21:47
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 at 20:54
So should I conclude that using ICMP is natural to have quicker responses?
– adrhc
Jan 8 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 8 at 21:42
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 8 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.
– adrhc
Jan 8 at 21:47
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.
– adrhc
Jan 8 at 21:47
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493292%2fhping3-reports-higher-latency-than-ping%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown