Bandwidth vs Throughput vs Latency vs Jitter

Concrete Example

Take a single satellite internet plan: 200 Mbps bandwidth, 600 ms RTT. One link, one set of numbers, and two workloads that it treats in opposite ways.

Workload A — download a 40 GB game
  transfer  = 40 GB × 8 = 320,000 Mb ÷ 200 Mbps = 1,600 s
  latency   = 0.6 s paid once at the start
  total     ≈ 1,600.6 s        → latency is 0.04% of the job

Workload B — a video call
  every gesture, word and frame waits a full 600 ms round trip
  bandwidth used ≈ 3 Mbps out of 200 available
  total     → unusable, and 2 Gbps would not change it

The same link is excellent and unusable at once. Nothing about the plan changed between the two runs; what changed is which quantity the work depends on. The download is bandwidth-bound — one round trip amortized over 1,600 seconds of streaming bits. The call is latency-bound — thousands of round trips, each paid in full, using a rounding error of the available capacity.

The same split explains the most common disappointment in consumer networking: upgrading a home connection and finding that the web feels identical. A typical page pulls 80 small resources, and the ones that matter arrive over a handful of sequential round trips:

Page load, 100 ms RTT, resources fetched over 10 sequential round trips

  round trips   10 × 100 ms      = 1,000 ms   ← pure waiting
  bytes         2 MB at 100 Mbps =   160 ms

  upgrade 100 Mbps → 1 Gbps:
  round trips   10 × 100 ms      = 1,000 ms   ← unchanged
  bytes         2 MB at 1 Gbps   =    16 ms
                                   ---------
  total 1,160 ms → 1,016 ms       (12% better for 10× the bandwidth)

A tenfold bandwidth increase removed 144 ms from a 1,160 ms page load, because 86% of that page load was never bandwidth at all. It was distance and round trips. This is why so much of modern protocol design is a war on round trips rather than a hunt for capacity: HTTP/2 multiplexing removes serialized requests, connection reuse removes repeated handshakes, TLS 1.3 cuts setup to one round trip, QUIC to zero on resumption, and CDNs attack the RTT itself by moving the content physically closer.

That last one is the deepest point. Propagation delay is distance ÷ ~200,000 km/s, so New York to London is about 28 ms one-way, permanently. No amount of money buys a shorter speed-of-light path. It only buys a shorter distance — which is precisely, and only, what a CDN sells.

Visual Model

Picture a highway between two cities. The number of lanes is your bandwidth — how many cars can travel abreast. The length of the road is your latency — how long any single car takes to get from end to end. The cars actually arriving per hour at the far end is throughput, and how irregularly spaced those arrivals are is jitter.

Now hold the picture and ask the question that settles the whole topic: if you add lanes, does the road get shorter? It does not. You can widen a 3,000 km highway to twelve lanes and every car still drives 3,000 km. That is the entire reason "upgrade to gigabit" so often changes nothing — and the reason the only real fix for a long road is to move the destination closer, which is a CDN.

Drag the two sliders below and watch which numbers move. Adding lanes transforms the bulk transfer and barely touches the interactive page. Shortening the road does the reverse. Watch the third readout especially: with a fixed send window, a long road can cap your throughput far below the lanes you paid for.

The third readout is the one that surprises people. A sender may only keep a limited amount of data unacknowledged — a window. If that window is smaller than the BDP, the sender fills the road, stops, and waits for the far end's acknowledgement to travel all the way back before it may send again. With a 64 KB window and a 600 ms RTT, throughput is pinned near 0.9 Mbps no matter how many lanes exist. The road is wide and long, and mostly empty. That configuration has a name: a long fat network, and it is the cleanest proof that latency limits throughput.