Three words, three meanings
By now you have run iperf and watched it report a number in megabits per second, and you have run ping and watched it report milliseconds. Those two numbers measure completely different things, and the most common confusion in all of networking is to treat them as one. So let us be precise. Latency is how long it takes one bit to travel from here to there: a duration, measured in milliseconds. Throughput is how many bits per second actually flow once data is moving: a rate, measured in megabits or gigabits per second. One is a delay; the other is a flow. They can vary completely independently.
An analogy keeps this straight. Picture a highway. Latency is how long one car takes to drive from one city to the next, set mostly by the distance and the speed limit. Throughput is how many cars per minute roll past a point, set by how many lanes are open. Widening the road from two lanes to ten lets far more cars through every minute, that is more throughput, but it does not make any single car arrive one second sooner, because the trip length never changed. Bandwidth and latency are different knobs, and turning one does not turn the other.
What latency is actually made of
Ping gives you one number, but that number is a sum of four very different delays, and knowing which one dominates is half of diagnosis. First, transmission delay: the time to push the bits of a packet onto the wire, which is the packet size divided by the link rate. Second, propagation delay: the time for those bits to travel the distance at the speed of light, which depends only on length and is utterly unaffected by how fast the link is. Third, processing delay: the brief moment each router spends reading the header and deciding where to forward. Fourth, and the troublemaker, queuing delay.
Be careful not to confuse transmission delay with propagation delay, because they look similar and behave oppositely. Transmission delay shrinks when you buy a faster link, a bigger pipe drains a packet onto the wire sooner. Propagation delay does not budge no matter what you pay, because it is set by distance and physics alone. This is exactly why more bandwidth helps transmission but never touches the speed-of-light floor under a long-distance trip.
Queuing delay is the one that swings wildly, and it is the heart of most slowness complaints. When packets arrive at a router faster than the outgoing link can drain them, they wait in a buffer, a line at the checkout. An almost-empty queue adds nothing; a queue near capacity can add tens or hundreds of milliseconds, and the closer the link gets to full, the more savagely the wait grows. Recall from the congestion-control rung that this is why a link at 99% utilization can feel dramatically worse than one at 80%, even though it is moving only a little more data. The flow barely changed; the wait exploded.
Throughput versus goodput: the bits that count
Now the third word, the one most people have never heard. Throughput counts every bit crossing the link, but not every bit is useful to you. Each packet carries headers, the Ethernet frame, the IP header, the TCP header, all the addressing and bookkeeping from the layering you learned early on. Add to that the bits spent retransmitting packets that were lost, and the bits of pure protocol chatter like acknowledgements. Goodput is throughput minus all of that: the rate of application data that actually arrives intact and in order, the bytes of the file or the video, and nothing else.
Carrying a 1000-byte chunk of your file over Ethernet: application data ............ 1000 bytes <- what you want + TCP header ................ 20 bytes + IP header ................. 20 bytes + Ethernet frame overhead ... 38 bytes ---------------------------------------- total on the wire .......... 1078 bytes goodput / throughput = 1000 / 1078 ~= 93% And that is the GOOD case: zero loss, zero retransmission. Lose and resend a packet, and goodput drops further still.
So goodput is always less than or equal to throughput, and the gap tells a story. A small gap means efficient transfer with little loss. A large gap, throughput near the link rate but goodput far below it, is a red flag: you are pushing lots of bits but losing and resending many of them, so the wire is busy while the user waits. This is why a speed test bragging about throughput can still feel sluggish, and why goodput, the bits that count, is the honest measure of a transfer.
Where the bottleneck sits
An end-to-end path is a chain of links, each with its own rate. The throughput of the whole path cannot exceed the slowest link in the chain, and that slowest link is the bottleneck. If your home link runs at 100 Mbps and your fibre backbone at 10 Gbps, the path's ceiling is min(R1, R2) = 100 Mbps. Upgrading any link except the bottleneck changes nothing; widening a six-lane road feeding into a one-lane bridge does not move more cars. The whole game of performance is finding the one link that is actually limiting you.
Here latency and throughput come together in one beautiful idea: the bandwidth-delay product, bandwidth times round-trip time. It is the amount of data in flight, filling the pipe, when the link is fully busy, the volume of the pipe itself. Think of a hose: its capacity is its cross-section (the bandwidth) times its length (the delay). To keep a fat, long pipe full, a sender must have that many bytes outstanding at once, which is exactly why TCP's window must be at least as large as the bandwidth-delay product, or the link sits half-idle waiting for acknowledgements.
Put real numbers on it. A 1 Gbps link across an ocean with a round-trip time of 100 ms has a bandwidth-delay product of 1 Gbps times 0.100 s, which is 100,000,000 bits, about 12.5 megabytes that must be in flight to keep it full. If TCP lets only 64 KB go unacknowledged at a time, the sender fires 64 KB then stops and waits a whole 100 ms for the acknowledgement, so the 1 Gbps pipe limps along at well under 1% of its rate, not because the link is slow, but because of latency. On such a long fat pipe the limit is the round trip, not the bandwidth, which is exactly why high-latency paths feel slow even on fast links.
Buffers, bufferbloat, and reading the symptoms
One more trap closes the loop between latency and throughput. To avoid dropping packets during a burst, engineers gave routers and home gateways large buffers. It seemed kind: rather than discard a packet, hold it. But an oversized buffer at the bottleneck quietly fills and stays full, and every packet now waits behind a long standing queue. The result is bufferbloat: throughput looks fine, yet latency under load balloons to seconds. Your download is fast and your video call is unwatchable at the same moment, on the same link.
Put the vocabulary to work as a diagnostic checklist. High latency but normal throughput points at distance or a bloated queue, not a slow link. Low throughput but normal latency points at the bottleneck link's rate, or a window too small for the bandwidth-delay product. Throughput far above goodput points at loss and retransmission. And latency that is fine when idle but terrible under load points squarely at bufferbloat. Naming the symptom precisely is what tells you which link, and which mechanism, to go fix, the subject of the final guide in this rung.