Bölüm 15:İçerik Dağıtım Ağları

İsteğin yola çıktı. Ama adres çubuğuna yazdığın ada karşılık gelen makineye gitmiyor.

Paketi alan makine çoğu zaman aynı ülkede bile değil. Kararı sen vermedin ve karar istek yola çıkmadan önce alınmıştı. Peki kim aldı?

Tek büyük sunucu neden yetmiyor?

Yaklaşık bir milyar kullanıcıya aynı içeriği ulaştırman gerekiyor. En sade tasarım tek bir dev makine: bütün içerik orada dursun, herkes oraya gelsin.

Bu tasarım üç yerden birden eleniyor: tek bir arıza noktası oluyor, ağın tıkanma noktası oluyor, ve uzaktaki bir istemciye giden yol hem uzun hem tıkanmaya açık kalıyor.

Sonuncusunu fizik tek başına bitiriyor. Tek modlu fiberde kırılma indisi yaklaşık 1,5, yani ışık saniyede 200.000 km yol alıyor. Aradaki mesafe 2.000 km ise tek yön 10 ms, gidiş-dönüş 20 ms. Sunucuyu ne kadar hızlandırırsan hızlandır bu süre olduğu yerde duruyor; kısaltabileceğin tek şey mesafenin kendisi.

Çözümün adı içerik dağıtım ağı, kısaca CDN, ve tanımı sade. Aynı içeriğin kopyalarını coğrafi olarak dağıtılmış birçok yerde tutuyorsun, ve isteği en yakın kopyaya götürüyorsun. Bu çözüm ağın içine kurulmuyor; uygulama katmanında duruyor. İnternet ona yalnızca uçtan uca taşıma veriyor. Böyle hizmetlere over the top deniyor, üstten geçen.

Sunucuları nereye koyacağın ayrı bir tercih ve iki felsefe var. Derine girmek, sunucuları erişim ağlarının içine, kullanıcının dibine sokmak demek. Eve getirmek ise erişim ağlarına yakın buluşma noktalarında daha az sayıda ama daha büyük küme kurmak. İlkini Akamai seçti, ikincisini Limelight tipi işletmeciler.

Derine gitmenin ölçeği şaşırtacak kadar büyük. Akamai 2015’te 240.000 sunucuyu 120’den fazla ülkeye yaymıştı. Bölersen ülke başına ortalama 2.000’den az sunucu düşüyor. Yoğunluk birkaç dev merkezde toplanmıyor, ince yayılmış küçük yığınlara dağılıyor. Aynı ağın başka bir sayımında 1.000’den fazla ağda kurulu 1.000’den fazla küme geçiyor.

Bu ölçeğin sebebi trafiğin kendisi. 2020’de servis sağlayıcıların konut trafiğinin %80’i üç akış hizmetine gidiyordu. Büyük içerik sağlayıcılar bir adım daha atıyor: veri merkezlerini internete bağlayan kendi özel ağlarını işletiyorlar ve trafiği değişim noktalarında doğrudan takas ediyorlar. Aradaki omurga işletmecileri bu akışın dışında kalıyor.

İsteği kim yönlendiriyor?

Adı devreden zincir

Yönlendirmenin asıl aracı DNS. Zincir tanıdık: sorgu kök sunucudan başlıyor, üst düzey alandan geçiyor ve yetkili sunucuya iniyor. İçerik sahibinin yetkili sunucusuna vardığında bir adres almıyorsun. Oradaki kayıt bir CNAME ve soruyu CDN’in alan adına devrediyor.

Bir DNS kaynak kaydı dört alan taşıyor: ad, değer, tür ve yaşam süresi. CNAME kaydında ad takma addır, değer ise o adın kanonik karşılığı. Devir birkaç kez tekrarlanabiliyor, ama zincirin sonunda mutlaka bir A kaydı duruyor. CNAME tek başına adres vermiyor.

Asıl seçimi en sonda CDN’in kendi yetkili sunucusu yapıyor. Kasıtlı bir yan etkisi var: içeriğin gerçekte hangi makinede durduğunu sen bilmiyorsun. Ad da bunu ele vermiyor. Makine tarafından üretilmiş o uzun etiketlerin her biri, bir DNS etiketine tanınan 63 karakterlik sınırın altında kalıyor.

