Disse tre beskriver forskellige ting og forveksles konstant. Latency er forsinkelse — hvor lang tid én enhed af data tager at rejse fra A til B (målt i tid, fx ms). Bandwidth er kapacitet — den maksimale datarate, et link kan bære (fx Gbps). Throughput er den rate, du opnår i praksis, som normalt er under bandwidth. En rør-analogi får det til at klikke:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Afgørende gør et bredere rør det ikke kortere: at tilføje bandwidth reducerer ikke latency. Et fedt transatlantisk link har stadig ~80 ms round-trip-latency dikteret af afstand og lysets hastighed — du kan ikke købe dig under den. Det er derfor, latency, ikke bandwidth, dominerer følelsen af interaktive apps: hvert round trip (DNS, TCP-handshake, TLS, så request'en) betaler latency-afgiften, og de lægges sammen.
Latency og throughput interagerer gennem Bandwidth-Delay Product (BDP = bandwidth × round-trip time), mængden af data "undervejs" for at holde et rør fyldt. På et "long fat network" med høj bandwidth og høj latency kan en protokol som TCP, der venter på ACKs, ikke fylde røret, medmindre dens vindue er mindst BDP'en — så throughput ender med at være begrænset af latency, ikke bandwidth. Det er derfor, én TCP-stream over lang afstand ofte underpræsterer selv på et hurtigt link, og hvorfor parallelisme, større vinduer og CDN'er (som skærer afstand og dermed latency) hjælper.
At sammenblande disse tre er en af de mest almindelige — og mest betydningsfulde — performance-fejl: teams køber mere bandwidth for at rette, hvad der reelt er et latency-problem, og ser ingen forbedring. Senior-indsigten er, at latency er et gulv sat af fysik (afstand), som du angriber arkitektonisk — placér servere/CDN'er tættere på brugere, reducér round trips (genbrug af forbindelser, HTTP/3, caching) og batch requests — mens bandwidth ofte er noget, du bare kan provisionere. At forstå BDP forklarer kontraintuitive resultater som et "hurtigt" link, der leverer langsomme single-stream-overførsler, hvilket er præcis den slags ræsonnement, der forventes, når du designer eller fejlfinder højtydende, geografisk distribuerede systemer.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér