Course contentsShow
← Linux
Lesson 1112 of 1,81910. Network Administration and Kernel StacksFree lesson

Tuning the Receive Window

Adjust buffer sizes to handle high-bandwidth long-latency network paths.

In this lesson, you will learn how to optimize Linux TCP buffer sizes to maintain high throughput across high-bandwidth, long-latency network paths.

The Problem: The Bandwidth-Delay Product

When data travels over long distances—such as a cross-continental fiber link—the "latency" (Round Trip Time or RTT) means that it takes a significant amount of time for a sender to receive an acknowledgment (ACK) for the data it sent. If your TCP receive window is too small, the sender will stop transmitting once that window is full, forcing it to wait for an ACK before sending more. This leaves your high-speed pipe sitting idle while waiting for the network to "catch up."

To saturate the link, your buffer must be large enough to hold the Bandwidth-Delay Product (BDP), calculated as Bandwidth × Round Trip Time.

Adjusting Buffer Limits

Linux uses kernel parameters to manage the memory allocated to these TCP buffers. You can inspect the current limits for the receive buffer (rmem) using sysctl:

# Check current default and maximum receive buffer sizes
sysctl net.core.rmem_default
sysctl net.core.rmem_max

While the Linux kernel now supports "Auto-tuning" (enabled by default), which dynamically adjusts window sizes based on traffic patterns, you may occasionally need to increase the rmem_max value to allow the kernel to scale windows high enough for extremely fast, long-distance links (like 10Gbps+ connections across oceans).

To increase the maximum receive buffer size to 16MB, you would update the configuration:

# Temporarily set max receive buffer to 16MB
sudo sysctl -w net.core.rmem_max=16777216

Why Balance is Key

Increasing these buffers isn't a "set to infinity" task. Every open TCP connection reserves memory based on these limits. If you set your maximums unnecessarily high on a server handling hundreds of thousands of concurrent connections, you risk exhausting the system's physical RAM, leading to kernel OOM (Out of Memory) kills. Always calculate your BDP and tune accordingly, keeping your total memory overhead in mind.

Key Takeaway: Tuning the receive window ensures that high-latency, high-bandwidth connections remain productive by allowing the kernel to buffer enough in-flight data to keep the pipe full while waiting for acknowledgments.