DNS’in ilan edilmiş hizmetlerinden biri zaten yük dağıtımı. Çoğaltılmış sunucular için tek ada birden çok adres karşılık gelebiliyor, ve CDN bu eski yeteneği bir kat yukarıda kullanıyor. Hacim de buna göre büyümüş: Akamai’nin ad sunucuları günde 2,2 trilyon sorgu görüyor, Comcast’inkiler 600 milyar.

Sorana göre değişen cevap

RFC 7871 işe bir olguyu tespit ederek başlıyor. Yetkili ad sunucuları bugün aynı ada, sorana göre farklı adres döndürüyor, ve konum tahmini için baktıkları şey gelen sorgunun kaynak adresi. Kusur da burada. Yetkili sunucu senin adresini görmüyor, özyineli çözücünün adresini görüyor; merkezî bir çözücü ise sana topolojik olarak uzak olabiliyor.

Topolojik yakınlık ile coğrafi yakınlık aynı şey değil. Standart bunu ayrı bir terim olarak tanımlıyor: iki komşu şehir ağ üstünde çok uzak, iki uzak şehir çok yakın olabiliyor.

Standardın çözümü bir DNS seçeneği ve adı EDNS Client Subnet. Mayıs 2016 tarihli, Informational ve EDNS0’ın bir seçeneği olarak taşınıyor:

OPTION-CODE           2 oktet    = 8
OPTION-LENGTH         2 oktet
FAMILY                2 oktet    adres ailesi
SOURCE PREFIX-LENGTH  1 oktet    soldan kaç bit sorulacak
SCOPE PREFIX-LENGTH   1 oktet    cevap kaç biti kapsıyor (sorguda 0)
ADDRESS               değişken   yalnızca öneki taşıyacak kadar oktet

Standart metinlerinde bayt yerine oktet yazıldığını göreceksin; ikisi aynı şeyi, sekiz biti anlatıyor. ADDRESS alanı yalnızca öneki kapsayacak kadar oktet taşıyor: 24 bitlik önek üç oktet, 56 bitlik önek yedi oktet. Fazlasını gönderirsen sunucu paketi FORMERR ile geri çevirebiliyor.

Çözücü de boş durmuyor. Gelen cevabı ağa bağlı olarak önbelleğe alıyor, ve birden çok kayıt aynı sorguya uyduğunda en uzun SCOPE PREFIX-LENGTH kazanıyor. Seçenek yalnızca IN, yani Internet DNS sınıfı için tanımlı.

Mahremiyet dengesi standardın kendi metninde duruyor. Çözücülere IPv4 adresini 24 bite, IPv6 adresini 56 bite kırpmaları öneriliyor. IPv4’te bu, adresin son 8 bitini gizlemek demek; geriye kalan blokta 256 adres var ve hangisi olduğun görünmüyor. Kendi ağını tanıyan bir servis sağlayıcı daha azıyla yetinebiliyor. Bir /20 içindeki bütün /24’lerin aynı bölgede olduğunu biliyorsa 20 bit gönderiyor ve önbellek de daha verimli kullanılıyor.

Standart burada durmuyor ve kendi önerdiği özelliği açıkça eleştiriyor. Seçenek açıkken çözüm zincirindeki her sunucu senin ağ adresini görüyor. RFC bu yüzden özelliğin ad sunucusu yazılımlarında varsayılan olarak kapalı gelmesini tavsiye ediyor. Desteklenmediğinde de dünya durmuyor: en kötü sonuç yanlış bir konum tahmini.

Aynı adres, yüzlerce düğüm

İkinci araç anycast. RFC 4786 tarifi şöyle veriyor: tek bir hizmet adresi birbirinden bağımsız birçok düğümden aynı anda ilan ediliyor, ve o adrese gönderilen datagram bunlardan yalnızca birine yöneliyor. Belge Aralık 2006 tarihli ve BCP 126 numarasını taşıyor.

