Cele trei descriu lucruri diferite și sunt confundate constant. Latency este întârziere — cât durează ca o unitate de date să călătorească de la A la B (măsurată în timp, ex. ms). Bandwidth este capacitate — rata maximă de date pe care o poate transporta o legătură (ex. Gbps). este rata pe care o obții în practică, de obicei sub bandwidth. O analogie cu o conductă face totul clar:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Crucial, o conductă mai lată nu o face mai scurtă: adăugarea de bandwidth nu reduce latency. O legătură transatlantică groasă tot are ~80 ms de latență round-trip dictată de distanță și de viteza luminii — nu poți plăti ca să cobori sub ea. De aceea latency, nu bandwidth, domină senzația aplicațiilor interactive: fiecare round trip (DNS, TCP handshake, TLS, apoi cererea) plătește taxa de latență, și se adună.
Latency și throughput interacționează prin Bandwidth-Delay Product (BDP = bandwidth × round-trip time), cantitatea de date „în zbor” necesară pentru a menține o conductă plină. Pe o „long fat network” cu bandwidth mare și latență mare, un protocol precum TCP care așteaptă ACK-uri nu poate umple conducta decât dacă fereastra sa este cel puțin BDP-ul — deci throughput-ul ajunge limitat de latency, nu de bandwidth. De aceea un singur stream TCP pe o distanță mare subperformează adesea chiar și pe o legătură rapidă, și de aceea paralelismul, ferestrele mai mari și CDN-urile (care taie distanța, deci latența) ajută.
Confundarea acestor trei este una dintre cele mai comune — și mai consecvente — greșeli de performanță: echipele cumpără mai mult bandwidth pentru a repara ceea ce e de fapt o problemă de latență și nu văd nicio îmbunătățire. Intuiția de senior este că latency este un prag stabilit de fizică (distanță) pe care îl ataci arhitectural — pune servere/CDN-uri mai aproape de utilizatori, reduce round trips (reutilizarea conexiunilor, HTTP/3, caching) și grupează cererile — în timp ce bandwidth este ceva ce adesea doar poți provisiona. Înțelegerea BDP explică rezultate contraintuitive precum o legătură „rapidă” care livrează transferuri lente pe un singur stream, exact tipul de raționament așteptat când proiectezi sau depanezi sisteme de înaltă performanță, distribuite geografic.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează