Round Trip Time (RTT) Nedir? Nasıl Ölçülür ve Düşürülür?

İnternet bağlantınız saniyede yüzlerce megabit indirebiliyor olabilir; buna rağmen bazı siteler yavaş açılır. Sebep çoğu zaman bant genişliği değil, gecikmedir. Bir web sayfası açılırken tarayıcı ile sunucu arasında çok sayıda kısa mesaj gidip gelir ve her birinin cevabını beklemek zorunda kalınır. Bu gidip gelme süresine Round Trip Time (RTT), Türkçesiyle gidiş-dönüş süresi denir.

RTT, web performansının en az konuşulan ama en temel bileşenlerinden biridir. TTFB, FCP ve LCP gibi metriklerin önemli bir kısmı, aslında kaç gidiş-dönüş yaşandığının ve her birinin ne kadar sürdüğünün sonucudur.

RTT nedir?

RTT, bir veri paketinin kaynaktan hedefe ulaşması ve hedeften gelen cevabın kaynağa geri dönmesi için geçen toplam süredir. Milisaniye cinsinden ifade edilir. Kullanıcının tarayıcısı sunucuya “merhaba” dediğinde, bu mesajın sunucuya varması ve sunucunun “merhaba” cevabının geri gelmesi bir gidiş-dönüştür.

RTT üç bileşenden oluşur:

1. Yayılma gecikmesi: Sinyalin fiziksel mesafeyi kat etmesi için gereken süre. Işık fiber optik kabloda boşluktakinden daha yavaş, saniyede yaklaşık 200 bin kilometre hızla ilerler. Bu, her bin kilometre için tek yönde yaklaşık 5 milisaniye demektir. Bu süre hiçbir optimizasyonla kısaltılamaz; yalnızca mesafe azaltılarak düşürülebilir.
2. Yönlendirme ve kuyruk gecikmesi: Paketin yol boyunca geçtiği her yönlendiricide işlenmesi ve yoğunluk varsa sırada beklemesi.
3. İşleme gecikmesi: Hedef cihazın paketi alıp cevabı hazırlaması.

Pratikte kablolar düz bir çizgide döşenmediği ve paketler çok sayıda noktadan geçtiği için gerçek RTT, teorik değerin belirgin biçimde üzerindedir.

RTT, gecikme ve ping arasındaki fark

Gecikme (latency) genellikle tek yönlü süreyi ifade eder: paketin bir noktadan diğerine ulaşması. RTT ise iki yönü ve aradaki işlem süresini kapsar. Kabaca RTT, tek yönlü gecikmenin iki katı ile işlem süresinin toplamıdır. Günlük kullanımda iki terim sıkça birbirinin yerine kullanılır; web performansı bağlamında genellikle kastedilen RTT’dir.

Ping ise bir ölçüm aracıdır: bir sunucuya küçük bir kontrol paketi gönderip cevabın ne kadar sürede geldiğini gösterir. Yani ping, RTT’yi ölçmenin en yaygın yoludur. Ancak bazı sunucular güvenlik gerekçesiyle ping paketlerine cevap vermez; bu durumda ping sonucunun alınamaması sunucunun kapalı olduğu anlamına gelmez.

Bant genişliği ile gecikme aynı şey değil

Bant genişliği, birim zamanda taşınabilecek veri miktarıdır; gecikme ise verinin yolda geçirdiği süredir. İkisini bir otoyolla düşünebilirsiniz: bant genişliği şerit sayısıdır, gecikme ise yolun uzunluğu. Şerit sayısını artırmak daha fazla aracın aynı anda gitmesini sağlar ama yolu kısaltmaz. Web sayfaları çok sayıda küçük dosyadan oluştuğu ve her biri için karşılıklı mesajlaşma gerektiği için, belirli bir noktadan sonra bant genişliğini artırmak sayfayı hızlandırmaz; gecikme belirleyici hâle gelir.

Bir web sayfası açılırken kaç gidiş-dönüş yaşanır?

Bu, RTT’nin site hızı açısından neden bu kadar önemli olduğunu anlamanın anahtarıdır. Kullanıcı daha önce hiç bağlanmadığı bir siteye girdiğinde, tarayıcının ilk baytı alabilmesi için şu adımlar yaşanır:

1. DNS çözümlemesi: Alan adının IP adresini öğrenmek için en az bir gidiş-dönüş (önbellekte yoksa).
2. TCP bağlantısı: Bağlantıyı açmak için bir gidiş-dönüş.
3. TLS el sıkışması: Güvenli bağlantı için TLS 1.3’te bir, eski TLS 1.2’de iki gidiş-dönüş.
4. HTTP isteği: Sayfayı isteyip ilk baytı almak için bir gidiş-dönüş.

