TCP Nagle and Delayed ACK PCAP Analysis: Small Packet Latency, 40ms Stalls, and Slow Request/Response Apps

Some TCP applications feel slow even with no packet loss, low CPU, and healthy bandwidth. The cause can be the interaction between Nagle's algorithm and delayed ACK behavior. Users search for "TCP Nagle delayed ACK pcap", "40ms TCP delay", "small packet latency", "TCP_NODELAY packet capture", "slow request response TCP", and "why does TCP wait before sending small packets" when an interactive protocol stalls on tiny writes.

PCAP Surgery is useful because this problem is entirely timing-based. You need to preserve packet timestamps, payload sizes, ACK timing, direction, and application message boundaries.

What Nagle does

Nagle's algorithm reduces small packet overhead by holding back tiny writes when there is already unacknowledged data in flight. For bulk transfer, this can be efficient. For interactive request/response protocols that send many small messages, it can introduce visible latency.

The typical pattern:

1. Application sends a small segment.
2. Another small write is ready.
3. Sender waits for ACK before sending more.
4. Receiver delays ACK hoping to piggyback it.
5. Both sides wait briefly.

That delay can look like a mysterious application pause.

What delayed ACK does

Delayed ACK lets the receiver wait before acknowledging data, often to reduce ACK traffic or piggyback ACKs on response data. This is normally valid TCP behavior.

The problem appears when:

• Sender waits because of Nagle.
• Receiver waits because of delayed ACK.
• Application waits for the second small segment.
• No side sends enough data to break the wait immediately.

The packet capture shows a repeated gap, often around a small fixed delay.

Common symptoms

Searchers often describe:

• "TCP has no packet loss but app is slow."
• "Every request has 40ms delay."
• "Small writes are slow."
• "Disabling TCP_NODELAY fixed latency."
• "Database protocol slow over VPN."
• "Remote UI slow with many tiny packets."
• "RPC calls have weird gaps."
• "Latency only happens on Linux to Windows."

The root cause may be socket options, application write patterns, or receiver ACK policy.

Packet evidence

Look for:

• Small TCP payloads.
• One side sends less than MSS.
• Second application message is delayed.
• ACK arrives after a fixed timer-like gap.
• No retransmission occurs.
• Window is not full.
• RTT is lower than observed stall.
• Throughput is not the main bottleneck.

This differentiates Nagle/delayed ACK from loss, congestion, DNS delay, TLS negotiation, and server processing time.

Request/response protocols

Interactive protocols are especially sensitive:

• Database queries.
• RPC framing.
• Telnet-like protocols.
• Custom industrial control protocols.
• Remote desktop control channels.
• Financial trading gateways.
• Chatty HTTP client libraries.
• Line-oriented command protocols.

If an application sends headers, length fields, and body fragments as separate small writes, the packet trace may reveal avoidable latency.

TCP_NODELAY and application batching

Disabling Nagle with TCP_NODELAY can reduce latency for some interactive applications. But it is not always the best fix.

Options include:

• Enable TCP_NODELAY for latency-sensitive small messages.
• Batch small writes into one application write.
• Flush only complete protocol frames.
• Avoid write-write-read patterns with tiny segments.
• Tune delayed ACK behavior if the platform allows it.
• Keep Nagle enabled for bulk transfers.

The pcap should guide the decision.

False diagnoses

This issue is often misdiagnosed as:

• Packet loss.
• Slow server CPU.
• TLS overhead.
• Wi-Fi latency.
• VPN congestion.
• DNS delay.
• MTU problem.

Those may be real in other cases, but if the trace shows consistent small-packet gaps without retransmissions, TCP send/ACK interaction deserves attention.

Capture requirements

For a useful analysis, preserve:

• TCP handshake.
• First slow request.
• Payload sizes.
• Packet timestamps with high resolution.
• ACK-only packets.
• Direction of each segment.
• Application log timestamps if available.
• Socket option knowledge if available.

Do not trim away the small idle gaps. They are the evidence.

Debug checklist

Use this workflow:

1. Identify repeated latency gaps.
2. Measure gap duration.
3. Check whether payloads are small.
4. Check whether sender has unacknowledged data.
5. Check ACK timing.
6. Confirm no retransmission explains the gap.
7. Compare with RTT.
8. Test application write batching.
9. Test TCP_NODELAY if appropriate.
10. Preserve before/after pcaps.

Final diagnosis

TCP Nagle and delayed ACK problems are timing and small-write problems, not bandwidth problems. The important evidence is tiny segments, ACK delay, sender wait behavior, and repeated fixed latency gaps.

PCAP Surgery helps preserve and compare the packet timing needed to prove whether a slow request/response application is blocked by TCP small-packet behavior.