TCP Window Scaling and Throughput PCAP Analysis: Receive Window, Zero Window, Window Full, and Slow Transfer Debugging

Slow TCP throughput is not always packet loss. It can be receive-window pressure, missing window scaling, small socket buffers, application read delay, proxy buffering, VPN constraints, or bandwidth-delay product mismatch. Users search for "TCP window scaling pcap", "TCP zero window", "TCP window full", "slow download packet capture", "receive window limiting throughput", and "bandwidth delay product TCP analysis" when speed tests are bad but retransmissions do not explain the slowdown.

PCAP Surgery is useful because throughput problems require preserving the exact handshake options, advertised windows, ACK timing, payload bursts, pauses, and window updates.

What TCP window scaling does

The TCP window field is limited in size. Window scaling allows larger receive windows by negotiating a scale factor during the SYN exchange. If window scaling is missing, disabled, stripped by a device, or misinterpreted, throughput can be capped on high-latency links.

This matters most when latency is significant:

• WAN transfers.
• VPN links.
• Satellite or cellular networks.
• Cross-region cloud traffic.
• Long-distance backup replication.
• Remote file copy.
• Large HTTP downloads.

On a local LAN, a small receive window may still look fast. Across a high-latency path, it can become the bottleneck.

Bandwidth-delay product

Bandwidth-delay product describes how much data must be in flight to fill the path. A connection with high bandwidth and high round-trip time needs a larger window.

If the receive window is too small, the sender must stop and wait for ACKs instead of keeping the pipe full.

Packet capture evidence:

• Sender transmits until advertised window limit.
• Receiver ACKs slowly or advertises small window.
• Throughput forms bursts and pauses.
• Retransmissions are low, but speed is still poor.
• Window update packets appear after application reads data.

This is a receive-side or flow-control bottleneck, not classic loss.

Zero Window

TCP Zero Window means the receiver advertised no available receive buffer. The sender cannot continue sending application data until a window update arrives.

Common causes:

• Receiving application is not reading fast enough.
• Server is overloaded.
• Client is paused or blocked on disk.
• Proxy buffers are full.
• TLS stack is backpressured.
• Database client or file receiver is slow.
• Packet capture is taken near the receiver and shows local pressure.

Zero Window is not automatically a network fault. It often points to application or host resource pressure.

Window Full

"Window full" usually means the sender has filled the receiver's advertised window. It may happen before Zero Window. The sender is ready to send more, but flow control prevents it.

Look for:

• Long runs of data up to the window edge.
• No packet loss around the stall.
• ACKs that do not advance window enough.
• Sender pauses while waiting.
• Window updates followed by another burst.

This pattern is especially important for "slow upload" and "slow download" support cases.

Missing scale option

Window scaling must be negotiated during the handshake. If one side does not include the window scale option in SYN or SYN-ACK, the connection cannot use scaling later.

Evidence:

• SYN options.
• SYN-ACK options.
• Window scale value.
• Initial receive window.
• Effective scaled window.
• Middlebox behavior that strips options.

If the capture starts after the handshake, the scale factor may be unknown. That is why support traces should include the full TCP handshake.

Capture location matters

Window analysis depends on where the capture was taken. A capture near the sender may show different timing than a capture near the receiver. NAT, VPN, proxies, and load balancers can also split connections.

Questions:

• Was the pcap captured on client, server, firewall, or proxy?
• Is this one end-to-end TCP connection or two proxy-side connections?
• Are sequence numbers translated?
• Are ACKs delayed by the receiver or by the network?
• Does the proxy advertise a different window than the final endpoint?

PCAP Surgery helps trim and compare conversations without losing handshake options.

Avoid false packet loss conclusions

Throughput dashboards often blame packet loss. But if retransmissions are rare and the sender repeatedly pauses at the receive window, the real bottleneck is flow control.

Signs that loss is not the main cause:

• Few retransmissions.
• No duplicate ACK storm.
• Regular window update cycles.
• Sender pauses exactly at advertised window.
• Application-layer response is slow to consume data.

The article should target searches like "slow TCP no packet loss" because those users need a different diagnostic path.

Debug checklist

Use this workflow:

1. Keep the SYN and SYN-ACK packets.
2. Record window scale options.
3. Calculate effective receive window.
4. Identify zero-window and window-update packets.
5. Identify window-full periods.
6. Measure RTT.
7. Compare in-flight bytes with bandwidth-delay product.
8. Check retransmission rate separately.
9. Note capture location.
10. Preserve the slow interval and the handshake together.

Final diagnosis

TCP window scaling and receive-window issues create slow transfers without obvious packet loss. The evidence is in handshake options, advertised receive windows, zero-window events, window updates, RTT, and sender pause behavior.

PCAP Surgery helps keep the packets that prove whether the bottleneck is network loss, receive buffer pressure, missing window scaling, proxy behavior, or an application that is not reading fast enough.