Breaking the 64 KB Limit
The original TCP specification (RFC 793, 1981) allocated 16 bits for the receive window field. A 16-bit unsigned integer maxes out at 65,535 — meaning the original protocol could never advertise a receive window larger than 64 KB. In 1981, on a 56 Kbps ARPANET link with ~100ms RTT, the BDP was about 700 bytes. A 64 KB window was enormous. Today, it is a rounding error.
RFC 1323 — TCP Window Scaling solves this by introducing a Window Scale Option negotiated during the TCP three-way handshake. Each side advertises a scale factor S (0–14). The actual window size is then:
Effective Window = Window Field Value × 2^S
Example:
- Window field: 65,535
- Scale factor:
S = 8→ multiplier = 256 - Effective window: 65,535 × 256 = 16,776,960 bytes (~16 MB)
With S = 14 (the maximum), the effective window can reach ~1 GB — sufficient for even 100 Gbps links with significant RTT.
Window scaling is enabled by default on modern Linux kernels, but the buffer size limits must also be raised — otherwise the kernel will never advertise a large window even if scaling is on. Linux exposes the receive and send buffer sizing as three values each: a minimum kept under memory pressure, a default for new connections, and a maximum the kernel will auto-tune up to. The default maximum is around 6 MB — fine for most links, but for a Virginia-to-Tokyo connection requiring roughly 21 MB of window to stay full, that default becomes the bottleneck, and the ceiling has to be raised well past it (to 32 MB or more) before window scaling can do any good.
Important: Window scaling only works if both endpoints support it. A middlebox (firewall, NAT device, load balancer) that strips TCP options during connection setup will silently disable window scaling, capping the window at 64 KB. This is a notoriously hard-to-diagnose failure mode — the connection appears healthy but throughput is mysteriously capped.
Interviewers sometimes ask: "Window scaling is enabled on both endpoints, but throughput is still capped at ~5 Mbps on a high-latency link. What else could be wrong?" The answer is middlebox interference — a firewall or NAT device stripping TCP options during the handshake. You can confirm this with tcpdump or Wireshark by checking whether the WS (Window Scale) option appears in the SYN-ACK. If it is absent on the receiver side but present in the original SYN, a middlebox is stripping it.
Key Point: Window scaling removes the 64 KB ceiling, but both endpoints must negotiate it during the handshake, and no middlebox may strip TCP options. The buffer
maxvalue must also be large enough to match the BDP.