TCP Zero Window Detect

What is TCP Zero Window?

In TCP, every ACK includes a Window Size field (the “receive window”).

This tells the sender: “I can accept up to X more bytes of data.”

If the receiver’s buffer is full (application isn’t reading fast enough), it advertises:

Window Size = 0

This is called a TCP Zero Window → basically:

“Stop sending, I can’t take more right now.”

What happens after a Zero Window?

Sender stops sending (flow control).

Sender periodically probes with a Zero Window Probe (ZWP):

A 1-byte packet sent to check if the receiver has opened space.

If receiver still has no room → responds with Window=0.

If space is available → responds with Window > 0, and data flow resumes.

Why does it happen?

Common causes:

Receiver-side application too slow: app is reading from socket buffer slower than sender is writing.

Small socket buffer on receiver (or not tuned for workload).

High-bandwidth, high-latency links (BDP mismatch: buffer < bandwidth × delay).

Resource bottleneck on receiver (CPU, disk I/O, etc.) → app can’t keep up.

How it looks in Wireshark

Packet marked [TCP ZeroWindow] (ACK with Win=0).

Later: [TCP ZeroWindowProbe] from sender.

Eventually: [TCP ZeroWindowProbeAck] with a new nonzero window.

Impact

Throughput drops dramatically (sender waits).

Can cause application stalls, poor performance, or session timeouts if window stays closed too long.

Quick Analogy

Imagine you’re pouring water (sender) into a glass (receiver buffer).

If the glass is full, the receiver says “Stop!” (Zero Window).

Every few seconds, you drip one drop (probe) to see if there’s space.

Only when the receiver empties some water (app reads from buffer) can you continue.

Summary:

Zero Window = receiver buffer full, sender must stop.

Sender waits for probe/ack cycle to resume.

Root cause usually: slow application reading or buffer sizing issue on receiver.