Bölüm 16: İç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 (Content Delivery Network) 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; application layer’da 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 gibi 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: Netflix, YouTube ve Amazon Prime. 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.

CNAME kaydını 4. bölümde görmüştün: ad takma addır, değer ise o adın kanonik karşılığı. Devir birkaç kez tekrarlanabiliyor ama zincirin sonunda mutlaka bir A ya da AAAA kaydı duruyor. CNAME tek başına adres vermiyor.

Asıl seçimi en sonda CDN’in kendi yetkili sunucusu yapıyor. Zinciri kendi makinende görebilirsin; dig www.microsoft.com (Windows’ta Resolve-DnsName www.microsoft.com) Eylül 2026’da şunu döndürüyordu:

www.microsoft.com.                  870  IN  CNAME  www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net.  870  IN  CNAME  e13678.dscb.akamaiedge.net.
e13678.dscb.akamaiedge.net.          16  IN  A      184.29.240.90

Ad iki kez devrediliyor ve üçüncü basamakta Akamai’nin makine üretimi bir adına varıyor. İçeriğin gerçekte hangi makinede durduğunu bu zincirden anlamıyorsun; seçim her sorguda yeniden yapılabildiği için sabit bir cevabı da yok. Asıl haber ikinci sütunda. İlk iki satırın yaşam süresi 870 saniye, son satırınki 16 saniye. Takma adlar nadiren değişiyor, kenar seçimi ise saniyeler içinde tazelenebiliyor: CDN bir kenarı kapatmak ya da yükü kaydırmak istediğinde eski cevabın dünyadaki önbelleklerden düşmesini yalnızca birkaç saniye bekliyor. 5. bölümdeki hesap burada işe yarıyor; çok sorulan bir ad için kısa yaşam süresinin bedeli kullanıcıya değil, CDN’in kendi sunucularına yazılı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, resolver’ın adresini görüyor; merkezî bir resolver 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.

Resolver da 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. Resolver’lara 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. Açık resolver’lar da bu yüzden ikiye ayrılıyor: Google’ın 8.8.8.8’i seçeneği destekleyen yetkili sunuculara gönderiyor, Cloudflare’in 1.1.1.1’i mahremiyet gerekçesiyle hiç göndermiyor. 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ı routing ç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; 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 routing tarafında nasıl yapıldığını burada açmıyorum; 45. 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 (origin) 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 (redirect) kuralı, bir oturum denetimi, kullanıcının ülkesine göre farklı bir sayfa. Kazanç aynı yerden geliyor: kararı veren makine yaklaştıkça yayılım gecikmesi küçülüyor.

Şimdi kendi makinene bak. Bir CDN’in sunduğu herhangi bir nesnenin başlıklarını iste:

curl -sI https://cdn.jsdelivr.net/npm/react@18.2.0/package.json

Eylül 2026’da dönen satırların arasında şunlar vardı:

Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable
Age: 4014434
x-cache: HIT, HIT

Tarayıcıya da kenara da bir yıl ömür verilmiş. immutable işareti “bu adresin içeriği hiç değişmeyecek” diyor; sürüm numarası adresin içinde yazılı olduğu için doğru bir söz. Ömürler ayrı da verilebiliyor: max-age=86400, s-maxage=604800 tarayıcıya bir gün, kenara bir hafta demek. Age başlığı, cevabın menşede üretilmesinin ya da doğrulanmasının üstünden geçen saniye sayısını taşıyor. Buradaki dört milyon saniye, aynı kopyanın kenarda kırk altı gündür durduğunu söylüyor. Sıfırdan büyük bir değer cevabın önbellekten geldiğinin kanıtı, x-cache satırındaki HIT de aynı şeyi CDN’in kendi diliyle söylüyor.

Seni yönlendiren resolver’ı da görebilirsin. Windows’ta ipconfig /all çıktısındaki DNS Servers satırı, Linux’ta resolvectl status, macOS’ta scutil --dns senin adına soran makineyi veriyor. EDNS Client Subnet kapalıyken bütün bu seçim onun adresine bakılarak yapılıyor.

Özet

• 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: zincir sonunda mutlaka bir adres kaydına düşüyor ve o son kaydın yaşam süresi saniyelerle ölçülecek kadar kısa olabiliyor.
• EDNS Client Subnet tahmini düzeltirken adresini açıyor: IPv4 için 24 bitlik kırpma öneriliyor; 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?