Bir düğümün kendine çektiği ağ bölgesine havza deniyor. Terim coğrafyadan alınmış ama sınırı harita çizmiyor. Sınırı yönlendirme çiziyor ve gün içinde kayabiliyor.

Bedel iki yerde çıkıyor. Birincisi TCP tarafında: el sıkışma çok paketli bir işlem ve bütün paketlerin aynı düğüme düşmesi gerekiyor; eşit maliyetli çoklu yol varsa aynı işlemin paketleri farklı düğümlere dağılabiliyor. İkincisi izleme. Hizmetin ayakta olup olmadığı artık tek cevabı olan bir soru olmaktan çıkıyor, ve bir düğüm öldüğünde bunu yalnızca o havzadaki kullanıcılar hissediyor.

Anycast’in en tanıdık örneği kök DNS sunucuları. Mantıksal olarak 13 kök ad sunucusu var ama her biri dünyaya çok sayıda kopyayla yayılmış. İlanın yönlendirme tarafında nasıl yapıldığını burada kasten açmıyorum; 42. bölümde ele alacağım.

Kenarda seni karşılayan şey bir önbellek

İsteğini taşıyan kalıcı bağlantının öbür ucunda artık kenardaki makine duruyor. Kenar sunucu bir HTTP önbelleği. RFC 9111’in diliyle paylaşılan önbelleğin kenardaki hâli.

Aradığın nesne kenarda yoksa kenar sunucu onu menşe sunucudan alıyor, kendine saklıyor, sana veriyor. Aynı anda iki rol taşıyor: sana sunucu, menşeye istemci.

Her nesne bu yolu izlemiyor. Akış hizmetlerinde aynı videonun farklı kodlamaları kenar düğümlerine önceden yükleniyor. İstek geldiğinde önce bir manifest dosyası dönüyor, ve her parçayı hangi düğümden çekeceğine istemci kendi karar veriyor.

Kopyanın güncelliğini koşullu GET koruyor. Mekanizma aynı; burada kenar ile menşe arasında çalışıyor.

Asıl yeni olan şey ömrün ikiye bölünmesi. Süreyi içerik sahibi belirliyor ve kenara ayrı, tarayıcıya ayrı ömür verebiliyor. Bunu yapan yönerge s-maxage: yalnızca paylaşılan önbelleğe hitap ediyor, tarayıcının özel önbelleğini hiç ilgilendirmiyor, ve hem max-age’i hem Expires’ı eziyor. Kenardaki kopya çok daha uzun yaşıyor.

Kazanç iki kalemde ayrı ayrı sayılıyor: cevap süresi ve bant genişliği tüketimi. İkincisi erişim hattındaki trafiği düşürüyor, ve doyuma yaklaşan bir hatta kuyruk gecikmesini çökertiyor. Birincisini bir örnek üstünde görelim.

kenar isabet oranı  0,85         kenara gidiş-dönüş   12 ms
menşeye düşen pay   0,15         menşeye gidiş-dönüş  180 ms

ortalama = 0,85 × 12 + 0,15 × 180 = 10,2 + 27 = 37,2 ms

Menşeye her seferinde gitmeye göre kazanç yaklaşık 4,8 kat. İsteklerin %85’i hiç uzağa çıkmıyor.

Ama o 0,85 gökten inmiyor. Bütün hesap tek bir şeye bağlı: kenar sunucu iki isteğin aynı nesneyi istediğine nasıl karar veriyor?

Cevabı önbellek anahtarı veriyor. Varsayılan hâlde bu anahtar metot ile tam adresten oluşuyor: GET https://ornek.com/logo.png. İki isteğin anahtarı aynıysa ikinci istek isabet sayılıyor.

Sorun şu ki aynı adres her zaman aynı cevabı üretmiyor. Sunucu sıkıştırmayı destekleyen istemciye sıkıştırılmış, desteklemeyene ham gövde yolluyor olabilir. Kenar sunucu bunu bilmezse birine ait cevabı ötekine verir. Sunucu bu yüzden cevaba bir uyarı iliştiriyor:

