2026-06-03

TCP Nagle and Delayed ACK PCAP Analysis

How to analyze TCP Nagle algorithm and delayed ACK interactions in packet captures, small packet latency, request/response stalls, interactive protocol delays, and TCP_NODELAY evidence.

An interactive TCP protocol can pause for roughly 40 ms on tiny writes even with low RTT, no loss, and ample bandwidth. To test a Nagle/delayed-ACK interaction, measure each small segment, outstanding unacknowledged data, ACK timing, and the next application write; compare the pattern before assuming TCP_NODELAY is the cure. The trace can demonstrate wire-level delay and segment coalescing, but it cannot show precisely when the application called send() without host instrumentation.

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:

Application sends a small segment.
Another small write is ready.
Sender waits for ACK before sending more.
Receiver delays ACK hoping to piggyback it.
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:

Identify repeated latency gaps.
Measure gap duration.
Check whether payloads are small.
Check whether sender has unacknowledged data.
Check ACK timing.
Confirm no retransmission explains the gap.
Compare with RTT.
Test application write batching.
Test TCP_NODELAY if appropriate.
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.

Identify the repeated small-write cycle

Build a table for several consecutive application turns. Record each data segment’s direction, payload bytes, prior unacknowledged bytes, time to ACK, and time to the next data segment. A Nagle/delayed-ACK interaction should repeat under comparable message boundaries; one 40 ms gap can be scheduler delay, application work, proxy queueing, or packet loss.

Time	Direction	Payload	Outstanding before send	Next event	Gap
T0	client → server	12 B	0	server ACK	38 ms
T1	client → server	8 B	12 B	sent after ACK	39 ms

The table becomes persuasive when multiple cycles show a small write withheld while prior data remains unacknowledged, followed immediately by ACK and next send. Host instrumentation is still needed to know when the application actually issued the write.

Is every 40 ms pause caused by delayed ACK?

No. Delayed-ACK timers vary by OS and connection state, and 40 ms is only a familiar pattern. Compare the gap with ACK arrival, RTT, retransmission timers, application logs, and CPU scheduling. Name observed timing rather than diagnosing by number alone.

How does `TCP_NODELAY` change the test?

It disables Nagle-style coalescing for that socket, allowing small writes to be sent promptly. Run an authorized before/after test with identical request sequence and load. Confirm that segment timing changes and user latency improves without unacceptable packet-rate overhead.

Can write batching be better than `TCP_NODELAY`?

Often. If the protocol can combine related fields into one logical message, batching reduces both latency interactions and packet overhead. Test application buffering, flush behavior, and message framing. Do not change TCP options before understanding why many tiny writes exist.

What about `TCP_QUICKACK`?

It is platform-specific and often temporary. Relying on it as a permanent protocol fix can be fragile. Prefer correcting application write/read behavior or using documented socket policy with regression tests.

Separate competing explanations

Alternative	Packet clue	Next evidence
Packet loss	retransmission, duplicate ACK/SACK	sequence analysis
Receiver backpressure	shrinking or zero window	socket/read activity
Application processing	quiet wire after complete request	application spans/logs
Proxy buffering	different timing on two TCP legs	capture both sides
CPU scheduling	write call delayed before packet	host tracing

Encrypted application traffic can still reveal directional small records and timing, but record coalescing may not map one-to-one to application messages. State that limitation when TLS keys or host logs are unavailable.

Regression test and handoff

Record OS/runtime, socket options, request pattern, write sizes, RTT, ACK delays, packet count, latency distribution, and CPU/network overhead. Test fresh and reused connections, idle and loaded systems, and both directions if the protocol is interactive.

After a change, require disappearance of the repeated ACK-gated gap and improvement at the application boundary. A larger packet count with no latency gain is not a successful fix. Preserve representative before/after flows with the same message sequence.

Use TCP window scaling analysis when receive capacity limits flight, packet-loss analysis when recovery occurs, and capture scope help to retain the idle gaps that make this diagnosis possible.

Worked timing interpretation

Suppose the client sends 15 bytes, then application logs show another logical field is ready almost immediately. The capture shows no second segment until the server ACK arrives 38 ms later, and this pattern repeats across ten requests. There is no loss, the RTT is 2 ms, and the receive window is large. This supports an ACK-gated small-write interaction.

It still does not prove Nagle is enabled or that the second send() occurred before the ACK. Confirm with socket-option inspection, syscall tracing, runtime instrumentation, or a controlled TCP_NODELAY test. Packet evidence supplies the timing hypothesis; host evidence supplies the API-level cause.

Why might the receiver delay ACK?

TCP implementations reduce ACK traffic and may wait briefly for more data or data to piggyback in the reverse direction. Protocols that alternate tiny one-way fragments can interact badly with that policy. The receiver is not necessarily broken; the application message pattern may be unsuitable.

Can TLS change the visible pattern?

Yes. TLS libraries buffer and frame application writes, and one TLS record can span TCP segments or combine writes. Test at both application and wire boundaries. A change in record sizing can improve or worsen small-packet behavior independently of TCP_NODELAY.

What should a final diagnosis say?

Use bounded wording: “At the client capture point, each second small segment was transmitted within 1 ms after the ACK for the prior 15-byte segment; ACKs arrived 37–41 ms after the first segment across 10 cycles. No loss or receive-window limit was observed. Host tracing is required to confirm write timing and socket options.”

Production safety

Before enabling TCP_NODELAY broadly, measure packet rate, CPU, battery/radio effects for mobile clients, congestion behavior, and throughput. Apply it to the socket/protocol path that needs low latency, not as a blanket performance flag. Where possible, redesign writes so each logical message is framed and sent intentionally.

Keep a regression case that asserts both application latency and packet pattern. Future runtime or OS upgrades may change buffering and delayed-ACK behavior even when application code does not.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: