TCP Window Size Calculator

Calculate the bandwidth-delay product (BDP) and maximum achievable TCP throughput for a given window size and round-trip time (RTT). This calculator is essential for WAN optimization, diagnosing slow file transfers over long-distance links, and tuning TCP buffer sizes on servers and firewalls.

Calculate Maximum TCP Throughput

Link Bandwidth

Round-Trip Time (ms)

TCP Window Size (bytes) Default: 65535 (without scaling)

Window Scale Factor

What Is the TCP Window Size?

The TCP window size (also called the receive window or RWIN) is the amount of data a receiver can accept before requiring an acknowledgment from the sender. It acts as a flow control mechanism: the sender can transmit up to the window size worth of data, then must wait for an ACK before sending more.

The original TCP specification (RFC 793) allocated 16 bits for the window size field, limiting it to 65,535 bytes. On high-bandwidth, high-latency links (like cross-continental WAN connections), this is far too small to fill the pipe. TCP Window Scaling (RFC 7323) solves this by using a scale factor that multiplies the window size by powers of 2, allowing effective windows up to 1 GB.

The Bandwidth-Delay Product (BDP)

The bandwidth-delay product is the maximum amount of data that can be "in flight" on a network link at any moment. It is calculated as:

BDP (bits) = Bandwidth (bits/sec) x RTT (seconds)
BDP (bytes) = BDP (bits) / 8

For a 100 Mbps link with 50 ms RTT:

BDP = 100,000,000 bits/sec x 0.050 sec = 5,000,000 bits = 625,000 bytes = 610 KB

If the TCP window is smaller than the BDP, the sender cannot keep the pipe full. It sends a window's worth of data, then idles while waiting for an ACK. The maximum throughput becomes limited by the window size, not the bandwidth.

Bandwidth	RTT	BDP	Required Window	Max Throughput (64KB window)
10 Mbps	10 ms	12.5 KB	12.5 KB	10 Mbps (window sufficient)
100 Mbps	50 ms	625 KB	625 KB	10.5 Mbps (bottleneck!)
1 Gbps	20 ms	2.5 MB	2.5 MB	26.2 Mbps (bottleneck!)
1 Gbps	100 ms	12.5 MB	12.5 MB	5.2 Mbps (severe bottleneck!)
10 Gbps	5 ms	6.25 MB	6.25 MB	104.9 Mbps (bottleneck!)

Pro Tip: A classic symptom of a TCP window size bottleneck is a WAN file transfer that runs much slower than the link bandwidth. If you have a 1 Gbps WAN link but file copies max out at 25 Mbps, check the TCP window size. With a 50 ms RTT and default 64 KB window, the maximum theoretical throughput is only 10.5 Mbps. Enable window scaling to fix this.

TCP Window Scaling Explained

Window scaling uses a multiplier (scale factor) negotiated during the TCP three-way handshake. The scale factor is a power of 2, from 0 (no scaling) to 14 (multiply by 16,384). Modern operating systems typically negotiate a scale factor of 7-8 automatically.

Scale Factor	Multiplier	Max Effective Window	Max Throughput @ 50ms RTT
0	1x	65,535 bytes (64 KB)	10.5 Mbps
1	2x	131,070 bytes (128 KB)	21.0 Mbps
3	8x	524,280 bytes (512 KB)	83.9 Mbps
7	128x	8,388,480 bytes (8 MB)	1,342 Mbps
10	1024x	67,107,840 bytes (64 MB)	10,737 Mbps
14	16384x	1,073,725,440 bytes (1 GB)	171,796 Mbps

Tuning TCP Window Size

Linux

# View current settings
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

# Set receive/send buffers (min, default, max) in bytes
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Enable window scaling (usually on by default)
sudo sysctl -w net.ipv4.tcp_window_scaling=1

Windows

# Check current receive window auto-tuning level
netsh interface tcp show global

# Set to normal (recommended) or experimental
netsh interface tcp set global autotuninglevel=normal

Cisco Router

! Set TCP window size on router
ip tcp window-size 65535

Pro Tip: Some firewalls and WAN optimizers strip TCP window scaling options from the SYN packet, silently capping connections to 64 KB. If you see slow transfers only through a specific firewall, capture packets on both sides with Wireshark and compare the TCP options in the SYN/SYN-ACK. Look for the Window Scale option in the TCP header.

Real-World Impact: Cloud and WAN

TCP window tuning is especially important for cloud workloads. A server in US-East transferring data to a client in EU-West faces 80-120 ms RTT. Without proper window scaling, a 1 Gbps link between the two regions delivers only 5-10 Mbps of actual TCP throughput. This is why cloud providers like AWS and Azure recommend enabling TCP window scaling and tuning buffer sizes for cross-region transfers.

Use the Network Latency Test to measure your RTT, then plug it into this calculator to determine if TCP window size is limiting your throughput. The Network Throughput Calculator can help factor in additional protocol overhead.

Video Tutorial

Key Takeaways

The bandwidth-delay product (BDP) determines the optimal TCP window size: BDP = bandwidth x RTT
Without window scaling, TCP is limited to a 64 KB window, severely bottlenecking high-latency links
A 1 Gbps link with 100 ms RTT and 64 KB window delivers only 5.2 Mbps — window scaling is essential
Modern OSes negotiate window scaling automatically, but firewalls may strip the option
Tune tcp_rmem/tcp_wmem on Linux servers to ensure buffer sizes match the BDP
Always measure RTT before tuning — use ping or the Network Latency Test tool

Related Tools & Guides

Frequently Asked Questions

What is the bandwidth-delay product?

The bandwidth-delay product (BDP) is the maximum amount of data that can be in transit on a network link at any instant. It equals the bandwidth multiplied by the round-trip time. The TCP window must be at least as large as the BDP to fully utilize the available bandwidth.

Why are my file transfers slow on a fast WAN link?

The most common cause is an undersized TCP window. If the TCP window (limited to 64 KB without scaling) is smaller than the BDP, the sender must wait for acknowledgments before sending more data, leaving the link idle. Enable TCP window scaling and ensure firewalls are not stripping the scaling option from TCP handshakes.

What is TCP window scaling?

TCP window scaling (RFC 7323) is an extension that multiplies the 16-bit window size field by a power-of-2 scale factor, allowing effective windows up to 1 GB. The scale factor is negotiated during the three-way handshake and both endpoints must support it. All modern operating systems enable it by default.

How do I check if window scaling is enabled?

Capture the TCP handshake with Wireshark and look for the "Window Scale" option in the SYN and SYN-ACK packets. On Linux, run sysctl net.ipv4.tcp_window_scaling (1 = enabled). On Windows, run netsh interface tcp show global and check the "Receive Window Auto-Tuning Level" setting.

What RTT values are typical?

Local LAN: 0.1-1 ms. Same city: 5-10 ms. Same continent: 20-50 ms. Cross-continental: 80-150 ms. Satellite (GEO): 500-700 ms. Each hop through a router or switch adds 0.1-2 ms of latency. Use ping or traceroute to measure actual RTT to your destination.

Can I set the TCP window size too large?

An excessively large TCP window wastes memory on both endpoints and can cause buffer bloat, increasing latency for other connections. The optimal window size equals the BDP. Most modern OSes use auto-tuning to dynamically adjust the window based on measured conditions, which is the recommended approach.