Vary: Accept-Encoding

Vary başlığı önbelleğe “bu cevap şu istek başlığına göre değişiyor, anahtara onu da kat” diyor. Böylece aynı adres için birden çok kopya tutuluyor ve her istemci doğru olanı alıyor.

Buradaki bıçak iki taraflı ve pratikte en sık yapılan yapılandırma hatası burada. Vary listesine eklenen her başlık, o başlığın her farklı değeri için ayrı bir kopya demek. Accept-Encoding iki üç değer alır, zararsız. Ama Vary: User-Agent yazarsan, tarayıcı sürümü kadar ayrı kopya oluşur — pratikte binlerce. Her biri ayrı ayrı ısıtılmayı bekler, isabet oranı çöker ve yukarıdaki 37,2 ms hızla 180 ms’ye yaklaşır. Kenar sunucu hâlâ çalışıyordur; yalnızca hiçbir şeye yaramıyordur.

Aynı sebeple sorgu dizesindeki izleme parametreleri de önbelleği parçalıyor. Aynı görselin sonuna eklenmiş bir kampanya etiketi, kenar için bambaşka bir nesne demek. Ciddi yapılandırmalarda bu yüzden anahtarın hangi parametreleri kapsayacağı elle sayılıyor.

İşin bir de tersi var. Kenardaki makine yalnızca kopya tutan bir raf olmak zorunda değil; üstünde küçük kod parçaları da çalıştırabiliyor. Kenar hesaplama denen bu yetenek, menşeye hiç gitmeden karar verilebilen işleri kenara indiriyor: bir yönlendirme kuralı, bir oturum denetimi, kullanıcının ülkesine göre farklı bir sayfa. Kazanç aynı yerden geliyor — yayılım gecikmesi, kararı veren makine yaklaştıkça küçülüyor.

Zincire üçüncü katmanı DNS önbelleği katıyor. Kayıtlar yaşam süresi dolunca kendiliğinden düşüyor. Bir ad yeni adrese taşındığında değişiklik bütün süreler dolana kadar internet genelinde bilinmiyor. Addan adrese çeviri en iyi çaba temelli.

Şimdi kendi makinene bak. Bir nesneyi iki kez iste ve ikinci cevabın başlıklarını oku:

> curl -sI https://example.com/logo.png
HTTP/2 200
cache-control: public, max-age=86400, s-maxage=604800
age: 214

Bu çıktıda tarayıcıya bir gün, kenara bir hafta ömür verilmiş. Age başlığı, cevabın menşede üretilmesinin ya da doğrulanmasının üstünden geçen saniye sayısını taşıyor. Sıfırdan büyük bir değer, cevabın önbellekten geldiğinin doğrudan kanıtı. 0 saniye görürsen kopya menşeden taze gelmiş.

Seni yönlendiren çözücüyü de görebilirsin. ipconfig /all çıktısındaki DNS Servers satırı, senin adına soran makineyi veriyor, ve EDNS Client Subnet kapalıyken bütün bu seçim onun adresine bakılarak yapılıyor.

Özet

Peki, ne öğrendik?

• Karar sen fark etmeden alınıyor: yazdığın ad CDN’in yetkili sunucusuna devrediliyor ve asıl adres orada seçiliyor.
• CNAME zinciri kimin sunduğunu gizliyor: kayıt dört alan taşıyor ve zincir sonunda mutlaka bir A kaydına düşüyor.
• EDNS Client Subnet tahmini düzeltirken adresini açıyor: IPv4 için 24 bitlik kırpma öneriliyor, ve RFC özelliğin varsayılan olarak kapalı gelmesini istiyor.
• Anycast aynı adresi çok yerde ayakta tutuyor: sınırı havza çiziyor, bedeli izlemede çıkıyor.
• Kenar sunucu paylaşılan bir önbellek: kazancı hem gecikmede hem erişim hattının trafiğinde ölçülüyor.

Kenar sunucunun kapısına vardık ve cevap artık birkaç milisaniye uzakta. Ama aynı kabloda o an akan her şey web değil. Peki aynı ağda o an başka ne akıyor?