Bölüm 70: Gecikme Bütçesi

Kayıt elinde ve hangi segmentin ne zaman kaybolduğunu görüyorsun. Tek bir sayı hâlâ eksik: ilk bayt sandığından geç düşüyor.

Bu gecikmenin nerede biriktiğini tahmin etmek yerine ölçebilirsin. Peki o süre hangi kalemlerden toplanıyor?

Fatura hangi kalemlerden çıkıyor?

Ölçünün adı ilk bayta kadar geçen süre (time to first byte, TTFB). Tarayıcının gezinme adımını başlattığı an başlıyor, yanıtın ilk baytı geldiğinde duruyor. Tuşa bastığın anla arasında küçük bir fark var: adres çubuğundaki yazım, öneri listesi ve tarayıcının kendi hazırlığı bu ölçünün dışında kalıyor. İçinde tek bir mekanizma yoktur; yolculuğun her durağı bu sayıya bir şey yazar.

Sayma birimi gidiş-dönüş süresidir. Küçük bir paket sunucuya gidip geri dönene kadar ne kadar geçiyorsa, kalemlerin hepsi o birimin katları olarak yazılır.

Tek bir nesnenin yanıt süresi de üç parçadan oluşuyor. Bağlantıyı kurmak bir gidiş-dönüş, isteği gönderip ilk baytları geri almak bir gidiş-dönüş, dosyanın akması ise ayrı bir süre. İlk bayt bu formülün ikinci turunun sonunda düşüyor. Üçüncü parça ondan sonra başlıyor. Bu yüzden ilk bayt ile sayfanın tamamlanması ayrı iki ölçüdür ve biri iyileşirken öteki bozulabilir.

Somut bir yol kuralım ve sayıları oraya oturtalım. Tek yön uzunluğu 2.000 km olsun. Yayılım hızını 200.000 km/s alalım. Bölme işlemi tek yön için 10 ms veriyor. Gidiş-dönüş 20 ms eder.

Şimdi turları sayalım. Adı adrese çevirmek, cevap resolver’ın önbelleğindeyse bir tur ister; değilse 3. bölümdeki kökten yetkili sunucuya inen zincir buna birkaç tur daha ekler. Hesabı sade tutmak için bir tur sayalım. Bağlantıyı kurmak ikinci turdur ve o tur bittiğinde henüz tek bir uygulama baytı yola çıkmamıştır; 8. bölümdeki üç el sıkışmanın RTT bedeli bu kalemin ta kendisidir. 11. bölümdeki kilidi kurmak üçüncü turdur. İsteği gönderip ilk baytları geri almak dördüncüdür.

Dört tur, 20 ms’lik birimle 80 ms yapıyor. Buna bir de sunucu düşünme süresi ekleniyor; isteği alıp yanıtı hazırlamak için 25 ms koyalım.

Dağılım asıl dersi veriyor. Dört kurulum turu gecikme bütçesinin %76’sını yiyor. Sunucunun payı %24’te kalıyor. Tek başına ad çözme kalemi %19 tutuyor. Sunucu kodunu iki katına hızlandırmak, tek bir turu silmekten daha az kazandırır.

Bu turların hangisi silinebilir?

Sabit sanılan kalem aslında en oynak olanı. Ad çözme kalemi soğukken var, sıcakken yok. Bir resolver öğrendiği eşlemeyi önbelleğine alır ve sonraki sorguyu doğrudan yanıtlar. Girdi, yaşam süresi dolunca silinir. Aynı siteye ikinci girişte o 20 ms çoğu zaman ortadan kalkar.

Bağlantı kalemi de her nesne için yeniden ödenmiyor. Her nesneye ayrı bağlantı kurmak nesne başına iki gidiş-dönüş ve her bağlantı için ayrı bir işletim sistemi yükü demek. Tarayıcılar bu yüzden paralel bağlantı açıyor. Kalıcı bağlantı ise kurulum turunu bir kez ödetiyor; 15. bölümdeki HTTP/2 multiplexing de aynı bağlantıda nesneleri paralel isteyerek istek turlarını üst üste bindiriyor.

Kurulumun sırası bedeli açıklıyor. Önce TCP bağlantısı kuruluyor, ancak o bitince TLS anahtar paylaşımını ve kimlik doğrulamayı yapabiliyor. İkisi aynı anda yapılamıyor ve ikincisi birincinin bitmesini bekliyor; bütçenin en büyük sabit kalemi bu sıralılıktan çıkıyor.

