Why TCP Window Full Slows Your File Transfers – A Deep Wireshark Walkthrough

Understanding TCP Window Full

A customer needed to copy files from a Beijing data center to Shanghai and observed slow transfer speeds; Wireshark showed many "TCP Window Full" warnings, prompting an analysis of the capture file.

The Expert Information view revealed 69 warning‑level packets indicating that the receiver's TCP window was completely full. In TCP terminology, this refers to the receive window being filled when the amount of data in flight equals the window size.

By selecting packet 224 in Wireshark, the analysis shows that the warning originates from the receive window being full. The brackets around "TCP Window Full" indicate that Wireshark generated this interpretation, not a field in the TCP header.

To locate the actual receive window, one must find the latest packet from the server (source port 22) before the warning. Packet 222 contains the server's receive window value of 112000 bytes, matching the bytes‑in‑flight reported for packet 224.

A diagram illustrates the data flow: the client (A) sends data until its bytes‑in‑flight equals the server's (B) receive window; only after B acknowledges can A send more data.

Manual verification involves calculating the difference between the Next Sequence Number of the client’s data packet and the acknowledgment number from the server. For the example, 310854 − 198854 = 112000 bytes, confirming the bytes‑in‑flight.

The article also explains why Wireshark may not flag "Window Full" when the window is almost, but not completely, full (e.g., 99.9% utilization).

Impact on transfer speed: a full receive window becomes a bottleneck, limiting throughput. The article compares I/O Graph settings in Wireshark and shows how to adjust the interval for finer granularity.

Further analysis explores the relationship between receive, congestion, and send windows, and introduces the TCP Stream Graph's Window Scaling view to pinpoint where Bytes Out meets the Receive Window.

Finally, the piece revisits the core throughput formula. While "velocity = window / RTT" works when all in‑flight data is promptly acknowledged, a more accurate expression in cases with lingering data is "velocity = acked_data / RTT". Using this refined formula yields speeds consistent with observed I/O Graph values.