Toplamda dört ile beş gidiş-dönüş. RTT 50 milisaniye olan masaüstü bir bağlantıda bu yaklaşık 200-250 milisaniye eder. RTT 150 milisaniye olan bir mobil bağlantıda ise sunucu anında cevap verse bile 600-750 milisaniye harcanır. Google’ın Core Web Vitals değerlendirmesinde mobilin neden daha zor olduğunun bir sebebi de budur. Bu arada Lighthouse’un mobil testlerinde kullandığı simülasyon da yaklaşık 150 milisaniyelik bir RTT varsayar.

Üstelik bu yalnızca ilk belge içindir. Sayfa, farklı alan adlarından (yazı tipi sağlayıcısı, analitik, reklam, sohbet balonu, görsel CDN’i) kaynak yüklüyorsa, her yeni alan adı için DNS, TCP ve TLS adımları yeniden yaşanır.

Yönlendirmelerin RTT maliyeti

Her yönlendirme en az bir ek gidiş-dönüş demektir; yönlendirme başka bir alan adına gidiyorsa bağlantı adımları da baştan başlar. HTTP’den HTTPS’e, oradan www’li adrese, oradan da kampanya sayfasına giden bir reklam bağlantısı, mobilde kullanıcı hiçbir şey görmeden bir saniyeye yakın süre kaybettirebilir. Yönlendirme zincirlerinin temizlenmesini URL yönlendirmeleri rehberimizde anlattık.

14 KB kuralı: ilk gidiş-dönüşte ne gelir?

TCP, yeni bir bağlantıda veriyi temkinli başlatır; ilk gidiş-dönüşte yalnızca sınırlı miktarda veri gönderir ve her başarılı turda miktarı artırır. Bu mekanizmaya yavaş başlangıç (slow start) denir. Yaygın ayarlarda ilk turda yaklaşık 14 KB’lık sıkıştırılmış veri gönderilebilir.

Bunun pratik anlamı şudur: sayfanın ilk ekranını çizmek için gereken HTML ve kritik CSS ilk 14 KB’a sığarsa, tarayıcı ilk turda çizime başlayabilir. Sığmazsa ek gidiş-dönüşler gerekir. Bu yüzden kritik CSS’i satır içine alırken ölçülü olmak ve HTML’in başını şişirmemek önemlidir. Kural kesin bir sınır değil, bir yön göstericidir; ama gecikmesi yüksek bağlantılarda farkı belirgin biçimde hissedilir.

HTTP/2 ve HTTP/3 RTT’yi nasıl etkiler?

HTTP/1.1 döneminde tarayıcılar aynı sunucuya birkaç paralel bağlantı açar ve her bağlantı için el sıkışma maliyetini ayrı ayrı öderdi. HTTP/2, tek bir bağlantı üzerinden çok sayıda dosyayı paralel taşıyarak bu maliyeti ortadan kaldırdı. Ancak HTTP/2 hâlâ TCP üzerinde çalıştığı için, tek bir paket kaybolduğunda o bağlantıdaki tüm dosyalar bekler.

HTTP/3, TCP yerine QUIC adlı protokolü kullanır. QUIC, bağlantı kurulumu ile güvenlik el sıkışmasını birleştirerek yeni bir bağlantıyı tek bir gidiş-dönüşte açar. Daha önce bağlanılmış sunuculara ise veri gönderimine sıfır gidiş-dönüşle başlanabilir (0-RTT). Ayrıca paket kayıplarında yalnızca etkilenen dosya bekler. Bu özellikler özellikle yüksek gecikmeli ve kayıplı mobil ağlarda belirgin kazanç sağlar.

RTT nasıl ölçülür?

Ping

Komut satırında ping alanadi.com komutu, sunucuya gönderilen kontrol paketlerinin gidiş-dönüş süresini milisaniye olarak gösterir. Birkaç ölçümün ortalaması, en düşük ve en yüksek değerleri ile kayıp oranı birlikte verilir. En yüksek ile en düşük arasındaki fark büyükse bağlantı dalgalıdır (jitter).

Traceroute ve MTR

traceroute (Windows’ta tracert), paketin hedefe giderken geçtiği her ara noktayı ve her noktaya kadar geçen süreyi listeler. Gecikmenin yolun neresinde arttığını görmek için kullanılır. MTR gibi araçlar ping ile traceroute’u birleştirerek her ara noktadaki gecikme ve kayıp oranını sürekli izler.