Bir adım daha var: QUIC güvenilirliği, tıkanıklık denetimini, kimlik doğrulamayı ve şifreleme durumunu tek el sıkışmada kuruyor. Ardışık iki kurulum turu tek tura iniyor ve bütçeden bir 20 ms siliniyor. Önceki oturumdan saklanan bilet ise el sıkışma gecikmesini sıfıra indiriyor; ilk istek verisi el sıkışmanın ilk paketiyle birlikte yola çıkıyor. 10. bölümde bedelini görmüştün: bu ilk paket tekrar oynatılabildiği için sunucular ona yalnızca yan etkisi olmayan istekler için, örneğin sayfa okuyan bir GET için güveniyor.

Aynı yolu iki uçtan hesaplamak bütçenin ne kadar oynadığını gösteriyor. Kilit iki tur sürdüğünde toplam 125 ms’e çıkıyor. Ad önbellekteyse ve bilet elindeyse aynı yolculuk 45 ms’e iniyor. Arada tam 80 ms var. Yol aynı yol, mesafe aynı mesafe. Değişen tek şey kaç kez gidip geldiğin.

Milisaniyeyi kim yazıyor?

2. bölümde bir durakta biriken gecikmeyi dört bileşene ayırmıştık; bu bütçede o dördünün ağırlıkları birbirine hiç benzemiyor.

İşleme kalemi görünmez. Başlığı okumak, bit hatasına bakmak ve çıkış hattını seçmek bugünün donanımında mikrosaniyenin altında kalıyor.

İletim kalemi de şaşırtacak kadar küçük. 1.500 baytlık bir paket 100 Mbit/s hatta 120 µs sürüyor. Aynı paket 1 Gbit/s hatta 12 µs sürüyor. İkisi de 20 ms’lik turun yanında yuvarlama hatası kadar kalıyor.

Geriye iki kalem kalıyor. Yayılım pazarlığa kapalıdır: mesafeyi hıza bölersin, sonuç neyse odur. Sinyalin ışık hızında gittiğini de sanma; 55. bölümde gördüğün gibi bakırda da camda da sinyal ışık hızının üçte ikisi civarında ilerliyor.

Kuyruk ise bütçenin tek gerçekten değişken kalemi. Çıkış hattında beklemek router’ın o anki yüküne bağlıdır ve o yük saniye saniye oynar. Yayılım her ölçümde aynı sayıyı verir; kuyruk vermez. Bu yüzden tek bir koşu sana bir sayı vermez, bir örnek verir: aynı adresi arka arkaya ölçtüğünde farklı süreler görürsün ve aradaki fark bu kalemden gelir.

Kalemler tek bir durakta da bitmiyor. Aynı dört bileşen yol üstündeki her kutuda yeniden birikiyor, dolayısıyla iki uç arasındaki cihaz sayısı arttıkça toplam da büyüyor. Bir atlama eklemek bir kablonun boyunu uzatmakla aynı şey değil; eklenen şey mesafe değil, bir kuyruk ile bir iletim daha.

İlk bayt düştükten sonra hesap el değiştiriyor. Aktarım süresini artık turlar belirlemiyor, yol üzerindeki darboğaz hattı belirliyor. 68. bölümde tıkanıklık penceresinin tavanını çizen bant genişliği-gecikme çarpımı bu bütçeden çıkıyor: 100 Mbit/s’lik darboğazı 20 ms’lik turla çarpınca 2.000.000 bit, yani 250.000 bayt. İlan edilen sliding window bu sayının altında kalırsa gönderen boruyu hiç dolduramaz.

Süreyi kendin nasıl ölçersin?

Traceroute yol üzerindeki her router’a kadar olan gecikmeyi ölçer. Ölçtüğü şey uçtan uca süre değil, o ara noktaya kadar geçen süredir. Aracı 1987’de Van Jacobson yazdı.

Yöntemi tek bir alana yaslanıyor. 49. bölümde paket süzme kurallarını yazarken ayırdığın iki ICMP mesajı burada yöntemin kendisi oluyor. İlk set TTL=1 ile gider, ikinci set TTL=2 ile. Sıradaki router datagramı atar ve kaynağa tür 11 kod 0 zaman aşımı mesajı döner. Her atlama için üç yoklama paketi gönderilir. Yolculuk hedefe varınca durur: Unix’teki traceroute yoklamaları yüksek numaralı, kapalı bir UDP portuna yolluyor ve hedef tür 3 kod 3 cevabıyla dönüyor. Windows’un tracert’i ise ICMP echo yolluyor ve hedef ona echo cevabıyla dönüyor.

Çıktı bir merdivene benziyor.

$ traceroute -n 203.0.113.7        # Windows: tracert -d 203.0.113.7
 1  192.0.2.1           1 ms   1 ms   1 ms
 2  198.51.100.9        6 ms   6 ms   6 ms
 3  * * *
 4  198.51.100.42      14 ms  14 ms  14 ms
 5  203.0.113.7        21 ms  21 ms  20 ms

Merdivenin asıl işi satırların farkını okumaktır. İkinci satır 6 ms, dördüncü satır 14 ms gösteriyor; aradaki 8 ms o iki nokta arasına giren hattın payıdır. Son satırdaki 21 ms ise bütçeye 20 ms diye yazdığımız turun ölçülmüş hâlidir.

Üçüncü satırdaki yıldızlar yolun koptuğu anlamına gelmiyor. Ya o yoklama kayboldu ya da router yanıt vermemeyi seçti. Paket yoluna devam etti; kanıtı dördüncü satırın dolu gelmesi.

Ters yönde şaşırtan bir durum daha var. İleri bir atlamanın süresi bir öncekinden küçük çıkabilir. Her satır ayrı bir paketin ayrı bir yolculuğudur; merdiven birikimli bir sayaç değildir. Üstelik router’lar ICMP cevabını düşük öncelikle, 43. bölümdeki kontrol düzleminde üretiyor. Ortadaki bir atlamanın büyük görünmesi o router’ın meşgul olduğunu gösterebilir, yolun yavaş olduğunu göstermez; sonraki satırlar küçükse gecikme yolda değil, cevabı üreten kutudadır.

Aynı mesajları yakalama aracında da görebilirsin. ip.ttl süzgeci gelen paketin kaç atlama harcadığını gösterir. icmp.type ve icmp.code süzgeçleri traceroute’un ürettiklerini ayıklar. Aynı yakalamada bütçeyi doğrudan da okuyabilirsin: isteği taşıyan frame’in zaman damgasıyla yanıtın ilk baytını getiren frame’in zaman damgası arasındaki fark, ilk bayta kadar geçen sürenin ta kendisidir.

En kaba ölçüm hâlâ ping. ICMP üzerinden bir echo isteği gider, karşı taraf cevabını döner, arada geçen zaman hesaplanıp ekrana yazılır. Windows tarafında pathping, Linux tarafında mtr aynı yolu traceroute ile ping’i birleştirerek ve daha uzun örneklemeyle ölçer.

Faturayı kalem kalem görmek istiyorsan tek satır yetiyor.

curl -o /dev/null -s \
  -w 'ad: %{time_namelookup}  tcp: %{time_connect}  tls: %{time_appconnect}  ilk bayt: %{time_starttransfer}\n' \
  https://example.com

Son sütun ilk bayta kadar geçen süredir ve örneğimizde 0,105 saniye yazar. curl’ün sayıları başlangıçtan itibaren birikerek ölçülüyor; aradaki farklar kalemleri veriyor. Ad ile TCP arasındaki fark bağlantı turu, TCP ile TLS arasındaki fark kilit turu, TLS ile ilk bayt arasındaki fark ise isteğin turu artı sunucunun düşünme süresidir.

Özet

• İlk bayta kadar geçen süre bir toplamdır: yolculuğun her durağı ona bir kalem yazar ve sayma birimi tek bir gidiş-dönüştür.
• Ağırlık kurulumdadır: 2.000 km’lik bir yolda dört tur 80 ms, sunucu 25 ms tutar ve 105 ms’lik bütçenin %76’sı turlara gider.
• Turlar silinebilir: önbellek ad çözmeyi, kalıcı bağlantı ile tek el sıkışma kurulumu, saklanan bilet ise el sıkışma gecikmesini düşürür.
• Mikrosaniye ile milisaniye karışmaz: işleme ve iletim mikrosaniye mertebesinde kalır, faturayı yayılım ile kuyruk yazar.
• traceroute merdiveni birikimli değildir: her satır ayrı bir paketin ölçümüdür, yıldız da kopukluk değil yanıtsızlık demektir.

Yolculuk bitti. Tuşa bastığın andan ilk baytın düştüğü ana kadar her durağın faturaya ne yazdığını artık sayıyla biliyorsun. Bu yolculuğun tamamını tarayıcı senin yerine yaptı. Aynı isteği tarayıcı olmadan, birkaç satır kodla göndermek mümkün mü?