How to Diagnose and Reduce Linux Network Latency with Ping, Traceroute, and Wireshark
This article explains how to identify the causes of increased network latency on Linux servers using tools such as ping, traceroute, hping3, wrk, tcpdump and Wireshark, demonstrates a practical case with two Nginx containers, analyzes TCP delayed ACK behavior, and provides actionable steps to measure, trace, and mitigate latency.
Linux Network Latency
Network latency (RTT) is the round‑trip time for a packet to travel from source to destination and back. Application latency adds the time the application spends processing the request, so total latency = network latency + processing time.
Common tools for measuring latency include ping (ICMP‑based RTT), traceroute (TCP/UDP mode), hping3, and wrk for concurrent load testing.
Example Commands
# -c: 3 requests
# -S: Set TCP SYN
# -p: Set port to 80
$ hping3 -c 3 -S -p 80 google.com
HPING google.com (eth0 142.250.64.110): S set, 40 headers + 0 data bytes
len=46 ip=142.250.64.110 ttl=51 id=47908 sport=80 flags=SA seq=0 win=8192 rtt=9.3 ms
len=46 ip=142.250.64.110 ttl=51 id=6788 sport=80 flags=SA seq=1 win=8192 rtt=10.9 ms
len=46 ip=142.250.64.110 ttl=51 id=37699 sport=80 flags=SA seq=2 win=8192 rtt=11.9 ms
--- baidu.com hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 9.3/10.9/11.9 msTraceroute in TCP mode:
$ traceroute --tcp -p 80 -n google.com
traceroute to google.com (142.250.190.110), 30 hops max, 60 byte packets
1 * * *
2 240.1.236.34 0.198 ms * *
3 * * 243.254.11.5 0.189 ms
4 * 240.1.236.17 0.216 ms 240.1.236.24 0.175 ms
5 241.0.12.76 0.181 ms 108.166.244.15 0.234 ms 241.0.12.76 0.219 ms
...
24 142.250.190.110 17.465 ms 108.170.244.1 18.532 ms 142.251.60.207 18.595 msCase Study: Two Nginx Containers
We run two containers on host1 :
Official Nginx (port 80)
Latency‑modified Nginx (port 8080)
# Official nginx
$ docker run --network=host --name=good -itd nginx
# Latency version of nginx
$ docker run --name nginx --network=host -itd feisky/nginx:latencyVerify both containers serve traffic:
$ curl http://127.0.0.1
<!DOCTYPE html>
<html> ... <p><em>Thank you for using nginx.</em></p> ...
$ curl http://127.0.0.1:8080
<!DOCTYPE html>
<html> ... <p><em>Thank you for using nginx.</em></p> ...From host2 we test latency with hping3:
# Port 80
$ hping3 -c 3 -S -p 80 192.168.0.30
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=29200 rtt=7.8 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=29200 rtt=7.7 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=29200 rtt=7.6 ms
--- 192.168.0.30 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.6/7.7/7.8 ms
# Port 8080
$ hping3 -c 3 -S -p 8080 192.168.0.30
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=0 win=29200 rtt=7.7 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=1 win=29200 rtt=7.6 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=2 win=29200 rtt=7.3 ms
--- 192.168.0.30 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.3/7.6/7.7 msConcurrent load testing with wrk shows a clear difference:
# Port 80
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30/
Latency 9.19ms (avg), 12.32ms (stdev), 319.61ms (max)
Requests/sec: 12340.91
# Port 8080
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
Latency 43.60ms (avg), 6.41ms (stdev), 56.58ms (max)
Requests/sec: 2283.31The latency‑modified Nginx exhibits roughly four times higher average latency under load.
Analyzing the Cause
We capture packets on host1:
$ tcpdump -nn tcp port 8080 -w nginx.pcapAfter the test, we open the pcap in Wireshark. Filtering by a TCP stream (e.g., tcp.stream eq 24) and viewing the Flow Graph reveals that the second HTTP request experiences a 40 ms delay before the ACK is sent.
This 40 ms pause corresponds to the TCP delayed ACK timeout, a mechanism that waits briefly to combine ACKs with outgoing data.
Our client (the wrk tool) does not enable TCP_QUICKACK, so the default delayed ACK behavior applies.
TCP_QUICKACK (since Linux 2.4.4)
Enable quickack mode if set; otherwise delayed ACK is used.
In quickack mode, ACKs are sent immediately.Confirming with strace shows that wrk sets TCP_NODELAY but not TCP_QUICKACK:
$ strace -f wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
... setsockopt(52, SOL_TCP, TCP_NODELAY, [1], 4) = 0 ...Conclusion
Use hping3 and wrk to verify single‑request and concurrent latency.
Use traceroute to check routing and per‑hop delays.
Use tcpdump and Wireshark to inspect packet flows.
Use strace to observe socket options used by applications.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.