Tarayıcı geliştirici araçları

Chrome geliştirici araçlarının ağ panelinde bir isteğin “Timing” sekmesi, DNS, ilk bağlantı ve SSL sürelerini ayrı ayrı gösterir. “İlk bağlantı” ve “SSL” kalemleri, doğrudan gidiş-dönüş sayısı ile RTT’nin çarpımıdır. Ağ panelindeki hız sınırlama özelliğiyle yüksek gecikmeli bir mobil bağlantı simüle edilerek sayfanın bu koşullarda nasıl davrandığı test edilebilir.

Tarayıcının ağ bilgisi

Chromium tabanlı tarayıcılar, Network Information API aracılığıyla kullanıcının tahmini RTT değerini sayfaya sunar (navigator.connection.rtt). Değer gizlilik amacıyla yuvarlanır ve tüm tarayıcılarda desteklenmez; ancak gerçek kullanıcı ölçümü yapan siteler için ziyaretçilerin ağ koşullarını anlamada yardımcıdır. Bu bilgiyle yüksek gecikmeli kullanıcılara daha hafif bir deneyim sunmak da mümkündür.

Çok noktalı test araçları

WebPageTest gibi araçlar, farklı şehirlerden ve farklı bağlantı profilleriyle test yaparak coğrafi gecikme farklarını görünür kılar. Kullanıcılarınız farklı bölgelerdeyse tek bir noktadan yapılan ölçüm yanıltıcıdır.

İyi bir RTT değeri kaçtır?

RTT için Google’ın tanımladığı resmî bir eşik yoktur; değer büyük ölçüde mesafeye ve bağlantı türüne bağlıdır. Genel bir yön gösterici olarak web kullanımı için şu aralıklar kullanılabilir:

1. 50 milisaniyenin altı: Çok iyi. Kullanıcı ile sunucu aynı ülkede ve kaliteli bir bağlantıda.
2. 50-100 milisaniye: İyi. Çoğu web kullanımı için sorunsuz.
3. 100-200 milisaniye: Belirgin. Özellikle çok sayıda alan adından kaynak yükleyen sayfalarda gecikme hissedilir.
4. 200 milisaniyenin üzeri: Yüksek. Uzak sunucular, uydu bağlantıları veya zayıf mobil sinyalde görülür.

Burada önemli olan mutlak değerden çok, gidiş-dönüş sayısıyla çarpımıdır. 100 milisaniyelik RTT, 3 gidiş-dönüşte 300 milisaniye, 15 gidiş-dönüşte bir buçuk saniye eder.

RTT’nin site hızına etkisi nasıl azaltılır?

RTT’yi iki yoldan azaltabilirsiniz: her gidiş-dönüşü kısaltarak veya gidiş-dönüş sayısını azaltarak.

Her gidiş-dönüşü kısaltmak

1. İçerik dağıtım ağı (CDN) kullanın. Kullanıcıya yakın bir kenar sunucusu, yayılma gecikmesini doğrudan düşürür. En büyük kazanç, HTML dahil tüm içeriğin kenar sunucularından verilmesiyle elde edilir.
2. Sunucu konumunu kitlenize göre seçin. Kullanıcılarınızın çoğu Türkiye’deyse, uzak bir kıtadaki sunucu her gidiş-dönüşe onlarca milisaniye ekler.
3. Hızlı bir DNS sağlayıcısı kullanın. DNS çözümlemesi de bir gidiş-dönüştür.

Gidiş-dönüş sayısını azaltmak

1. Yönlendirmeleri kaldırın. Her yönlendirme en az bir tur demektir.
2. Alan adı sayısını azaltın. Kritik kaynakları mümkün olduğunca kendi alan adınızdan sunun; yazı tiplerini kendi sunucunuzda barındırmak buna iyi bir örnektir.
3. Bağlantıları önceden kurun. Kaçınılmaz üçüncü taraf alan adları için preconnect ile DNS, TCP ve TLS adımlarını sayfa yüklenirken erkenden tamamlatın.
4. Güncel protokolleri açın. TLS 1.3 bir tur, HTTP/3 bir tur daha kazandırır. Oturum sürdürme (session resumption) sayesinde tekrar ziyaretlerde el sıkışma kısalır.
5. Bağlantıları yeniden kullanın. HTTP/2 ve kalıcı bağlantılar, aynı sunucuya giden istekler için yeniden el sıkışmayı önler.
6. Kritik istek zincirini kısaltın. Birbirini bekleyen dosyalar (CSS içinden çağrılan CSS, CSS içinden keşfedilen yazı tipi) her halkada bir tur ekler.
7. 103 Early Hints kullanın. Sunucu sayfayı hazırlarken tarayıcı kritik dosyaları indirmeye başlar; bekleme süresi boşa gitmez.
8. Tarayıcı önbelleğinden yararlanın. Önbellekten gelen dosya için hiç gidiş-dönüş yaşanmaz; geri-ileri önbelleği ise tüm sayfayı ağa gitmeden gösterir.

