Te trzy opisują różne rzeczy i są nieustannie mylone. Latency (opóźnienie) to zwłoka — jak długo jedna jednostka danych podróżuje z A do B (mierzona w czasie, np. ms). Bandwidth (przepustowość łącza) to pojemność — maksymalne tempo danych, jakie łącze może przenieść (np. Gbps). (przepustowość osiągana) to tempo, jakie uzyskujesz w praktyce, zwykle poniżej bandwidth. Analogia rury sprawia, że to zaskakuje:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Co kluczowe, szersza rura nie czyni jej krótszą: dodanie bandwidth nie zmniejsza latency. Grube łącze transatlantyckie wciąż ma ~80 ms opóźnienia w obie strony podyktowanego odległością i prędkością światła — nie da się kupić drogi pod to. Dlatego to latency, a nie bandwidth, dominuje odczucie aplikacji interaktywnych: każda runda tam i z powrotem (DNS, TCP handshake, TLS, potem żądanie) płaci haracz latency, a one się sumują.
Latency i throughput oddziałują przez Bandwidth-Delay Product (BDP = bandwidth × round-trip time), ilość danych „w locie" potrzebną, aby utrzymać rurę pełną. Na wysokoprzepustowym, wysokoopóźnieniowym „long fat network" protokół jak TCP, który czeka na ACK-i, nie może wypełnić rury, chyba że jego okno jest co najmniej równe BDP — więc throughput kończy jako ograniczony przez latency, a nie bandwidth. Dlatego jeden strumień TCP na dużą odległość często osiąga słabe wyniki nawet na szybkim łączu i dlaczego pomagają równoległość, większe okna i CDN-y (które skracają odległość, a więc latency).
Mylenie tych trzech to jeden z najczęstszych — i najbardziej brzemiennych w skutki — błędów wydajnościowych: zespoły kupują więcej bandwidth, aby naprawić to, co naprawdę jest problemem latency, i nie widzą poprawy. Spostrzeżenie seniora jest takie, że latency to podłoga ustawiona przez fizykę (odległość), którą atakujesz architektonicznie — umieść serwery/CDN-y bliżej użytkowników, redukuj rundy tam i z powrotem (ponowne użycie połączeń, HTTP/3, caching) i grupuj żądania — podczas gdy bandwidth to często coś, co możesz po prostu doprowizjonować. Zrozumienie BDP wyjaśnia kontrintuicyjne wyniki, jak „szybkie" łącze dostarczające wolne transfery jednostrumieniowe, czyli dokładnie ten rodzaj rozumowania oczekiwany, gdy projektujesz lub debugujesz wysokowydajne, geograficznie rozproszone systemy.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj