Bu üçü farklı şeyleri tanımlar ve sürekli birbirine karıştırılır. Latency gecikmedir — bir birim verinin A'dan B'ye gitmesinin ne kadar sürdüğü (zamanla ölçülür, örn. ms). Bandwidth kapasitedir — bir linkin taşıyabileceği maksimum veri hızı (örn. Gbps). ise pratikte elde ettiğiniz hızdır, ki genellikle bandwidth'in altındadır. Bir boru benzetmesi durumu netleştirir:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Çok önemlisi, daha geniş bir boru onu daha kısa yapmaz: bandwidth eklemek latency'yi azaltmaz. Şişman bir transatlantik link hâlâ mesafe ve ışık hızının dayattığı ~80 ms round-trip latency'ye sahiptir — bunun altına para vererek inemezsiniz. İşte bu yüzden interaktif uygulamaların hissini bandwidth değil latency belirler: her round trip (DNS, TCP handshake, TLS, sonra istek) latency bedelini öder ve bunlar birikir.
Latency ve throughput, Bandwidth-Delay Product (BDP = bandwidth × round-trip time) aracılığıyla etkileşir; bu, bir boruyu dolu tutmak için "uçuşta" olması gereken veri miktarıdır. Yüksek bandwidth'li, yüksek latency'li "uzun şişman bir ağ"da, ACK'leri bekleyen TCP gibi bir protokol, penceresi en az BDP olmadıkça boruyu dolduramaz — böylece throughput sonunda bandwidth değil, latency ile sınırlanır. İşte bu yüzden uzun mesafeli tek bir TCP stream'i, hızlı bir linkte bile çoğu zaman yetersiz performans gösterir ve paralellik, daha büyük pencereler ile CDN'ler (mesafeyi, dolayısıyla latency'yi kısaltan) yardımcı olur.
Bu üçünü birbirine karıştırmak en yaygın — ve en sonuç doğuran — performans hatalarından biridir: ekipler aslında bir latency problemi olan şeyi düzeltmek için daha çok bandwidth satın alır ve hiçbir iyileşme görmez. Senior içgörü şudur: latency, fizik (mesafe) tarafından belirlenen bir tabandır ki ona mimari olarak saldırırsınız — sunucuları/CDN'leri kullanıcılara yaklaştır, round trip'leri azalt (bağlantı yeniden kullanımı, HTTP/3, caching) ve istekleri gruplandır — bandwidth ise çoğu zaman basitçe sağlayabileceğiniz bir şeydir. BDP'yi anlamak, "hızlı" bir linkin yavaş tek-stream aktarımları sunması gibi sezgiye aykırı sonuçları açıklar ki bu, yüksek performanslı, coğrafi olarak dağıtık sistemler tasarlarken veya hata ayıklarken beklenen türden bir akıl yürütmedir.
Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap