Computer Science · Network Engineering · Protocol Analysis
TCP Window Size Calculator
Calculates the optimal TCP window size and maximum throughput based on bandwidth-delay product and network parameters.
Calculator
Formula
W_opt is the optimal TCP window size in bytes; BDP is the Bandwidth-Delay Product; B is the available link bandwidth in bits per second (converted to bytes per second by dividing by 8); RTT is the round-trip time in seconds; T_max is the maximum achievable throughput in bytes per second when the window size equals the BDP; W is the actual configured window size in bytes.
Source: RFC 1323 — TCP Extensions for High Performance; RFC 7323 — TCP Extensions for High Performance (updated); Kurose & Ross, Computer Networking: A Top-Down Approach, 8th ed.
How it works
TCP uses a sliding window mechanism to control how much data a sender can have "in flight" — transmitted but not yet acknowledged — at any given moment. The receiver advertises a window size in each ACK, telling the sender the maximum number of bytes it can accept. If the window is too small, the sender is forced to pause and wait for acknowledgment before sending more data, creating idle gaps that reduce throughput. The fundamental insight is that the window must be large enough to keep the network "pipe" completely full at all times.
The optimal window size is defined by the Bandwidth-Delay Product (BDP): BDP = B × RTT, where B is the bottleneck link bandwidth in bytes per second and RTT is the round-trip time in seconds. This product represents the number of bytes that can be in transit on the network at any instant. If the TCP window is smaller than the BDP, the link will be underutilized because the sender runs out of window space before the first acknowledgment returns. Maximum throughput is then T_max = W / RTT, where W is the effective window size. Link utilization efficiency is simply the ratio of the configured window to the BDP, capped at 100%. TCP's standard 16-bit window field allows a maximum of 65,535 bytes (64 KB). For high-BDP paths, RFC 7323 defines a Window Scale option (values 0–14) that left-shifts the window field, enabling effective window sizes up to 1 GB (65535 × 2^14 bytes).
This calculator is used in a wide range of scenarios: tuning Linux kernel parameters (net.core.rmem_max, tcp_rmem), configuring application-layer buffer sizes, diagnosing performance on satellite or intercontinental WAN links, validating network hardware capabilities, and benchmarking the impact of RTT on achievable throughput. It is equally valuable for cloud architects designing high-throughput data pipelines, DevOps engineers investigating slow file transfers, and researchers studying transport-layer performance.
Worked example
Consider a 1 Gbps fiber link between two data centers with a measured round-trip time of 80 ms (0.080 s). The system administrator has configured a TCP receive window of 64 KB (the default on many older systems) with no window scaling (factor = 0).
Step 1 — Compute the BDP:
B = 1,000 Mbps = 1,000 × 10^6 / 8 = 125,000,000 bytes/s
BDP = 125,000,000 × 0.080 = 10,000,000 bytes ≈ 9,765 KB ≈ 9.54 MB
Step 2 — Effective window size:
With scaling factor 0, effective window = 64 KB = 65,536 bytes.
Step 3 — Maximum throughput:
T_max = 65,536 / 0.080 = 819,200 bytes/s = 6.55 Mbps
Step 4 — Link utilization:
Efficiency = 65,536 / 10,000,000 × 100 = 0.66% — severely under-utilized!
Step 5 — Required scaling factor:
We need a window of at least 10,000,000 bytes. 65,535 × 2^n ≥ 10,000,000 → 2^n ≥ 152.7 → n ≥ 8. A scaling factor of 8 gives an effective window of 65,535 × 256 = 16.7 MB, achieving full link utilization.
With a scaling factor of 8, the maximum throughput becomes 16,773,120 / 0.080 = 1,677 Mbps — capped at the link speed of 1 Gbps, indicating the window is now more than sufficient and the link is fully utilized.
Limitations & notes
This calculator models a single TCP flow under ideal conditions and does not account for packet loss, which can cause TCP congestion control algorithms (Reno, CUBIC, BBR) to reduce the congestion window well below the receive window, dramatically limiting throughput. The RTT used should be the measured path RTT under realistic load, not just a ping measurement, as queuing delay can add significant latency under traffic. The model assumes the receive window is the sole bottleneck; in practice, CPU processing speed, storage I/O, NIC offload capabilities, and intermediate router queues all affect actual throughput. Furthermore, both endpoints must negotiate and support the Window Scale option (RFC 7323) — if either side does not, scaling is disabled and the maximum window remains 65,535 bytes. Multi-path TCP, connection bonding, and hardware acceleration are not modeled. For UDP-based protocols (QUIC, DTLS, RTP), different flow control mechanisms apply and this calculator is not directly applicable.
Frequently asked questions
What is the TCP window size and why does it matter?
The TCP window size is the maximum number of bytes a sender can transmit before it must wait for an acknowledgment from the receiver. It directly determines the maximum achievable throughput: T_max = Window / RTT. A window that is too small causes the sender to stall, leaving the network link idle and wasting available bandwidth.
What is the Bandwidth-Delay Product (BDP)?
The Bandwidth-Delay Product is the product of a network link's bandwidth (in bytes per second) and the round-trip time (in seconds). It represents the volume of data that can be "in flight" on the network at any moment. Setting the TCP window equal to the BDP allows the sender to keep the pipe completely full, achieving maximum link utilization.
When do I need TCP window scaling?
You need TCP window scaling whenever the BDP exceeds 65,535 bytes (64 KB) — the maximum value of the 16-bit TCP window field. This is common on high-bandwidth links (100 Mbps and above) with RTTs above a few milliseconds, or on any long-distance (satellite, intercontinental) connection. RFC 7323 defines scaling factors from 0 to 14, enabling windows up to 1 GB.
How do I set the TCP window size in Linux?
In Linux, you can tune TCP buffer sizes via sysctl parameters: net.core.rmem_max and net.core.wmem_max set the maximum socket buffer sizes, while net.ipv4.tcp_rmem and net.ipv4.tcp_wmem control the minimum, default, and maximum receive/send buffer sizes. Set these to at least twice the BDP to allow for overhead. TCP window scaling is enabled by default (net.ipv4.tcp_window_scaling = 1).
Does a larger TCP window always improve performance?
Not always. A window larger than the BDP does not increase throughput beyond the link's physical capacity and wastes memory. More importantly, on lossy networks, a very large window means more in-flight data is lost per drop event, causing larger throughput reductions during congestion recovery. Modern congestion control algorithms like BBR dynamically probe for the optimal operating point regardless of the receive window limit, as long as the window is at least as large as the BDP.
Last updated: 2025-01-15 · Formula verified against primary sources.