2026-06-02

TCP Window Scaling and Throughput PCAP Analysis

How to analyze TCP window scaling, receive window limits, zero window, window full events, slow throughput, bandwidth delay product, and packet capture evidence.

A slow TCP transfer with little loss may be bounded by the receiver rather than the link. Preserve the handshake to decode window scaling, then track advertised receive windows, TCP Window Full, zero-window periods, RTT, and bytes in flight against the bandwidth-delay product. These fields can show that the receive window limits throughput or the application stops draining buffers; they cannot expose the receiver's CPU, socket configuration, or proxy queue directly.

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:

Keep the SYN and SYN-ACK packets.
Record window scale options.
Calculate effective receive window.
Identify zero-window and window-update packets.
Identify window-full periods.
Measure RTT.
Compare in-flight bytes with bandwidth-delay product.
Check retransmission rate separately.
Note capture location.
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.

Calculate the effective receive window correctly

The scale option is negotiated only in SYN packets and applies to later advertised window values from that endpoint. If the handshake is absent, analyzers may guess or leave the value unscaled. Do not present an exact byte capacity without the option.

effective receive window = 16-bit window field × 2^scale
bandwidth-delay product = target bytes/second × RTT seconds

Compare the effective advertised window with bytes in flight and bandwidth-delay product. For example, a 10 MB/s target over 80 ms RTT needs about 800 KB in flight. A stable 64 KB receive limit cannot sustain that target even without loss. This calculation is a ceiling estimate, not a guarantee of throughput.

Pattern	Packet evidence	Likely next owner
Sender repeatedly reaches advertised edge	Window Full and ACK-dependent bursts	Receiver/socket tuning
Window shrinks to zero	Zero Window, probes, later update	Receiving application
Window remains large, bytes in flight stay small	Sender/app/congestion limit	Sender logs and congestion state
Loss and retransmissions dominate	ACK/SACK gaps and recovery	Network/path analysis
High RTT with moderate window	BDP exceeds allowed flight	Path and endpoint tuning

What is TCP Window Full?

It is an analyzer interpretation that the sender has filled the currently advertised receive window. It differs from Zero Window, which is an explicit receiver advertisement of no available space. Repeated sender pauses at the window edge support a flow-control limit; a single label does not establish a sustained bottleneck.

Can a proxy hide the real receiver window?

Yes. A load balancer or proxy terminates one TCP connection and creates another. Client-side window evidence applies to the client-proxy leg, not the proxy-backend leg. Capture or correlate both legs before blaming the ultimate server.

Does a large receive window rule out application stalls?

No. The receiver can advertise space while application response logic is idle, and an application can stop reading later and shrink the window. Separate request processing time, sender behavior, and receive flow control along the timeline.

Throughput measurement worksheet

Record flow, direction, capture point, handshake scale factors, RTT range, effective receive-window range, peak bytes in flight, zero/window-full intervals, retransmission rate, measured goodput, and the application time window. Use several steady-state intervals rather than a connection’s startup alone.

For an actionable comparison, keep endpoint, path, file size, congestion state, proxy leg, and connection reuse constant. After changing socket buffers or policy, require the advertised window and bytes-in-flight pattern to change as predicted, not merely one faster transfer.

When should TCP_NODELAY or application batching be investigated?

When windows are ample but tiny writes and ACK timing create fixed gaps, flow control is probably not the primary issue. Follow the Nagle and delayed ACK analysis.

Where does Zero Window fit?

If the receiver explicitly closes the window, measure its duration, probes, and Window Update using the TCP Zero Window guide. The host then needs process-level evidence for why reads stopped.

Create a focused artifact containing the handshake, one healthy transfer interval, the slow interval, window updates, and recovery. Use capture scope help and the packet preparation workflow to preserve scale negotiation and timing.

Worked throughput ceiling example

Assume a client receives from a server across an 85 ms RTT path. The receiver advertises an effective 262,144-byte window. Ignoring loss and protocol overhead, the receive-window ceiling is approximately:

262,144 bytes / 0.085 seconds ≈ 3.08 MB/s

If measured goodput repeatedly sits near that value and sender bursts stop at the advertised edge until ACK/window progress, receive flow control is a strong lead. If goodput is far below it and bytes in flight never approach the window, inspect sender pacing, application generation, congestion control, proxy behavior, and loss instead.

Do not use a single RTT sample. Measure baseline and tail RTT through the steady interval. ACK compression, delayed ACK, path changes, and queueing change the practical relationship. The calculation supplies a falsifiable bound, not a complete performance model.

What should be changed first?

Change the owner-specific constraint demonstrated by evidence. That may be application read behavior, socket receive buffer policy, window-scaling negotiation through a middlebox, or a proxy leg. Increasing buffers blindly can consume memory and only postpone a stalled consumer.

What proves the fix?

The same controlled transfer should show the intended scale/window, larger sustained bytes in flight where needed, fewer window-edge pauses, no new Zero Window episodes, and higher application goodput. Record endpoint memory and CPU so a throughput gain is not purchased by unsafe resource growth.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: