the network bottleneck
A chain is only as strong as its weakest link, and a water supply only flows as fast as its narrowest pipe. The same is true of a network path made of many links in a row: data can move no faster than the slowest link along the way. That slowest link is the bottleneck, and it alone sets the ceiling on how fast a transfer can go, no matter how fast every other link is.
Picture a path of several links with capacities R1, R2, R3 and so on. The end-to-end throughput a single transfer can achieve is at most the minimum of those rates — min(R1, R2, R3, ...). If a 1 Gbps fibre feeds into a 50 Mbps home line and then into a 10 Gbps datacentre link, the whole path tops out at 50 Mbps, because the 50 Mbps link is the bottleneck. Data piles up just before the bottleneck — that is where a queue forms and queuing delay grows, because packets arrive faster than the bottleneck can drain them. Upgrading any link other than the bottleneck changes nothing; you must widen the narrowest one.
Two honest refinements. First, the bottleneck is per-path and can move: it is wherever the slowest or most congested link currently sits, and on a shared link your effective bottleneck is your share of it, not its full capacity. Second, a slow transfer is not always the network's fault at all — the limit might be a slow disk, a busy CPU, a small TCP window, or a distant server, not any link. Diagnosing where the real bottleneck lies — link, host, DNS, or path — is the heart of the art of network troubleshooting, and it is why measuring before upgrading saves money and frustration.
A download crawls at 50 Mbps even though your office has a 1 Gbps link. A traceroute and a few iperf tests reveal the path crosses a congested 50 Mbps WAN circuit between two sites. Upgrading your already-fast office switch would do nothing; the only fix is to widen min(R1, R2, ...) — the 50 Mbps bottleneck.
End-to-end throughput is at most min(R1, R2, ...); upgrading any link except the bottleneck changes nothing.
A slow transfer is not always a link's fault: the real limit can be a slow disk, a busy CPU, a small TCP window, or a distant server. Measure to find where the bottleneck actually lies before paying to upgrade anything.