RTT ve SEO

RTT doğrudan bir sıralama faktörü değildir ve Search Console’da ayrı bir rapor olarak yer almaz. Ancak etkisi dolaylı olarak her yerde görünür: yüksek RTT, TTFB’yi uzatır; uzayan TTFB, FCP ve LCP’yi geciktirir; LCP ise Google’ın doğruladığı sayfa deneyimi sinyallerinden biridir. Doğrulanmış faktörlerin genel tablosunu sıralama faktörleri yazımızda bulabilirsiniz.

Ayrıca Googlebot’un sunucunuza ulaşırken yaşadığı gecikme, tarama hızını etkiler. Sunucunuz Googlebot’un tarama noktalarından çok uzaksa ve yanıt süreleri yüksekse, Google siteyi daha temkinli tarar.

RTT’yi etkileyen faktörler

Fiziksel mesafe: En belirleyici ve değiştirilemeyen faktördür. Kullanıcı ile sunucu arasındaki her bin kilometre, gidiş-dönüşe teorik olarak en az 10 milisaniye ekler; gerçek hatlarda bu değer daha yüksektir.

Bağlantı türü: Fiber ve kablolu bağlantılar düşük ve kararlı gecikme sunar. Mobil ağlarda gecikme hem daha yüksek hem daha değişkendir; telefon uyku modundan uyanırken veya baz istasyonu değiştirirken ek gecikme yaşanır. Uydu bağlantıları, sinyalin uzaya gidip gelmesi nedeniyle en yüksek gecikmeye sahiptir.

Ağ yoğunluğu: Yoğun saatlerde yönlendiricilerdeki kuyruklar uzar ve paketler sırada bekler. Aynı sitenin akşam saatlerinde daha yavaş açılmasının bir sebebi budur.

Yönlendirme verimliliği: Paketlerin izlediği yol her zaman en kısa yol değildir. İnternet servis sağlayıcılarının birbirleriyle nerede bağlandığı, paketin gereksiz yere başka bir ülkeden dolaşıp dolaşmayacağını belirler.

Sunucu yükü: Aşırı yüklenmiş bir sunucu, gelen paketleri işlemekte gecikir; bu, RTT’nin işlem bileşenini artırır.

Ev ve ofis ağı: Kablosuz ağ sinyalinin zayıflığı, aynı ağdaki yoğun kullanım (büyük dosya indirmeleri, görüntülü görüşmeler) ve eski modemler de ölçülen gecikmeyi etkiler. Bu yüzden kendi bilgisayarınızda yaptığınız ölçüm, kullanıcılarınızın deneyimini temsil etmeyebilir.

Jitter ve paket kaybı

Ortalama RTT tek başına tabloyu anlatmaz. Jitter, ardışık ölçümler arasındaki dalgalanmadır; ortalaması 60 milisaniye olan ama 20 ile 300 arasında gidip gelen bir bağlantı, sabit 80 milisaniyelik bir bağlantıdan daha kötü bir deneyim yaratır. Paket kaybı ise bazı paketlerin hedefe hiç ulaşmamasıdır; TCP kaybolan paketi yeniden gönderir ve bu, en az bir ek gidiş-dönüş demektir. Kayıplı mobil ağlarda sayfaların beklenmedik biçimde takılmasının sebebi genellikle budur. HTTP/3’ün kayıplı ağlarda daha iyi performans göstermesinin nedeni de, bir paketin kaybının diğer dosyaları bekletmemesidir.

Varsayımsal bir hesap: üçüncü taraf alan adlarının maliyeti

RTT’nin gidiş-dönüş sayısıyla nasıl katlandığını bir örnekle görelim. Rakamlar örnek amaçlıdır.

Bir sayfa, kendi alan adının yanında yazı tipi sağlayıcısı, analitik aracı, reklam sunucusu, sohbet balonu ve görsel CDN’i olmak üzere beş farklı alan adından kaynak yüklüyor. Mobil kullanıcının RTT’si 120 milisaniye. Her yeni alan adı için DNS, TCP ve TLS adımları yaklaşık üç gidiş-dönüş tutuyor: 360 milisaniye. Bu bağlantıların bir kısmı paralel kurulsa bile, kritik olanlar (yazı tipi ve görsel CDN’i) sayfanın çizimini doğrudan bekletiyor.

Yazı tiplerini kendi alan adına taşımak ve görsel CDN’i için preconnect eklemek, kritik yoldan iki tam bağlantı kurulumunu çıkarır. Sonuç, sunucu veya dosya boyutu tarafında hiçbir değişiklik yapmadan ilk ekranın yüzlerce milisaniye erken çizilmesidir. Bu tür kazançların FCP ve LCP üzerindeki etkisini ilgili yazılarımızda ayrıntılı anlattık.

Sık yapılan hatalar

1. Hız sorununu yalnızca bant genişliğiyle açıklamak. Hızlı internetli kullanıcılar da yüksek gecikmede yavaşlık yaşar.
2. Sunucuyu yalnızca fiyata göre seçmek. Kitleden uzak bir sunucu, her ziyarette sabit bir gecikme vergisi ödetir.
3. Her üçüncü taraf alan adına preconnect eklemek. Kullanılmayan bağlantılar kaynak israfıdır; yalnızca kritik iki-üç alan adı seçilmelidir.
4. Yalnızca ofis bağlantısından ölçmek. Kullanıcıların mobil ağdaki deneyimi çok farklıdır.
5. Ping cevabı alınamadığında sunucuyu kapalı sanmak. Birçok sunucu güvenlik gerekçesiyle ping paketlerini yanıtlamaz.

RTT kontrol listesi

1. Sunucu veya CDN kenar noktası kullanıcılarınıza coğrafi olarak yakın mı?
2. HTML dahil içerik CDN kenarından sunuluyor mu?
3. İç bağlantılar ve reklam hedefleri yönlendirmesiz mi?
4. Kritik kaynaklar kaç farklı alan adından geliyor; azaltılabilir mi?
5. Kaçınılmaz kritik alan adları için preconnect var mı?
6. TLS 1.3 ve HTTP/3 açık mı?
7. Kritik HTML ve CSS ilk gidiş-dönüşe sığacak ölçüde mi?
8. Statik dosyalar uzun süreli tarayıcı önbelleğiyle sunuluyor mu?
9. Testler mobil gecikme simülasyonuyla ve farklı konumlardan yapılıyor mu?

Mobil ağlarda RTT neden daha yüksek?

Mobil bağlantılarda veri, telefondan baz istasyonuna, oradan operatörün çekirdek ağına ve ancak ondan sonra internete çıkar. Bu ek halkalar gecikmeyi artırır. Buna ek olarak telefonlar pil tasarrufu için radyo modülünü düşük güç moduna alır; bir süre işlem yapılmadıktan sonra gelen ilk istek, radyonun yeniden etkinleşmesini bekler ve ilk gidiş-dönüş belirgin biçimde uzar. Kullanıcı hareket hâlindeyse baz istasyonu değişimleri ve sinyal dalgalanmaları jitter ile paket kaybını artırır.

Bu yüzden hız hedeflerini masaüstü değil mobil koşullara göre belirlemek gerekir. Mobil ziyaretçi oranı yüksek sitelerde gidiş-dönüş sayısını azaltmaya yönelik her düzenleme, masaüstünde fark edilmeyen ama mobilde belirgin biçimde hissedilen bir kazanç sağlar. Hızın dönüşüm ve sıralamayla ilişkisini site hızı yazımızda ele aldık.

Özetle

RTT, bir veri paketinin sunucuya gidip cevabının geri gelmesi için geçen süredir ve web performansının görünmeyen temelidir. Yeni bir güvenli bağlantıyla sayfa açılırken ilk bayttan önce dört-beş gidiş-dönüş yaşanır; bu yüzden mobilde gecikmenin etkisi katlanır. RTT’nin etkisi iki yoldan azaltılır: CDN ve doğru sunucu konumuyla her turu kısaltmak; yönlendirmeleri kaldırarak, alan adı sayısını düşürerek, bağlantıları önceden kurarak ve güncel protokolleri açarak tur sayısını azaltmak. Hız altyapınızı bütüncül planlamak için SEO hizmetimizi inceleyebilirsiniz.