TCP Window Size (Flow Control)
What it is (Definition)
The TCP window is a flow-control signal sent by the receiver to the sender. It tells the sender how many bytes the receiver is currently willing to accept without additional acknowledgment. This is not congestion control (which is sender-side and network-driven). The TCP window is receiver-driven and protects the receiver’s buffers.
In captures, the window is one of the best fields for diagnosing “the network is fine but throughput is bad.” A slow application that is not reading data can shrink the window. When the receiver cannot accept more data, it may advertise a Zero Window, temporarily stalling the sender.
Where it appears in the stack
The window is a TCP (Layer 4) field, present in every TCP segment. Modern TCP commonly negotiates a Window Scale option during handshake, which expands the effective window beyond the 16-bit field. This means the “window value” you see may need scaling to reflect the true advertised capacity.
How flow control works
- Receiver tracks how much buffer space is available.
- Receiver advertises a window value in ACKs (and other segments).
- Sender limits in-flight unacknowledged data to the advertised window.
- If receiver becomes busy, it advertises a smaller window, slowing the sender.
- If the window reaches 0, sender pauses and probes until a Window Update appears.
Importantly, window behavior is affected by the receiver’s application and system load. A server under memory pressure or an endpoint with a slow consumer can shrink the window even if the network path is perfect.
Common values and signals (Value table)
| Window signal | Meaning | What you observe | Notes |
|---|---|---|---|
| Large window | Receiver can accept more data | Good throughput potential | May be scaled (Window Scale negotiated) |
| Small window | Receiver is limiting sender | Throughput capped even without loss | Often correlates with app or host bottlenecks |
| Zero Window | Receiver buffer full | Sender pauses; “ZeroWindow” expert info | Not congestion; it is receiver-side backpressure |
| Window Update | Receiver reopened buffer | Flow resumes after stall | Look for timing between zero window and update |
| Window Scale option | Expands window range | Negotiated during SYN/SYN-ACK | Without scaling, high-BDP paths are limited |
How it looks in Wireshark
Display filter example:
tcp.window_size_value == 0What you typically see:
- Advertised window values in TCP header details (and “calculated window size” in Wireshark).
- Zero Window and Window Update events in Expert Info.
- Window scaling negotiated during handshake (SYN options).
Quick read tip: When a transfer stalls, check whether the receiver is advertising zero window. If yes, focus on the receiver host/app behavior, not packet loss.
Common troubleshooting patterns
Zero Window stalls during downloads or API responses
If the receiver frequently advertises zero window, it is effectively telling the sender “stop, I’m full.” Common causes include slow application reads, CPU pressure, or constrained buffers. In captures, you’ll see the sender stop sending payload data and start window probes, waiting for a Window Update.
Low throughput on a high-latency path
High bandwidth-delay product paths require large windows. If window scaling is absent or limited, throughput can appear “mysteriously capped” even without loss. Confirm whether Window Scale was negotiated and whether the effective window is sufficient.
Related pages (internal links)
- Back to Fields Index
- Dictionary: TCP overview
- Topics Index (TCP zero window troubleshooting — Soon)
- Dictionary Index