TCP Window Scaling Factor

TCP window scaling and high-throughput links

The original TCP header set aside just 16 bits for the receive window, which caps it at 65,535 bytes (64 KB). On today's high-bandwidth, high-latency links that ceiling strangles throughput long before you hit the real capacity. RFC 1323 (later updated by RFC 7323) brings in the Window Scale option, and it is negotiated only during the SYN/SYN-ACK handshake. What it does is apply a left bit-shift of 0–14 to the advertised window, pushing it as high as 65,535 · 2^14 = 1 GB. So a shift count of 7 multiplies the window by 128, turning 64 KB into 8 MB. On Linux you turn it on with net.ipv4.tcp_window_scaling=1.

Applications and context

You can't do without it on LFNs (Long Fat Networks), the transcontinental and satellite links whose bandwidth-delay product runs past 64 KB. It's what lets you saturate 10 GbE and 40/100 GbE circuits, and it shows up in intercontinental backups, CDN origin pulls, video streaming and gaming backbones. ATC (air traffic control) and SCADA links riding long-haul WAN lean on it too.

FAQ

Why is the maximum shift 14? RFC 1323 draws the line there to keep the effective window under 2^30 bytes, which avoids any ambiguity against the 32-bit sequence number space.

Can scaling be enabled mid-connection? No. The negotiation happens only in the initial SYN exchange, and if either side strips the option out, the connection drops back to 64 KB.

Do middleboxes break it? A few old NATs and firewalls still rewrite or drop the Window Scale option, which leads to stalls. Modern stacks tend to handle it fine.