Jaký je rozdíl mezi latency, bandwidth a throughput?

Question

IT Interview Practice · Accepted Answer

Tyto tři popisují různé věci a neustále se pletou. **Latency** je *zpoždění* — jak dlouho trvá jedné jednotce dat cesta z A do B (měří se v čase, např. ms). **Bandwidth** je *kapacita* — maximální datová rychlost, kterou linka unese (např. Gbps). **Throughput** je *skutečná* rychlost, které v praxi dosáhnete, obvykle nižší než bandwidth. Přirovnání k trubce to objasní:

```text
   ├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
   ╔══════════════════════════════════════════════════════════════════════════╗
   ║  width of pipe = BANDWIDTH (max capacity)                                  ║
   ║  water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth)      ║
   ╚══════════════════════════════════════════════════════════════════════════╝
```

Zásadní je, že **širší trubka ji neudělá kratší**: přidání bandwidth nesníží latency. Tlustá transatlantická linka má stále ~80 ms round-trip latency danou vzdáleností a rychlostí světla — pod ni se koupit nedá. Proto pocit z interaktivních aplikací určuje latency, ne bandwidth: každý round trip (DNS, TCP handshake, TLS, pak request) platí daň latency a ty se sčítají.

Latency a throughput se propojují přes **Bandwidth-Delay Product** (BDP = bandwidth × round-trip time), množství dat "v letu" potřebné k naplnění trubky. Na "long fat network" s vysokou bandwidth a vysokou latency nemůže protokol jako TCP, který čeká na ACK, naplnit trubku, dokud není jeho okno alespoň rovné BDP — takže throughput je nakonec *limitován latency*, ne bandwidth. Proto jeden TCP stream na dlouhou vzdálenost často podává slabý výkon i na rychlé lince a proto pomáhá paralelismus, větší okna a CDN (které zkracují vzdálenost, tedy latency).

## Proč je to důležité

Zaměňování těchto tří je jedna z nejčastějších — a nejzávažnějších — výkonnostních chyb: týmy nakoupí víc bandwidth, aby vyřešily to, co je ve skutečnosti problém latency, a nevidí žádné zlepšení. Seniorní vhled je, že **latency je podlaha daná fyzikou** (vzdáleností), na kterou útočíte architektonicky — umístěte servery/CDN blíž uživatelům, snižte počet round tripů (opětovné využití spojení, HTTP/3, caching) a dávkujte requesty — zatímco bandwidth často stačí prostě dokoupit. Pochopení BDP vysvětluje protiintuitivní výsledky jako "rychlá" linka doručující pomalé jednoproudové přenosy, což je přesně ten druh uvažování, který se očekává, když navrhujete nebo ladíte vysoce výkonné, geograficky distribuované systémy.

Proč je to důležité

Související otázky