TCP Zero Window PCAP Analysis: Finding Receiver Bottlenecks and Application Stalls

TCP Zero Window is one of the most misunderstood packet capture symptoms. A trace may show TCP ZeroWindow, stalled data transfer, retransmissions, and long gaps. Users search for "TCP zero window meaning", "TCP zero window Wireshark", "slow download pcap analysis", or "TCP window full vs zero window" because the network looks slow but the root cause may not be the network at all.

TCP Zero Window usually means the receiver has told the sender: "Stop sending. My receive buffer is full." That can happen because the receiving application is not reading data fast enough, the receiver is overloaded, the OS socket buffer is constrained, or a downstream process is blocked.

PCAP Surgery is useful because these cases require careful packet evidence. You need timing, sequence numbers, acknowledgments, window advertisements, retransmissions, and directionality. Without that, it is easy to blame bandwidth, packet loss, firewall, or server performance when the receiver is actually applying backpressure.

What TCP window means

TCP flow control lets the receiver advertise how much data it can accept. The advertised receive window tells the sender how many bytes it may send beyond the acknowledged data.

When the window is healthy, data keeps flowing. When the window shrinks, the sender must slow down. When the window reaches zero, the sender must stop sending new data until the receiver advertises more space.

In a capture, this often appears as:

Receiver -> Sender: ACK, Window size value: 0
Sender   -> Receiver: TCP Zero Window Probe
Receiver -> Sender: ACK, Window size value: 0
Receiver -> Sender: Window Update
Sender   -> Receiver: data resumes

The key point: zero window is a receiver-side signal. It is not the same as packet loss.

TCP Zero Window vs TCP Window Full

TCP Window Full usually means the sender has filled the receiver's advertised window. The sender has sent as much as it is allowed to send.

TCP Zero Window means the receiver advertised a window of zero. It is explicitly telling the sender that no more receive buffer space is available.

Both can appear in the same investigation, but they point to flow-control pressure rather than ordinary network congestion.

Common causes

Common TCP Zero Window causes include:

• Receiving application is too slow to read from the socket.
• Application thread is blocked on disk, database, lock, or CPU.
• TLS layer is blocked above TCP.
• Proxy or gateway buffers are full.
• Client is downloading but cannot write to disk fast enough.
• Server is sending to an embedded device with limited memory.
• Receiver socket buffer is too small for the workload.
• Middlebox or capture offload makes the trace look confusing.

In web systems, this may appear as slow upload, stalled download, delayed API response, or long time-to-first-byte after a connection is already established.

Direction matters

Always identify which side advertised zero window. If the client advertises zero window, the client or client-side receive path is the bottleneck. If the server advertises zero window, the server or server-side receive path is the bottleneck.

Do not diagnose from packet labels alone. A packet capture has two directions, and the meaning changes completely depending on who sent the zero window ACK.

For example:

• Client zero window during download: client cannot accept data fast enough.
• Server zero window during upload: server cannot accept request body fast enough.
• Proxy zero window: proxy buffering or upstream/downstream imbalance.

Zero window probes

When the receiver advertises zero window, the sender periodically sends small probes to check whether the window has opened. These are TCP Zero Window Probes.

Probes are not the cause of the problem. They are a recovery mechanism. If you see repeated probes and repeated zero-window ACKs, the receiver remained blocked.

The timing between probes can help show how long the stall lasted.

Window update

A Window Update indicates that the receiver has opened its receive window again. Data can resume.

The important questions are:

• How long did the zero window last?
• What packet caused the window to close?
• Did the receiver open the window gradually or suddenly?
• Did the sender resume immediately after the update?
• Did the zero window repeat in a pattern?

If zero window repeats every time a response reaches a certain size, the receiver may be processing data in bursts or writing to a slow sink.

Application stalls hidden as network problems

TCP Zero Window is often an application problem visible in a network trace. For example, a service reads from a socket and writes to disk. If disk I/O stalls, the application stops reading. The OS receive buffer fills. TCP advertises zero window. The sender stops.

From the user's perspective, the network is slow. From TCP's perspective, flow control is working correctly.

This is why packet capture evidence matters. It prevents a network team from chasing packet loss when the receiving process is blocked above TCP.

Capture placement matters

Where you capture changes what you can prove.

If you capture on the sender, you can see what the sender transmitted and what window advertisements it received. If you capture on the receiver, you can see whether packets arrived and whether the receiver advertised zero window. If you capture in the middle, you can inspect direction and timing but may miss host-specific offload details.

For the strongest diagnosis, capture as close as possible to the endpoint advertising zero window.

Offload and misleading checksums

TCP segmentation offload, large receive offload, and checksum offload can make captures look strange, especially when captured on the host itself. You may see large segments, odd checksums, or packet sizes that do not match wire behavior.

Do not let offload artifacts distract from the flow-control evidence. The advertised window, ACK direction, sequence numbers, and timing are still the core of the zero-window diagnosis.

Checklist for TCP Zero Window analysis

Use this process:

1. Identify the client, server, and any proxy.
2. Determine which side advertised zero window.
3. Mark the timestamp when the window first reached zero.
4. Find the last data packet before the zero window.
5. Measure how long the zero window lasted.
6. Look for zero window probes and responses.
7. Find the first window update.
8. Check whether data resumed immediately.
9. Look for repeated zero-window patterns.
10. Correlate with application logs, CPU, disk, memory, and downstream dependency latency.

What PCAP Surgery can help preserve

When sharing a trace, you may want to isolate the affected TCP conversation, trim unrelated traffic, preserve timing, and annotate the exact zero-window interval. PCAP Surgery is aimed at this kind of evidence handling: keep the packet facts intact while making the capture easier to inspect and share.

The goal is not to magically "fix" TCP. The goal is to preserve the packet story clearly enough that the responsible layer is obvious.

Final diagnosis

TCP Zero Window means the receiver is applying backpressure. It can be caused by application stalls, buffer limits, disk delays, proxy behavior, or resource exhaustion. The correct diagnosis starts by identifying which side advertised zero window and measuring how long the stall lasted.

PCAP Surgery supports this evidence-first workflow by helping turn a noisy capture into a focused trace that shows who stopped reading, when the window closed, and when the flow recovered.