Disse tre beskriver forskjellige ting og forveksles stadig. Latency er forsinkelse — hvor lang tid én dataenhet bruker på å reise fra A til B (målt i tid, f.eks. ms). Bandwidth er kapasitet — den maksimale dataraten en lenke kan bære (f.eks. Gbps). er den raten du oppnår i praksis, som vanligvis ligger under bandwidth. En rør-analogi får det til å klaffe:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Avgjørende: et bredere rør gjør det ikke kortere — å legge til bandwidth reduserer ikke latency. En tykk transatlantisk lenke har fortsatt ~80 ms round-trip-latency diktert av avstand og lysets hastighet — du kan ikke kjøpe deg under den. Det er derfor latency, ikke bandwidth, dominerer følelsen av interaktive apper: hver round trip (DNS, TCP-handshake, TLS, så forespørselen) betaler latency-avgiften, og de summerer seg.
Latency og throughput samspiller gjennom Bandwidth-Delay Product (BDP = bandwidth × round-trip time), mengden data «underveis» som trengs for å holde et rør fullt. På et «long fat network» med høy bandwidth og høy latency kan en protokoll som TCP, som venter på ACK-er, ikke fylle røret med mindre vinduet er minst BDP — så throughput ender opp begrenset av latency, ikke bandwidth. Det er derfor én TCP-stream over lang avstand ofte underpresterer selv på en rask lenke, og hvorfor parallellitet, større vinduer og CDN-er (som kutter avstand, altså latency) hjelper.
Å blande sammen disse tre er en av de vanligste — og mest følgerike — ytelsesfeilene: team kjøper mer bandwidth for å fikse det som egentlig er et latency-problem, og ser ingen forbedring. Senior-innsikten er at latency er et gulv satt av fysikken (avstand) som du angriper arkitektonisk — plassere servere/CDN-er nærmere brukerne, redusere round trips (gjenbruk av tilkoblinger, HTTP/3, caching) og batche forespørsler — mens bandwidth ofte bare er noe du kan provisjonere. Å forstå BDP forklarer kontraintuitive resultater som at en «rask» lenke leverer trege enkeltstrøm-overføringer, akkurat den typen resonnement som forventes når du designer eller feilsøker høyytelses, geografisk distribuerte systemer.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner