How to Diagnose and Reduce Linux Network Latency with hping3, traceroute, and Wireshark

In Linux servers, kernel tuning, DPDK, and XDP can improve resistance to attacks, while application‑level caches, WAF, and CDN help mitigate DDoS impact. However, once DDoS traffic reaches the server, network latency typically spikes.

Beyond DDoS, latency may stem from slow network transmission, slow kernel packet processing, or slow application data handling.

Linux Network Latency

Network latency (RTT) measures the round‑trip time of packets. Application latency adds the time the application spends processing the request. The ping command measures RTT via ICMP, but many services disable ICMP, so traceroute or hping3 (TCP/UDP mode) are used instead.

# -c: 3 requests
# -S: Set TCP SYN
# -p: Set port to 80
$ hping3 -c 3 -S -p 80 google.com

$ traceroute --tcp -p 80 -n google.com

Case Demonstration

Two hosts are prepared:

host1 (192.168.0.30): runs two Nginx containers (standard and latency‑modified).

host2 (192.168.0.2): analysis host.

host1 preparation

Run the containers:

# Official nginx
$ docker run --network=host --name=good -itd nginx
# Latency version of nginx
$ docker run --name nginx --network=host -itd feisky/nginx:latency

Verify they serve traffic:

$ curl http://127.0.0.1
$ curl http://127.0.0.1:8080

host2 testing

Measure single‑request latency with hping3:

$ hping3 -c 3 -S -p 80 192.168.0.30
$ hping3 -c 3 -S -p 8080 192.168.0.30

Run concurrent load tests with wrk:

$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30/
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/

The standard Nginx (port 80) shows ~9 ms average latency, while the latency‑modified Nginx (port 8080) averages ~44 ms.

Capture packets on host1 with tcpdump and analyze them in Wireshark: $ tcpdump -nn tcp port 8080 -w nginx.pcap Wireshark filtering (e.g., tcp.stream eq 24) and the Flow Graph reveal that the second HTTP request experiences a ~40 ms delay due to TCP delayed ACK.

Delayed ACK is a TCP optimization that waits up to ~40 ms before sending an ACK, hoping to piggyback data. The client (wrk) does not enable TCP_QUICKACK, so the delayed ACK occurs.

Confirm with strace 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

The article demonstrates a systematic approach to analyzing increased network latency using hping3, traceroute, wrk, tcpdump, and Wireshark, highlighting how kernel, network, and application factors—and TCP delayed ACK—affect perceived performance.