Flow Control vs Congestion Control
- Networking Fundamentals & OSI Model
- TCP/IP Model
- Network Topologies
- IP Addressing & Subnetting
- Routing Algorithms & Protocols
- Switching Concepts
- Transport Layer Protocols (TCP & UDP)
- Application Layer Protocols
- Network Security & Firewalls
- Wireless Networking & Wi-Fi
- Network Address Translation (NAT)
- DNS Deep Dive
- Congestion Control & Flow Control
- Error Detection & Correction
- Network Devices
- VPN & Tunneling
- Load Balancing & CDN Networking
- Socket Programming
- Network Troubleshooting Tools
- Physical Layer & Transmission Media
- Data Link Layer & MAC Addressing
- Ethernet Protocol
- ARP (Address Resolution Protocol)
- ICMP Protocol
- Unicast, Multicast, Broadcast and Anycast
- Proxy Servers
- Port Numbers Reference
- Network Performance Metrics
- Quality of Service (QoS)
- Software-Defined Networking (SDN)
- HTTP/2 and HTTP/3 Overview
- 5G and Mobile Networks
- IoT Networking Basics
- VoIP Networking Basics
Two Problems That Sound Similar, But Aren't
Flow control and congestion control both slow down a sender - but they respond to two completely different problems, and confusing them is a common source of misunderstanding.
Flow Control: Protecting the Receiver
As covered in an earlier note, flow control exists purely to stop a fast sender from overwhelming a slow receiver's buffer. It's a conversation between exactly two endpoints, and has nothing to do with the state of the network in between them.
Congestion Control: Protecting the Network Itself
Congestion control exists to stop a sender from overwhelming the network path in between - the routers and links data must cross - even if the receiver itself is perfectly capable of handling the data.
Flow control: Sender <---- receiver's buffer status ----> Receiver
Congestion control: Sender <---- signals from the network path ----> ReceiverSide-by-Side Comparison
| Flow Control | Congestion Control | |
|---|---|---|
| Protects | The receiver's buffer | The shared network path |
| Signal used | Receiver's advertised window size | Packet loss, delay, or explicit congestion signals |
| Who is "slow" | The specific receiver | Some router or link along the path |
Why TCP Needs Both, Simultaneously
A receiver could be perfectly fast, but a router three hops away could still be overloaded by other traffic entirely unrelated to this connection. TCP constantly balances both signals together, sending at whichever rate is currently limited by the more restrictive of the two.