Congestion control is the collection of mechanisms that make a sender slow down when the network between it and the receiver is overloaded, and speed up when capacity is available. In TCP, it is governed by a congestion window that limits how much unacknowledged data may be in flight.
Why it matters
Without it, every sender would transmit as fast as possible, queues in routers would overflow, packets would be dropped and retransmitted, and the network could collapse. Classic algorithms start with slow start, doubling the window each round trip, then switch to additive increase and multiplicative decrease once loss is seen. Newer ones such as CUBIC (default on Linux) and BBR use different signals; BBR estimates bandwidth and round-trip time rather than treating loss as the main cue.
Congestion control differs from flow control, which protects the receiver rather than the network.
Example
A download starts with a window of about 10 segments (roughly 14 KB). After each round trip without loss it grows. When a packet is lost, a classic algorithm halves the window, so throughput saw-tooths around the link capacity. On Linux, sysctl net.ipv4.tcp_congestion_control shows the algorithm in use.
Common mistakes
- Blaming bandwidth alone for slow transfers when high RTT and loss limit the window.
- Confusing congestion control with QoS.
- Assuming UDP is covered; applications must implement their own.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.