Three words people use as if they meant the same thing
When someone says their network is "fast," they usually mean one of three different things without realizing it. Bandwidth is how much data the link can carry per second. Latency is how long one bit takes to get from here to there. Throughput is how much data you actually move per second in practice. They feel related, but they are genuinely separate measurements, and confusing them is the single most common networking mistake.
A vivid way to keep them apart: picture a highway. Bandwidth is how many lanes it has — its capacity. Latency is how long the drive itself takes, set mostly by the distance and the speed limit. Throughput is how many cars per hour actually arrive at the far end, which depends on the lanes, the traffic, and any toll booths along the way. Widening the road (more bandwidth) does nothing to shorten a 500-kilometre drive (the latency).
Where the delay actually comes from
Back in guide 2 we saw that a router uses store-and-forward: it must receive a whole packet before it can send it on. That single fact is the seed of all delay. The total time a packet spends crossing one hop is the sum of four pieces, and each piece has a completely different cause. Naming them separately is what lets engineers diagnose a slow network instead of just shrugging.
- Processing delay — the router reads the header, checks for errors, and decides which way to send the packet. Tiny, usually microseconds.
- Queuing delay — if other packets are already waiting for the same outgoing link, this packet sits in line. This is the wildly variable one: zero when the link is idle, huge when it is congested.
- Transmission delay — the time to push every bit of the packet onto the wire, which is packet size divided by the link's bandwidth. A 12,000-bit packet on a 100 Mbps link takes 12,000 / 100,000,000 = 0.12 ms.
- Propagation delay — the time for a bit to physically travel down the wire at near light speed, which is distance divided by signal speed. It does not care how big the packet is — only how far it has to go.
The two that beginners conflate are transmission and propagation delay. Transmission delay depends on how big the packet is and how fat the pipe is; propagation delay depends only on distance. A short message over a transatlantic fibre is almost all propagation; a giant file over a slow modem in the same room is almost all transmission. They are independent, and only their sum is the delay you feel.
Why more bandwidth cannot beat the speed of light
Here is the misconception worth burning into memory: buying more bandwidth does not reduce latency. Bandwidth only shrinks the transmission piece of delay — it lets you pour bits onto the wire faster. But propagation delay is set by distance and physics, and no amount of money widens it. Light in glass fibre covers roughly 200,000 km per second, so a signal from New York to London (about 5,600 km) needs around 28 ms each way no matter how many gigabits per second your plan promises.
This is why a video call to the other side of the planet still feels laggy on a blazing fibre connection, and why competitive gamers care about ping, not bandwidth. The round trip — there and back, often called the round-trip time or RTT — is bounded below by geography. You can add lanes forever; you cannot make the drive shorter than the distance allows.
Throughput: what you actually get
Bandwidth is the link's rated capacity; throughput is what you really achieve end to end, and it is almost always lower. A path is a chain of links, and a chain is only as strong as its weakest link. If your home link is 1 Gbps but it passes through a server that can only send at 10 Mbps, your throughput is min(R1, R2) = 10 Mbps. That slowest link is the bottleneck, and it alone caps the whole transfer.
client ===== 1 Gbps =====> [router] ----- 10 Mbps -----> server
^^^^^^^^^
bottleneck
throughput = min(1 Gbps, 10 Mbps) = 10 Mbps
(the fat first link cannot rescue the thin second one)Even the bottleneck rate is an optimistic ceiling. Real throughput is eaten away by queuing when links get busy, by protocol overhead (every header is bytes that are not your data), and by retransmissions when packets are lost. The clean count of useful application bytes per second — your file, minus all the machinery — has its own name, goodput, and it is the honest number you should compare against a download's actual finish time.
Putting the three together
Bandwidth and latency multiply into a surprisingly useful quantity. The bandwidth-delay product is bandwidth times round-trip time, and it tells you how many bits can be "in flight" — already sent but not yet acknowledged — at once. Think of it as the volume of the pipe: a wide pipe (high bandwidth) that is also long (high latency) holds a lot of water even before any comes out the far end. A protocol that does not keep at least this many bits in flight will leave the link idle and feel slow no matter how much capacity it has.
This is exactly the gap the bandwidth-delay product explains and that TCP's congestion control spends its life trying to fill: send enough to keep the long fat pipe full, but not so much that queues overflow. A careful driver speeds up gently and brakes hard — we will meet that mechanism properly in the transport-layer rung. For now, the point is that "fast" is never one number. It is a negotiation between how much you can pour, how far it must go, and what actually survives the trip.