What does a TCP zero window mean in a capture, and whose problem is it?
Show the answer
Say this first
Every ACK carries the receiver's window: how many more bytes it can buffer. A zero window means the
receiving application is not reading from its socket fast enough, its buffer is full, and the sender must
stop. The sender then sends window probes until the window opens again. It points at the receiving host
or application (CPU, disk, a stalled thread), not at the network. Filter with tcp.analysis.zero_window.
Go deeper
What it looks like
A client at 10.10.0.25 copies a file to a server at 10.30.0.15 over SMB:
No. Time Source Destination Protocol Info
2201 8.4410 10.30.0.15 10.10.0.25 TCP 445 > 50114 [ACK] Seq=1 Ack=5120001 Win=1460 Len=0
2202 8.4412 10.10.0.25 10.30.0.15 TCP [TCP Window Full] 50114 > 445 [ACK] Seq=5120001 Ack=1 Win=8192 Len=1460
2203 8.4790 10.30.0.15 10.10.0.25 TCP [TCP ZeroWindow] 445 > 50114 [ACK] Seq=1 Ack=5121461 Win=0 Len=0
2204 8.7795 10.10.0.25 10.30.0.15 TCP [TCP ZeroWindowProbe] 50114 > 445 [ACK] Seq=5121461 Ack=1 Win=8192 Len=1
2205 8.7797 10.30.0.15 10.10.0.25 TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 445 > 50114 [ACK] Seq=1 Ack=5121461 Win=0 Len=0
2206 9.3801 10.10.0.25 10.30.0.15 TCP [TCP ZeroWindowProbe] 50114 > 445 [ACK] Seq=5121461 Ack=1 Win=8192 Len=1
2207 9.3803 10.30.0.15 10.10.0.25 TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 445 > 50114 [ACK] Seq=1 Ack=5121461 Win=0 Len=0
2210 11.2050 10.30.0.15 10.10.0.25 TCP [TCP Window Update] 445 > 50114 [ACK] Seq=1 Ack=5121461 Win=262144 Len=0The server answers each probe in 0.2 ms, so the network is fast. For almost 3 seconds the server simply will not take more data. The probe byte is not accepted while the window is zero, so the ACK number stays at 5121461. That stall is on the server: its application or disk is not keeping up.
Window Full and Zero Window
[TCP Window Full] marks the sender's segment that fills the receiver's advertised window. [TCP ZeroWindow]
is the receiver advertising zero. Both point at the receiver as the bottleneck, while retransmissions point
at the path.
The window scaling trap
The window field is 16 bits, so 65,535 at most. Window scaling, agreed in the SYN and SYN-ACK, multiplies it. A capture that starts mid-connection cannot know the scale factor and shows windows that look tiny. Capture from the handshake. A middlebox that strips the scale option caps each flow at 64 KB per round trip.
They will ask next
The client advertises a zero window during a download. What does that suggest?
The client host cannot keep up: a slow disk, antivirus scanning every write, high CPU, or a small receive buffer. The network delivers faster than the host consumes.
Is a small non-zero window a problem too?
It can be. Throughput is capped at window divided by round-trip time, so on a long path even a healthy receiver with a small window makes transfers slow.
Traps
- Calling a zero window "network congestion". Congestion shows as loss and retransmissions, not as a full receive buffer.