Deze drie beschrijven verschillende dingen en worden voortdurend verward. Latency is vertraging — hoe lang één eenheid data erover doet om van A naar B te reizen (gemeten in tijd, bijv. ms). Bandwidth is capaciteit — de maximale datasnelheid die een link kan dragen (bijv. Gbps). is de snelheid die je in de praktijk haalt, meestal onder de bandwidth. Een pijp-analogie maakt het duidelijk:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Cruciaal: een bredere pijp maakt hem niet korter: bandwidth toevoegen vermindert latency niet. Een dikke transatlantische link heeft nog steeds ~80 ms round-trip-latency, bepaald door afstand en de lichtsnelheid — je kunt je er niet onderuit kopen. Daarom domineert latency, niet bandwidth, het gevoel van interactieve apps: elke round trip (DNS, TCP-handshake, TLS, dan de request) betaalt de latency-tol, en ze tellen op.
Latency en throughput interacteren via het Bandwidth-Delay Product (BDP = bandwidth × round-trip time), de hoeveelheid data "in flight" om een pijp vol te houden. Op een "long fat network" met hoge bandwidth en hoge latency kan een protocol als TCP dat op ACK's wacht de pijp niet vullen tenzij zijn window minstens de BDP is — dus throughput wordt uiteindelijk begrensd door latency, niet bandwidth. Daarom presteert één TCP-stream over een lange afstand vaak onder de maat, zelfs op een snelle link, en daarom helpen parallellisme, grotere windows, en CDN's (die afstand, en dus latency, verkleinen).
Deze drie verwarren is een van de meest voorkomende — en meest ingrijpende — performance-fouten: teams kopen meer bandwidth om iets op te lossen dat eigenlijk een latency-probleem is en zien geen verbetering. Het senior-inzicht is dat latency een vloer is die door de natuurkunde wordt bepaald (afstand) en die je architectonisch aanpakt — servers/CDN's dichter bij gebruikers plaatsen, round trips verminderen (connectiehergebruik, HTTP/3, caching), en requests batchen — terwijl bandwidth iets is dat je vaak gewoon kunt bijprovisionen. Het BDP begrijpen verklaart contra-intuïtieve resultaten zoals een "snelle" link die trage single-stream-overdrachten levert, precies het soort redeneren dat verwacht wordt wanneer je high-performance, geografisch gedistribueerde systemen ontwerpt of debugt.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren