Why TCP Window Full Slows Your Transfer and How to Diagnose It with Wireshark

Case Background

A customer copying files from a Beijing data center to Shanghai observed low throughput. Wireshark captured many TCP Window Full warnings, prompting an investigation into whether these messages caused the slowdown.

Understanding the Expert Information

The capture contains 69 warning packets indicating that the receiver's TCP window is completely full. In TCP terminology, this refers to the receive window . When the amount of data “in flight” equals the receive window size, Wireshark flags the condition as TCP Window Full.

Inspecting a Sample Packet

By selecting packet 224, the Wireshark UI highlights the warning. The packet details show the receive window (19200 bytes) and a [Bytes in flight: 112000] annotation, confirming that 112 KB of data are currently unacknowledged.

Identifying the Correct Receive Window

The analysis distinguishes the sender (A, client port 38979) from the receiver (B, server port 22). The relevant receive‑window value is found in the most recent packet from B (source port 22) before the TCP Window Full event—packet 222, which reports a receive window of 112 000 bytes.

Step‑by‑Step Verification

Locate packet 222 (server → client) and note the acknowledged byte count X (e.g., 198 854 bytes).

Find packet 224 (client → server) and read the Next Sequence Number Y (e.g., 310 854 bytes).

Compute Y ‑ X = 112 000 bytes, matching the Bytes in flight shown by Wireshark.

This confirms that the sender’s outstanding data exactly fill the receiver’s window.

Impact on Transfer Speed

When the receive window becomes the bottleneck, the transfer rate drops to the range of 300–400 KB/s, as shown by the I/O Graph. Adjusting the graph interval to 100 ms yields a finer‑grained view of the speed fluctuations.

Deeper Window Analysis

Using Wireshark’s TCP Stream Graph → Window Scaling , one can visualize the staircase‑like evolution of the receive window and identify points where Bytes Out intersect the window—these are the moments when TCP Window Full occurs.

Re‑evaluating the Speed Formula

The classic formula speed = window / RTT assumes that all bytes in flight are immediately acknowledged. In this case, acknowledgments lag, so a more accurate expression is velocity = acked_data / RTT. Applying the revised formula to packets 1337–1357 yields 33600 / 0.094 ≈ 357 KB/s, aligning with the I/O Graph.

Why the Original Formula Still Works in Some Scenarios

When acknowledgments are prompt, the amount of data in flight equals the window size, making the simpler formula valid. In the present case, delayed ACKs cause “in‑flight” data to linger, requiring the refined calculation.

Practical Takeaways

Use Wireshark’s Expert Information to spot TCP Window Full warnings.

Identify the receiver’s actual window by examining the latest packet from the server.

Manually verify bytes‑in‑flight with NextSeq ‑ Ack arithmetic.

Correlate window saturation with throughput using I/O Graphs and Window Scaling graphs.

Apply the appropriate speed formula based on whether ACKs are immediate or delayed.