Gecikme (Latency) Nedir?

Gecikme, bant genişliği ve throughput

Bu üç kavram günlük dilde “internet hızı” başlığı altında birbirine karışır, ama farklı şeyleri ölçerler. Bir boru benzetmesi işe yarar: bant genişliği borunun çapı, gecikme borunun uzunluğu, throughput ise borudan saniyede fiilen akan su miktarıdır.

Throughput hiçbir zaman bant genişliğini aşamaz ve çoğu zaman ondan düşüktür; paket kaybı, sıkışıklık ve gecikmenin kendisi onu aşağı çeker. Sunucu tarafında throughput aynı zamanda bir sistemin birim zamanda işleyebildiği istek sayısını da anlatır. Gecikme ile throughput birbirine bağlıdır ama aynı şey değildir: bir API saniyede binlerce isteği işleyebilir (yüksek throughput) ve yine de her biri 800 ms sürebilir (yüksek gecikme).

Neden bant genişliğini artırmak her zaman hızlandırmaz?

Büyük bir video dosyasını indirmek bant genişliğiyle sınırlıdır. Bir web sayfası ise çoğunlukla birbirini bekleyen çok sayıda küçük istekten oluşur: HTML gelmeden CSS'in adresi bilinmez, CSS gelmeden fontun adresi bilinmez. Bu zincirde her halka en az bir gidiş-dönüş bekler ve aboneliği 100 Mbps'den 1 Gbps'ye çıkarmak bu bekleme sürelerini kısaltmaz.

Gecikmenin fiziksel bir tabanı da vardır. Işık fiber optik kabloda saniyede yaklaşık 200.000 km yol alır; yani 1.000 km'lik bir hat tek yönde en az 5 ms, gidiş-dönüşte en az 10 ms ekler. Gerçek kablo güzergâhları kuş uçuşundan uzun olduğu ve yol boyunca yönlendiriciler bulunduğu için ölçülen değerler bunun üzerindedir. Türkiye'deki bir ziyaretçiye ABD'deki bir sunucudan hizmet vermek, sunucu ne kadar hızlı olursa olsun her gidiş-dönüşe onlarca, çoğu zaman yüz milisaniyeyi aşan bir süre ekler.

Bir web isteğinde gecikme nerede birikir?

Daha önce bağlantı kurulmamış bir sunucuya yapılan ilk HTTPS isteği, içerik gelmeden önce birkaç gidiş-dönüş harcar:

1. DNS çözümleme: Alan adının IP adresine çevrilmesi (önbellekte değilse).
2. TCP bağlantısı: Üçlü el sıkışma, bir RTT.
3. TLS el sıkışması: TLS 1.3'te bir RTT, TLS 1.2'de iki RTT.
4. İstek ve yanıt: Bir RTT artı sunucunun işlem süresi; bu toplamın tarayıcıdaki karşılığı TTFB'dir.

RTT'nin 100 ms olduğu bir bağlantıda bu, sunucu tek milisaniye harcamasa bile ilk bayttan önce 300–400 ms demektir. Araya bir yönlendirme zinciri girerse, özellikle başka bir alan adına yapılan yönlendirmelerde, bu maliyet bir kez daha ödenir. HTTP/3'ün kullandığı QUIC protokolü taşıma ve şifreleme el sıkışmalarını birleştirerek bu turlardan birini ortadan kaldırır.

Ortalamaya değil yüzdelik dilimlere bakın

Gecikme dağılımı simetrik değildir: isteklerin çoğu hızlıdır, küçük bir kısmı çok yavaştır. Ortalama bu kuyruğu gizler. Bu yüzden gecikme genellikle yüzdelik dilimlerle raporlanır: p50 (ortanca) tipik deneyimi, p95 ve p99 ise en kötü deneyimi yaşayan kullanıcıları gösterir. Bir sayfa açılırken arka planda on farklı servise istek atılıyorsa, sayfanın hızını en yavaş yanıt belirler; tek tek servislerin p99 değeri, sayfa düzeyinde sık karşılaşılan bir duruma dönüşür.

Gecikmeyi azaltmanın yolları

• İçeriği kullanıcıya yaklaştırın: CDN ve edge function'lar yanıtı kullanıcıya coğrafi olarak yakın bir noktadan verir.
• Tur sayısını azaltın: Gereksiz yönlendirmeleri kaldırın, kritik kaynakları HTML içinde erken keşfedilebilir yapın, istek zincirlerini kısaltın.
• Bağlantıları yeniden kullanın: HTTP/2 ve HTTP/3 tek bağlantı üzerinden çok sayıda istek taşır; üçüncü taraf alan adları için preconnect bağlantı kurulumunu öne çeker.
• Sunucu tarafını ölçün: Veritabanı sorguları, harici API çağrıları ve soğuk başlatmalar da gecikmenin parçasıdır; bunlar ağ ayarlarıyla çözülmez.
• Önbelleğe alın: Hiç yapılmayan istek, gecikmesi sıfır olan istektir.