Ağlar'a “Sen”i Katmak

Bölüm 0: Tek Bir İsteğin Peşinde

Adres çubuğuna bir şey yazıp Enter’a bastığında ne oluyor?

Bu soruyu herkes cevaplayabilir: “sayfa geliyor.” Biraz daha ileri gidenler DNS’ten, TCP’den, belki TLS’ten söz eder. Ama sorunun peşine gerçekten düşenler azdır, çünkü cevap tek bir yerde durmuyor. Adres çözümlemede, taşıma katmanında, bir anahtarın MAC tablosunda, bir yönlendiricinin TCAM’inde, bir cam liften geçen ışığın kırılma açısında ve iki operatör arasındaki ticari anlaşmada aynı anda duruyor.

Bu kitap o cevabı baştan sona takip ediyor: tek bir isteğin peşinden altmış üç durak boyunca gidiyoruz.

Kitabın tek sorusu ve üç omurgası

Kitap boyunca izlediğimiz nesne değişmiyor: adres çubuğuna yazdığın tek bir HTTP isteği. Her bölümde “istek şu anda nerede?” sorusunun bir cevabı var. Bölümleri birbirinden bağımsız konu başlıkları olarak değil, aynı yolculuğun durakları olarak sıraladım.

Bunun altında üç soru yatıyor. Üçünü şimdi soruyorum, üçünü kitabın farklı yerlerinde tek tek kapatacağız, ve son sözde üçünü birlikte mühürleyeceğiz.

1. Bir isim nasıl adrese dönüşüyor ve bunu sana kim söylüyor?

2. Kaybolabilen bir yolun üstünde kaybolmayan bir aktarım nasıl kuruluyor?

3. Kimsenin yolun tamamını bilmediği bir ağda paket yolunu nasıl buluyor?

Yolun haritası

Bölümlerin içinde yer yer katlanabilir paneller göreceksin. Tasarım gerekçesini, tarihsel kararı ve ödünleşimi onların içine koydum; kapalıyken de bölümün tamamı anlaşılıyor.

Parmağın tuşun üstünde duruyor. Bastığın anda o metin kimin eline geçiyor?

Bölüm 1: Adres Çubuğundan İsteğe

Adres çubuğuna bir şeyler yazdın, Enter’a bastın, sayfa geldi. Aradaki süre belki üçte bir saniyeydi ve o sürede olan şey bu kitabın tamamı.

Yazdığın metin ise hâlâ senin makinende; henüz hiçbir yere gitmedi. Tarayıcı o metinden bir isteği nasıl çıkarıyor?

Yazdığın şey bir adres değil, bir tarif

Adres çubuğuna yazılan metne genellikle adres deniyor ama bu ad yanıltıyor. Yazdığın şey bir konum bildirmiyor, bir tarif veriyor, ve tarifin parçaları standartla tanımlı:

https://aglar.emircandemir.com/bolum/yol?dil=tr#kuyruk
└─┬─┘   └──────────┬─────────┘└───┬────┘└──┬──┘└──┬──┘
şema        yetkili alan         yol     sorgu  parça

Bu biçimi tanımlayan belge RFC 3986 ve adı da tam olarak bunu söylüyor: tekbiçimli kaynak tanımlayıcısı.

Şemayı bir sunucu adı olarak okuma; o bir yöntem adı ve harfle başlamak zorunda, sonrasında harf, rakam ve birkaç işaret gelebiliyor. Yetkili alan makineyi gösteriyor ve yanında isteğe bağlı bir port taşıyabiliyor. Yol makinenin içindeki kaynağı gösteriyor, sorgu ise sunucuya ilettiğin ayrıntıyı.

Portu yazmadığın zaman boş kalmıyor; şemanın varsayılanı devreye giriyor.

https://example.com ile https://example.com:443 bu yüzden aynı adres. Tarayıcı ikincisini yazsan bile adres çubuğunda birincisini gösterir, çünkü normalleştirme varsayılan portu siliyor.

Parçaların hepsi aynı kurallara da tabi değil. Şema ile makine adını büyük-küçük harf duyarsız yazabiliyorsun; HTTPS://Example.COM ile https://example.com aynı yere gidiyor. Standart ikisinin de küçük harfe normalleştirilmesini öneriyor. Tarayıcı bunu senin adına yapıyor, üstelik daha adres çubuğunu terk etmeden. Yol için aynı şey geçerli olmuyor: /Belgeler ile /belgeler iki ayrı kaynağı gösterebiliyor, çoğu sunucuda gösteriyor da. Sebebi tarihsel: makine adları en baştan harf duyarsız yazılmış bir sistemin kuralına tabi kalıyor. Yol ise sunucunun dosya sistemine bakıyor ve dosya sistemleri her zaman aynı davranmıyor.

Bunun pratik bedelini bağlantıların hiçbir uyarı vermeden sessizce kırılmasında göreceksin. Bir belgeyi /Rapor.pdf diye yayımlayıp bağlantıyı /rapor.pdf diye paylaştığını düşün. Windows üstünde çalışan bir sunucuda hiçbir sorun çıkmıyor, çünkü orada dosya adı harf duyarsız. Linux üstünde çalışan bir sunucuda ise dosya bulunamıyor. Türkçe tuzağı derinleştiriyor. Büyük harfe çevirme kuralları dile bağlı. Türkçede i harfinin büyüğü noktalı İ, ı harfinin büyüğü noktasız I olur. Bu kuralı İngilizceye göre uygulayan bir kütüphane ilan kelimesini ILAN yapıyor. Sonra yanlış dosyaya bakıyor. Çoğu kütüphanenin varsayılanı İngilizce kuralı olduğu için bu hata sık görülüyor.

Yetkili alanın isteğe bağlı kullanıcı bilgisi taşıyabilmesi klasik bir tuzak doğuruyor. Standart, makine adından önce @ işaretiyle ayrılmış bir bölüm tanıyor: https://a@b.com adresinde makine b.com, a ise yalnızca kullanıcı bilgisi. Gözün soldan sağa okuduğu ilk ad, gidilen yer olmuyor. Uzun bir kullanıcı bilgisi yazıp adresi tanıdık gösteren eski bir kandırma yöntemi bu; tarayıcılar bugün o bölümü ya gizliyor ya da uyarı veriyor.

Sondaki parça tanımlayıcıyı ise sunucu hiç görmüyor. Tarayıcıda kalıyor ve belgenin neresine kaydırılacağını belirliyor. Bir bağlantıyı paylaştığında kare işaretinden sonrası karşı tarafın kayıtlarında görünmez.

Yazamadığın karakterler de var. Standart bunları iki kümeye ayırıyor: harfler, rakamlar ve - . _ ~ her yerde olduğu gibi yazılabiliyor; / ? # & = gibi yapı taşıyan karakterler ise veri olarak kullanılacaksa kodlanmak zorunda. Kodlama yüzde işareti ve iki onaltılık basamak: boşluk %20 oluyor, ç harfi ise iki bayta açılıp %C3%A7 hâline geliyor.

Hangi karakterin kodlanmadan geçebileceği tahmine bırakılmamış:

Listedeki asıl haber ikinci ve üçüncü satırda. O karakterler yasak değil; yapısal. Yol ayırıcısı olarak kullanılan / olduğu gibi yazılır, ama bir dosya adının içinde geçmesi gerekiyorsa %2F diye kodlanmak zorundadır. Aynı karakter, aynı adreste iki farklı anlam taşıyor ve ayrımı yalnızca kodlama yapıyor.

Ayrımın sinsi bir sonucu var ve adı çift kodlama. Zaten kodlanmış bir adresi ikinci kez kodlarsan yüzde işaretinin kendisi de kodlanıyor ve ortaya %2520 gibi bir dizi çıkıyor. Sunucu bunu boşluk yerine metin olarak okuyor. Bir bağlantının neden “bulunamadı” dediğini çözemediğinde ilk bakacağın yerlerden biri burasıdır.

Şemanın bir yöntem adı olduğunu görmenin en hızlı yolu, ağa hiç çıkmayan şemalara bakmak. file: yerel diskteki bir dosyayı açıyor, data: içeriğin kendisini adresin içinde taşıyor, mailto: ise tarayıcıyı bırakıp posta programını çağırıyor. Üçünde de ortada ne sunucu var ne paket. Tarayıcı ilk parçaya bakıp hangi mekanizmayı çalıştıracağına karar veriyor; geri kalan parçaların anlamı bile o karara bağlı.

Adresin ne kadar uzayabileceği de sık sorulan bir soru ve cevabı şaşırtıyor: standart hiçbir üst sınır koymuyor, sınırı uygulamalar koyuyor. Tarayıcılar ve sunucular kendi tamponlarına göre bir yerde kesiyor, araya giren vekiller daha erken kesebiliyor, ve kesen taraf çoğu zaman hata da vermiyor. Bu yüzden uzun veri adres satırında değil, isteğin gövdesinde taşınır.

Yukarıda saydığım parçaların çoğunu da aslında yazmıyorsun. example.com yazdığında ortada ne şema var ne yol; tarayıcı önce güvenli şemayı deniyor, sonra kök yolu ve şemanın varsayılan portunu ekliyor. Hiçbiri adres çubuğunda görünmüyor.

Zarfın üstünde şehir, sokak ve kapı numarası ayrı ayrı yazar; postacı hepsini birden okumaz, sırayla kullanır ve adres de böyle katmanlı. Benzetme şurada bitiyor: zarfı tek bir postacı okur, bu adresi ise üç ayrı sistem okur — şemayı tarayıcı, makine adını resolver (ad çözümleyici), yolu karşıdaki sunucu.

Türkçe bir alan adı ağa nasıl çıkıyor?

Alan adı sistemi doğduğunda yalnızca harf, rakam ve tire tanıyordu. Bu kısıt hâlâ yerinde, çünkü dünyadaki milyonlarca sunucu o varsayımla yazıldı.

Çözüm, adı ağa çıkmadan önce çevirmek oldu. ASCII dışı harf taşıyan bu adların ortak adı uluslararası alan adı. Tarayıcı böyle bir adı belirli bir kodlamayla indiriyor ve sonuç her zaman xn-- önekiyle başlıyor:

türkçe.com     ->  xn--trke-2oa7j.com
ağ.com         ->  xn--a-eja.com
İstanbul.com   ->  xn--istanbul-o0e.com

Numaranın kendisi de zarif: kodlama önce ASCII harfleri sırasıyla yazıyor, sonra tireden sonra kalan harflerin hangi konumda ve hangi karakter olduğunu sıkıştırılmış biçimde ekliyor: türkçe kelimesinden geriye trke kalıyor ve gerisi 2oa7j içinde saklı duruyor, yani dönüşüm kayıpsız ve geri çevrilebilir.

Üçüncü satır ayrıca dikkat çekici. Noktalı büyük İ, sıradan bir i gibi görünüyor ama farklı bir karakter ve kodlama bu farkı korumak zorunda.

Bu ayrım bir güvenlik sorunu doğuruyor. Bazı alfabelerde Latin harflerine tıpatıp benzeyen karakterler var; kötü niyetli biri tanıdık bir markanın adını bu harflerle kaydedip ayırt edilemeyen bir adres üretebilir. Tarayıcılar buna karşı kural koyuyor: ad tek bir alfabeye ait değilse Türkçesi yerine xn-- hâli gösteriliyor. Çirkin görünmesi de kasıtlı.

Tarayıcı önce kendi cebine bakıyor

Enter’a bastığın anda tarayıcının ilk işi ağa çıkmak değil. Önce bu yolculuğu hiç yapmadan kurtulup kurtulamayacağına bakıyor. Sırayla dört cep yokluyor.

En hızlısı bellekteki kopya: sayfayı biraz önce açtıysan resimler ve stil dosyaları hâlâ işlemin belleğinde durabilir. Sonra diskteki kopya geliyor ve tarayıcı orada nesnenin yanına ne kadar taze sayılacağını da yazmış oluyor.

Süre dolmuşsa ağa çıkıyor ama tam bir istek göndermiyor. Bunun yerine elindeki kopyanın tarihini bildirip “bundan sonra değişti mi” diye soruyor; bu biçimin adı koşullu istek. Değişmediyse sunucu gövdeyi hiç göndermiyor, kısa bir yanıtla yetiniyor. Tazeliğin nasıl hesaplandığını 4. bölümde yaşam süresiyle birlikte açacağız.

Üçüncü cep bir liste. Tarayıcı, daha önce yalnızca güvenli bağlantı kabul ettiğini bildirmiş siteleri saklıyor; o listedeki bir adrese http yazsan bile istek hiç gönderilmeden https hâline çevriliyor. Ağda tek bir şifresiz istek görünmüyor.

Dördüncüsü tahmin. Tarayıcı sen yazarken nereye gitmek istediğini kestirmeye çalışıyor ve yeterince eminse adı çözüp bağlantıyı kurmaya başlıyor. Tahmin yanlışsa gitmek istemediğin bir sunucu senin geldiğini görmüş oluyor.

Sayfa tek dosya değil

Tek bir adres yazdın ama karşılığında tek bir dosya gelmiyor. Bir web sayfası nesnelerin toplamı: gelen ilk şey taban HTML dosyası, içinde resimlere, stil dosyalarına, yazı tiplerine ve betiklere göndermeler var, ve her birinin kendi adresi.

Tarayıcı belgeyi baştan sona beklemiyor. Parça parça alıyor, elindekini hemen ayrıştırıyor ve ilk resmin adresini gördüğü anda onu istemeye başlıyor. Sayfanın üst kısmının alttan önce görünmesinin sebebi bu.

Ayrıştırma her zaman kesintisiz de ilerlemiyor. Bir betik etiketi geldiğinde tarayıcı durur. Betik indirilip çalışana kadar belgenin geri kalanı beklemede kalır. Sebep, betiğin belgeyi değiştirebilme ihtimali. Sayfa başına düşen betik sayısının neden bu kadar konuşulduğunu bu kural açıklıyor.

Göndermelerin çoğu tam adres taşımıyor ve tarayıcı bunları belgenin kendi adresine göre tamamlıyor. Kural iki satırla yazılabiliyor:

belge /a/b/  içindeyken   c.png  ->  /a/b/c.png
belge /a/b   içindeyken   c.png  ->  /a/c.png

Aradaki fark tek bir karakter. Sondaki eğik çizgi, tarayıcının b parçasını dizin mi dosya mı saydığını değiştiriyor. Bir sayfayı taşırken o çizgiyi kaybetmek, belgedeki bütün göreli bağlantıları tek seferde kırabiliyor.

Sayı da hızla büyüyor: sıradan bir haber sayfası kolayca yüzden fazla nesne isteyebiliyor ve hepsi aynı makinede durmak zorunda değil. Bedeli gecikmeye yazılıyor, çünkü her yeni bağlantı en az bir gidiş-dönüş süresi istiyor.

İstek nasıl bir şeye dönüşüyor

Tarayıcı ceplerini yokladı ve ağa çıkmaya karar verdi. Elindeki şey şaşırtıcı derecede sade — birkaç satır okunabilir metin:

GET /bolum/yol?dil=tr HTTP/1.1
Host: aglar.emircandemir.com
Accept: text/html
Accept-Language: tr
If-Modified-Since: Wed, 20 Aug 2026 09:14:22 GMT

İlk satır ne istediğini, hangi yolu istediğini ve hangi sürümü konuştuğunu söylüyor, altında da başlıklar duruyor. Parça tanımlayıcının burada olmadığına dikkat et: #kuyruk ağa hiç çıkmadı.

İkinci satır ilk bakışta gereksiz görünüyor. Tarayıcı zaten o makineye bağlandıysa, adını tekrar yazmasının anlamı ne?

Anlamı, bir makinenin tek bir siteye ev sahipliği yapmak zorunda olmamasında. Aynı sunucu yüzlerce alan adına birden hizmet verebiliyor ve gelen bağlantı hepsi için aynı görünüyor; sunucu hangi siteyi istediğini ancak bu satırdan öğreniyor. Paylaşımlı barındırmanın ucuz olmasının sebebi tam olarak burada.

Aynı sorun şifreli bağlantılarda bir kez daha çıkıyor: sunucunun hangi sertifikayı sunacağına karar verebilmesi için siteyi bilmesi gerekiyor, ama sertifika gelmeden istek de şifrelenemiyor. Bu düğümü kilidi kurarken çözeceğiz.

Metin bir sokete yazılıyor. Soket, işletim sisteminin uygulamaya verdiği bir tutamak; uygulama oraya yazıyor, gerisini çekirdek hallediyor. Bu tutamağın çekirdek tarafını başka bir kitapta ele almıştım.

Ama soketi açmak için karşı tarafın adresi gerekiyor ve o adres bu metinde yok. Elindeki şey bir isim; ağın taşıdığı şey bir sayı.

Özet

Peki, ne öğrendik?

• Adres çubuğuna yazdığın metin parçalara ayrılmış bir tarif. Parçalar aynı kurallara tabi değil ve parça tanımlayıcı sunucuya hiç gitmiyor.
• Yapı taşıyan karakterler veri olacaksa kodlanıyor: boşluk %20, ç harfi %C3%A7. Aynı adresi iki kez kodlamak %2520 üretiyor.
• Türkçe harf taşıyan alan adı ağa xn-- önekiyle çıkıyor ve dönüşüm kayıpsız; karma alfabede bu hâlin gösterilmesi bir güvenlik kuralı.
• Tarayıcı ağa çıkmadan önce dört cebini yokluyor: bellek, disk, güvenli bağlantı listesi ve tahmin. Yolculuğun en hızlısı, hiç yapılmayanıdır.
• İstek birkaç satır okunabilir metinden ibaret ve Host satırı olmadan tek bir makine tek bir siteye hizmet etmek zorunda kalırdı.

Tarayıcı hazır, metin hazır, soket açılmayı bekliyor. Elinde bir isim var ama ağ isimden anlamıyor; peki neden anlamıyor?

Bölüm 2: Paket Anahtarlamalı Yol

Tarayıcı isteği yazdı, soketi açmaya hazırlandı, sonra durdu. Ağ isimden anlamıyor ve bunun sebebi kabalık değil. Sebep ölçek: yolu bilen tek bir merkez yok.

Merkez yoksa yol neye benziyor? Veri o yolda bütün hâlde mi gidiyor, parça parça mı?

Ortada baştan sona uzanan bir yol yok

Ağ sözcüğü kafada bir tel canlandırıyor: bir ucunda sen, bir ucunda sunucu. Böyle bir tel yok. Onun yerine kutular var, her kutunun birkaç kablosu ve kabloların ucunda başka kutular.

Bir paket geldiğinde kutu tek bir karar veriyor: bunu hangi kablodan çıkarmalı? Kutu paketin nereden geldiğini umursamıyor, kaç durak sonra varacağını bilmiyor. Elindeki tek bilgi paketin üstünde yazan hedef ve kendi belleğindeki bir tablo. Tabloya bakıyor, kablo seçiyor, paketi itiyor.

Karar paket başına veriliyor, sohbet başına değil. Aynı sohbetin iki paketi, tablo arada değişmişse farklı kablolardan gidebiliyor. Görünür sonucu şu: paketler gönderildikleri sırayla varmak zorunda değil. Ağ hiçbir yerde sıralama sözü vermiyor ve bu eksiği kapatma işini uçlara bırakıyor.

Ortaya iki ayrı iş çıkıyor ve bunları karıştırmamak gerekiyor. Gelen tek bir paketi doğru kabloya itmek yerel bir iştir, hızlıdır, mikrosaniyeler içinde biter; buna iletme diyoruz. O tabloyu doldurmak ise küresel bir iştir, yavaştır, kutuların birbiriyle konuşmasıyla yürür; buna da yönlendirme. İkisini ayrı ayrı açacağız. Kutuların adını da burada verelim. Bunlara yönlendirici deniyor; kitabın geri kalanında o adla anacağım.

Yol kimsenin sahibi olmadığı için sabit de değil. Bir kablo koptuğunda tablolar değişiyor ve aynı sohbetin paketleri başka duraklardan geçmeye başlıyor. Sen bunu fark etmiyorsun.

Mesaj neden parçalara bölünüyor?

Tarayıcının ürettiği istek birkaç satır metindi ama yola tek bir bütün olarak çıkmıyor. Küçük parçalara bölünüyor ve her parça kendi başına yolculuk ediyor. Bunlara paket diyoruz.

Bir paket iki kısımdan oluşuyor. Önde ağın kendisi için yazılmış bilgi var — nereye gittiği, nereden geldiği, ne kadar uzun olduğu — ve buna başlık (header) deniyor. Arkadaki asıl içeriğe ise yük (payload) deniyor. Yoldaki kutular yalnızca başlığa bakıyor; yükün ne olduğunu hiçbiri bilmiyor.

Bölmenin üç sebebi var. Birincisi paylaşım: bir kablo aynı anda tek bir şey taşıyabiliyor, dolayısıyla büyük bir dosya bölünmeden gönderilseydi o dosya bitene kadar aynı kabloyu kullanan herkes beklerdi. İkincisi hata: bölünmemiş bir mesajda tek bir bozuk bayt her şeyi baştan göndermek demek, paketlerde ise yalnızca bozulan parça yeniden gönderiliyor. Üçüncüsü daha az göze çarpıyor — bölünmüş bir mesaj aynı anda birden fazla kabloda birden bulunabiliyor; baştaki paket ikinci kabloya geçmişken sondaki hâlâ birincide ilerliyor.

Bunun bir de maliyeti var ve adı sakla-ve-ilet. Bir kutu, paketin tamamı kendisine ulaşmadan onu bir sonraki kabloya itmeye başlamıyor; başlıktaki hata denetimini ancak sonu görünce yapabiliyor. Yani her durakta paketin tamamı bir kez daha kabloya itiliyor.

Öteki tasarım: yolu baştan ayırtmak

Ağ kurmanın tek yolu bu değildi. Konuşmaya başlamadan önce baştan sona bir yol ayırtan, çok daha eski bir tasarım var; adı devre anahtarlama. Bağlantı istediğinde ağ bir hazırlık turu yapıyor, yol üstündeki her durakta sana bir pay ayırıyor ve ancak sonra “konuşabilirsin” diyor. Ayrılan pay konuşma bitene kadar senin kalıyor.

Payı ayırmanın iki klasik yolu var. Frekans bölmede taşıyıcı bant dar dilimlere ayrılıyor ve her konuşma kendi diliminde kesintisiz akıyor, ama o dilimin izin verdiği hızı hiç aşamıyor. Zaman bölmede ise saat eşit aralıklara ayrılıyor ve her konuşmaya düzenli dönen bir slot düşüyor; bu kez bandın tamamı kullanılıyor, ama yalnızca kendi slotu boyunca.

Bunu bir otoyolla düşünmek işi kolaylaştırıyor. Devre anahtarlama, otoyolda sana özel bir şerit ayırmaya benziyor: o şerit senindir, kimse giremez, trafiğe takılmazsın, ama kullanmadığın sürece boş durur. Paket anahtarlama şerit ayırmıyor; herkes bütün şeritleri paylaşıyor. Haritalaması şöyle: şerit hattın kapasitesi, ayrılmış şerit devre, giriş rampasındaki bekleme kuyruk gecikmesi, yolun en dar kesiti ise darboğaz. Benzetme şurada bitiyor: otoyolda sıkışan araç bekler ve eninde sonunda geçer, ağda ise kuyruk dolduğunda gelen paket beklemeye alınmaz, silinir.

Ayrılmış payın bedeli o boşlukta saklı. Bir web isteği sürekli akan bir şey değil; kısa bir patlama yapıyor, sonra uzun süre susuyor. Böyle bir trafiğe en yüksek hızına göre pay ayırırsan zamanın çoğunda boş kapasite tutmuş olursun.

Paket anahtarlama tam buradan kazanıyor. Kullanıcılar aynı anda konuşmadığı için aynı hat çok daha fazla kullanıcıya yetiyor; ağ ayrılmış pay yerine anlık talebe göre dağıtım yapıyor ve bu dağıtım biçiminin adı istatistiksel çoklama. Bedeli de aynı yerden geliyor: ayrılmış pay olmadığı için garanti de yok.

Bir paketin başına gelen dört gecikme

Paket bir duraktan geçerken dört ayrı gecikme topluyor ve bunları ayırmak, ağ hakkında konuşabilmenin ön şartı.

İşleme gecikmesi, kutunun başlığı okuyup hata denetimi yaptığı ve kabloyu seçtiği süre; bugünün donanımında mikrosaniyenin altında. Kuyruk gecikmesi, çıkış kablosu meşgulse beklenen süre — dördü içinde senin paketine değil, başkalarının trafiğine bağlı olan tek bileşen. Kalan ikisi ise doğrudan formülle yazılabiliyor ve ikisi de tek bir bölme işlemi:

iletim gecikmesi  =  paket uzunluğu (bit)  /  hat hızı (bit/s)
yayılım gecikmesi =  mesafe (m)            /  ortamdaki hız (m/s)

Sayı koyalım. Yerel ağlarda alışılmış en büyük paket 1.500 bayt, yani 12.000 bit. Saniyede bir gigabit taşıyan bir hatta bu paketi itmek 12 mikrosaniye sürüyor. Sinyalin bakırdaki ya da camdaki hızı ise ışığın boşluktaki hızının kabaca üçte ikisi, saniyede iki yüz bin kilometre civarında; hız ortamın elektriksel özelliklerine ve frekansa göre biraz oynuyor. Bin kilometrelik bir fiber hattı geçmek bu hızla yaklaşık 5 milisaniye tutuyor.

Dördünü yan yana koyunca hangisinin önemli olduğu tek bakışta görünüyor:

Aradaki fark dört yüz katın üstünde. Hattını hızlandırmak iletim gecikmesini küçültüyor, yayılım gecikmesine hiç dokunmuyor. İki katı hızlı bir hat alabilirsin ama okyanusu yarı boyuna indiremezsin.

Tablonun son satırı da bu bölümün geri kalanının konusu: dört kalemden üçü hesaplanabilir, dördüncüsü tahmin edilemez.

Dört kalemin birbirine göre büyüklüğünü görmek istersen:

Kuyruk neden birden büyüyor?

Dört gecikmenin üçü baştan hesaplanabiliyor; dördüncüsü öyle değil ve tuhaf davranıyor.

Kuyruğun davranışı tek bir orana bağlı: kabloya gelen bit hızının, kablonun çıkarabildiği bit hızına oranı; bu orana trafik yoğunluğu deniyor ve kuyruk hakkında söylenebilecek neredeyse her şey bu tek sayıdan çıkıyor.

trafik yoğunluğu  =  (ortalama paket varış hızı × paket uzunluğu)  /  hat hızı

Oran birin altındaysa kuyruk zaman zaman doluyor ama boşalabiliyor; biri geçtiyse gelen iş çıkan işten fazla demektir ve kuyruk sürekli büyür. Beklenen şey, oran arttıkça gecikmenin de aynı ölçüde artması. Öyle olmuyor: oran bire yaklaştıkça ortalama bekleme dikleşerek tırmanıyor. Yüzde altmışta rahat çalışan bir hat, yüzde doksan beşte tanınmaz hâle gelebiliyor. Hatları asla tam dolulukta çalıştırmama alışkanlığı buradan geliyor.

Asıl şaşırtıcı olan şu: kuyruklar oran daha bire çok uzakken de oluşuyor. Sebep, trafiğin düzgün gelmemesi. Paketler saat gibi eşit aralıklarla değil, öbekler hâlinde geliyor. Aynı mikrosaniyede on paket geldiyse dokuzu bekliyor. Kuyruğu büyüten şey ortalama yük değil, yükün dalgalanması.

Dalgalanma öngörülebilirliği de bozuyor. Aynı yolu izleyen iki paketten biri boş bir kablo bulup hemen geçerken öteki dolu bir kuyruğa takılabiliyor; gecikmenin paketten pakete böyle oynamasına gecikme oynaması (jitter) deniyor. Dosya indirirken fark etmezsin. Sesli görüşmede ise en çok şikâyet edilen şey gecikmenin büyüklüğü değildir, bu oynamadır.

Bekleme alanının kendisi de sonsuz değil. Kutunun her kablo için ayırdığı bellek belli bir boyutta ve dolduğunda gelen paket bekletilmiyor. Siliniyor. Kutu kimseye haber vermiyor, sayacını bir artırıp yoluna devam ediyor. Silinen paketin akıbetini de ağ değil uçlar belirliyor.

Burada bir basitleştirme yapıyorum ve açıkça söylüyorum: tıkanıklığı “kuyruk dolar, paket silinir” diye geçiyorum. Ağın buna nasıl tepki verdiği ayrı bir konu; tıkanıklık denetimini kurarken bu borcu ödeyeceğiz.

Hız en dar yerde ölçülür

Günlük dilde tek bir hız var: hattının hızı. Ağda ise iki ayrı büyüklük var. Bir kablonun taşıyabileceği en yüksek hıza bant genişliği diyoruz ve o kablonun kendi özelliği. Baştan sona gerçekten elde ettiğin hıza ise throughput diyoruz ve o bütün yolun özelliği.

İlişki bir zincire benziyor. Yolun üstünde onlarca kablo var ve baştan sona akan hız bunların en yavaşını aşamıyor; o halkaya darboğaz hattı deniyor. Otoyol yeniden işe yarıyor: en dar kesit akışı belirliyor, öteki kesitleri genişletmek hiçbir şeyi değiştirmiyor.

Bu cümle bir formüle sığıyor. Sunucunun çıkış hattı Rs, senin erişim hattın Rc olsun:

throughput = min(Rs, Rc)

Aradaki bütün omurga bu hesaba girmiyor — çünkü omurga hatları uçlardan kat kat geniş. Yolun ortasında paylaşılan bir darboğaz varsa formül bir terim daha alıyor. R kapasiteli o kesiti N bağlantı paylaşıyorsa:

throughput = min(Rs, Rc, R/N)

Aktarımın ne kadar süreceği de buradan çıkıyor: F boyundaki bir dosya için süre F / throughput.

Sayıya dökelim. 32 Mbit’lik bir dosya, sunucu hattı 2 Mbit/s, senin hattın 1 Mbit/s. Throughput min(2, 1) = 1 Mbit/s, süre 32 saniye. Şimdi kendi hattını ikiye katla: throughput min(2, 2) = 2 Mbit/s olur ve süre 16 saniyeye iner — kazanç gerçek. Bir kez daha katla: min(2, 4) = 2 çıkar, süre 16 saniyede kalır. İkinci katlamanın hiçbir etkisi yok, çünkü darboğaz artık sende değil.

Bu, evindeki hattı yükseltip hiçbir şeyin hızlanmadığını görmenin tam açıklaması. Darboğaz sunucunun çıkış hattında ya da yolun ortasındaki paylaşılan bir kesitte duruyor olabilir; üstelik o kesiti yalnız da kullanmıyorsun, aynı anda oradan geçen her bağlantı payı bölüyor. Formüldeki N tam olarak bu.

Bunun tersi de doğru: bant genişliği bol olan bir yol, gecikmesi büyükse yine de yavaş hissettirir. Bant genişliği aktarımın ne kadar sürede biteceğini, gecikme ise ne kadar sürede başlayacağını belirliyor. Küçük dosyalarda baskın olan ikincisidir.

Bunu manzarayla birleştirdiğinde tablo tamamlanıyor: bir sayfa nesnelerin toplamıydı ve tarayıcı önbelleklerinden karşılanamayan her nesne kendi isteğini doğuruyordu. O isteklerin çoğu küçük. Küçük nesnelerde geçen sürenin büyük kısmı veri taşımak değil, gidip gelmek.

Özet

Peki, ne öğrendik?

• Yol, iki ucu olan bir tel değil; bağımsız kararlar veren kutuların ağı. Karar paket başına verildiği için sıra bile garanti değil.
• Mesaj paketlere bölünüyor, çünkü kablo paylaşılıyor. Bedeli sakla-ve-ilet: her durakta paketin tamamı bir kez daha kabloya itiliyor.
• Devre anahtarlama garanti veriyor, karşılığında boş kapasite tutuyor. Paket anahtarlamanın kazancı istatistiksel çoklama, bedeli garantisizlik.
• Dört gecikme üst üste biniyor: işleme, kuyruk, iletim ve yayılım. İletim L/R, yayılım d/s; hattı hızlandırmak yalnızca ilkini küçültüyor.
• Kuyruğu büyüten şey ortalama yük değil, yükün dalgalanması ve bellek dolduğunda paket bekletilmiyor, siliniyor.
• Baştan sona hız en dar kesitte belirleniyor. Küçük nesnelerde asıl bedel taşınan bayt değil, yapılan gidiş dönüş sayısı.

Yolun neye benzediğini artık biliyorsun: paylaşılan, garantisiz, her durağında yerel karar verilen bir yol. Ama o kutuların baktığı bir şey vardı, paketin üstündeki hedef. Yol paketlerle çalışıyorsa, paketin üstüne hangi adresi yazacaksın?

Bölüm 3: İsimden Adrese

Her kutu paketin üstündeki hedefe bakıyordu. O hedefin ne olduğunu ise atladım: bir isim değil, bir sayı.

Adres çubuğuna yazdığın metinde sayı yok. Aradaki dönüşüm kitabın omurga sorularından birini de cevaplıyor — bir isim nasıl adrese dönüşüyor ve bunu sana kim söylüyor?

Bu listeyi tek bir yerde tutamazsın

Akla ilk gelen çözüm bir tablo: solda ad, sağda sayı duruyor ve herkes aynı tabloya bakıyor. İş biter.

Birkaç yüz makine için gerçekten işe yarardı. Milyarlarca kayıt için yaramıyor ve sebepleri tek tek sayılabilir. Tek bir kopya varsa o kopyanın çöktüğü an ağın tamamı isimden anlamaz hâle gelir. Tek bir makine, saniyede milyonlarca soruyu da karşılayamaz. Üstelik o makine dünyanın bir yerinde durmak zorunda ve ötekilere uzak kalır.

Asıl sorun ise teknik değil. Kayıtların sahibi tek bir kurum değil; milyonlarca ayrı kuruluş kendi adlarından sorumlu. Merkezî bir tablo, her küçük değişiklik için herkesin aynı masaya başvurması demek olurdu. Böyle bir masa kurulmadı.

Bunun yerine veritabanı bölündü, ve bölünme adın kendi yapısını izledi. Noktalar süs değil; her nokta bir sorumluluk sınırı. ornek.com.tr adını sağdan sola okuyunca üç ayrı sahip görürsün: en sağda ülke alanı, onun içinde ticari alan, onun içinde de kurumun kendi adı.

Adın kendisi de serbest biçimli bir metin değil. Noktalar arasındaki her parçaya etiket deniyor ve standart iki üst sınır koyuyor: tek bir etiket 63 karakteri, adın tamamı ise 255 karakteri aşamıyor. Sınırlar keyfî değil, kaydın telde kapladığı yerle ilgili. Büyük-küçük harf ayrımı da burada yok; adı nasıl yazarsan yaz aynı yere gidiyor.

Adres çubuğundaki metni katmanlı bir zarf adresine benzetmiştik. Benzetme burada bir kat daha işe yarıyor: postacı zarfı kabaca sağdan sola okur, alan adı da öyle. Fark şu — zarfta bütün adımları tek kurum yürütür, burada her adımın sahibi ayrıdır.

Adın sağ ucunda görünmeyen bir nokta daha var: tam yazılmış bir alan adı kökün kendisiyle biter. Adres çubuğuna yazdığın adın sonuna nokta koyup denersen aynı sayfa gelir.

Zincirin en tepesinde kök duruyor. Tek bir işi var: hangi üst düzey alanın nerede sorulacağını bilmek. Bir alt basamakta üst düzey alan sunucuları var; com, org, net ve ülke uzantıları buradan yönetiliyor. En altta ise yetkili sunucu var ve bir adın gerçek karşılığını yalnızca o biliyor.

Sistem okumak için tasarlandı, yazmak için değil: kayıt değişikliği seyrek, sorgu ise sürekli, ve neredeyse her internet işlemi işe bu soruyla başlıyor.

Soruyu senin makinen sormuyor

Makinende bu zinciri yürüten bir program yok. Onun yerine çok küçük bir parça var ve bildiği tek şey, sorulacak yerin adresi.

O adresi de genellikle sen yazmıyorsun. Ağa bağlandığın anda yapılandırma bilgisiyle birlikte geliyor; elle değiştirmek mümkün ama çoğu kişi hiç dokunmuyor. İşte o adresteki makineye resolver diyoruz.

Bu adres genellikle bağlandığın ağı işleten kurumu gösteriyor; herkesin kullanabildiği açık resolver’lar da var. Hangisini kullandığın performansı da, gördüğün cevapları da değiştirebiliyor.

Resolver’ın ilginç yanı, anlattığım hiyerarşinin parçası olmaması. Üç basamağın hiçbirine ait değildir; zincirin dışında durur ve zinciri senin adına yürür.

Sorunun kendisi küçük bir paket ve varsayılan hâlde 53 numaralı kapıya, bağlantısız taşımayla gidiyor: tek paket gidiyor, tek paket dönüyor, el sıkışma yok. Neden el sıkışmadığını ve bunun neyi kazandırıp neyi feda ettiğini 6. bölümde açacağız.

Cevap sığmazsa ne oluyor? Standart, bağlantısız taşımadaki mesajı 512 bayta sınırlıyor. Sığmayan cevap “kesildi” işaretiyle dönüyor ve resolver aynı soruyu bu kez bağlantı kurarak yeniden soruyor. Bir uzantıyla bu sınır pazarlıkla büyütülebiliyor; imzalı cevaplar 512 bayta sığmadığı için o uzantı olmadan imzalama pratikte çalışmıyor.

Sorunun ve cevabın ortak iskeleti

Soru ile cevap aynı biçimi paylaşıyor. İkisinin de başında 12 baytlık sabit bir başlık var ve o başlığın ardından dört bölme geliyor. Başlığın tamamı şu:

Dört sayaç, dört bölmenin uzunluğunu veriyor. Bölmelerin adları da işlerini söylüyor: soru sorulanı tekrar eder, cevap karşılığı taşır, yetki bu cevaba kimin kefil olduğunu, ek ise işine yarayabilecek fazladan kayıtları.

Bayrak alanının içi de sabit ve her biti bir soruyu cevaplıyor:

Son satır arıza ararken en çok baktığın yer. Dört bitin taşıdığı değerler kısa bir liste:

İki kodu birbirinden ayırmak arızanın yerini de ayırıyor. NXDOMAIN “ad yanlış yazılmış” demek; SERVFAIL ise “ad doğru olabilir ama ben sana söyleyemiyorum” demek. Birincisinde yazım hatası ararsın, ikincisinde resolver’ı ya da imzayı.

Kendi makinende hepsini bir arada görebilirsin:

$ dig ornek.com

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24601
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

İkinci satır tam olarak yukarıdaki tablodur: qr cevap olduğunu, rd özyineleme istendiğini, ra resolver’ın bunu yapabildiğini söylüyor. aa yok — demek ki cevap yetkili sunucudan değil, önbellekten geldi.

Sormanın iki biçimi var. Özyinelemeli sorguda soruyu sorup bekliyorsun; karşı taraf gerekirse başkalarına sorar ama sana dönerken elinde hazır cevap olur. Yinelemeli sorguda ise cevap değil yön veriliyor: bende yok, şuraya sor.

Pratikte ikisi arka arkaya kullanılıyor. Senin makinen resolver’a özyinelemeli soruyor; resolver ise hiyerarşiye yinelemeli soruyor. Bölünme keyfî değil: bütün dünyanın yükünü kök sunucuların üstlenmesi ölçek olarak mümkün olmazdı.

Bu düzenin bir bedeli var ve şimdiden söylemek gerek. Resolver’ı kim işletiyorsa, senin baktığın her adı da o görüyor.

Zincir nasıl yürüyor?

Resolver’ın elinde hiçbir bilgi olmadığını varsayalım. Soru geldi ve baştan başlaması gerekiyor.

İlk durak kök. Resolver köke www.ornek.com adresini soruyor ama cevap almıyor; kökün verdiği şey, com alanına bakan sunucunun adı. Sonra o sunucuya aynı soru gidiyor ve bu kez ornek.com alanının yetkili sunucusunun adı dönüyor. Üçüncü soruda ise zincir bitiyor: yetkili sunucu adın gerçek karşılığını veriyor.

Her adımda dönen şeyin bir ad olduğuna dikkat et. Ama resolver bir sonraki sunucuya bağlanmak için sayıya ihtiyaç duyuyor ve elinde yalnızca ad var. Aynı çıkmaz bir kat aşağıda tekrar doğuyor. Çözüm, sunucu adını veren kaydın yanına o sunucunun adresini de iliştirmektir; böylece zincir kendi kendini kilitlemez.

Bu iliştirilen adres kaydının adı tutkal kaydı (glue record) ve gerçekten de zinciri yapıştıran şey o. Ne zaman gerekli olduğunu bir örnek net gösteriyor. ornek.com alanının yetkili sunucusu ns1.ornek.com ise, ornek.com adresini öğrenmek için ns1.ornek.com adresini bilmen gerekiyor — ama o adresi de yalnızca ornek.com sunucusu biliyor. Kısır döngü. com sunucusu bu yüzden NS kaydının yanına ns1.ornek.com için bir de A kaydı koyuyor ve döngü kırılıyor. Yetkili sunucu alanın dışında olsaydı — mesela ns1.baskadns.net — tutkala hiç gerek kalmazdı, çünkü o adı bağımsız olarak çözebilirdin.

Aynı sorunun bir kat yukarısı da var: resolver köke soru sorabilmek için kökün adresini bilmek zorunda ve bunu DNS’e sorarak öğrenemez. Cevap yazılımın içinde gömülü duruyor; dosyanın adı kök ipuçları (root hints) ve içinde on üç kök sunucunun adı ile adresi yazılı. Resolver açılışta bu listedeki bir sunucuya bağlanıp güncel listeyi ister; işlemin adı hazırlık sorgusu (priming). Bütün hiyerarşinin altında, ağdan öğrenilmeyen tek bir sabit dosya duruyor.

Sekiz mesajın tamamını sırayla izlemek istersen:

Zincirin her adımı başarılı olmak zorunda da değil. Sorulan sunucu adı hiç tanımıyorsa “böyle bir ad yok” diye kesin bir cevap dönüyor ve arama orada bitiyor. Sunucu hiç cevap vermezse durum başka: resolver bir süre bekliyor, sonra aynı alanın öteki sunucusunu deniyor. Alan adı kaydettirirken birden fazla yetkili sunucu istenmesinin sebebi bu.

Zincirin bir de bedeli var ve bu bedel gecikme bileşenleri cinsinden ödeniyor. Her soru ayrı bir gidiş dönüş demek: kök, üst düzey alan ve yetkili için üç tur, üstüne senin makinenle resolver arasındaki tur. Sayfa daha ilk baytını almadan bunların hepsi bitmiş olmak zorunda. Uzaktaki bir resolver seçmenin açılışı fark edilir biçimde geciktirmesinin sebebi de bu.

Gerçekte bu zincir çok daha kısa yürüyor, çünkü resolver öğrendiklerini bir süre elinde tutuyor. Bunu şimdilik böyle bırakıyorum: zincirin neden kısaldığını ve elindeki cevabın ne kadar taze sayıldığını bir sonraki durakta ölçeceğiz.

Cevap tek çeşit değil

Zincir boyunca dönen her satır aynı kalıptadır. Dört alan var: adın kendisi, karşılığı olan değer, kaydın türü ve ne kadar süre geçerli sayılacağı. Bu satırlara kaynak kaydı diyoruz.

Satırlar gerçekte şöyle görünüyor:

ornek.com.        300     IN   A       203.0.113.9
ornek.com.        3600    IN   NS      ns1.ornek.com.
ornek.com.        3600    IN   MX      10 posta.ornek.com.
www.ornek.com.    300     IN   CNAME   ornek.com.

Soldan sağa: ad, yaşam süresi, sınıf, tür, değer. Adın sonundaki nokta yukarıda anlattığım gizli kök; burada gizlenmiyor. Sınıf alanı bugün pratikte hep IN çıkıyor — sistem başka ağ aileleri için de tasarlanmıştı ama internetten başkası kalmadı. Posta satırındaki baştaki sayı ise öncelik: birden fazla sunucu varsa küçük olan önce deneniyor.

Kendi makinende görmek istersen dig ornek.com ANY ya da Windows’ta nslookup -type=A ornek.com aynı satırları döküyor.

Türü bilmek işe yarıyor, çünkü aynı ada farklı türlerde farklı cevaplar durabiliyor. Tür alanı 16 bit ve yüzlerce değer tanımlı; gündelik hayatta karşına çıkanlar bir sayfaya sığıyor:

Son üçü genç ve üçü de kitabın başka bölümlerine bağlanıyor.

SRV kaydı DNS’in tek başına yapamadığı bir şeyi yapıyor: port numarasını da söylüyor. A kaydı sana yalnızca makineyi verir, portu uygulamanın bilmesi gerekir — 5. bölümde iyi bilinen port numaralarının niçin ezberlendiğini göreceğiz. SRV bu ezberi kaldırıyor ve adı _hizmet._protokol.alan biçiminde yazıyor: _sip._tcp.ornek.com.

CAA kaydı bir yasak listesi. Her sertifika makamı teknik olarak her ad için sertifika üretebiliyor; CAA alan sahibine “benim adıma yalnızca şu makam sertifika verebilir” deme imkânı veriyor. Makamlar sertifikayı basmadan önce bu kaydı sorgulamak zorunda.

HTTPS kaydı ise tarayıcıya bağlantıyı kurmadan önce yol gösteriyor: hangi protokol sürümleri destekleniyor, hangi port, ve varsa şifreli istemci merhabası için gereken açık anahtar. HTTP/3’e geçişin bir gidiş-dönüşü nasıl kısalttığını konuşurken bu kayda geri döneceğiz.

Adres kaydının iki ayrı türü olması da tesadüf değil: internette iki ayrı adres ailesi kullanılıyor ve çoğu makine ikisini birden istiyor. Farkı ve neden hâlâ ikisinin birden yaşadığını 35. bölümde açacağız.

Ters yön ayrı bir ağaçta yürüyor

Elinde bir adres var ve hangi ada ait olduğunu öğrenmek istiyorsun. DNS bu soruyu doğrudan cevaplayamaz, çünkü ağaç adlara göre bölünmüş — adresleri arayacak bir dizin yok.

Çözüm zarif: adres bir ada çevriliyor. IPv4 adresinin dört sayısı ters sırada dizilip in-addr.arpa alanının altına asılıyor.

203.0.113.9   →   9.113.0.203.in-addr.arpa.   PTR   sunucu.ornek.com.

Ters sıralamanın sebebi hiyerarşi. Alan adlarında en genel parça sağdadır (com), adreslerde ise soldadır (203). Sırayı çevirince adresin de en genel parçası sağa geçiyor ve DNS’in olağan yetki devri mekanizması hiç değiştirilmeden çalışıyor: bir kuruluşa 203.0.113.0/24 bloğu tahsis edildiğinde ona 113.0.203.in-addr.arpa alanının yetkisi devrediliyor.

IPv6’da aynı numara dörtlük bit gruplarıyla yapılıyor ve ağaç ip6.arpa altında duruyor; adres 32 basamağa açıldığı için ters kayıt adı da 32 etiketten oluşuyor.

Kritik ayrıntı şu: iki yön birbirini doğrulamak zorunda değil. A kaydı bir adı bir adrese bağlarken PTR kaydı adresi bambaşka bir ada bağlayabilir, çünkü ikisinin sahibi farklıdır — ileri yön alan adının sahibine, ters yön adres bloğunun sahibine aittir. Posta sunucuları bu yüzden ikisinin uyuşmasını ayrıca kontrol eder; uyuşmayan bir gönderici spam sayılır.

Aynı ada birden çok adres kaydı da konabiliyor. Cevapta birden fazla sayı döndüğünde istemciler farklı makinelere dağılıyor ve yük paylaşılıyor. Tek bir ad, tek bir makine demek değil.

ornek.com.  3600  IN  SOA  ns1.ornek.com. yonetici.ornek.com. (
                          2026082201 ; seri numarası
                          7200       ; yenileme  (refresh)
                          900        ; yeniden deneme (retry)
                          1209600    ; süre bitimi (expire)
                          3600 )     ; asgari — negatif önbellek süresi

Dönen cevabın kendisi de tek bir satırdan ibaret değil. Paket üç bölmeye ayrılıyor: sorulan şeyin cevabı, o cevaba kimin yetkili olduğu, ve işine yarayabilecek ek kayıtlar. Sunucu adresinin ada iliştirilmesi işte bu üçüncü bölmede oluyor. Resolver böylece bir sonraki adımı ayrı bir soru sormadan öğreniyor.

Peki bir ad bu sisteme nasıl giriyor? Kaydettirdiğinde kayıt kuruluşuna yetkili sunucularının adlarını ve adreslerini veriyorsun. Kuruluş da bu bilgileri üst düzey alan sunucusuna yazıyor. Zincirin sana çıkan halkası tam olarak o an kuruluyor.

Bu yüzden yeni kaydedilen bir ad bir süre çalışmayabiliyor; kimi resolver’lar adı bilir, kimileri bilmez. Sebebini 4. bölümde açacağız.

Böylece omurga sorularından ilkini kapatabiliriz.

Omurga sorusu 1 — Bir isim nasıl adrese dönüşüyor ve bunu sana kim söylüyor?

Ad, sağdan sola okunan bir yol olarak çözülüyor: kök hangi üst düzey alana bakılacağını, üst düzey alan hangi yetkili sunucuya gidileceğini, yetkili sunucu ise gerçek karşılığı söylüyor. Sana söyleyen ise bunların hiçbiri değil; resolver. Zinciri o yürüyor, cevabı o getiriyor, ve senin ondan başka konuştuğun kimse yok.

Özet

Peki, ne öğrendik?

• Ad-adres listesi tek bir yerde tutulamıyor ve sebep yalnızca ölçek değil: kayıtların sahibi milyonlarca ayrı kuruluş.
• Bölünme adın kendi yapısını izliyor. Her nokta bir sorumluluk sınırı; kök, üst düzey alan ve yetkili sunucu bu sınırların üstüne oturuyor.
• Zinciri senin makinen yürümüyor, resolver yürüyor ve resolver hiyerarşinin parçası değil, müşterisi.
• Sormanın iki biçimi var: özyinelemeli sorgu cevabı getiriyor, yinelemeli sorgu bir sonraki adresi veriyor.
• Cevap tek çeşit değil. Adres, sunucu, posta ve takma ad kayıtlarının yanında SRV portu, CAA sertifika iznini, HTTPS ise bağlantı parametrelerini taşıyor.
• Mesajın başlığı 12 bayt ve dört bölme sayacı taşıyor. Bayraklardaki AA cevabın sahibinden mi geldiğini, RCODE ise işin nasıl bittiğini söylüyor — NXDOMAIN ile SERVFAIL arasındaki fark arızanın yerini de ayırıyor.
• Ters yön ayrı bir ağaçta yürüyor: adres ters çevrilip in-addr.arpa altına asılıyor, ve iki yönün uyuşması zorunlu değil çünkü sahipleri farklı.

Elinde artık bir sayı var ve soket açılabilir. Ama o sayıyı sana bir yabancı söyledi ve sen sorgulamadan kabul ettin. Sana bir sayı söylediler; peki söyleyenin doğruyu söylediğini nereden biliyorsun?

Bölüm 4: Önbellek, Tazelik ve Güven

Sorgu bir sayı getirdi ve iki şeyi hiç sınamadık: söyleyenin doğru söylediğini, ve cevabın ne kadar taze olduğunu.

İkisi de aynı yerde, resolver’ın sana gösterdiği yüzün arkasında duruyor. Peki orada ne var?

Cevap büyük ihtimalle hiyerarşiden gelmedi

Zinciri kökten yetkili sunucuya kadar yürütürken resolver’ın elinde hiçbir şey olmadığını varsaymıştık. O varsayım anlatmak için gerekliydi. Ölçmek için değil.

Gerçek hayatta zincir nadiren baştan yürür.

Sebep basit: her isim sunucusu öğrendiği eşlemeyi bir süre saklıyor. Aynı ad tekrar sorulduğunda kimseye danışmadan, elindeki kopyayla cevap veriyor. Bu depoya önbellek diyoruz ve zincirin kısalmasının tek sebebi o.

Kısalma tek bir yerde de olmuyor. Cevap sana ulaşana kadar birkaç ayrı depodan geçme ihtimali var ve her biri ötekinden habersiz çalışıyor.

En üstteki depo tarayıcının kendi ad deposu: 1. bölümde yokladığı ceplerin yanında duran ayrı bir bölme. Orada cevap varsa istek makineden hiç çıkmıyor. Yoksa bir alt basamağa düşüyor. Ancak hepsi boş çıktığında hiyerarşiye soru gidiyor.

Kazancın nerede olduğunu gecikme bileşenleriyle ölçmek gerekiyor. Kısalan şey iletim süresi değil, yapılan gidiş dönüş sayısı. Depodan gelen bir cevap sıfır tur harcıyor. Zincirin tamamı ise dört tur.

Saklanan şey yalnızca başarılı cevaplar da değil. Bir ad yoksa, o yokluk da bir süre saklanıyor ve buna olumsuz önbellekleme deniyor. Yeni kaydedilen bir adın neden hemen çalışmadığını sormuş ve sebebini buraya bırakmıştım: adı sen kaydetmeden önce birinin sorduğu ve “yok” cevabı aldığı bir resolver, o yokluğu hâlâ elinde tutuyor olabilir.

Katmanların birbirinden habersiz olması da başlı başına bir sorun kaynağı. Bir kaydı değiştirdiğinde makinendeki depo tazelenmiş, tarayıcınınki eskide kalmış olabiliyor. Aynı adres iki farklı programda iki farklı yere gidiyor ve hangi katmanın yanıldığını dışarıdan görmek kolay olmuyor.

Depoların büyüklüğü de aynı değil. Tarayıcınınki yalnızca sana hizmet ediyor, resolver’ınki binlerce kişiye; bu hem kazancı hem riski büyütüyor. O depoya giren tek bir yanlış kayıt, aynı resolver’ı kullanan herkesi birden yanıltıyor.

Bunun görünmeyen bir sonucu daha var. Üst düzey alan sunucularının adresleri neredeyse her resolver’da saklı duruyor, dolayısıyla kök çoğu sorguda hiç devreye girmiyor. Kökün yükünü hafifleten şey ek donanım değil, bu depolama.

Tazeliğin ölçüsü kaydın içinde

Bir kaydın ne kadar süre saklanabileceğini kimse tahmin etmiyor. Süre kaydın kendi alanlarından biri olarak yazılı geliyor ve adı yaşam süresi.

Bu süreyi senin resolver’ın da yazmıyor; alanın sahibi yazıyor. Kaydı yayımlarken “bu değeri şu kadar süre saklayabilirsin” demiş oluyor. Süre dolduğunda kayıt depodan düşüyor. Bir sonraki soru zinciri yeniden başlatıyor.

Buradaki seçim gerçek bir ödünleşim. Süreyi uzun tutarsan sorgu sayısı düşer, cevaplar hızlanır, sunucuların yükü azalır. Kısa tutarsan bir değişiklik dünyaya çabuk yayılır ama her şey daha sık sorulur.

Ödünleşimin ne kadar sert olduğu sayılabilir ve sonuç sezgiye ters çıkıyor. Mantık basit: her yaşam süresi penceresinde yetkili sunucuya tek bir soru gidiyor, o pencerede gelen diğer bütün sorular depodan karşılanıyor. Yani isabet oranını belirleyen şey sürenin kendisi değil, süre boyunca kaç soru geldiği.

Çok sorulan bir adı düşün: saniyede on soru, süre beş dakika. Pencerede üç bin soru birikiyor ve yalnızca biri dışarı çıkıyor — isabet oranı on binde 9.997. Şimdi süreyi otuz saniyeye indir: oran hâlâ %99,67, kullanıcı hiçbir şey hissetmiyor. Ama yetkili sunucuya giden soru sayısı on katına çıktı. Aynı değişiklik, iki tarafta iki ayrı hikâye.

Şimdi az sorulan bir adı düşün: on yedi dakikada bir soru. Beş dakikalık pencere, ikinci soru gelmeden doluyor ve neredeyse her soru ıskalıyor. Yaşam süresini uzatmak bu ada hiçbir şey kazandırmıyor.

Buradan iki pratik sonuç çıkıyor. Büyük siteler kısa süreleri neredeyse bedelsiz kullanabiliyor ve hızlı taşınma esnekliğini bedavaya alıyorlar. Küçük siteler ise süreyi uzatarak bir şey kazanmıyor, yalnızca kendi değişikliklerini yavaşlatıyor.

Bedelin nerede ortaya çıktığını bir taşınmada görürsün. Sunucunu başka bir makineye taşıdığında kaydı güncellersin, ama eski değer hâlâ binlerce depoda duruyordur. Yeni adres herkese ancak eski kayıtların süresi dolduğunda ulaşır. O zamana kadar bazı ziyaretçiler yeni makineye, bazıları eskisine gider.

Deneyimli yöneticiler bu yüzden taşımadan önce süreyi kısaltır, taşımayı yapar, sonra tekrar uzatır. Ama kısaltma da anında etkili olmuyor: eski uzun süreyle saklanmış kayıtlar kendi süreleri dolana kadar yerinde kalıyor.

Sürenin nasıl işlediği de sezgiye ters. Kaydı ilk alan resolver geri saymaya başlıyor ve sana cevabı verirken kalan süreyi bildiriyor. Yani elindeki kayıt, yayımlandığı andaki tam süreyi değil ondan geriye kalanı taşıyor.

Bunu kendin ölçebilirsin: aynı adı kısa aralıkla iki kez sor ve dönen süreye bak.

$ dig +noall +answer example.com A        # ilk sorgu
example.com.   132   IN   A   ...

$ sleep 7 && dig +noall +answer example.com A
example.com.   125   IN   A   ...

Aradaki fark tam olarak beklediğin kadar. Kayıt yeni sorulmuyor; resolver’ın deposunda duran aynı kayıt, üstündeki sayaç azalmış hâlde veriliyor. Sayaç sıfıra indiğinde kayıt düşüyor ve bir sonraki soru zinciri yeniden başlatıyor.

Tarayıcılar ise bu sayıya her zaman uymuyor. Kendi depolarında adları çoğu kez kaydın söylediğinden farklı bir süre tutuyorlar; bazen daha uzun, bazen bağlantı kapanana kadar. Sebep performans: her sekmede yeniden sormak pahalı. Sonuç ise şu — kaydın yaşam süresini kısaltmak, tarayıcı tarafında beklediğin etkiyi yaratmayabiliyor.

Yokluk cevapları için de ayrı bir süre yazılıyor ve bu süre genellikle çok daha kısa tutuluyor. Sebebi asimetrik bir maliyet: var olan bir kaydı bayat tutmak yalnızca eski adrese göndermekle sonuçlanıyor, olmayan bir kaydı bayat tutmak ise yeni kurulan her şeyi görünmez kılıyor. Sistem, iki hatadan daha ucuz olanı seçmiş.

Süreyi kimin belirlediği bir sorumluluk sorusu da doğuruyor. Kaydı yayımlayan taraf uzun bir süre yazarsa, kendi değişikliğinin gecikmesine kendisi razı olmuş oluyor. Ama aynı kaydı kullanan başka kimseye bu tercih sorulmuyor.

Buradan çıkan sonuç, sistemin kendi hakkında verdiği sözü de belirliyor. Ad-adres çevirisi kesin tazelik vaat etmiyor. Elinden gelenin en iyisini yapıyor ve elindeki cevabın bayat olma ihtimalini hep taşıyor.

Bu cevaba neden güveniyorsun?

Şimdi ertelediğim ikinci soruya gelelim. Resolver sana bir sayı söyledi. Peki doğru söylediğini nereden biliyorsun?

Kısa cevap rahatsız edici olacak: varsayılan hâlde bilmiyorsun. Sorgu ve cevap, kendi başlarına ne imzalı ne de gizli. Cevabın gerçekten yetkili sunucudan geldiğini kanıtlayan hiçbir şey yok. Sen ilk gelen cevaba inanıyorsun.

Bunun iki klasik sömürüsü var. Birincisinde araya giren taraf sorguyu görüp sahte bir cevap yetiştiriyor. İkincisi daha sinsi ve adı zehirleme saldırısı: sahte cevap resolver’ın deposuna yerleşirse aynı yalan, süresi dolana kadar o resolver’ı kullanan herkese servis ediliyor. Tek bir başarılı saldırı, binlerce kişiyi yanlış makineye gönderiyor.

Sahteciliğin nasıl yürüdüğünü bilmek, çözümün neden imza olduğunu da açıklıyor. Saldıran taraf gerçek cevabı beklemiyor; kendi cevabını daha önce yetiştirmeye çalışıyor. Ama uydurduğu cevabın kabul edilmesi için sorgunun kimlik numarasını ve hangi porttan sorulduğunu da doğru bilmesi gerekiyor.

Bu yöntemin en bilinen biçimi 2008’de yayımlandı ve bulanın adıyla Kaminsky saldırısı diye anılıyor. Numarası kısaydı: saldırgan var olan bir adı değil, o alanın altında var olmayan rastgele adları soruyor. Her soru yeni bir tahmin hakkı veriyor ve sahte cevaba alanın yetkili sunucusunu değiştiren bir kayıt iliştiriliyor. Tek bir tutturma, alanın tamamını ele geçiriyor.

Savunma bu iki sayıyı tahmin edilemez kılmak üzerine kuruldu. Kimlik numarası 16 bit, yani 65.536 olasılık — tek başına yetersiz. Kaynak portunun da rastgele seçilmesi olasılığı milyarlara çıkardı; kuralı RFC 5452 yazıyor. Üstüne iki ucuz hile daha eklendi: sorulan adın harflerini rastgele büyük-küçük yazıp cevapta aynen geri beklemek, ve soruyu üst basamaklara sorarken adın yalnızca gereken kadarını göstermek. Üçü birden tahmini pratikte imkânsız kılıyor — ama yalanı matematiksel olarak imkânsız kılmıyor. Bunu ancak imza yapıyor.

Çözüm olarak kayıtları imzalamak öneriliyor. İmza zinciri kökten aşağı iniyor ve doğrulayan bir resolver, cevabın gerçekten o alanın sahibinden geldiğini matematiksel olarak sınayabiliyor. Adı DNSSEC ve tek bir şey yapıyor: kaynağı ve bütünlüğü doğruluyor. Gizlemiyor.

Yayılımına baktığında garip bir dengesizlik göreceksin. Kullanıcıların yaklaşık %36’sı imzayı doğrulayan bir resolver’ın arkasında. Buna karşılık imzalanmış bölge oranı yıllardır %8 civarında takılı. Uçtan uca gerçekten doğrulanan sorgu oranı ise Temmuz 2026 ölçümünde %0,62.

İmza da ayrı kayıt türleriyle taşınıyor ve adlarını bilmek işe yarıyor. DNSKEY alanın açık anahtarını yayımlıyor, RRSIG bir kayıt kümesinin imzasını taşıyor, DS ise üst basamakta duruyor ve bir alt alanın anahtarının özetini gösteriyor. Zincir böyle kuruluyor: kökün anahtarına güveniyorsun, kök com alanının DS kaydını imzalıyor, com da bir alt alanınkini. Güven aşağı doğru akıyor.

Zincirin en tepesinde doğrulanacak bir şey değil, baştan bilinen bir şey duruyor: kökün açık anahtarı. Adı güven çıpası ve doğrulayan her resolver’ın içine gömülü geliyor. Bu anahtar 2010’da yayımlandı ve ilk kez 2018’de değiştirildi; değişim, dünyadaki bütün doğrulayıcıların aynı anda yeni anahtarı tanımasını gerektirdiği için yıllarca hazırlandı.

İmzalamanın neden bu kadar geride kaldığı da anlaşılır bir hikâye. İmza, düzenli olarak yenilenmesi gereken anahtarlara dayanıyor ve yenileme kaçırılırsa imza geçersiz oluyor. Geçersiz imzanın cezası da ağır: doğrulayan bir resolver o cevabı kabul etmiyor ve alan, yanlış adrese gitmek yerine tamamen erişilemez hâle geliyor. Yani imzalamanın hatası, hiç imzalamamanın hatasından daha görünür sonuç veriyor. Bu asimetri, isteksizliğin büyük kısmını tek başına açıklıyor.

Aradaki uçurum tek bir cümleyle özetlenebilir: doğrulayacak taraf hazır, imzalayacak taraf değil. Alan sahibi imzalamadığı sürece doğrulayıcı resolver’ın sınayacağı bir şey olmuyor.

Sorguyu kim görüyor?

İmza bir sorunu çözüyor, ötekini hiç ele almıyor. Cevabın doğru olduğunu kanıtlasan bile soruyu sorduğun herkesin gözü önünde soruyorsun.

Sorgu düz metin gittiği sürece yolun üstündeki taraflar hangi adlara baktığını görebiliyor. Sayfanın içeriğini görmeleri de gerekmiyor. Ad tek başına yeterli oluyor; ne yaptığın hakkında hatırı sayılır bilgi taşıyor.

Buna karşı birkaç taşıma önerildi ve hepsine birden şifreli DNS diyoruz.

Fark son sütunda. İlkinin kendi kapısı olduğu için trafiği tanınabiliyor; bir ağ yöneticisi 853’ü kapatarak şifreli sorguyu engelleyebiliyor. İkincisi ise web trafiğinin içine karışıyor, o yüzden engellenmesi çok daha zor — ama aynı sebeple kurumsal ağlarda tepki çeken de o oluyor.

Şifreleme neyin görünmediğini değiştiriyor, neyin göründüğünü tamamen kapatmıyor. Resolver’ın kendisi her şeyi görmeye devam ediyor; şifre onunla senin aranda. Adı çözdükten sonra o makineye bağlanıyorsun ve bağlantının hedef adresi paketin üstünde açıkça yazıyor. Aynı adreste tek bir site duruyorsa, adı gizlemek gittiğin yeri gizlemiyor. Üstelik şifreli bağlantıyı kurarken sunucuya hangi siteyi istediğini de söylüyorsun; o adım 10. bölümün konusu.

Şifrelemenin ikinci sonucu ise ölçekle ilgili ve teknik olmaktan çok yapısal. Tarayıcılar şifreli sorgu için genellikle kendi seçtikleri birkaç büyük sağlayıcıyı varsayılan yapıyor. Böylece sorgu, ağını işleten kurumun gözünden çıkıp dünya çapında birkaç şirketin gözüne giriyor. Kimin göreceği değişiyor, kaç kişinin göreceği azalıyor, ama görenin elindeki resim büyüyor. Şifreleme bir tehdit modelini kapatıyor, hepsini birden değil. Tehdit modeli, “kime karşı korunuyorum” sorusunun cevabı; hangisini kapattığı söylenmeden hiçbir şifreleme kararı değerlendirilemez.

Kendi durumunu görmek de zor değil. Tarayıcıların ayarlarında şifreli sorgunun açık olup olmadığı yazılı duruyor ve çoğu tarayıcı bugün bunu varsayılan olarak açıyor. Ağın buna izin vermediği durumlar da var: bazı kurumsal ağlar şifreli sorguyu kapatıp bütün soruları kendi resolver’ına yönlendiriyor.

Yayılım burada da mütevazı. Ölçümlerde ilk yöntem %6,33, ikincisi %5,75 paya sahip; ikincisi bir yılda yaklaşık üçe katlandıktan sonra tırmanışı duraksadı. Yani sorguların büyük çoğunluğu hâlâ açık gidiyor.

Özet

Peki, ne öğrendik?

• Gelen cevap çoğu zaman hiyerarşiden gelmiyor; tarayıcıdan resolver’a uzanan bir depo dizisinin ilk dolu olanından geliyor.
• Tazeliği kaydın içindeki yaşam süresi belirliyor ve o süreyi resolver değil, alanın sahibi yazıyor.
• Süre seçimi gerçek bir ödünleşim: uzun süre yükü azaltıyor, kısa süre değişikliği hızlandırıyor, ve taşıma sırasında bedeli okur değil yönetici ödüyor.
• Cevap varsayılan hâlde imzasız. İmzalama kaynağı doğruluyor ama gizlemiyor, ve imzalayan taraf doğrulayan taraftan çok geride.
• Şifreli taşıma gözlemciyi değiştiriyor, yok etmiyor; resolver hâlâ her şeyi görüyor ve merkezileşme ayrı bir tartışma başlatıyor.

Elinde artık bir sayı var ve o sayının nereden geldiğini de biliyorsun. Ama sayı yalnızca makineyi gösteriyor. Bir makinede aynı anda onlarca program çalışıyor ve hepsi ağ kullanabiliyor. Adres elinde; şimdi o makinenin hangi kapısını çalacaksın?

Bölüm 5: Port Numarası ve Soket

Adres elinde. Ama tek başına adres, karşındaki makinede kiminle konuşacağını söylemiyor.

Bir konuşmanın hangi programa ait olduğuna ne karar veriyor?

Adres binayı gösteriyor, daireyi değil

Zincirin sonunda aldığın şey bir makinenin adresiydi. O adres posta kutusuna değil, binaya kadar götürüyor.

Bir sunucu makinesinde aynı anda web sunucusu, posta sunucusu, veritabanı ve yönetim arayüzü çalışıyor olabilir. Dördü de aynı adresin arkasında. Gelen bir parçanın hangisine ait olduğunu adres söylemiyor.

Bu yüzden kimliğe ikinci bir parça eklendi: port numarası. Süreci belirleyen şey adres ile port numarasının ikisi birden.

Sokak adresi binayı buluyor, daire numarası ise binanın içinde kimi arayacağını söylüyor. Postacı binaya kadar geliyor, sonrasını numara belirliyor. Haritalaması şöyle: bina makinenin adresi, daire numarası port, dairede oturan kişi ise o portu dinleyen süreç.

Benzetmenin nerede bittiğini söylemek gerekiyor. Apartmanda daireler sabittir ve boş daire de bir dairedir. Ağda ise dinleyen bir süreç yoksa o numara hiç yoktur; oraya gelen bir parça beklemeye alınmaz, geri çevrilir.

Numaranın kaç basamak olabileceği de başlıktaki alanın genişliğine bağlı. Taşıma katmanı parçasının başında kaynak ve hedef için birer alan var ve her biri 16 bit. Yani numara sıfırdan başlıyor ve 65.535’te bitiyor: toplam 65.536 ayrı kapı.

Numaralar rastgele değil

Bir sunucuya bağlanırken numarayı sen uydurmuyorsun. Tarayıcı https gördüğünde 443’e, http gördüğünde 80’e bağlanıyor. Posta sunucuları 25’i, isim sunucuları 53’ü dinliyor.

Bu numaralar üç aralığa bölünmüş durumda ve ayrım standartla tanımlı:

Birinci aralıktaki numaraların çoğunu tanımasan da işin bir yerinde karşına çıkıyorlar. Ezberlenecek liste değil ama okunacak listedir; hangi hizmetin hangi kapıda oturduğunu bilmek, bir güvenlik duvarı kuralına ya da bir bağlantı hatasına bakarken tek başına yön verir.

Son satır bir kuralı ele veriyor. 1.024’ün altındaki numaraları açmak çoğu sistemde yönetici yetkisi ister. Kural, ağın kendisinden değil işletim sisteminden gelir ve amacı basittir: sıradan bir kullanıcı 443’ü kapıp kendi sahte sunucusunu oraya oturtamasın. Yetkisi olmayan geliştiricinin 8080’e ya da 3000’e düşmesinin sebebi bu tek kısıttır.

İlk aralığın yetki istemesi tarihsel bir güvenlik önlemi. Fikir şuydu: düşük numaralı bir kapıyı yalnızca makinenin yöneticisi açabilirse, sıradan bir kullanıcı sahte bir web sunucusu kurup gelenleri kandıramaz.

Ama burada altı çizilmesi gereken bir şey var. Numara ile hizmet arasındaki bağ gelenek, zorunluluk değil. 80’i dinleyen bir program web sunucusu olmak zorunda değil; istersen orada bambaşka bir protokol konuşabilirsin. Aynı şekilde web sunucunu 8080’de de çalıştırabilirsin, yalnızca adres çubuğunda numarayı yazmak zorunda kalırsın.

Bunu bilmek pratikte işe yarıyor. Bir kapının açık olması orada beklediğin hizmetin çalıştığını kanıtlamıyor; yalnızca bir şeyin dinlediğini gösteriyor.

Numaranın ne taşıdığı da başlıkta yazmıyor. Aynı numara iki ayrı taşıma protokolünde birbirinden bağımsız kullanılabiliyor: 53 hem bağlantı kuran hem bağlantısız taşımada tanımlı ve ikisi ayrı soketler. Yani “53 açık” cümlesi bile eksik; hangi taşımada açık olduğunu söylemeden bir şey ifade etmiyor.

Aynı kapıdan yüz binlerce konuşma

Şimdi ilk bakışta çelişki gibi duran bir şey. Bir web sunucusu tek bir numarayı dinliyor, diyelim 443. Aynı anda yüz binlerce kişi ona bağlanıyor. Numara bir tane olduğuna göre sunucu bunları nasıl ayırıyor?

Önce bir ayrım. Yoldaki kutular paketin üstündeki hedefe bakıyordu; o hedef adres, port değil. Yoldaki hiçbir yönlendirici port numarasına bakmak zorunda değil. Port, yalnızca iki uçta anlam taşıyor.

Cevap, taşıma katmanının soketi tek bir sayıyla değil, dört sayıyla tanımlamasında. Kaynak adres, kaynak port, hedef adres, hedef port. Bu four-tuple’ın (dörtlü) tamamı aynı olan iki konuşma olamaz.

Aynı sunucuya bağlanmış üç istemciyi yan yana koyalım:

Üçünün de hedefi aynı, hatta ilk ikisi aynı makineden geliyor. Ayrım tek bir sütunda: kaynak port. Üçüncüsü ise başka bir makineden, dolayısıyla kaynak portu aynı olsa da karışmazdı.

Gelen her parça için makine bu dört değere bakıyor ve parçayı doğru sokete bırakıyor. Bu ayıklama işine çoklama çözme deniyor.

Four-tuple’da görünmeyen gizli bir beşinci sütun daha var: protokol. Port numarası taşıma katmanına ait ve her taşıma protokolünün kendi numara uzayı var. Yani TCP’nin 443’ü ile UDP’nin 443’ü aynı kapı değil, birbirinden tamamen bağımsız iki kapı. Aynı makinede biri açık öbürü kapalı olabilir; ikisini iki ayrı süreç dinleyebilir. HTTPS’in hem TCP hem UDP 443’te yaşayabilmesi de tam olarak bu yüzden mümkün — QUIC aynı numarayı öteki protokolde kullanıyor ve kimsenin ayağına basmıyor.

Bunun doğal sonucu şu: portu olmayan protokoller de var. IP başlığındaki protokol alanı ICMP diyorsa içeride port yoktur, çünkü ICMP bir taşıma protokolü değildir. Ping’in port numarası yoktur ve bir güvenlik duvarında ping’i “port kapatarak” engelleyemezsin; onu protokol düzeyinde ele almak zorundasın.

Sunucu tarafında olan biteni çağrı sırasıyla görmek daha da netleştiriyor:

1. tutamağı oluştur
2. yerel adres ve porta bağla     -> 203.0.113.9:443
3. gelen bağlantıları beklemeye başla
4. bekleyeni kabul et             -> YENİ bir soket doğar

Kendi makinende bu tabloyu görebilirsin. Linux’ta ss -tan, Windows’ta netstat -an dinleyen ve kurulu soketleri listeliyor:

Durum        Yerel adres:port        Uzak adres:port
LISTEN       0.0.0.0:443             0.0.0.0:*
ESTAB        203.0.113.9:443         192.0.2.14:51322
ESTAB        203.0.113.9:443         192.0.2.14:51323
ESTAB        203.0.113.9:443         198.51.100.7:49930
TIME-WAIT    203.0.113.9:443         192.0.2.14:51290

İlk satırda uzak uç boş. Dinleyen soketin karşı tarafı yok, çünkü henüz kimseyle konuşmuyor; yalnızca bekliyor. Yerel taraftaki 0.0.0.0 ise bir makineyi göstermiyor; “bu makinedeki bütün arayüzler” anlamına geliyor.

Bu ayrıntı pratikte sık karşına çıkıyor. Bir süreç soketi 0.0.0.0 yerine 127.0.0.1 adresine bağlarsa yalnızca aynı makineden erişilebilir hâle geliyor; dışarıdan gelen paketler o sokete hiç düşmüyor. Veritabanları çoğu zaman böyle kurulu geliyor ve “servis çalışıyor ama uzaktan bağlanamıyorum” şikâyetinin en yaygın sebebi bu tek satır. Tersi de doğru: yanlışlıkla bütün arayüzlere açılan bir yönetim arayüzü, olması gerekenden çok daha geniş bir kitleye görünür oluyor.

Son satır anahtar. Kabul etmek sana dinlediğin soketi vermiyor; o konuşmaya özel yeni bir soket veriyor. Dinleyen soket kapıda beklemeye devam ediyor. Yüz binlerce bağlantı, yüz binlerce ayrı soket demek — ama hâlâ tek bir port numarası.

Bir port dışarıdan neye benziyor?

Portun ikinci bir yüzü daha var. Dinleyen her port, dışarıdan bakan biri için bir giriş denemesi noktasıdır; bir makinenin saldırı yüzeyi, kabaca açık portlarının toplamıdır.

Dışarıdan bakan biri üç yanıttan birini alır ve üçü üç ayrı şey söyler:

Aradaki fark önemli. Kapalı bir port cevap verdiği için makinenin varlığını ele veriyor; filtrelenmiş bir port ise makinenin orada olup olmadığını bile söylemiyor. Güvenlik duvarlarının varsayılan davranışının “reddet” değil “sessizce düşür” olmasının sebebi bu.

Buradan iki pratik sonuç çıkıyor. Birincisi, kapatılması gereken şey port değil süreçtir; kimsenin dinlemediği bir numara zaten kapalıdır. İkincisi, bir hizmeti standart dışı bir numaraya taşımak onu gizlemez. Numara değiştirmek yalnızca gelişigüzel taramaların gürültüsünü azaltır, hedefli bir taramayı hiç yavaşlatmaz.

Kendi numaranı sen seçmiyorsun

Four-tuple’ın üç değerini biliyorsun: hedef adres isim çözümlemesinden geldi, hedef port şemadan, kaynak adres de makinenin kendi adresi. Dördüncüsü nereden çıkıyor?

Onu işletim sistemi veriyor. Soket açılırken kaynak portu belirtmezsen çekirdek dinamik aralıktan boş bir numara seçip sana veriyor. Bu numaraya geçici port deniyor ve konuşma bitince havuza geri dönüyor.

Seçimin rastgele olması da önemli. İsim sorgusuna sahtecilik yapmak, kimlik numarasını ve kaynak portu tahmin etmeye dayanıyordu. Kaynak portu tahmin edilebilir olsaydı, araya girmek isteyen tarafın işi bir kat kolaylaşırdı.

Havuzun sınırları da yazılı. IANA dinamik aralığı 49152-65535 diye tanımlıyor, yani 16.384 numara. İşletim sistemleri bu öneriye tam uymuyor: Linux varsayılan olarak 32768-60999 aralığını kullanıyor ve 28.232 numara veriyor, Windows ise IANA aralığına sadık kalıyor. Kendi makinendeki değeri okuyabilirsin:

$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

Havuzun sonu da var. Aynı hedef adres ve porta doğru açabileceğin bağlantı sayısı, elindeki geçici numara kadar; four-tuple’ın öteki üç değeri sabitken ayrım yalnızca kaynak porttan gelebiliyor. Yani tek bir arka uca, tek bir porta doğru açabileceğin eşzamanlı bağlantı sayısının tavanı Linux’ta 28.232.

Sayı bol görünüyor ama tükendiği yerler var ve hep aynı desen: çok sayıda kısa ömürlü bağlantı, tek bir hedefe. Saniyede 500 bağlantı açıp kapatan bir vekil sunucu düşün. Her kapanan four-tuple bir süre beklemede kalıyor; bekleme dört dakikaysa aynı anda beklemede duran four-tuple sayısı 500 × 240 = 120.000 eder. Havuzda 28.232 numara var. Havuz saniyeler içinde tükenir ve yeni bağlantı açılamaz — arıza mesajı “adres zaten kullanımda” olur, oysa hedef sunucu turp gibi ayaktadır.

Yukarıdaki çıktıda görünen TIME-WAIT durumu da tam burada devreye giriyor. Kapanan bir bağlantının four-tuple’ı hemen serbest bırakılmıyor, bir süre beklemede tutuluyor. Sebep şu: yolda gecikmiş eski bir paket, aynı four-tuple’la açılan yeni bir bağlantıya düşerse yeni konuşmanın içine eski veri karışır. Bekleme, o paketlerin ömrünün dolmasını garanti ediyor. Bu sürenin kaç dakika olduğunu ve neden o kadar olduğunu el sıkışmayı kurarken hesaplayacağız.

Bedeli havuzda görülüyor. Kısa ömürlü çok sayıda bağlantı açan bir sunucuda beklemedeki four-tuple’lar birikiyor ve boş numara bulunamaz hâle gelebiliyor. Sıradan bir kullanıcı bunu hiç görmez; tek bir arka uca saniyede binlerce bağlantı açan bir vekil sunucu görür.

Soketin çekirdek tarafını burada kapalı kutu bırakıyorum: tutamağın nasıl bir tabloya düştüğünü, tamponların nerede durduğunu ve kopyalamanın maliyetini 20. bölümde ağ kartına indiğimizde açacağız.

Özet

Peki, ne öğrendik?

• Adres binayı gösteriyor, süreci değil. Kimlik adres ile port numarasının ikisi birden; port alanı 16 bit olduğu için toplam 65.536 kapı var.
• Numara ile hizmet arasındaki bağ gelenek. Standart üç aralık tanımlıyor, ama açık bir kapı orada beklediğin hizmetin çalıştığını kanıtlamıyor.
• Soketi dört değer tanımlıyor: kaynak adres, kaynak port, hedef adres, hedef port. Tek bir dinleme portu bu sayede yüz binlerce ayrı konuşmayı taşıyabiliyor.
• Kabul işlemi yeni bir soket doğuruyor; dinleyen soket kapıda kalıyor ve her konuşma kendi soketine düşüyor.
• Kaynak portu sen değil çekirdek seçiyor, dinamik aralıktan ve tahmin edilemez biçimde; havuzun sonu da bağlantı sayısına sınır koyuyor.

Four-tuple tamam, kapı belli, soket açılmaya hazır. Ama şu ana kadar hep “taşıma katmanı” deyip geçtim; adını bir kez andım, ne vaat ettiğini hiç açmadım. Kapıyı buldun; peki oradan geçen her şey aynı sözü mü veriyor?

Bölüm 6: Bağlantısız Taşıma: UDP

Aynı kapıdan geçen her taşıma aynı sözü vermiyor. En kolayı hiçbir vaatte bulunmayan: isim sorgusunun 53 numaralı kapıya “bağlantısız taşımayla” gittiğini söyleyip geçmiştim.

O taşımanın adı UDP ve tanımı 1980 tarihli RFC 768’de duruyor — dört sayfa. Hiçbir şey vaat etmeyen bir taşıma neye yarıyor?

Sekiz bayt, dört alan

Başlığın tamamı bu:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|          kaynak port          |          hedef port           |
+-------------------------------+-------------------------------+
|            uzunluk            |        checksum        |
+-------------------------------+-------------------------------+
|                          yük (payload)                        |

Dört alan, her biri 16 bit, toplam sekiz bayt. Karşılaştırma için: bir sonraki bölümde göreceğimiz bağlantı kuran taşımanın başlığı en az yirmi bayt ve on bir alan taşıyor.

Alanları soldan sağa okuyalım. Kaynak ve hedef port, four-tuple’ın iki ayağı; makine gelen parçayı doğru sokete bunlarla bırakıyor. Kaynak port zorunlu bile değil, cevap beklemiyorsan sıfır bırakabiliyorsun.

Uzunluk alanı başlık dahil parçanın bayt sayısını taşıyor. On altı bit olduğu için üst sınır 65.535 bayt, yükte kalan da 65.527. Pratikte bu sınıra hiç yaklaşılmıyor: yol üstündeki en küçük çerçeveye sığmayan bir parça yolda bölünüyor ve bölünen parçalardan biri kaybolursa tamamı çöpe gidiyor.

Dördüncü alan checksum ve ilginç olan o.

Hesaba giren şey yalnızca yukarıdaki sekiz bayt ile yük değil. Gönderen, hesabı yapmadan önce var olmayan bir başlık uyduruyor: içinde IP kaynak adresi, IP hedef adresi, protokol numarası ve UDP uzunluğu var. Adı sözde başlık ve telde hiç gitmiyor; yalnızca iki uçta da aynı biçimde kurulup hesaba katılıyor.

Neden? Çünkü UDP’nin tek başına cevaplayamadığı bir soru var: bu datagram gerçekten bana mı geldi? Bir yönlendiricinin belleğinde hedef adres bozulursa paket yanlış makineye düşer; o makinenin UDP katmanı, kendi adresini sözde başlığa koyup hesapladığında sağlama tutmaz ve paketi atar. Adresi taşımayan bir sağlama bu hatayı hiç göremezdi.

Bunun bir bedeli var ve adını koymak gerekiyor: taşıma katmanı, altındaki katmanın alanlarını okuyor. Katman sınırının kasten delindiği yerlerden biri burası. Ve delinmesinin somut bir bedeli daha var: adres çevirisi, IP başlığındaki adresi değiştirdiği için taşıma katmanının sağlamasını da yeniden hesaplamak zorunda kalıyor.

Checksum ne yakalar, ne kaçırır?

Hesap sandığından basit. Gönderen taraf parçanın içeriğini 16 bitlik sayılar dizisi sayıyor, hepsini topluyor, en anlamlı bitten taşan eldeyi sonuca geri ekliyor ve çıkan sayının tersini alana yazıyor. Adreslerin de hesaba katılması, parçanın yanlış makineye teslim edildiğini yakalamayı sağlıyor.

Adreslerin hesaba girmesi bir katman ihlali. Taşıma katmanı, kendi altındaki katmanın alanlarını okuyor; bunun için geçici olarak kurulan yapıya sözde başlık deniyor ve telde hiç gönderilmiyor, yalnızca iki tarafta hesaplanıyor.

Alıcı aynı hesabı tekrarlıyor. Sonuç tutmuyorsa parça bozulmuş demektir ve sessizce atılıyor — kimse haber vermiyor.

Şimdi bu korumanın sınırı. İki ayrı 16 bitlik sayıda birbirini götüren iki bit dönerse toplam değişmiyor:

1110 0110 0110 0110      ->   1110 0110 0110 0111   (son bit 0 -> 1)
1101 0101 0101 0101      ->   1101 0101 0101 0100   (son bit 1 -> 0)
-----------------------       -----------------------
toplam aynı                   toplam aynı

Bitler değişti, toplam değişmedi, alıcı hiçbir şey fark etmedi. Bu yüzden checksum’a hata saptama deniyor, hata düzeltme değil — üstelik saptaması da eksiksiz değil.

Bir tuhaflık daha: alan isteğe bağlı. Sıfır yazılırsa “ben hiç hesaplamadım” anlamına geliyor ve alıcı denetlemiyor. Bu esneklik protokolün ilk tasarımından kalma; bugünün adres ailesinde ise checksum zorunlu.

Hiçbir söz vermemek neden işe yarıyor?

Bu taşıma teslim sözü vermiyor, sıra sözü vermiyor, yineleme koruması vermiyor. Kaybolan paketi yeniden göndermiyor, sıralamayı düzeltmiyor, hızını ağa göre kısmıyor. Standart bunu gizlemiyor bile; teslimin garanti edilmediği metnin kendisinde yazılı.

Karşılığında iki şey kazanıyorsun.

Birincisi zaman kazandırıyor: bağlantı kurulmadığı için baştan bir gidiş-dönüş ödemiyorsun. İlk paket doğrudan veriyi taşıyor. Bir isim sorgusu tek paket gidip tek paket dönüyor ve milisaniyeler içinde bitiyor. El sıkışan bir taşımada aynı sorgu, daha soru sorulmadan bir tur harcardı.

İkincisi mesaj sınırı. Gönderdiğin her mesaj alıcıya ayrı bir mesaj olarak çıkıyor; iki mesaj birleşmiyor, bir mesaj ikiye bölünmüş gibi okunmuyor. Akış taşıyan bir protokolde nerede bittiğini kendin işaretlemek zorundasın. Burada sınır zaten korunuyor.

Bir ayrıntı da soket tarafında. Bağlantısız bir sokete de “bağlan” diyebiliyorsun; bu gerçek bir bağlantı kurmuyor, yalnızca karşı ucu sabitliyor. Kazancı şu: çekirdek artık o sokete hangi hataların ait olduğunu bilebiliyor ve “böyle bir kapı yok” cevabını sana iletebiliyor. Sabitlemezsen o cevap sessizce düşüyor.

Bu yüzden bu taşımayı seçen uygulamalar birbirine benziyor: isim çözümlemesi, ağ yönetimi, sesli ve görüntülü görüşme, oyunlar. Ortak noktaları, geç gelen verinin hiç gelmemiş sayılması. Kaybolan bir ses paketini yeniden istemek anlamsız; o an çoktan geçti.

Şaşırtıcı olan, en yeni web protokolünün de bunun üstüne kurulmuş olması. HTTP/3 garantileri bırakmıyor, onları taşımadan alıp uygulamanın içine taşıyor: yeniden gönderim de tıkanıklık denetimi de var, ama artık çekirdekte değil uygulamada. Sebebini 14. bölümde açacağız.

El sıkışma olmamasının bir de karanlık tarafı var. Kaynak adresi doğrulayan hiçbir adım olmadığı için gönderen, paketin üstüne başkasının adresini yazabiliyor. Cevap o adrese gidiyor.

Sorun, cevabın sorudan büyük olmasıyla ciddileşiyor. Kısa bir isim sorgusuna çok daha uzun bir cevap dönebiliyor; saldıran taraf küçük paketler gönderip kurbanın üstüne katlanmış bir trafik yığıyor. Buna yükseltme saldırısı deniyor ve bağlantısız taşımanın en bilinen kötüye kullanımı. Savunması da protokolde değil, işletmede: açık resolver’ı herkese kapatmak, cevap hızını sınırlamak, kaynak adresi kendi ağının çıkışında doğrulamak.

Kendi makinende görmek istersen bunlar soyut kalmasın. Wireshark’ta udp.port == 53 süzgeci, ya da komut satırında tcpdump -n udp port 53, bir sayfa açtığın anda giden isim sorgularını dökecek. Her satırda göreceğin şey tek bir paket: soru gitti, cevap geldi, arada başka hiçbir şey yok.

Özet

Peki, ne öğrendik?

• Başlık sekiz bayt ve dört alan: kaynak port, hedef port, uzunluk, checksum. Bağlantı kuran taşımanın başlığı bunun en az iki buçuk katı.
• Checksum hata saptar, düzeltmez ve saptaması da eksiksiz değil: birbirini götüren iki bit dönmesi toplamı hiç değiştirmiyor.
• Hiçbir söz vermemenin karşılığı zaman ve sınır. El sıkışma olmadığı için ilk paket doğrudan veri taşıyor, ve mesaj sınırları alıcıda korunuyor.
• Bu taşımayı seçen uygulamaların ortak noktası, geç gelen verinin işe yaramaması.

İsim sorgusu bu yüzden tek pakette bitti. Ama sayfanın kendisi tek pakete sığmıyor ve kaybolan bir parçayı kimsenin fark etmemesi kabul edilebilir değil. Garanti istemeyen taşımayı gördün; peki karşı taraf senin geldiğini nereden bilecek?

Bölüm 7: Üç Adımlı El Sıkışma

Kapıyı buldun. Karşı taraf ise senin geldiğini henüz bilmiyor: bir soket açmak bağlantı kurmuyor, önce iki ucun da birbirini duyduğunu kanıtlaması gerekiyor.

Bunun bedeli üç mesaj, ve o üçüncü mesajın neden gerektiği ilk bakışta belli olmuyor.

İki mesaj neden yetmiyor?

El sıkışmanın üç işi var. Birincisi karşılıklı isteklilik: her iki uç da diğerinin bağlanmaya razı olduğunu öğreniyor. İkincisi parametre kararı. Başlangıç sıra numarası ve alıcının ilan ettiği tampon boyu tam burada kararlaştırılıyor. Üçüncüsü kaynak ayırmak. Tampon alanı ile bağlantı tablosunda bir satır ayrılıyor; saldırganın bastığı yer orası.

İnsan konuşmasında iki mesaj yeter. Sorarsın, cevap gelir, iş biter. Ağda yetmiyor, çünkü araya üç şey giriyor: gecikme sabit değil, kaybolan mesajlar yeniden gönderiliyor ve mesajlar sırasını şaşırabiliyor.

İki mesajlı kurulumun birinci arızası gecikmiş bir kopya. Eski bir kurulum isteğinin kopyası ağda oyalanıp sunucuya geç varırsa, sunucu tarafında yarı açık bir bağlantı kalıyor. İstemcisi olmayan bir bağlantı. İkinci arıza daha sinsi: kapanmış bir bağlantının gecikmiş verisi yeni bağlantıda ikinci kez kabul ediliyor.

Üçüncü mesajın gerekçesi bu yüzden nezaket değil. RFC 9293 onu, ağda dolaşan eski kurulum isteklerinin karışıklık yaratmasını engellemek diye yazıyor. İlk isteği alan taraf onun taze mi bayat mı olduğunu bilemiyor. Tek çıkar yol gönderene doğrulatmak.

Standart aslında dört mantıksal adım tanımlıyor. Ortadaki ikisi tek segmentte birleşebildiği için geriye üç mesaj kalıyor. Üçlü el sıkışma adı da tam olarak buradan geliyor.

Üç mesaj, iki durum makinesi

Adım bir: istemci başlangıç sıra numarasını seçiyor ve SYN denetim biti kalkık bir segment gönderiyor. Bu bitlerin yaygın adı bayrak, ben de öyle diyeceğim. Kendisi SYN-SENT durumuna geçiyor.

Adım iki: sunucu SYN-RECEIVED durumuna geçiyor. Henüz bağlanmış değil. Kendi başlangıç numarasını ilan ediyor ve istemcininkini onaylıyor; SYN ile ACK aynı segmentte birlikte kalkık duruyor.

Adım üç: istemci onayı gönderiyor ve ESTABLISHED oluyor. Sunucu ise ancak bu üçüncü mesaj eline geçince aynı duruma varıyor. İki uç aynı anda kurulmuş sayılmıyor.

Üç mesajı ve iki tarafın durumlarını birlikte izlemek istersen:

Sunucudaki uygulama süreci bağlantıyı tam o anda görüyor; kabul için bekleyen çağrı üçüncü mesaj varınca dönüyor. Dinleyen soket ile konuşan soket ayrı şeylerdi; el sıkışma bitince sunucuda ikincisi yaratılıyor ve dinleme kesintisiz sürüyor.

Beşinci bölümün apartmanına dönersek: kapıyı çalmak içeri girmek değil. Kapı açılacak, içeriden bir ses cevap verecek, sen de o sesi duyduğunu belli edeceksin. Üç mesaj tam olarak bu. İkinci mesaj istemciye sunucunun canlı olduğunu kanıtlıyor, üçüncü mesaj sunucuya istemcinin canlı olduğunu. Daha kısası yok.

Üçüncü mesajın boş gitmesi zorunlu değil; içinde istemciden sunucuya veri taşıyabiliyor. Bağlantı zaten tam çift yönlü (full duplex): aynı bağlantıda veri iki yöne birden akıyor. İki ucun da kendi başlangıç numarasını ilan etmesinin sebebi bu.

İki uç aynı anda kurulum isteği gönderirse sorun çıkmıyor. İkisi de SYN-SENT durumundan SYN-RECEIVED durumuna, oradan ESTABLISHED durumuna geçiyor ve standart bunu desteklemeyi şart koşuyor. Aynı port çifti arasında aynı anda yalnızca tek bir bağlantı olabiliyor; ama tek bir port, farklı karşı portlarla çok sayıda bağlantı taşıyabiliyor.

Bir ayrıntı da sıra numarası uzayında duruyor. SYN bayrağı orada 1 bayt yer kaplıyor, bu yüzden onay numarası başlangıç numarasının bir fazlası oluyor. Salt onay ise hiç yer kaplamıyor. Kaplasaydı onayların onayı diye sonsuz bir zincir doğardı ve standart bunu açıkça yazıyor.

İki ucun ilan ettiği numara sıfırdan başlamıyor. Her bağlantı için yeniden ve tahmin edilemeyecek biçimde seçiliyor. Sebebi güvenlik: numarayı bilen biri trafiği hiç görmeden o bağlantıya veri yazabiliyor. Numaranın burada yaptığı tek iş kurulumu işaretlemek. Kayıpları bulup sırayı düzelten asıl işini 58. bölümde çalıştıracağız; burada yalnızca ilan ediyorum.

El sıkışma aynı zamanda bir pazarlık

İlk iki mesaj yalnızca selamlaşma taşımıyor. Başlıktaki alanlar burada dolduruluyor ve seçeneksiz haliyle o başlık 20 bayt.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|         kaynak portu          |          hedef portu          |
+-------------------------------+-------------------------------+
|                         sıra numarası                         |
+---------------------------------------------------------------+
|                         onay numarası                         |
+-------+-------+---------------+-------------------------------+
| uzun. | ayrl. |   bayraklar   |            pencere            |
+-------+-------+---------------+-------------------------------+
|        checksum        |    acil veri işaretçisi       |
+-------------------------------+-------------------------------+
|                  seçenekler (0 ile 40 bayt)                   |

Alanları soldan okuyalım. Kaynak portu ile hedef portu 16’şar bit; soket four-tuple’ının taşıma tarafı bu iki alan. Sıra numarası ile onay numarası 32’şer bit, yani 4’er bayt. Onay numarası beklenen bir sonraki baytın numarasını taşıyor, ACK bayrağı da o alanın geçerli olduğunu söylüyor.

Başlık uzunluğu alanı 4 bit ve başlığı 32 bitlik kelimeler cinsinden ölçüyor. Üst sınırı on beş kelime, yani 60 bayt. Seçeneklere kalan en fazla yer 40 bayt. Taşıma başlığı ile IPv4 başlığı birlikte her veri birimine en az 40 bayt sabit yük bindiriyor.

Bayrak alanı bugün sekiz atanmış denetim biti taşıyor ve her birinin tek cümlelik bir işi var:

Listeyi IANA’nın TCP Header Flags defteri yönetiyor; yeni bir bit oraya yazılmadan kullanılamıyor. Bağlantı yönetimini bunlardan üçü yapıyor: RST, SYN ve FIN.

RST ile FIN arasındaki fark ince ama sahada belirleyici. FIN kibar bir kapanış: “benim söyleyeceğim bitti, sen devam edebilirsin”. RST ise “böyle bir bağlantı yok, ne gönderdiysen at” demek. Kapalı bir porta bağlanmaya çalıştığında aldığın o anlık ret, teldeki karşılığıyla tam olarak bu bayraktır — bekleyip zaman aşımına uğramamanın sebebi de o.

Son ikisi ilerideki bir durağa bağlanıyor: tıkanıklık kayıp beklemeden, yol üstündeki bir yönlendirici tarafından da bildirilebiliyor. ECE ve CWR o bildirimin taşıma katmanındaki iki ucu.

Seçenekler: pazarlığın asıl yapıldığı yer

Pazarlık kısmı seçeneklerde duruyor ve bunların çoğu yalnızca SYN bayraklı segmentlerde gönderilebiliyor. Yani anlaşma ya el sıkışmada olur ya hiç olmaz; bağlantı kurulduktan sonra taraflar bu ayarları değiştiremiyor.

İlk dördü bağlantının ömrü boyunca etkili olan kararlar ve üçü de bu kitapta ilerideki bölümlerin konusu: pencere ölçekleme ile seçici onay 59. bölümde kayan pencereyi kurarken, zaman damgası ise 61. bölümde gecikmeyi ölçerken çalışacak.

Bir seçenek karşı tarafça anlaşılmazsa sessizce yok sayılıyor — cevapta o seçenek geri gelmiyor ve gönderen “desteklenmiyor” diye anlıyor. Pazarlığın “hayır” demesi bu: konuşmamak.

MSS seçeneği hiç gelmezse varsayılan devreye giriyor: IPv4’te 536 bayt, IPv6’da 1.220 bayt. İkisi de taban boydan başlık yükü düşülerek çıkıyor, 576 bayt eksi 40 bayt ve 1.280 bayt eksi 60 bayt. Bu değerler kimseyi mutlu etmiyor ama kimseyi de kırmıyor.

Üçüncü mesaj hiç gelmezse?

Önce kapıyı çalmanın cevabına bakalım. Kapalı bir porta gelen bağlantı isteği sessizlikle karşılanmıyor; geriye RST ile ACK birlikte dönüyor. Açık portta ise SYN ile ACK dönüyor. Fark tek bir segmentte görünüyor.

Bu yüzden port taraması el sıkışmanın ortasında durabiliyor. Yarı açık tarama (nmap -sS) üçüncü mesajı hiç göndermiyor, yerine RST atıp bağlantıyı koparıyor; el sıkışma tamamlanmadığı için uygulamanın günlüğüne hiçbir bağlantı düşmüyor. Üçüncü mesajı gönderip el sıkışmayı bitiren tarama (nmap -sT) ise iz bırakıyor.

Aynı boşluk bir saldırıya da açık. SYN seli ağı ya da belleği değil, port numarasına bağlı yarı açık bağlantı kuyruğunu tüketmeyi hedefliyor. Saldırgan çoğu zaman sahte kaynak adresle SYN yağdırıyor; ikinci mesajın cevabı hiç gelmiyor ve kayıt kuyrukta asılı kalıyor. Varsayılan kuyruk derinliği tipik olarak yarım düzine ile birkaç düzine arasında. Saldırının ucuzluğu tam buradan geliyor.

Kayıt sonsuza kadar durmuyor. Örnek bir uygulamada ilk SYN-ACK gönderilirken 75 saniyelik bir zamanlayıcı kuruluyor. Ama zamanlayıcı dolmadan kuyruk dolarsa gerçek istemciler kapıda kalıyor.

Standart yarı açık bağlantıyı ayrıca tanımlıyor: bir uç kapatmış ya da çökmüş, diğerinin haberi yok. Böyle bir bağlantı sessizce sürmüyor. İki yönden birine veri gönderilmeye çalışıldığı anda RST ile sıfırlanıyor. Kural genel: bağlantı henüz açık değilken gönderilmemiş bir şeyi onaylayan geçersiz bir ACK gelirse RST gidiyor. Gecikmiş eski bir SYN’in yarattığı sahte kurulum böyle iptal ediliyor.

Kuyruğun neden bu kadar kolay dolduğu da ölçülmüş. Bağlantı durumunu tutan yapı Linux 2.6.10’da 1.300 baytın üstünde yer kaplıyor; ölçümleri derleyen belge RFC 4987. SYN cookie savunması bu yükü tümden kaldırıyor. Sunucu SYN-RECEIVED için hiç durum ayırmıyor. Tutması gereken durumu ikinci mesajın sıra numarasına kodluyor. Üçüncü mesajın onay numarası o değeri geri getirince durum yeniden kuruluyor.

Kuyruk diye bir yapı olmayınca taşacak bir şey de kalmıyor. Bedeli, sıra numarasına sığmayan bazı TCP seçeneklerinin bu kipte kaybolması; çoğu sistemde varsayılan olarak kapalı duruyor. Sunucu durumu saklamak yerine karşı tarafa taşıtınca tüketilebilecek kaynağı da ona devretmiş oluyor. Aynı fikri, durumu senin makinene yazan çerez mekanizmasında yeniden göreceğiz.

Bu üç mesajın faturası ne kadar?

Bedeli ölçmenin birimi belli. El sıkışmanın maliyeti tam olarak bir gidiş-dönüş süresi, kısaca 1 RTT. Bağlantı kurup tek bir nesne çekmek ise 2 RTT artı aktarım süresi ediyor.

Bağlantısız gönderim kurulum için hiçbir gidiş-dönüş ödemiyordu; aradaki fark tam olarak bu bir tur. Taşıma el sıkışması ile güvenlik el sıkışması ayrı yapıldığında iki ardışık el sıkışma oluyor ve fatura ikiye katlanıyor. İkisini tek el sıkışmada birleştiren protokoller, ve oturum biletiyle kurulumu sıfır gidiş-dönüşe indiren yöntemler tam olarak bu bedeli hedef alıyor.

İlk SYN’in ağ için hiçbir ayrıcalığı yok. Yetkili sunucudan öğrenilen adres burada ilk kez bir bağlantı isteğinin üstüne yazılıyor. Paketin başına gelen dört gecikme onun için de aynen geçerli; sıradan bir paket gibi, alan adları arası yönlendirmeyle yol alıyor.

Kapanış tarafı ise kurulumdan pahalıya geliyor ve dört mesaj sürüyor: FIN, ACK, FIN, ACK. Sebebi bağlantının tam çift yönlü olması — iki ayrı yön var ve her yön ayrı ayrı kapanıyor. Buna yarı kapanma deniyor: bir uç “benim söyleyeceğim bitti” derken karşı taraf konuşmaya devam edebiliyor.

Kapanışın da kendi durum adları var ve iki taraf ayrı yollardan yürüyor:

İkinci satırın ortasındaki italik adım bir arıza teşhisi taşıyor. CLOSE-WAIT durumundan çıkışı protokol değil uygulama tetikliyor: karşı taraf kapandı, çekirdek onayladı, ve şimdi sıra senin programının soketi kapatmasında. Program bunu yapmayı unutursa soket orada kalıyor. Bir sunucuda yığınla CLOSE-WAIT görüyorsan sorun ağda değil, kodda — bir yerde kapatılmayan bir tutamaç var. Buna karşılık yığınla TIME-WAIT görmek normaldir; o durumdan çıkışı zamanlayıcı sağlıyor.

Onay kendi FIN’iyle aynı segmentte birleşirse mesaj sayısı üçe iniyor. Kapanışı başlatan taraf TIME-WAIT durumunda en uzun segment ömrünün iki katı kadar bekliyor. RFC 9293 o ömrü 2 dakika sayıyor, yani bekleme 4 dakika.

Bu dört dakikanın iki ayrı gerekçesi var ve ikisi de bir arızayı önlüyor. Birincisi son onayın kaybolma ihtimali: ACK yolda düşerse karşı taraf FIN’ini yeniden gönderiyor ve onu tekrar onaylayacak birinin ayakta olması gerekiyor. İkincisi gecikmiş kopya: aynı four-tuple hemen yeniden kullanılırsa eski bağlantının yolda kalmış bir segmenti yeni konuşmanın içine düşebiliyor. Bekleme, o segmentlerin ömrünü doldurmasını garanti ediyor. Beşinci bölümde geçici port havuzunun neden daraldığını sormuştuk; cevabı bu dört dakika.

Buraya kadar anlatılan her adımı kendi makinende görebilirsin. Wireshark’ta tcp.flags.syn == 1 && tcp.flags.ack == 0 süzgeci yalnızca ilk mesajları listeliyor, yani bir sayfa açtığında kaç ayrı bağlantı kurulduğunu orada sayabilirsin. Komut satırında ise ss -tan çıktısını izle: aynı bağlantı sırayla SYN-SENT, ESTAB ve kapanıştan sonra TIME-WAIT satırlarında görünüyor.

Özet

Peki, ne öğrendik?

• Üçüncü mesaj bir doğrulama adımı: ilk isteği alan taraf onun taze mi bayat mı olduğunu bilemediği için gönderene doğrulatıyor.
• Kurulum aynı zamanda pazarlık: en büyük segment boyu yalnızca SYN bayraklı segmentlerde gönderilebildiği için boy anlaşması ya el sıkışmada olur ya hiç olmaz.
• Başlangıç sıra numarası bir güvenlik parametresi: tahmin edilebilirse yol üstünde hiç bulunmayan bir saldırgan kurulmuş bağlantıya veri sokabiliyor.
• Kaynak ayırma saldırının hedefi: yarı açık bağlantı kuyruğu sahte kaynak adresli SYN’lerle doluyor ve gerçek istemciler kapıda kalıyor.
• Bağlantının faturası bir gidiş-dönüş: veri gitmeden önce ödenen bu tur, garanti vermeyen taşımada hiç ödenmiyor.

Üç mesaj bitti, iki uç da karşısının orada olduğunu biliyor ve sıra numaraları anlaşıldı. Bağlantı kuruldu; peki aradaki herkes ne yazdığını okuyabilir mi?

Bölüm 8: Simetrik Şifreleme

Bağlantı kuruldu ve imleç parolanın yanında bekliyor. Yazacağın şey aradaki onlarca cihazın önünden geçecek, ve hepsi onu olduğu gibi okuyabilecek.

Okunamaz hâle getirmek varsayılan bir davranış değil, ayrı bir hazırlık gerektiriyor ve o hazırlığın ilk yarısını bu bölümde kuruyoruz.

Aradaki herkes ne görüyor?

Ağ güvenliği tek bir vaat gibi konuşuluyor. Aslında dört ayrı vaat var ve hiçbiri diğerinin yerine geçmiyor. Gizlilik, içeriği yalnızca gönderenin ve hedeflenen alıcının anlayabilmesi. Kimlik doğrulama, iki tarafın da karşısındakinin kim olduğunu teyit edebilmesi. Mesaj bütünlüğü, mesajın yolda ya da sonrasında fark edilmeden değiştirilememesi. Erişilebilirlik ise hizmetin kullanıcılara açık kalması.

Bu bölümde yalnızca birincisini çözüyoruz. Şifrelemenin bütünlük vermediğini baştan bilmen gerekiyor: okunamaz bir mesaj, değiştirilemez bir mesaj anlamına gelmiyor. Bütünlük ayrı bir mekanizma istiyor ve o mekanizmanın kendi anahtarı var.

Aradaki saldırganın elinde ne olduğunu beş başlıkta toplayabilirsin. Mesajları yakalayıp dinleyebiliyor. Kurulu bir bağlantıya kendi mesajını sokuşturabiliyor. Kaynak adresini, hatta paketteki herhangi bir alanı sahteleyebiliyor. Süregelen bir bağlantıda taraflardan birini çıkarıp yerine geçebiliyor. Kaynakları boğarak hizmeti tümden engelleyebiliyor.

Bunların ilki özel bir yetenek bile istemiyor. Karışık (promiscuous) moda alınmış bir ağ arayüzü, yanından geçen bütün paketleri okuyup kaydediyor; parolalar dahil. Paylaşımlı Ethernet ve kablosuz gibi yayın ortamlarında bu doğrudan çalışıyor.

Sahtecilik de ucuz. Paketin üstündeki kaynak adresi bir kanıt taşımıyor; yalnızca bir iddia. O alanı gönderenin kendisi dolduruyor, ve doğru doldurduğunu kimse denetlemiyor.

SYN, SYN-ACK ve ACK ile kurulan bağlantı bir kanal açıyor, ama o kanal hiçbir şey saklamıyor. Sade bir TCP ya da UDP soketinde hiç şifreleme yok: sokete yazdığın düz metin parola, internette düz metin olarak yol alıyor. Bunun en görünür karşılığı adres çubuğunda duruyor. HTTP varsayılan olarak 80. portu kullanıyor, HTTPS ise 443’ü; iyi bilinen portlar bir gelenekti. HTTPS ayrı bir taşıma değil; HTTP ile TLS’in birleşimi.

Şifrelemenin üç kelimesi, saldırganın üç modeli

Kriptografinin sözlüğü üç terimden ibaret. Açık metin (plaintext) gönderilecek şey, şifreli metin (ciphertext) telde giden şey, anahtar ise ikisi arasındaki dönüşümü belirleyen sayı. Şifreleme algoritması açık metni anahtarla şifreli metne çeviriyor, çözme algoritması tersini yapıyor.

Bunu bir kasayla düşünmek işi kolaylaştırıyor. Kasanın modeli herkesçe biliniyor ve mağazadan satın alınabiliyor; onu güvenli yapan şey kombinasyonun sende kalması. Şifreleme de aynı yere yaslanıyor: algoritma yayımlanmış durumda, gizli tutulan tek şey anahtar. Haritalaması şöyle: kasanın mekanizması algoritma, kombinasyon anahtar, içine koyduğun belge açık metin, kilitli kasa ise şifreli metin. Benzetme şurada biter: kasayı arkadaşına yollarken kombinasyonu telefonda söyleyebilirsin, ağda ise o telefon hattı da saldırganın dinlediği hat.

Bir şemayı kırmanın üç ayrı zemini var. En zayıfı yalnızca şifreli metin saldırısı: saldırganın elinde sadece ciphertext var ve iki yolu kalıyor. Anahtar uzayını baştan sona taramak, ya da metnin istatistiğini çözümlemek. Bilinen açık metin saldırısında iş kolaylaşıyor, çünkü saldırgan bazı şifreli metinlerin açık karşılığını da biliyor. Seçilmiş açık metin saldırısında ise istediği metnin şifrelisini elde edebiliyor. Bu en güçlü model ve iyi bir şema ona karşı da dayanmak zorunda.

Bu bölümün konusu olan aile simetrik anahtarlı şifreleme ve tanımı tek cümle: iki taraf aynı anahtarı paylaşıyor. Aynı anahtar hem kilitliyor hem açıyor.

AES bir mesajı değil, bir bloğu şifreliyor

Bugün kullanılan simetrik şifrenin adı AES ve tanımını bilmek bir yanlış anlamayı baştan kesiyor: AES bir mesajı şifrelemiyor, tam olarak 128 bitlik bir bloğu şifreliyor. 16 bayt girer, 16 bayt çıkar. Anahtar 128, 192 ya da 256 bit olabiliyor ve uzunluk tek bir şeyi değiştiriyor — kaç tur döneceğini: sırasıyla 10, 12 ve 14 tur.

Her tur aynı dört adımı tekrarlıyor: bayt değiştirme, satır kaydırma, sütun karıştırma ve tur anahtarını ekleme. Üçü karıştırıyor, dördüncüsü anahtarı işin içine sokuyor. Fikir Shannon’ın koyduğu iki ölçüte dayanıyor — karıştırma, açık metnin her bitinin çıktının her bitini etkilemesi; yayma, anahtar ile şifreli metin arasındaki ilişkinin istatistiksel olarak izlenemez olması. Tek bir turda ikisi de zayıf; on turda pratikte imkânsız.

Ama senin isteğin 16 bayt değil. Uzun bir mesajı bloklara bölüp her birini ayrı ayrı şifrelemek gerekiyor ve bunun nasıl yapılacağı ayrı bir karar. Kararın adı çalışma kipi ve şifrenin kendisi kadar önemli.

Tablodaki XOR, iki biti karşılaştıran en basit işlem: ikisi farklıysa 1, aynıysa 0 veriyor. Aynı değerle iki kez uygulandığında ilk hâline dönmesi, onu şifrelemenin vazgeçilmez aleti yapıyor.

ECB’nin kusuru soyut değil, gözle görülür. Bir görüntü dosyasını ECB ile şifrelersen aynı renkteki bölgeler aynı şifreli bloğa dönüşür ve resmin hatları şifreli çıktıda okunmaya devam eder. Şifreleme yapıldı, ama içerik hâlâ tanınıyor. Bu yüzden ECB pratikte hiçbir yerde kullanılmıyor.

CBC ile CTR’nin ortak şartı ise bir sayı: her mesajda yeni bir başlangıç değeri. CBC’de adı başlangıç vektörü (IV), CTR’de sayacın başlangıcı (nonce). İkisi de gizli olmak zorunda değil, ama tekrarlanmamak zorunda. CTR kipinde aynı sayacı iki farklı mesaj için kullanırsan iki şifreli metnin XOR’u iki açık metnin XOR’unu verir; anahtar hiç kırılmadan içerik açığa çıkar. Kriptografide en sık yapılan uygulama hatalarından biri tam olarak budur.

Son satır bugünün varsayılanı ve bir eksiği kapatıyor: şifreleme tek başına kurcalamayı engellemiyor. CTR kipinde şifreli metindeki bir biti çeviren saldırgan, açık metindeki karşılık gelen biti de çevirmiş oluyor — anahtarı hiç bilmeden. GCM bunun üstüne bir doğrulama etiketi ekliyor ve alıcı etiketi tutmayan mesajı hiç çözmüyor. Aynı anda gizlilik ve bütünlük veren bu aileye AEAD deniyor. TLS 1.3’ün eski şifre takımlarını tümden atmasının sebebi de bu: artık yalnızca AEAD kabul ediliyor.

Tanımın açıkta bıraktığı şeyin de bir adı var: anahtar dağıtımı. İki taraf o anahtar değerinde nasıl anlaşacak?

Ev ağında bu sorunun cevabı elden veriliyor. WPA2 ve WPA3’ün kişisel kipinde parolayı cihaza sen yazıyorsun; değer ağdan hiç geçmiyor. Katılım sırasında telde dolaşan şey de parola değil, ondan türetilen taze bir AES anahtarı; o türetmenin adımlarını 29. bölümde açacağım. Uzaktaki bir sunucu için cevabı 9. bölüme bırakıyorum; önce anahtarın kendisini tanımak gerekiyor.

Anahtar kısaysa akıl gerekmiyor

Standartlaşan ilk simetrik şema DES oldu: 1993 tarihli, NIST kaynaklı bir ABD şifreleme standardı. 56 bitlik bir anahtar kullanıyor ve girdiyi 64 bitlik açık metin blokları halinde alıyor.

DES bir blok şifresi, ve blok şifreleri çıplak kullanılmıyor. Etraflarına bir kip sarılıyor; DES’te bu, şifreli blok zincirleme (cipher block chaining). Kipin işi şu: aynı açık metin bloğu her seferinde aynı şifreli çıktıyı vermesin diye her blok bir öncekine bağlanıyor. Bu, şifreleme algoritmasının kendisi değil; onun etrafındaki kullanım kuralı.

DES Challenge’da 56 bit anahtarla şifrelenmiş bir ifade, kaba kuvvetle bir günden kısa sürede çözüldü. Bilinen iyi bir analitik saldırı yoktu. Şemayı düşüren şey zekâ değil, anahtarın kısalığıydı.

Ayakta tutma çabası 3DES oldu: üç farklı anahtarla üç kez şifreleme. Kalıcı cevap Kasım 2001’de geldi. NIST’in yeni simetrik anahtar standardı AES DES’in yerini aldı ve bugün hâlâ orada. AES veriyi 128 bitlik bloklar halinde işliyor, yani tek seferde 16 bayt. Anahtar 128, 192 ya da 256 bit olabiliyor; blok boyu sabit kalıyor, değişen anahtar. Bir HTTP isteğinin ilk satırı bile birden çok bloğa yayılıyor.

Ölçek farkı düz metinde kayboluyor, o yüzden yan yana koymak gerekiyor:

Alt satır bu tablonun en sert yeri. Aynı kaba kuvvet donanımı DES anahtar uzayını 1 saniyede tarıyorsa, AES’in en kısa anahtarında 149 trilyon yıl harcıyor. Arada 2^72 kat var.

Aynı anahtarla kaç kayıt gönderebilirsin?

Anahtarın uzunluğu tek başına yetmiyor. Aynı anahtarın ne kadar iş görebileceğini üç kural sınırlıyor.

İlk kural anahtarı işlere bölmek. Aynı anahtarı birden çok kriptografik işlev için kullanmak kötü kabul ediliyor, o yüzden şifreleme ile mesaj kimlik doğrulama kodu (MAC) TLS 1.2 ve öncesinde ayrı anahtarlar kullanıyordu: dört anahtar türetiliyordu, iki yönün her biri için birer şifreleme ve birer MAC anahtarı. TLS 1.3’te ayrı MAC anahtarı yok: şifreleme ile doğrulama tek AEAD algoritmasında birleştiği için bölme başka eksende yapılıyor, yön başına ve evre başına ayrı anahtar.

İkinci kural aynı girdiyi aynı anahtarla iki kez şifrelememek. Bunun aracı nonce, yani ömür boyu yalnızca bir kez kullanılan sayı. Tekrar oynatma (playback) saldırısını kıran şey bu. Kaydedilip sonra yeniden gönderilen bir mesaj, yeni nonce’a cevap veremiyor.

TLS 1.3’te kayıt koruması AEAD ile yapılıyor ve AEAD dört girdi alıyor: tek bir anahtar, bir nonce, açık metin, ve kimlik doğrulamaya dahil edilecek ek veri. TLS’te ek veri kaydın başlığı. Nonce ise elle seçilmiyor. Kaydın 64 bitlik sıra numarası ağ bayt sırasında kodlanıyor, sola sıfırla dolduruluyor ve o yönün statik IV’siyle XOR’lanıyor. Sıra numarası okuma ve yazma için ayrı tutuluyor, her kayıttan sonra bir artıyor, anahtar değişiminde sıfırlanıyor. Bir trafik anahtarıyla gönderilen ilk kayıt 0 numarasını kullanmak zorunda. Böylece aynı anahtar altında iki kayıt asla aynı nonce’u görmüyor.

Üçüncü kural anahtarı zamanında bırakmak. AES-GCM ile tek bir bağlantıda yaklaşık 24 milyon tam boy kayıt şifrelenebiliyor; sonrasında anahtarın tazelenmesi gerekiyor. Bir anahtarın ömrü saatle ölçülmüyor, kayıt sayacıyla ölçülüyor.

TLS’in gizlilik vaadi dürüst ve sınırını da söylüyor. Kanal kurulduktan sonra gönderilen veri yalnızca uçlara görünüyor, ama uzunluk gizlenmiyor. İsteğinin kaç bayt olduğu dışarıdan sayılabiliyor; bulanıklaştırmak isteyen kayıtlara dolgu ekliyor.

Bütün bunları kendi makinende görebilirsin. Bir terminalde sudo tcpdump -n -A -i any 'tcp port 80 or tcp port 443' çalıştır, başka bir terminalde aynı sayfayı iki kez iste: önce curl http://example.com/, sonra curl https://example.com/. İlk çıktıda istek satırı ekranda düz okunuyor. İkincisinde yalnızca kayıt başlıkları görünüyor, gerisi anahtarın altında.

Özet

Peki, ne öğrendik?

• Güvenlik dört ayrı vaat: gizlilik, kimlik doğrulama, mesaj bütünlüğü ve erişilebilirlik. Şifreleme bunlardan yalnızca ilkini veriyor.
• Korumasızlık varsayılan: sade bir sokete yazılan parola telde düz metin gidiyor, ve yanından geçen paketleri okumak için karışık moda alınmış bir arayüz yetiyor.
• Şemayı düşüren şey çoğu zaman algoritma değil, anahtarın kısalığı: DES’i bitiren analitik bir buluş değildi, 56 bitlik uzayın taranabilir olmasıydı.
• Anahtarın bir kullanım bütçesi var: her kayıt nonce’unu sıra numarasından türetiyor ve tek bağlantıda şifrelenebilecek kayıt sayısının bir tavanı bulunuyor.

Şifrelemenin gücü artık elinde ve nereden geldiğini biliyorsun. Bu bölüm boyunca iki tarafın aynı anahtarı bildiğini varsaydım. Şifreleme var, ama anahtarı karşı tarafa nasıl ulaştıracaksın?

Bölüm 9: Açık Anahtarlı Kriptografi

Şifreleme kuruldu, anahtar hazır. Ama o anahtarı hiç tanışmadığın bir sunucuya nasıl ulaştıracaksın?

Ulaştırmayacaksın: iki taraf hiç tanışmadan, açıkta konuşarak ortak bir sırra varabiliyor.

İki anahtar, biri herkesin gözü önünde

Simetrik şifrelemenin şartı tekti: tek gizli anahtar, iki yön, ve o anahtarı iki tarafın da önceden bilmesi. Şart tam burada patlıyor. Tarayıcın bir sunucuya ilk kez bağlanıyor ve ortada paylaşılmış hiçbir sır yok.

Açık anahtarlı kriptografi anahtarı ikiye ayırıyor. Açık anahtar şifreler; sunucu onu isteyen herkese verir. Özel anahtar çözer, yalnızca alıcıda durur ve hiçbir zaman hatta çıkmaz. Sana kilit veriliyor, anahtar verilmiyor.

Kasa hâlâ ortada duruyor ama artık iki ayrı kombinasyonu var: biri yalnızca kilitliyor, öteki yalnızca açıyor. Kilitleyen kombinasyonu herkese dağıtabilirsin, kasanın içi yine de güvende kalır. Benzetme şurada biter: gerçek bir kasada aynı kombinasyon hem kilitler hem açar, burada iki yön matematiksel olarak birbirinden ayrılmıştır.

Şemanın iki şartı var. Birincisi, iki anahtar birbirini geri almalı: açık anahtarla şifrelenen mesajı özel anahtar aynen açmalı. İkincisi, açık anahtardan özel anahtarı hesaplamak pratikte imkânsız olmalı.

Fikir iki çalışmayla yayımlandı: 1976’da Diffie-Hellman, 1978’de RSA. Aynı fikir kabaca aynı yıllarda Birleşik Krallık’ta da doğmuştu, ama orada gizli tutuldu. İki bin yıldır yalnızca tek anahtarla yürüyen bir alan birkaç yılda ikiye ayrıldı.

Bunun nerede çalıştığını görmek için uzağa gitmen gerekmiyor. Tarayıcın iyi bilinen port numaralarından birine, 443’e bağlanırken de aynı iki anahtar devreye giriyor. Uzak bir makineye kabuk açtığında da öyle. Fark protokolde, fikirde değil.

RSA tek bir işlemin üstünde duruyor

Her bit dizisi tek bir tam sayıya karşılık gelir. Bir mesajı şifrelemek bu yüzden bir sayıyı şifrelemekle aynı şeydir. RSA’nın kullandığı işlem de tek: x mod n, yani x’in n’e bölümünden kalan.

Ad, üç yazarının baş harflerinden geliyor: Rivest, Shamir, Adleman. Anahtar üretimi beş adımda bitiyor. Gerçekte asallar 1024 bit uzunluğunda seçilir; burada elle takip edebilmen için ikisini küçük tuttum.

1. p = 11, q = 13           iki asal seçilir
2. n = 143                  n = p · q
   z = 120                  z = (p-1)(q-1)
3. e = 7                    7 ile 120'nin ortak böleni yok
4. d = 103                  7 · 103 = 721,   721 mod 120 = 1
5. açık anahtar (143, 7)    özel anahtar (143, 103)

Modül iki anahtarda da ortak; ayıran şey üs. Şifreleme ile çözme aynı kalıbı iki kez uyguluyor:

şifreleme:  c = m^e mod n   ->   9^7 mod 143 = 48
çözme:      m = c^d mod n   ->   48^103 mod 143 = 9

Dokuzun yedinci kuvveti 4782969 ediyor ve 143’e bölündüğünde kalan 48. Şifreleme yalnızca n’den küçük m için tanımlı; uzun veri bu yüzden bloklara ayrılıyor.

Güvenlik tek bir varsayıma dayanıyor: büyük bir sayıyı çarpanlarına ayırmak zordur. Özel anahtarı bulmak, n’yi p ile q’ya ayırmakla aynı iştir. 143’ü kafadan çarpanlarına ayırırsın; 2048 bitlik bir n için aynı işi yapan pratik bir yöntem yok.

İkinci özellik daha az bilinir ve bu bölümün sonunu belirler: sıra değiştirilebilir. Önce açık sonra özel anahtar uygulamak da, önce özel sonra açık anahtar uygulamak da mesajı aynen geri verir. İmzanın dayanağı bu simetri.

Bir de bedel var. Üs alma hesap açısından pahalı ve simetrik şifreleme aynı işi en az yüz kat hızlı yapıyor. Bu yüzden açık anahtar veriyi şifrelemek için kullanılmıyor. İkinci bir anahtarı, oturum anahtarını kurmak için kullanılıyor; veriyi o simetrik anahtar şifreliyor.

Açıkta konuşup aynı sayıda buluşmak

Diffie-Hellman anahtar uzlaşması ayrı bir algoritmadır ve bir şifreleme yöntemi değildir. Mesaj taşımaz. Yaptığı tek iş, iki tarafın ortak bir sayıda buluşmasını sağlamak.

Açık değerler büyük bir asal p ve p’den küçük bir taban g. İkisi de herkese açık. Her taraf kendi gizli sayısını bağımsız seçiyor, g’nin o kuvvetini p modülünde hesaplıyor ve çıkan değeri hatta gönderiyor.

açık değerler:  p = 97,   g = 5

sen     gizli 17   ->   5^17 mod 97 = 83     (hatta 83 gider)
karşı   gizli 29   ->   5^29 mod 97 = 74     (hatta 74 gider)

sen     74^17 mod 97 = 29
karşı   83^29 mod 97 = 29

Aynı sayıya iki ucun ayrı ayrı nasıl vardığını adım adım izleyelim:

Hattan yalnızca dört sayı geçti: 97, 5, 83 ve 74. Gizli sayılar hiç gönderilmedi. Ortak sır da gönderilmedi; iki taraf onu kendi tarafında ayrı ayrı hesapladı. Dinleyen taraf dört sayıyı da görüyor, sırra varamıyor.

Yukarıdaki dört satırı bir hesap makinesinde tekrarlayabilirsin; sonuç her seferinde aynı çıkar. İki tarafın birbirinden habersiz hesapladığı sayı, aynı sayı. Üç mesajlık el sıkışmanın bir gidiş-dönüş bedeli vardı; bu uzlaşma da onun üstüne biniyor. Bugünün güvenli web bağlantısı anahtar değişimi için Diffie-Hellman’ı zorunlu tutuyor; el sıkışmanın bunu nasıl yürüttüğünü 10. bölümde açacağız.

openssl s_client -connect www.rfc-editor.org:443 -tls1_3 </dev/null 2>/dev/null | grep 'Temp Key'

Parmak izinden imzaya

Aynı bedel imzayı da şekillendiriyor. İmza mesajın kendisine değil, özetine atılır. Kriptografik özet fonksiyonu girdinin boyu ne olursa olsun sabit uzunlukta bir çıktı üretir.

MD5 RFC 1321’de tanımlı ve dört adımlı bir süreçte 128 bit üretiyor, yani 16 bayt. SHA-1’in künyesi NIST FIPS PUB 180-1 ve çıktısı 160 bit, yani 20 bayt. Onaltılık yazıldığında ilki 32, ikincisi 40 karakter tutuyor.

Eşleme çoktan-bire. Sonsuz sayıda girdi sonlu sayıda çıktıya düştüğü için çakışma matematiksel olarak kaçınılmaz.

Checksum da sabit uzunlukta bir özet üretiyordu ve o da çoktan-bire bir eşlemeydi. Aradaki fark tek bir şartta. Checksum’da aynı değeri veren ikinci bir mesaj üretmek kolaydır; kriptografik özette, verilen bir özetten onu üreten mesajı bulmak hesap açısından yapılamaz olmalıdır. 16 bitlik bir toplam bu şartı karşılamaz.

Burada gizlilikten ayrı bir hedef devreye giriyor. Mesaj bütünlüğü şifrelemeden gelmiyordu; o boşluğu özet fonksiyonu dolduruyor.

Şimdi sayısal imza. Mesajın özeti gönderenin özel anahtarıyla şifrelenir ve mesajla birlikte gider. Doğrulama üç adımdır: imzayı gönderenin açık anahtarıyla çözersin, eline geçen mesajın özetini kendin hesaplarsın, ikisini karşılaştırırsın. Eşitlerse tek işlemle iki soru birden cevaplanmış olur. İmzayı atan özel anahtarı kullanmıştır ve mesaj yolda değişmemiştir.

Simetrik anahtarla bu kanıt kurulamaz. Anahtar iki taraftadır ve o mesajı ikisi de üretebilirdi. Açık anahtarlı imzada ise alıcı mesajı ve imzayı mahkemeye götürüp imzayı atanın kim olduğunu kanıtlayabilir; buna inkâr edilemezlik deniyor.

Aynı matematik, kimlik doğrulamanın kendisinde de aynen çalışıyor. Karşı taraf sana bir nonce yollar. Sen onu özel anahtarınla şifreleyip geri gönderirsin, o senin açık anahtarınla çözüp aynı sayıyı bulur. Kaydedilmiş eski bir cevabın tekrar oynatılması böyle kesilir.

Ama bir boşluk var. Araya giren biri her iki tarafa da öteki taraf gibi görünürse iki ayrı bağlantı kurar ve ikisini birden okur; buna ortadaki adam saldırısı deniyor. Matematik iki uçta da doğru çalıştı; yanlış olan, anahtarın kime ait olduğuydu.

Aynı boşluk imzada da duruyor. Saldırgan kendi açık anahtarını başkasınınmış gibi sunarsa doğrulama kusursuz çalışır ve yanlış kişiyi doğrular. Yetkili sunucudan dönen kaydın doğruluğunu kanıtlayan şey de bir imzaydı ve o imza aynı boşluğun üstünde duruyor. Bir açık anahtarın gerçekten kime ait olduğunu onaylayan sertifika zincirini 11. bölümde kuracağız.

Özet

Peki, ne öğrendik?

• Açık anahtar ikiye ayrılmış tek bir kimliktir: şifreleyen yarısı herkeste durur, çözen yarısı sahibinden hiç ayrılmaz.
• RSA’nın tamamı tek bir modüler üs alma işlemidir ve güvenliği, büyük bir sayıyı çarpanlarına ayırmanın zorluğuna dayanır.
• Diffie-Hellman bir uzlaşmadır: hatta hiç görünmeyen ortak sırrı iki taraf kendi tarafında ayrı ayrı hesaplar.
• İmza mesajın kendisine değil özetine atılır ve tek doğrulamayla hem imzalayanı hem de mesajın değişmediğini kanıtlar.

Anahtar sorunu çözüldü, imza mekanizması elimizde. Simetrik şifreleme, anahtar uzlaşması ve imza artık ayrı ayrı duruyor; peki gerçek bir bağlantı bunları hangi mesajlarla tek bir kanalda birleştiriyor?

Bölüm 10: TLS El Sıkışması

Simetrik şifreleme, anahtar uzlaşması ve imza ayrı ayrı elinde. Üçünü tek bir kanalda birleştiren şey bir bağlantı.

Kilit o kanalda kuruluyor ve birkaç mesaja sığıyor. Peki el sıkışma tam olarak neyi pazarlıyor?

Kilit tam olarak nereye takılıyor?

Kilit taşıma katmanının içine takılmıyor. Uygulama bir TLS kitaplığı çağırıyor, kitaplık da TCP’yi çağırıyor; sıra tam olarak bu ve tersi değil. TCP’nin kendisi hiç değişmiyor: aynı sıra numaraları, aynı pencere, aynı bayraklar. Değişen tek şey, sokete düz yazdığın metnin ağa şifreli çıkması.

Bunun pratik karşılığı 443 numaralı port. Kilitli web trafiği oradan geçiyor ama o port sıradan bir port; yol üstündeki yönlendiriciler orada özel hiçbir iş yapmıyor. Şifrelemeyi iki uç kendi arasında hallediyor. Kitaplık web’e özel de değil: isim sorgusunu gizleyen DoH ve DoT da altında aynı kilidi taşıyor.

Kilidin verdiği söz üç parçalı. Gizlilik simetrik şifrelemeden geliyor. Bütünlük kriptografik özetlemeden, kimlik doğrulama ise açık anahtar kriptografisinden. Üçü ayrı ayrı gerekiyor, çünkü şifreleme tek başına kurcalamayı engellemiyor. Okuyamayan biri de bitleri karıştırabilir; kilitli bir kutuyu açamadan sallamaya benziyor.

Kilitsiz HTTP bu üç sözden hiçbirini vermiyor. Hat dinlemeye de ortadaki adam saldırısına da açık. Amaç, dürüst olması beklenmeyen bir ağın üstünde dürüst bir kanal kurmak. Adı hâlâ SSL diye anılan eski protokol 2015’te kullanımdan kaldırıldı; bugünkü sürüm TLS 1.3 ve künyesi RFC 8446.

Tek gidiş-dönüş nasıl mümkün oldu?

El sıkışmanın dört işi var ve dördü de birkaç mesajın içine sığıyor: sürüm pazarlığı yapmak, kriptografik algoritmaları seçmek, karşı tarafı doğrulamak ve ortak anahtar malzemesi kurmak. Bunlar üç evreye dağılmış: Key Exchange, Server Parameters, Authentication. İlk evre bittikten sonra geriye kalan her şeyi şifreli akarken göreceksin; sunucunun sertifikası bile açıkta gitmiyor.

İlk mesaj ClientHello. İçinde 32 bayt uzunluğunda bir rastgele değer, önerilen protokol sürümleri, simetrik şifre ile anahtar türetme işlevinin (HKDF) özet çiftlerinden oluşan liste ve key_share uzantısında bir dizi Diffie-Hellman anahtar payı duruyor. Sürüm alanına ayrıca bak, çünkü tuhaf görünüyor. Adı legacy_version ve içine 0x0303, yani TLS 1.2 yazılıyor; gerçek sürüm ise supported_versions uzantısında 0x0304 olarak duruyor. Sebebi uyumluluk: yol üstündeki eski kutular tanımadıkları bir sürüm numarası görünce bağlantıyı düşürüyordu.

Bir gidiş-dönüşü kurtaran hileyi de burada göreceksin. İstemci sunucunun hangi grubu seçeceğini tahmin ediyor ve anahtar payını daha ilk mesajda gönderiyor. Sunucu kabul ederse ortak sır ikinci mesajda zaten hesaplanabilir hâle geliyor. Tahmin tutmazsa sunucu HelloRetryRequest yolluyor, istemci el sıkışmayı doğru grupla baştan kuruyor ve bir gidiş-dönüş daha ödüyor. El sıkışma özeti sıfırlanmıyor: ilk alışveriş de özete giriyor.

istemci -> sunucu   ClientHello           random 32 bayt, key_share, supported_versions
sunucu  -> istemci  ServerHello           seçilen takım, sunucunun key_share'i
                    EncryptedExtensions   <-- buradan sonrası şifreli
                    Certificate
                    CertificateVerify
                    Finished
istemci -> sunucu   Finished
                    [uygulama verisi]

El sıkışmanın hangi mesajında neyin kararlaştığını sırayla görelim:

Dökümde ServerHello satırına bak: seçilen şifre takımını ve sunucunun kendi payını taşıyor. Hemen ardından gelen EncryptedExtensions, sunucu el sıkışma trafik sırrından türeyen anahtarlarla korunan ilk mesaj. Finished ise doğrulama bloğunun sonuncusu: el sıkışmanın bütünlüğünü ve hesaplanan anahtarların doğruluğunu mühürlüyor. İçeriği yanlış çıkarsa bağlantı decrypt_error uyarısıyla kesiliyor; el sıkışmaya karışan bir kutu varsa tam burada yakalanıyor.

Sertifikayı burada yalnızca sunucunun gönderdiği imzalı belge olarak alıp geçiyorum. Onu kimin imzaladığını ve o imzaya neden güvenildiğini, sertifika zincirini kuran 11. bölümde açacağım.

SYN ve SYN-ACK ile ödediğin bir gidiş-dönüş vardı; kripto el sıkışması onun üstüne bir tane daha koyuyor. Yani ilk uygulama baytın yola çıkmadan önce iki gidiş-dönüş ödemiş oluyorsun. Naif bir tasarımda ya da TLS 1.2 üstünde bu üç gidiş-dönüştü.

Beş takım, iki karar

Şifre takımına baktığında artık yalnızca iki şey göreceksin: kayıtları koruyan AEAD algoritması ve HKDF ile kullanılacak özet algoritması. Anahtar değişimi ile imza algoritması takımın dışına, ayrı uzantılara çıkarıldı. Adlandırma kalıbı bu yüzden sade: TLS_AEAD_HASH.

Takım adındaki sayı anahtar uzunluğunu veriyor: ilk satırda 128 bit, ikincisinde 256 bit. Seçenek sayısı bir önceki sürümdeki 37’den 5’e indi ve bu sadeleşmeyi kasıtlı bir güvenlik kararı olarak oku; az seçenek, az yanlış yapılandırma anlamına geliyor.

İkinci karar daha sert çıkıyor: RSA ile anahtar taşıma seçeneği tamamen kaldırıldı ve anahtar değişimi için Diffie-Hellman zorunlu hâle geldi. Bunun sonucuna ileri gizlilik deniyor. Sunucunun uzun ömürlü özel anahtarı sonradan ele geçse bile eski oturumlar açılamıyor, çünkü o oturumların anahtarı hiç telden geçmedi. Matematiğini az önce kurduğun Diffie-Hellman anahtar uzlaşması, protokolde tam olarak burada işe koşuluyor.

Veri korumasında da şifreleme ile doğrulama tek algoritmada birleşti. Eskiden bunları arka arkaya iki ayrı adımda yapıyordun ve sıralamayı yanlış kurmak koca bir saldırı sınıfı üretiyordu.

Anahtarların kendisini kimse elle seçmiyor. Anahtar takvimini HKDF-Extract ve HKDF-Expand üstüne kurmuşlar. Türetme etiketleri tls13 önekiyle başlıyor. Her türetmeye o ana kadarki bütün el sıkışma mesajlarının özeti giriyor. Yani anahtar, konuşmanın kendisine bağlı kalıyor. Ortak sırrı da doğrudan kullanmıyorlar. Ondan yön başına ve evre başına ayrı anahtarlar çıkıyor. Simetrik şifrelemenin anahtarını işlere bölme kuralı vardı; HKDF takvimi tam olarak onu uyguluyor.

Kayıtlara bölmek, kapanışı ilan etmek

El sıkışma bitince iş kayıt katmanına kalıyor. Kayıt katmanı dört içerik türü tanıyor: handshake, application_data, alert ve yalnızca eski yazılımlarla uyum için duran change_cipher_spec. Böylece birden çok üst protokol aynı kayıt katmanını paylaşabiliyor.

Veri en fazla 16.384 baytlık parçalara bölünüyor ve her parça kendi bütünlük etiketini taşıyor. Bölmenin sebebi şu: alıcı bağlantının kapanmasını beklemeden her kaydı geldiği anda doğrulayıp kullanabiliyor.

Kapanış da protokolün içinde. Saldırgan sahte bir TCP kapatma parçası üretirse taraflardan biri veriyi olduğundan kısa sanır; buna kesme saldırısı deniyor. Çözüm kapanışa ayrı bir kayıt türü vermek; o tür de bütünlük hesabına giriyor. Her taraf yazma yönünü kapatmadan önce close_notify göndermek zorunda, ve o uyarıdan sonra gelen veri yok sayılıyor. Taşımanın FIN’i tek başına yeterli kanıt sayılmıyor.

İkinci ziyaret daha ucuz. İlk el sıkışma bittikten sonra sunucu NewSessionTicket ile istemciye bir PSK kimliği veriyor; istemci sonraki el sıkışmada pre_shared_key uzantısıyla o kimliği sunuyor. Sunucu kabul ederse yeni bağlantı kriptografik olarak eskisine bağlanıyor ve tam el sıkışma yerine eski anahtardan başlanıyor. Sunucu PSK ile doğrulandığı için Certificate ve CertificateVerify mesajlarını hiç göndermiyor.

Eski sürümlerdeki oturum kimliği ve oturum bileti mekanizmalarının ikisi de kaldırıldı; yerlerini önceden paylaşılan anahtar aldı. Ama PSK tek başına kullanılırsa uygulama verisi için ileri gizlilik kayboluyor. Bu yüzden istemci PSK sunarken key_share da gönderiyor: hem tazelik gelsin, hem de sunucu sürdürmeyi reddedip tam el sıkışmaya düşebilsin diye.

Paylaşılan anahtar varsa istemci daha ileri gidebiliyor. İlk mesaj demetinde early_data uzantısıyla birlikte şifrelenmiş bir HTTP isteği gidiyor ve el sıkışma gecikmesi sıfıra iniyor. Bedeli de var. Erken veri yalnızca sunulan PSK’dan türeyen anahtarlarla korunuyor, yani ileri gizliliği yok. Kaydedilip sonradan aynen tekrar oynatılabiliyor da.

Bütün bunlar kendi makinende görünür hâle gelebiliyor. openssl s_client -connect ornek-site.test:443 -tls1_3 çıktısında Protocol, Cipher ve Server Temp Key satırlarına bak; sırasıyla pazarlıkla seçilen sürümü, şifre takımını ve anahtar uzlaşma grubunu gösteriyorlar. Kendi sunucunu belgeleme için ayrılmış 203.0.113.10 adresinde dinletiyorsan hedefi doğrudan o sayıyla da verebilirsin.

Özet

Peki, ne öğrendik?

• Kilit uygulama katmanında kuruluyor: TCP hiç değişmiyor, sokete düz yazılan metin ağa şifreli çıkıyor ve varsayılan port 443.
• El sıkışma tek gidiş-dönüşe bir tahminle sığıyor: istemci grubu önceden seçip anahtar payını ilk mesajda gönderiyor, tutmazsa HelloRetryRequest bir tur daha yazıyor.
• Şifre takımı artık yalnızca AEAD ile özet algoritmasını seçiyor: anahtar değişimi ile imza dışarı çıktı, seçenek 37’den 5’e indi ve Diffie-Hellman zorunlu oldu.
• Kayıt katmanı akışı parçalara bölüyor: her kayıt kendi başına doğrulanıyor ve kapanış close_notify ile ilan ediliyor.

Kanal artık okunamıyor, kurcalanamıyor ve kapanışı bile sahtelenemiyor. Kilit kuruldu; ama kilidi karşı tarafla kurduğunu nereden biliyorsun?

Bölüm 11: Sertifika Zinciri

Kilit kuruldu, anahtar iki uçta hazır. Oturum anahtarını üreten el sıkışmayı izlerken bir cümleyi kasten hızlı geçtim: sunucunun sertifikası doğrulandı.

Perdeyi kaldırıyorum. Karşı tarafın gerçekten o olduğunu söyleyen şey anahtar değil, bir imza zinciri. Peki o zincirin ucu nerede duruyor?

Bir imza neyi mühürlüyor?

Sertifika tek bir iş yapan bir belge. Bir açık anahtarı belirli bir varlığa bağlıyor. O varlık bir kişi olabilir, bir web sitesi olabilir, kenardaki bir yönlendirici olabilir. Belgeyi üreten taraf anahtarın sahibi değildir; bağı kuran şey bir sertifika otoritesi. Sıra şöyle işliyor. Varlık açık anahtarını otoriteye kaydettirir ve kimliğinin kanıtını sunar. Otorite o kimliği anahtara bağlayan belgeyi üretir, sonra belgeyi kendi özel anahtarıyla imzalar.

Doğrulama ters yönde çalışıyor. Okuyan taraf otoritenin açık anahtarını sertifikaya uyguluyor ve içindeki açık anahtar ortaya çıkıyor. Kazancı da tam burada görüyorsun. Hiç tanımadığın bir sunucunun anahtarına güvenmek için tek bir anahtara, otoritenin anahtarına güvenmen yetiyor. Kasa benzetmesi hâlâ iş görüyor ama tek başına yetmiyor. Sağlam bir kilit, arkasında kimin durduğunu söylemez.

İmza belgenin tamamına değil, sabit boyutlu özetine atılıyor ve sebebi maliyet: uzun bir metni doğrudan açık anahtarla şifrelemek pahalı. Sayısal imza, özet fonksiyonunun geri döndürülemez olmasını şart koşuyordu; sertifikada işe yarayan tam olarak o şart. Bugünkü el sıkışma MD5 ile SHA-1’i bıraktı, SHA-256 kullanıyor.

Doğrulama tuttuğunda üç şeyi birden öğreniyorsun. Belgeyi sahibi imzaladı, başkası imzalamadı, imzalanan şey de elindeki metnin ta kendisi.

Ortadaki adam saldırısında matematik doğru çalışıyordu; yanlış olan, açık anahtarın sahibiydi. Sertifikanın kapattığı boşluk tam olarak bu. Aynı boşluk isim çözümlemesinde de vardı: yetkili sunucudan dönen kayıt, kim tarafından yazıldığına dair hiçbir kanıt taşımıyordu.

Sertifikayı göstermek bile yetmiyor. Sunucu onu telde açıkça yolluyor ve kopyalanması kimseyi zorlamaz. Bu yüzden sunucu bir mesaj daha gönderiyor: CertificateVerify. O mesajda el sıkışmanın o ana kadarki tamamını, sertifikanın özel anahtarıyla imzalıyor. Kopyalanmış sertifika bu adımı geçemez.

Bu kanıt tek yönlü isteniyor. Sunucunun sertifikası var, senin çoğunlukla yok. İnternette kimlik iki biçimde kuruluyor: ad ile parola, ya da ad ile açık anahtar sertifikası. Sunucu ikincisini kullanıyor, sen birincisini.

Zincirin ucunu kim koyuyor?

Sunucunun gönderdiği şey tek bir sertifika değil; sıralı bir liste. Yaprak sertifika ilk sırada olmak zorunda. Sonraki her sertifika bir öncekini doğrudan imzalamış olmalı.

certificate_list
  [0] yaprak       subject = example.com      issuer = Ara Otorite A
  [1] ara otorite  subject = Ara Otorite A    issuer = Kök Otorite K
 ([2] kök          subject = Kök Otorite K    issuer = Kök Otorite K)

Parantez içindeki satır telde yok. Güven demirleri zincirle taşınmıyor; işletim sisteminden ve tarayıcıdan geliyor. Tipik doğrulama zinciri bu yüzden 3 sertifikadan oluşuyor ama telde ikisi gidiyor. DNSSEC imzasında da aynı kural vardı: zincirin ucundaki anahtar dışarıdan gelir.

Yol doğrulamanın girdisi işte o güven çıpası. Zincirin dört koşulu birden tutması gerekiyor. Her sertifikanın öznesi bir sonrakinin ihraççısıdır, ilk halkayı güven çıpası vermiştir, sonuncusu doğrulanacak sertifikadır, hepsi ilgili anda geçerlidir. Bir sertifika aynı yolda iki kez görünemez; döngüyle güven üretmenin kapısı böyle kapanıyor.

Bir anahtarın sertifika imzalamaya yetkili olup olmadığını iki uzantı söylüyor. basicConstraints içindeki cA bayrağı, o anahtarla başka sertifikaların imzasının doğrulanıp doğrulanamayacağına karar veriyor. Uzantı yoksa ya da bayrak yoksa cevap hayır; yaprak sertifika kendini ara otorite ilan edemiyor. Aynı uzantıdaki pathLenConstraint, bu sertifikadan sonra zincire girebilecek azami ara otorite sayısı. Sıfır yazıyorsa hiç giremez.

İkinci uzantı keyUsage ve o bir bit dizisi. Her bitin numarası standartta sabit:

Beşinci bit açık değilse zincirin o halkası kurulamaz. İstemci ayrıca, desteklemediği kritik bir uzantı taşıyan sertifikayı reddetmek zorunda.

Zincirin ucundaki güven demirlerini kim koyuyor? Somut bir liste var. Mozilla’nın CCADB üstünden yayımladığı kök deposu raporunda 172 kök sertifika duruyor. Bunların 121’i “Websites” güven bitini taşıyor, yani TLS’te geçerli sayılıyor — deponun %70,3’ü. O 121 kök 47 ayrı kuruluşa ait. Tarayıcın senin adına kırk yedi kuruluşa güveniyor. Anahtar dağılımı da aynı listede yazılı ve TLS’te geçerli o 121 kökün hepsini kapsıyor. 59’u RSA 4096 bit, 37’si secp384r1 eğrisi, 21’i RSA 2048 bit kullanıyor. Bu üçü 117 kök ediyor. Kalan dördü secp256r1 ve secp521r1 eğrilerinde.

Bu listenin asıl gücü, bir otorite kötü davrandığında ortaya çıkıyor. Yanlış verilmiş bir sertifikanın iki yaptırımı var ve ikisi aynı ağırlıkta değil. Dar olanı şu: otoriteyle çalışıp o tek sertifikayı iptal ettirirsin. Sorun çözülür, otorite yerinde kalır, aynı hata ertesi gün tekrarlanabilir. Geniş olanı otoriteyi kök deposundan düşürtmek. Bunun için güven demiri listelerini tutanlarla konuşman gerekiyor. O otoritenin verdiği bütün sertifikalar aynı anda geçersizleşir; tek tek iptal edilmelerine gerek kalmaz, çünkü yol doğrulamanın ikinci koşulu artık tutmuyor. Zincirin ilk halkasını veren taraf bir güven çıpası değildir. Bedeli de o ölçüde ağır. Depodan düşen otoritenin müşterisi olan her site aynı anda tarayıcıda uyarı vermeye başlar. Kararı veren taraf da bunu bilir. Karar bu yüzden nadir, yavaş ve kanıt ister.

Sertifika hangi adı taahhüt ediyor?

Belgenin kendisi üç üst alandan oluşuyor: imzalanacak gövde, imza algoritmasının adı ve imzanın kendisi. İmza, gövdenin baytlara dökülmüş hâlinin üstüne atılıyor; o dökümün kurallarına DER deniyor ve tek bir gövdenin tek bir bayt dizisine karşılık gelmesini garanti ediyor. Gövdenin içinde sırayla şunlar duruyor:

tbsCertificate
  version               v3  (INTEGER 2)
  serialNumber          pozitif tamsayı, en çok 20 bayt
  signature             imza algoritmasının adı
  issuer                ihraççının adı
  validity              notBefore / notAfter
  subject               öznenin adı
  subjectPublicKeyInfo  mühürlenen açık anahtar
  extensions            basicConstraints, keyUsage, subjectAltName, ...
signatureAlgorithm
signatureValue

Seri numarası otoritenin verdiği pozitif bir tamsayı ve tek başına anlam taşımıyor. Bir sertifikayı tekilleştiren şey ihraççı adı ile seri numarasının çifti. Uyumlu otoriteler 20 bayttan uzun seri numarası kullanamıyor, çünkü iptal listeleri sertifikayı bu numarayla anıyor.

Geçerlilik iki tarihle çiziliyor ve iki uç da dahil: notBefore ve notAfter. Kodlamada eski bir miras duruyor. 2049 ve öncesi UTCTime ile yazılıyor, 2050 ve sonrası GeneralizedTime ile. Bitiş tarihi tanımsız olan sertifika bile bir tarih taşıyor: 99991231235959Z.

Günlük hayatta çarptığın alan ise ad doğrulaması. Sertifikanın hangi ad için geçerli olduğunu subjectAltName uzantısı söylüyor. Alan adı orada dNSName içinde IA5String olarak duruyor. Karşılaştırma büyük-küçük harf ayrımı gözetmiyor. IP adresi de yazılabiliyor: iPAddress alanına ağ bayt sırasıyla, IPv4 için tam 4 bayt, IPv6 için tam 16 bayt. Uzantıdaki adlar açık anahtara kesin biçimde bağlı sayıldığı için otorite oradaki her adı tek tek doğrulamak zorunda. Her satır bir taahhüt.

Eşleşme iki kimlik arasında aranıyor. Sunucunun sertifikada gösterdiğine sunulan kimlik, istemcinin adres çubuğundaki addan kurduğuna referans kimlik deniyor. Karşılaştırma etiket etiket yapılıyor ve her etiket tutmak zorunda. Joker karakter de yalnız en soldaki etikette durabiliyor.

Son iki satır sezgiye ters. Joker tek bir etiketi karşılıyor; ne iki alt seviyeyi kapsıyor ne de çıplak alan adını. Eski bir alışkanlık da kapandı: sertifikada dNSName varsa istemci Common Name alanına bakarak eşleşme aramamalı. Ad doğrulamasının yeri artık uzantı.

Yanlış verilmiş sertifikayı kim fark ediyor?

Bir sertifika verildikten sonra da yanlış olabilir. Anahtar çalınır, otorite yanılır, ya da adı sertifikada geçen taraf o belgeyi hiç istememiştir. İlk cevap iptal listesi: otoritenin ya da yetkilendirdiği bir birimin yayımladığı imzalı bir liste. Tam bir liste, kapsamındaki süresi dolmamış bütün iptal edilmiş sertifikaları taşıyor; süresi dolan düşer, liste sonsuza kadar büyümez.

Sebepler numaralı ve adlı: 1 keyCompromise, yani anahtarın ele geçmesi; 2 cACompromise, otoritenin kendisinin ele geçmesi; 10 aACompromise. Aradaki 7 hiç kullanılmıyor.

Koca listeyi indirmeden tek bir sertifikanın durumu da sorulabiliyor. Yolun adı çevrimiçi durum sorgusu, kısaltmasıyla OCSP. Üç kesin yanıt veriyor: good, revoked, unknown. İlkini yanlış okumak kolay: good yalnızca “iptal kaydı yok” demek; sertifikanın hiç verilmiş olduğunu bile garanti etmiyor. unknown ise çoğunlukla yanlış kapıyı çaldığını gösteriyor. Nereye soracağını da sertifikanın kendisi söylüyor. authorityInfoAccess uzantısı iki adres taşıyor: eksik ara sertifikayı nereden alacağın ve durumu kime soracağın.

OCSP’nin kendi tasarımında iki kusur var ve ikisi de tarayıcıyı zor durumda bırakıyor. Birincisi gecikme: her bağlantıda üçüncü bir sunucuya bir soru daha sormak, sayfa açılışına bir gidiş-dönüş daha ekliyor. İkincisi ve daha ağırı mahremiyet: o soruyu sorarken hangi siteye bağlandığını sertifika otoritesine söylemiş oluyorsun. Şifreli bağlantı kurmak için attığın adım, gezinme geçmişini üçüncü bir tarafa sızdırıyor.

Çözüm rolleri ters çeviriyor. OCSP stapling (zımbalama) denen yöntemde durumu tarayıcı değil sunucu soruyor: kendi sertifikasının OCSP cevabını önceden alıyor, imzalı hâliyle saklıyor ve el sıkışmanın içine iliştirip sana gönderiyor. Cevap otoritenin imzasını taşıdığı için sunucu onu uyduramıyor; ve cevabın kendi zaman damgası olduğu için bayatı da sürülemiyor. Tarayıcı hiçbir yere soru sormuyor: ne gecikme var ne sızıntı.

Geriye bir açık kalıyor. Sunucu zımbayı hiç iliştirmezse tarayıcı ne yapacak? Cevap uzun süre “devam et” oldu, çünkü ağ arızalarında siteyi kırmak istemediler — ve saldırgan da tam olarak bunu kullanabilirdi: zımbayı yutması yeterliydi. OCSP Must-Staple uzantısı bunu kapatıyor, sertifikaya “benim cevabım her zaman zımbalanmış gelecek” diye yazıyor ve gelmezse tarayıcı bağlantıyı reddediyor.

İptal, yanlış verilmiş bir sertifikayı ancak birileri fark ederse işe yarıyor. Fark etmeyi sağlayan mekanizmanın adı Certificate Transparency. Verilen sertifikalar yalnızca-ekleme günlüklerine yazılıyor. Günlük yanlış verilmeyi engellemiyor; adı sertifikada geçen tarafın bunu görmesini sağlıyor.

Günlük, kabul ettiği zincire imzalı bir zaman damgası döndürüyor. O damga bir kayıt değil, bir söz: bu girdiyi ağaca ekleyeceğim. Söz, Maximum Merge Delay içinde tutulmak zorunda; tutulmazsa günlüğün kendisi suçüstü yakalanıyor. Yalnızca-ekleme özelliği Merkle ağacından geliyor, çünkü yaprak olmayan her düğüm çocuklarının hash’i. Bugünkü ağacın dünküyü kapsadığı bu sayede ucuza kanıtlanabiliyor; geçmişi sessizce silmek mümkün olmuyor. Günlüğe atılan her zincirin de günlüğün tanıdığı bir güven çıpasında bitmesi gerekiyor.

İptalin yavaş ve güvenilmez olduğu kabul edilmiş durumda; çözüm başka yerden geliyor. Sertifika ömrü hızla kısalıyor. 2026-03-15’ten önce azami ömür 398 gündü, bugün 200 gün. Takvim 2027-03-15’ten sonra 100 güne, 2029-03-15’ten sonra 47 güne iniyor. İptal takvimi de sıkı: ağır durumlarda 24 saat, hafif durumlarda kesin üst sınır 5 gün, ara otorite sertifikasında 7 gün. Ömrü 7 günü aşmayan sertifikalar zaten iptal yükümlülüğünün dışında tutuluyor.

Aynı openssl s_client çağrısı, sonuna -showcerts eklendiğinde sunucunun gönderdiği zinciri olduğu gibi basıyor:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Çıktıda yaprak sertifika en üstte, ara otorite hemen altında duruyor. Kök yok, çünkü zaten sende. Tek bir sertifikanın künyesini görmek istersen, çıktıdaki BEGIN/END bloğunu bir dosyaya kaydet:

openssl x509 -in yaprak.pem -noout -subject -issuer -dates -ext subjectAltName

Dönen dört satır bu bölümün tamamı: belge kime verildi, kim imzaladı, hangi tarihler arası geçerli, hangi adları taahhüt ediyor.

Özet

Peki, ne öğrendik?

• Sertifika bir açık anahtarı bir ada bağlar ve bağı otorite kurar; doğrulama ters yönde, otoritenin açık anahtarıyla yapılır.
• Zincirin ucu sertifikadan çıkmaz: güven demirlerini işletim sistemi ve tarayıcı taşır, kök telde hiç gönderilmez.
• Ad eşleşmesi subjectAltName uzantısında aranır; joker yalnız en soldaki etiketi karşılar ve çıplak alan adını kapsamaz.
• İptal yavaş olduğu için ömür kısalıyor: azami sertifika ömrü basamak basamak düşürülüyor, kısa ömürlüler iptal yükümlülüğünün dışında kalıyor.
• Certificate Transparency yanlış verilmeyi engellemez, görünür kılar; yaptırımı asıl kök deposu uygular.

Kanal kuruldu, kilit takıldı, karşı tarafın kim olduğu doğrulandı. Geriye tek bir iş kaldı ve bu bölüm boyunca ona hiç bakmadık: şimdi tam olarak ne göndereceksin?

Bölüm 12: HTTP Mesajının Anatomisi

Kanal kuruldu, karşı taraf doğrulandı. Göndereceğin şey ise şaşırtıcı derecede sade: birkaç satır düz metin.

Şimdiye kadar “istek” deyip içine bakmadım. O metin neye benziyor, hangi kelimesi neyi belirliyor?

Bir istek neye benziyor?

HTTP web’in uygulama katmanı protokolü ve modeli tek cümleye sığıyor: bir taraf istiyor, öbür taraf istenen nesneyi yanıt olarak yolluyor. Bütün protokolde yalnızca iki tür mesaj bulunuyor, istek ile yanıt; üçüncü bir tür aramana gerek yok.

Mesajın kendisi düz metin olarak gidiyor. HTTP/1.1’de her satır ASCII, yani gözünle okuyabilirsin. Karşı tarafın kim olduğu ad doğrulamasıyla çözülmüştü; o kanal bu metni tek harfini değiştirmeden taşıyor.

RFC 9110 mesajı dört parçaya ayırıyor. Başta mesajı tanımlayan ve yönlendiren denetim verisi duruyor. Arkasından ad-değer çiftlerinden oluşan başlık tablosu geliyor. Sonra sınırsız uzunlukta olabilen içerik akışı, en sonda da kuyruk tablosu. Bir isteğin denetim verisi ilk satırda duruyor.

O satırın biçimi sabit: metot, boşluk, hedef URL, boşluk, sürüm ve satırı kapatan CR LF. Adres çubuğuna yazdığın adresin yolu buraya giriyor. Yetkili alanı ayrı, yolu ayrı kutulara koyan ayrıştırma tam da bunun içindi.

Başlık satırları arkadan geliyor. Nerede bittiklerini satır başında duran boş bir CR LF çifti söylüyor; ondan sonrası gövde. Tamamı şuna benziyor:

GET /kitap/bolum-12 HTTP/1.1
Host: example.com
User-Agent: kendi-istemcim/1.0
Accept: text/html

Dört satır, sonra boş bir satır. Her satırın sonunda görünmeyen iki bayt daha var. Onlar da sayıya giriyor: bu istek toplam 102 bayt. İstek satırı tek başına 30 bayt tutuyor. Aynı isteğin zorunlu parçalara indirgenmiş hâli 51 bayt: istek satırı, Host başlığı ve kapanış boş satırı.

HTTP kendi taşımasını da kurmuyor. İstemci sunucunun 80. portuna bir TCP bağlantısı açıyor, mesajlar o soketten geçiyor. HTTPS’te varsayılan port 443 oluyor. Numaranın neden sabit olduğu iyi bilinen portlarda geçmişti.

Bir bağlantıya kaç isteğin sığdığı ayrı bir hesap. Kalıcı olmayan HTTP’de bir TCP bağlantısında en çok bir nesne taşınıyor. Kalıcı HTTP’de sunucu yanıtı gönderdikten sonra bağlantıyı açık bırakıyor. Bunu burada tek cümleyle bırakıyorum; kalıcı bağlantının asıl hesabı iki durak sonra tutulacak.

Bir sayfa nesnelerin toplamıydı ve her nesne ayrı bir URL ile adresleniyor. O yüzden bu metin sayfa başına bir kez değil, onlarca kez yazılıyor.

Metot ne vaat ediyor?

İstek satırının ilk kelimesi isteğin anlamını taşıyor. RFC 9110 sekiz metot tanımlıyor ve bu küme protokole gömülü; uygulama kendi metodunu icat etmiyor. Metot adı büyük-küçük harfe duyarlı, standart adlar da sözleşme gereği tamamı büyük harfle yazılıyor.

Son iki sütun sözleşme. Güvenli olmak, metodun anlamının salt okunur olduğunu söylüyor. Sunucuda hiçbir şeyin değişmeyeceğini garanti etmiyor; sunucu istediği sayacı artırabilir. Söylediği şey, istemcinin değişiklik istememiş olduğu.

Yinelemeye dayanıklı metot ise aynı isteği iki kez yollamanın tek kez yollamakla aynı sonucu vermesi demek. POST ikisinin de dışında kalıyor, çünkü anlamını sunucu belirliyor.

Zorunluluk listesi kısa. Genel amaçlı her sunucu GET ve HEAD’i desteklemek zorunda; kalan altısı isteğe bağlı. HEAD’in gövdeyi hiç istememesi ucuz bir yetenek veriyor: bir dosyanın boyutunu indirmeden öğrenebiliyorsun. POST’un altına ise çok iş giriyor: form verisi, mesaj gönderme, yeni kaynak yaratma, var olan içeriğe ekleme. Yeni bir kaynak yarattıysa sunucunun 201 dönmesi ve yeni adresi Location başlığında vermesi bekleniyor.

Başlıklar neyi çözüyor?

Başlık tablosunun kuralı az. Adlar büyük-küçük harfe duyarsız, yani Host ile host aynı alan.

Host zorunlu. Tek makinede birden çok alan adına hizmet veren sunucu, hangi siteyi istediğini bununla ayırt ediyor. Aynı adres, aynı port, farklı siteler. HTTP/2 ve HTTP/3’te bu alanın yerini :authority sözde-başlığı aldı.

Gövdesi olan bir istekte iki alan daha devreye giriyor. Content-Type gövdenin ne olduğunu söylüyor ve karakter kümesi aynı satırda parametre olarak geliyor. Content-Length ise gövdenin uzunluğunu onluk tabanda bayt sayısı olarak veriyor.

POST /yorum HTTP/1.1
Host: example.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

ad=emir&yorum=merhaba+dunya

Gövdenin nerede bittiğini o sayı çiziyor. Eksik yazarsan sunucu gelmeyecek baytları beklemeye devam ediyor. Fazla yazarsan bir sonraki isteğin ilk satırını gövdenin parçası sanıyor. Boş gövdeli bir POST’ta bile alan yazılıyor ve değeri sıfır oluyor.

Mesajın sonunda bir tablo daha var, ama çoğu zaman boş kalıyor. Kuyruk, gövde bittikten sonra eklenen alanları taşıyor: akış tamamlanmadan hesaplanamayan bir özet oraya yazılıyor.

Aynı adresten farklı gösterimler istemek

Bir adres tek bir dosyayı göstermek zorunda değil. /logo adresinin arkasında hem PNG hem WebP, hem Türkçe hem İngilizce, hem sıkıştırılmış hem ham bir gösterim durabilir. İstemci hangisini istediğini istek başlıklarıyla söylüyor ve mekanizmanın adı içerik pazarlığı.

Accept: image/webp,image/png;q=0.8,*/*;q=0.5
Accept-Language: tr,en;q=0.7
Accept-Encoding: gzip, br

Virgülle ayrılmış her seçeneğin yanında bir q değeri var — 0 ile 1 arasında bir kalite ağırlığı, yazılmazsa 1 sayılıyor. Yukarıdaki satır “WebP’yi tercih ederim, PNG de olur, gerekirse her şeye razıyım” demek. Sunucu listeye bakıp en iyi eşleşmeyi seçiyor ve cevabında hangisini seçtiğini Content-Type ile bildiriyor.

Bir de “hangi başlığa göre seçtim” sorusu var; cevabı Vary başlığında dönüyor ve gibi önbelleğin anahtarını doğrudan etkiliyor. Pazarlık, aynı adresin arkasında birden çok kopya doğurduğu için önbelleğe de haber verilmesi gerekiyor.

Dosyanın yalnızca bir parçasını istemek

İkinci bir mekanizma, isteği bayt aralığına daraltıyor:

Range: bytes=1048576-2097151

Sunucu isteği kabul ederse 206 Partial Content dönüyor ve yalnızca istenen aralığı gönderiyor; Content-Range başlığında hangi aralığı verdiğini ve dosyanın toplam boyunu yazıyor. Desteklemiyorsa 200 ile bütün dosyayı gönderiyor — istemcinin bunu anlaması için durum koduna bakması yeterli.

Bu tek başlığın üç ayrı işi var. Kesilen indirme kaldığı bayttan sürüyor. video akışı, filmi baştan indirmek yerine parça parça çekiyor. Ve bir dosyayı birden çok bağlantıyla paralel indiren araçlar, her bağlantıya farklı bir aralık veriyor.

Katmanları sayarken, ağın yedi katmanlı klasik modeli olan OSI’nin oturum katmanına bakacağız ve o katmanın işini bugün kimin yaptığını soracağız. Cevabın bir parçası şimdiden elinde: kopan bir aktarımı işaretli noktadan sürdürmek, ayrı bir katman değil, tek bir istek başlığı.

Üç basamak neyi söylüyor?

Yanıtın ilk satırı durum satırı: sürüm, üç basamaklı durum kodu ve reason phrase (gerekçe cümlesi) yan yana duruyor. Kodu okumak için gövdeyi beklemek gerekmiyor: istek gidip yanıtın ilk baytları dönene kadar geçen bir gidiş-dönüş süresi yetiyor.

Kod bir tam sayı ve geçerli aralık 100 ile 599 arası. Sınıfı ilk rakam belirliyor; son iki basamağın sınıflandırmada hiçbir rolü yok.

İstemci tanımadığı bir kodu, o sınıfın x00 koduymuş gibi işlemek zorunda: 471 gelirse onu 400 gibi ele alıyor. Anlamını bilmiyor ama ne yapacağını biliyor. Yeni kod eklemek bu yüzden protokolü kırmıyor.

Koddan sonraki reason phrase (gerekçe cümlesi) ise yalnızca tavsiye. Yerel karşılığıyla değiştirilebilir, hiç yazılmayabilir; protokol bundan etkilenmiyor. Kararı taşıyan şey de sayının kendisi.

Asıl bilgi de birbirine yakın duran kodların arasındaki farkta. 404, kaynağın güncel bir gösteriminin bulunamadığını söylüyor. Durumun kalıcı mı geçici mi olduğunu söylemiyor; sunucu kalıcı olduğunu biliyorsa 410 tercih ediliyor. 405 ile 501 de ayrı arızalar. 405’te metot tanınıyor ama o kaynakta izinli değil ve sunucu Allow başlığıyla izinli metotları saymak zorunda. 501’de metot hiç tanınmıyor. 500 ise sunucunun beklenmedik bir durumla karşılaşıp isteği yerine getiremediği hâl. 505 istenen HTTP sürümünün desteklenmediğini bildiriyor. 301 ise nesnenin kalıcı olarak taşındığını, yeni yerinin de Location başlığında durduğunu söylüyor.

Bir kod da hiç veri taşımadığı için var. İstemci elindeki kopyanın tarihini If-Modified-Since başlığıyla isteğe yazıyor. Kaynak o tarihten sonra değişmediyse yanıt 304 oluyor ve gövde hiç gönderilmiyor. O yanıt başlık bölümü bitince bitiyor, içerik de kuyruk da taşıyamıyor. İstek ayrıca If-None-Match taşıyorsa alıcı tarihi yok saymak zorunda. Etiket üzerinden kurulan koşul daha doğru kabul ediliyor. Koşullu isteğin amacı tek cümle: kopya güncelse nesneyi hiç göndermemek.

Bütün bunları kendi makinende görebilirsin. 80. porta elle bir bağlantı açıp istek satırıyla Host başlığını yazman yetiyor. Sonuna iki kez satır sonu koyuyorsun. Belgeleme için ayrılmış bir adla deneyebilirsin:

printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' \
  | nc example.com 80 | head -12

İlk satırda sürümü, kodu ve reason phrase’i (gerekçe cümlesini) göreceksin. Altında ad-değer çiftleri sıralı duracak, sonra boş bir satır gelecek, sonra gövde başlayacak. Gördüğün şey, tarayıcının saniyede onlarca kez yazdığı metnin aynısı.

Özet

Peki, ne öğrendik?

• İsteğin biçimi sabit: metot, hedef, sürüm, arkasından ad-değer çiftleri ve satır başında duran boş bir satır.
• Metot bir vaat taşır: güvenli olan salt okunur olduğunu ilan eder, yinelemeye dayanıklı olan ikinci kez yollandığında sonucu değiştirmez.
• Başlıklar mesajı yorumlanabilir kılar: Host hangi siteyi, Content-Type gövdenin ne olduğunu, Content-Length nerede bittiğini söyler.
• Durum kodu üç basamakta karar taşır: sınıfı ilk rakam belirler, tanınmayan kod x00 gibi işlenir, reason phrase (gerekçe cümlesi) yalnızca tavsiyedir.

Metni kanaldan geçirdin, yanıtın ilk satırını okudun. Ama o mesajın hiçbir yerinde senin kim olduğunu söyleyen bir alan yok; sunucu da geçmiş istekler hakkında hiçbir bilgi tutmuyor. İsteği yazdın; peki sunucu seni daha önce gördüğünü nereden bilecek?

Bölüm 13: Durum, Çerez ve Oturum

Bir önceki bölümde yazdığın istekte seni tanıtan tek bir alan yoktu. Sunucu da geçmişi tutmuyor.

Yine de siteler seni hatırlıyor. Bunu yapan şey sunucunun belleği değil, geçen sefer verdiği kâğıdı geri götürmen. O kâğıt neye benziyor?

Sunucu neden hiçbir şey tutmuyor?

Her HTTP isteği ötekilerden bağımsız okunuyor. Bunun protokoldeki adı durumsuzluk. Çok adımlı işlem diye bir kavram yok, ve adımları birbirine bağlama işi protokolün dışında kalıyor.

Durumu bir yerde tutmanın iki yolu var ve ikisi de bu kitapta karşına çıkıyor. Birincisi durumu protokolün uçlarında tutmak. Bağlantı kuran taşımada iki tarafın da karşısındakinin nerede kaldığını gösteren bir kaydı var. İkinci yol durumu mesajların içinde taşımak.

Çerezin yaptığı iş tam olarak bu. Durumu sunucunun belleğinde tutmak yerine senin makinene yazıyor ve her istekte onu geri getirtiyor. Fikir yeni değil: sunucu yarı açık bağlantı durumunu ikinci mesajın sıra numarasına kodlayıp kuyruğu tümden ortadan kaldırabiliyordu. Çerez aynı işi bir kat yukarıda, uygulama katmanında yapıyor.

Çerez dört parçadan kurulur

Mekanizma dört parçayı birden istiyor. İlk ikisi mesajların içinde: yanıt mesajındaki Set-Cookie başlık satırı ve sonraki istek mesajındaki Cookie başlık satırı. Diğer ikisi mesajların dışında: tarayıcının makinende yönettiği çerez dosyası ve sitenin arka ucundaki veritabanı. Dördü bir arada olmadan zincir tamamlanmıyor.

Zincir ilk istekte başlıyor. Siteye ilk vardığında site bir kimlik üretiyor ve veritabanında ona bir kayıt açıyor. Kimliği de yanıtın başlığına yazıyor.

# sunucudan gelen yanıtta
Set-Cookie: oturum=7c1a94e0b3f582d6a4e71b09; Path=/; Max-Age=1800; Secure; HttpOnly

# sonraki her istekte tarayıcıdan giden
Cookie: oturum=7c1a94e0b3f582d6a4e71b09

Sonraki isteklerin hepsi o değeri taşıyor. Sunucunun seni tanıması tam olarak şu: gelen satırdaki değeri okumak ve veritabanındaki kaydı bulmak. Tanıdığı şey sen değilsin, taşıdığın numara. Bütün bunu tanımlayan belge RFC 6265, Nisan 2011 tarihli ve tam adı HTTP State Management Mechanism.

Değerin ne anlama geldiğine protokol değil uygulama karar veriyor. Protokol yalnızca taşımayı tarif ediyor, ve gelen Cookie satırını yok saymak sunucunun hakkı.

Tek bir yanıt birden çok Set-Cookie satırı taşıyabiliyor. Bu satırlar tek satıra katlanmıyor: virgül karakteri Set-Cookie’nin kendi sözdiziminde kullanılıyor ve katlama anlamı bozuyor.

Ad ve değerden sonrası kapsamı çiziyor

Örnekteki çerez 1.800 saniye, yani 30 dakika yaşıyor. Süre hiç yazılmasaydı çerez oturum bitene kadar saklanacaktı, yani tarayıcı kapanınca düşecekti. Oturum çerezi ile kalıcı çerez arasındaki fark tam olarak bu.

Secure yazan çerez yalnızca 443 numaralı portun açtığı kanaldan gidiyor. Koruduğu şey gizlilik, bütünlük değil: etkin bir saldırgan güvensiz kanaldan aynı adı taşıyan bir çerez göndererek onun üstüne yazabiliyor. HttpOnly ile Secure birbirinden bağımsız, bir çerez ikisini birden taşıyabilir.

Standart, genel amaçlı bir tarayıcıdan çerez başına en az 4.096 bayt saklamasını istiyor. Ad, değer ve öznitelikler bu toplama giriyor. Alan adı başına en az 50, toplamda en az 3000 çerez saklanması bekleniyor.

Sunucuların az ve küçük çerez kullanması bekleniyor, çünkü Cookie satırı her isteğe ekleniyor ve upstream (yukarı yön) bant genişliğinden yiyor. Örnekteki adın uzunluğu 6 bayt, kimlik 24 onaltılık basamak, ad-değer çifti 31 bayt ediyor. Başlık adı ve satır sonuyla birlikte Cookie satırı 41 bayt tutuyor. Bir sayfa aynı kaynaktan 60 nesne çekiyorsa aynı çerez tek sayfa yüklemesinde upstream tarafında 2.460 bayt yük üretiyor.

Tarayıcının çerezi kendiliğinden eklemesi bir açık üretiyor

Tabloya yeni eklenen son satır bir savunma ve neyi savunduğunu bilmeden anlamı yok.

Tarayıcının kuralı sade: bir adrese istek giderken, o adrese ait çerezleri kim istemiş olursa olsun ekliyor. Bankana giriş yaptın, oturum çerezin duruyor. Sonra başka bir sekmede bambaşka bir siteyi açıyorsun ve o sayfanın içinde görünmez bir form ya da bir görsel etiketi, senin bankana bir istek yaptırıyor. Tarayıcı o isteğe oturum çerezini de ekliyor — çünkü kuralı bu. Banka isteği senden gelmiş sayıyor.

Saldırının adı siteler arası istek sahteciliği (CSRF). Saldırganın oturum çerezini okuması gerekmiyor, hatta görmesi bile gerekmiyor; yalnızca kullandırması yetiyor. HttpOnly bu saldırıya karşı hiçbir şey yapmıyor, çünkü çerez okunmuyor.

SameSite özniteliği tam buraya oturuyor ve üç değer alıyor:

Lax bugünün varsayılanı ve bir ödünleşim: başka bir siteden gelen bir bağlantıya tıkladığında oturumun açık kalıyor, ama aynı siteden tetiklenen bir form gönderimine çerez eklenmiyor. None ise üçüncü taraf çerezleri için kalan tek yol.

İkinci bir savunma da adın kendisinde. Bir çerezin adı __Host- ile başlıyorsa tarayıcı onu yalnızca Secure işaretliyse, Domain yazılmamışsa ve Path kökse kabul ediyor. Böylece o çerezin tam olarak hangi makineye ait olduğu adın içinde kilitleniyor ve bir alt alan adı onu üstüne yazamıyor. __Secure- öneki daha gevşek, yalnızca Secure şartını koyuyor.

Numaranın zarafeti şurada: kural sunucuda değil, adın kendisinde taşınıyor. Çerezi kim gönderirse göndersin, tarayıcı adı okuyup şartı uyguluyor.

Birinci taraf çerez, ziyaret etmeyi seçtiğin siteden geliyor. Üçüncü taraf çerez hiç seçmediğin bir siteden geliyor, sayfanın içine gömülü bir nesne onu çekiyor. Kalıcı üçüncü taraf çerezleri aynı kimlik değerini birden çok sitede görünür kılıyor, ve izleme tam olarak o ortak değerin farklı sitelerde tekrar tekrar geri gönderilmesi. Görünür bir reklam bile gerekmiyor. Görünmez bir bağlantı aynı işi görüyor.

Bir not: Türkçe kaynaklarda “HTTP oturumu” çoğu zaman tek bir istek-yanıt turu anlamına geliyor. Bu kitapta oturum, protokolün üstünde çerezle kurulan kullanıcı oturumudur; 10. bölümde el sıkışmanın sonunda üretilen oturum anahtarıyla akrabalığı yok.

Aynı nesneyi kaç kez indirmen gerekiyor?

Bir web önbelleği istekleri asıl sunucuyu hiç işin içine katmadan karşılıyor. Nesne depoda varsa istemciye oradan dönüyor ve istek dışarı çıkmıyor. Yoksa önbellek nesneyi asıl sunucudan istiyor, gelen kopyayı saklıyor, aynı kopyayı istemciye veriyor. Kaçırılan isabet sonraki isabeti hazırlıyor.

Bu kutu iki rolü aynı anda oynuyor: isteği yapan istemciye karşı sunucu, asıl sunucuya karşı istemci. Adı vekil sunucu.

Kazanç iki tane. Birincisi yanıt süresinin kısalması, çünkü kopya sana daha yakın duruyor. İkincisi kurumun dış erişim hattındaki trafiğin azalması. Asıl dert de o hattın doluluğu: kullanım oranı yükseldikçe kuyruk gecikmesi patlıyor.

Bir kurumun erişim hattı 10 Mbit/s olsun. Kullanıcılar saniyede 40 istek yapıyor ve ortalama nesne 200 kbit. Önbelleksiz durumda hattan 8 Mbit/s geçiyor, yani hat %80 dolu. İsabet oranı %55 olduğunda dışarı yalnızca %45 çıkıyor: 3,6 Mbit/s ve %36 doluluk. Asıl sunucudan gelen istek 1,2 saniye, önbellekten gelen 5 ms sürüyorsa ortalama 0,54 saniyeye iniyor. Hiç kapasite satın alınmadı.

Önbellekler ağın ortasına yerleşmiş ara kutulardan biri. Servis sağlayıcıda, mobil ağda ve içeriğin kopyalarını dünyaya yayan içerik dağıtım ağlarında duruyorlar, ve tek bir sayfa isteği yol boyunca birden çok önbelleğe uğrayabiliyor. İsteğin doğuşunda andığım tarayıcı önbellekleri bu zincirin hem ilk halkası hem de sana en yakın duranı.

RFC 9111 iki tür ayırıyor. Paylaşılan önbellek birden çok kullanıcı için saklıyor ve genellikle ara kutu olarak konuşlanıyor. Özel önbellek tek kullanıcıya ait, çoğunlukla tarayıcının içinde duruyor. Tanım da sade: HTTP önbelleği, yanıt mesajlarının yerel deposu ve depoyu yöneten alt sistem. Tünel rolündeki bir taraf önbellek kullanamıyor.

Yaşı tazelik ömrünü aşmamış yanıt taze, aşmış olan bayat. Taze yanıt asıl sunucuya hiç sorulmadan kullanılıyor. Yanıtın yaşı, asıl sunucuda üretildiği ya da orada başarıyla doğrulandığı andan beri geçen süre, ve Age başlığı bu tahmini saniye olarak taşıyor.

Süreye sunucu karar veriyor, kararını da yanıt başlığında bildiriyor.

Ortadaki iki satır sık karıştırılıyor. Yasak farklı: no-store saklamayı, no-cache doğrulamadan kullanmayı engelliyor. Tarayıcının kendi önbelleği private yazan yanıtı yine de saklayabiliyor.

Çerez başlığının varlığı yanıtın önbelleklenmesini kendiliğinden engellemiyor. Kişiye özel bir yanıtı paylaşılan önbellekten korumak istiyorsan private ya da no-store’u açıkça yazman gerekiyor.

Sunucu hiç süre vermediyse önbellek kendi tahminini yapıyor. Last-Modified tarihine bakıp o tarihten beri geçen sürenin %10’unu ömür sayması yaygın bir seçim. O ömür dolana kadar oradaki kopya taze sayılıyor, gerçekte eskimiş olsa bile. Her önbellek tazelik ile doğruluk arasında bir takas yapıyor. Aynı takas, yaşam süresi adıyla, önbellek katmanlarının bir kat aşağısında da vardı.

Kopyan hâlâ geçerli mi?

Koşullu istek, metodun uygulanmasından önce sınanacak bir önkoşul taşıyan istek. Önkoşul tutmazsa metot hiç uygulanmıyor. Önbellek tazelemenin en verimli yolu koşullu GET. Aynı mekanizma PUT ile DELETE’te kayıp güncelleme sorununu da önlüyor.

Önkoşulda kullanılabilen kaynak üstverisine doğrulayıcı deniyor. HTTP iki tane tanımlıyor.

Last-Modified gösterimin son değişme anını HTTP tarih biçiminde ve saniye çözünürlüğünde taşıyor. ETag ise opak: içinde ne yazdığı istemciyi ilgilendirmiyor, yalnızca eşit mi değil mi diye karşılaştırılıyor. Tırnak içinde bir dizi. Zayıf üretilmiş etiketin başına W/ öneki konmak zorunda, varsayılanı güçlü doğrulayıcı. Saniye çözünürlüğü yetmediğinde ya da değişiklik tarihi düzgün tutulmadığında tarihten daha güvenilir çalışıyor.

İstemci koşulu iki başlıktan biriyle kuruyor. If-None-Match isteği, elindeki etiketlerden hiçbirinin eşleşmemesi koşuluna bağlıyor; eşleşme varsa koşul yanlış oluyor. If-Modified-Since ise GET ya da HEAD’i gösterimin değişme tarihine bağlıyor, veri değişmediyse hiç aktarılmıyor. İkisi birden gelirse tarih yok sayılıyor, çünkü etiket daha kesin sayılıyor. Birlikte gönderilmelerinin tek sebebi, If-None-Match’i gerçeklemeyen eski ara kutularla uyum.

Koşul yanlış çıkarsa sunucu GET ve HEAD için 304, diğer metotlar için 412 dönmek zorunda. Bu iki kodun sınıfı, durum kodlarını ilk rakama göre ayırırken sabitlenmişti. 304 Not Modified, koşul yanlış çıkmasaydı 200 dönecek olan bir isteğin yanıtı. Sunucu istemciyi kendi kopyasına yönlendiriyor. Yanıt başlık bölümü bitince bitiyor.

Boş dönmüyor ama. 304 üreten sunucu, aynı isteğe 200 dönseydi göndereceği Content-Location, Date, ETag ve Vary alanlarını, ayrıca Cache-Control ile Expires’ı yine göndermek zorunda.

HTTP/1.1 304 Not Modified
Date: Fri, 21 Aug 2026 09:14:02 GMT
ETag: "b41f-63c0a7d1e2"
Cache-Control: max-age=1800

Dört satır ve kapanış boş satırı, toplam 120 bayt. Tam gövdeli karşılığı 18.432 baytlık bir stil dosyası olsaydı fark 153 kat olurdu.

Kazanç turda değil, taşınan baytta. Koşullu istek de tam bir gidiş-dönüş ödüyor: soru çıkıyor, cevap dönüyor. Nesne hiç iletilmediği için aktarım gecikmesi ödenmiyor ve ağ kaynağı harcanmıyor.

Bunu kendi makinende iki adımda görebilirsin. Önce yalnızca başlıkları çekip last-modified satırını kopyalıyorsun, sonra o tarihi koşul olarak geri gönderiyorsun.

curl.exe -sI https://example.com/
curl.exe -sI -H "If-Modified-Since: <yukarıdaki tarih>" https://example.com/

İkinci çıktının ilk satırı HTTP/1.1 304 Not Modified oluyor ve gövde hiç gelmiyor. Aynı çıktıda etag ve Age satırları da duruyor, yani doğrulayıcıyı ve paylaşılan bir önbelleğin yaşını tek komutta görüyorsun. example.com belgeleme için ayrılmış bir ad.

Özet

Peki, ne öğrendik?

• HTTP hiçbir şey tutmuyor: her istek ötekilerden bağımsız okunuyor ve adımları birbirine bağlayan şey protokolün dışında kalıyor.
• Çerez durumu senin makinene koyuyor: Set-Cookie yazıyor, Cookie geri getiriyor, tarayıcı saklıyor, veritabanı karşılığını tutuyor.
• Öznitelikler ömrü ve kapsamı çiziyor: Max-Age süreyi, Domain ile Path yeri, Secure ile HttpOnly erişimi sınırlıyor.
• Önbellek kapasite satın almadan doluluğu düşürüyor: kopya sana yaklaşıyor ve dış hattın kullanım oranı geriliyor.
• Koşullu istek baytı kurtarıyor, turu değil: soru yine gidip geliyor, ama nesne hiç iletilmiyor.

Tek bir nesne için bütün bu yolu yürüdün: bir kimlik, bir saklama kararı, bir de tazelik sorusu. Ama açtığın sayfa tek nesne değil; onlarca parçadan kurulu. Bir sayfa yüzlerce parçadan oluşuyorsa, her parça için bu yolu baştan mı yürüyeceksin?

Bölüm 14: HTTP/2'den HTTP/3'e

Bir sayfa yüzlerce parçadan oluşuyor ve her parça için yolu baştan yürümek eski çözümdü. İstek satırını ve durum kodlarını açarken, tek bağlantıya kaç isteğin sığdığını tek cümleyle bırakmıştım.

Borcu burada ödüyorum. Aynı yolun üstünde kaç araba var, ve arkadaki neden bekliyor?

Bağlantıyı açık bırakmak neyi kurtarıyor?

Kalıcı olmayan kipte bir taşıma bağlantısı en çok tek bir nesne taşıyordu. Klasik anlatım dört adımdı: bağlan, ne istediğini söyle, cevabı al, bağlantıyı kes. Dördü de her nesnede baştan tekrarlanıyordu.

Bedeli gidiş-dönüş süresiyle ölçebilirsin. Kalıcı olmayan kipte her nesne iki tur yiyor: biri bağlantı kurulumu, biri istek ve yanıtın ilk baytları. Üç el sıkışmanın RTT bedelini sayarken bu turun ilkini adım adım görmüştük.

Sayıya dökelim. 60 bağlı nesne taşıyan bir sayfa düşün ve gidiş-dönüş süresi 40 ms olsun. Yalnızca kurulum ve istek turları 4.800 ms tutuyor, yani 4,8 saniye. Dosya aktarım süreleri bu hesaba daha hiç girmedi; sayfa açılmadan önce sırf yolu kurmak için beş saniyeye yakın bekliyordun.

Ödediğin şey yalnızca gecikme de değil. Her yeni bağlantı işletim sistemi tarafında tampon, durum kaydı ve kontrol bloğu istiyor; bunların hepsi altmış kez birden kuruluyor.

HTTP/1.1 varsayılanı tersine çevirdi. RFC 9112’de kalıcı bağlantı varsayılandır: sunucu yanıtı gönderdikten sonra bağlantıyı açık bırakıyor ve aynı bağlantıdan birden çok istek ile yanıt geçiyor. Varsayılandan çıkmak için Connection başlığına close yazman gerekiyor. Kapatmak artık istisna.

Kazanç burada görünüyor. Kalıcı bağlantı, sayfadaki bütün bağlı nesnelerin toplam bedelini tek gidiş-dönüşe kadar indirebiliyor. Aynı sayfa iki gidiş-dönüşe, yani 80 ms’ye iniyor: biri kurulum, öbürü bütün nesneler için. Aradaki fark 60 kat.

Sıra zorunluluğu kimi bekletiyor?

HTTP/1.1 bir de boru hattını getirdi. İstemci yanıtı beklemeden istekleri arka arkaya gönderebiliyor. Sunucu güvenli metotları paralel işleyebilir, ama yanıtları isteklerin geldiği sırayla göndermek zorunda.

Zorunluluğun sebebi sade. HTTP/1.1’de istekleri yanıtlarla eşleştiren bir kimlik alanı yok; tek dayanak varış sırası. Protokolün tek varsayımı da güvenilir ve sırayla teslim eden bir taşıma. HTTP/1.0’da durum daha dardı: bir bağlantıda aynı anda yalnızca tek bir istek açık kalabiliyordu.

Sonuç şu: küçük bir nesne, önündeki büyük nesnenin arkasında beklemek zorunda kalıyor. Buna baş engellemesi (head-of-line blocking) deniyor. Burada gördüğün, uygulama katmanındaki baş engellemesi.

tek bağlantı, yanıtlar isteklerin geliş sırasında
  istekler :  A ---> B ---> C
  yanıtlar :  [============ A ============][ B ][ C ]
                                            ^ B hazırdı, A bitene kadar bekledi

2. bölümde paket anahtarlamayı ve kuyruk gecikmesini otoyol şeritleriyle anlatmıştım; tek şeritte önündeki aracı geçemezsin. Tarayıcılar bu şeritten kaçmak için aynı sunucuya paralel bağlantılar açıyor. RFC 9112 kaçışın sebebini açıkça yazıyor. Standardın eski sürümleri paralel bağlantı sayısına sayısal bir tavan koyuyordu. O tavan kaldırıldı, çünkü pek çok uygulama için pratik değildi. Yerine ölçülü olma öğüdü kaldı.

Ölçülü olmayan taraf kazanıyor. 9 bağlantının paylaştığı bir hatta tek bağlantı isteyen onda bir pay alıyor, 11 bağlantı açan ise hattın yarısını alıyor. Tıkanıklık denetimini polisleyen kimse yok. Dahası, tıkanık olmayan bir ağda bile eşzamanlı başlayan gönderimler, daha az bağlantıyla hiç oluşmayacak bir tıkanıklık yaratabiliyor.

Çerçeveye bölmek yetiyor mu?

HTTP/2 ilk olarak 2015’te RFC 7540 ile yayımlandı; yürürlükteki belgesi RFC 9113 oldu. Metotlar, durum kodları ve başlık alanlarının çoğu HTTP/1.1’den olduğu gibi kaldı. Değişen anlam değil, taşıma biçimi.

İkili çerçeveleme geldi. Nesneler çerçevelere bölünüyor ve çerçeveler iç içe geçirilerek gönderiliyor; küçük nesne artık büyüğün bitmesini beklemiyor. Gönderim sırası da geliş sırasına göre değil, istemcinin bildirdiği önceliğe göre kurulabiliyor. Başlık alanları ayrıca sıkıştırılarak kodlanıyor.

Paralellik sayıyla korunuyor. SETTINGS_MAX_CONCURRENT_STREAMS için önerilen alt sınır 100 eşzamanlı akış ve gerekçesi açık: paralelliği gereksiz yere kısmamak. Her akış 65.535 baytlık bir başlangıç penceresiyle açılıyor. Pencere, alıcının “şu kadar baytı onaylamadan gönderme” demesinin yoludur ve adı flow control (akış denetimi); hızlı bir göndereni yavaş bir alıcının tamponunu taşırmaktan alıkoyar.

İş burada bitmiyor. HTTP/2 uygulama katmanındaki baş engellemesini çözüyor, taşıma katmanındakini çözmüyor. RFC 9113 bunu kendi giriş bölümünde açıkça yazıyor. Sebebi tek cümle: tek taşıma bağlantısı verinin sırayla teslim edilmesini garanti ediyor. Kaybolan ya da sırası bozulan tek bir paket, o paketle hiç ilgisi olmayan bütün işlemleri de durduruyor.

Çoklamayı uygulama katmanına koydular, ama alttaki taşımanın kayıp kurtarma mekanizması onu göremiyor. Tarayıcıların hâlâ paralel bağlantı açma teşviki buradan geliyor.

Taşımanın kendisi neden değişti?

Çıplak bir taşıma bağlantısı kendi başına hiçbir güvenlik getirmiyor. Şifreleme ayrı bir katmandan geliyor ve ayrı bir el sıkışma istiyor. Eski kurulumda iki el sıkışma arka arkaya çalışıyordu: önce taşımanın güvenilirlik ve tıkanıklık durumu, sonra güvenlik katmanının kimlik ve anahtar durumu. Biri bitmeden öbürü başlamıyordu.

HTTP/3 anlamları hiç değiştirmiyor. RFC 9114 aynı HTTP anlamlarını yeni bir taşıma protokolünün üstüne taşıyor: QUIC. Yığın şöyle diziliyor: HTTP/3, altında QUIC, onun altında UDP, onun altında IP.

QUIC yeni bir fikir de icat etmiyor. Bağlantı kurulumu, hata denetimi ve tıkanıklık denetimi için bilinen taşıma çözümlerini uygulama tarafına taşıyor. Spesifikasyon algoritmaların koşut olduğunu kendisi söylüyor.

Asıl fark akışlarda. QUIC’te akış çoklaması ve akış başına flow control taşıma protokolünün kendi işi. Güvenilir aktarım akış başına ayrı tutuluyor, tıkanıklık denetimi ise ortak: bütün akışlar tek bir bütçeyi paylaşıyor. Paket kaybında yalnızca o pakette verisi bulunan akışlar yeniden gönderimi bekliyor. Ötekiler yoluna devam ediyor.

Üç kuşağı aynı kayıp üstünde karşılaştırmak istersen:

Ayrım paket sınırında duruyor. Çoklama, farklı akışların STREAM çerçevelerini aynı QUIC paketlerine iç içe koyuyor. Tek pakete birden çok akışın verisi konabiliyor. O paketin kaybı hepsini birden durduruyor. Gerçekleştirimlere pakete gereğinden fazla akış koymamaları öğütleniyor.

El sıkışma da tek tura indi. QUIC, TLS 1.3’ü taşıma katmanının içine aldı; güvenilirlik, tıkanıklık denetimi, kimlik doğrulama ve şifreleme durumu tek el sıkışmada birlikte kuruluyor. İstemci daha önce sakladığı oturum biletini kullanırsa el sıkışma gecikmesi sıfıra iniyor ve uygulama verisi ilk pakette gidiyor. O biletin bedelini biliyorsun: tekrar oynatma saldırısına karşı koruma yok. RFC 9114 bu yüzden karşı önlemleri zorunlu tutuyor.

Bir kazanç daha var. QUIC bağlantısı adresle değil, bağlantı kimliğiyle tanınıyor ve bu kimlik QUIC sürüm 1’de en çok 20 bayt olabiliyor. Uç noktanın adresi ve portu değişse bile bağlantı yaşamaya devam ediyor; buna bağlantı göçü deniyor. Değişim her zaman kasıtlı da değil; aradaki NAT kutusu yeni bir giden port atadığında da oluyor. Her iki durumda da yeni yolun doğrulanması gerekiyor, ve doğrulama başarısızsa yalnızca o yol kullanılmıyor. Göçü yalnızca istemci başlatabiliyor, üstelik el sıkışma doğrulanmadan başlatamıyor.

HTTP/3 tarafında eşleme sade. Her istek, istemcinin açtığı çift yönlü bir QUIC akışında gidiyor ve bir akışta yalnızca tek bir istek gönderilebiliyor. İkinci istek yeni akış demek. Akış kimliği 62 bitlik bir tam sayı; en düşük bit akışı kimin açtığını, ikinci bit tek yönlü mü çift yönlü mü olduğunu söylüyor. İki bit dört akış türü üretiyor.

HTTP/3 mesajının parçaları        çerçeve      tür kodu
  başlık bölümü                   HEADERS      0x01
  gövde                           DATA         0x00
  fragman başlıkları              HEADERS      0x01
  bağlantı ayarları               SETTINGS     0x04
  kapanış duyurusu                GOAWAY       0x07

Gövdesi olmayan bir yanıtta DATA çerçevesi hiç gönderilmiyor; gövde 0 bayt ise ortada çerçeve de yok. Her uç ayrıca en az 3 tek yönlü akışa izin vermek zorunda: bir HTTP denetim akışı ve başlıkları sıkıştıran QPACK’in iki akışı. Bu akışlara en az 1.024 baytlık flow control kredisi verilmesi öğütleniyor.

Bunu kendi makinende görebilirsin. Sürüm seçimi TLS el sıkışmasında ALPN uzantısındaki h3 belirteciyle bildiriliyor, sunucu da desteğini Alt-Svc yanıt başlığıyla duyuruyor. HTTP/3 için zorunlu tek bir UDP portu yok; duyuruda port bu yüzden açıkça yazılıyor.

curl -sI https://cloudflare-quic.com/ | grep -i '^alt-svc'
# alt-svc: h3=":443"; ma=86400

Sonra trafiği dinle. İlk QUIC datagramı en az 1.200 bayt olmak zorunda ve gerekirse PADDING çerçeveleriyle şişiriliyor; sebebi yükseltme saldırısını sınırlamak. Yol o boyu taşıyamıyorsa QUIC hiç kullanılmıyor. QUIC en küçük IP paketini 1.280 bayt varsayıyor. IPv6’da bundan 40 baytlık IP başlığı ile 8 baytlık UDP başlığı düşülüyor ve datagram tavanı 1.232 bayta iniyor. IPv4 başlığı daha kısa olduğu için orada tavan 1.252 bayt oluyor.

sudo tcpdump -n -c 5 'udp port 443'

Şifreli HTTP’nin klasik varsayılan port numarası 443, şifresizinki 80. UDP engellenmiş bir ağda hiçbir şey göremezsin, çünkü orada QUIC bağlantısı hiç kurulamıyor. Standart bu durumda istemcinin eski sürümlere düşmesini bekliyor.

Özet

Peki, ne öğrendik?

• Kalıcı bağlantı varsayılan oldu: sunucu yanıttan sonra kapatmıyor, kapatmak için Connection başlığına close yazmak gerekiyor.
• Baş engellemesi sıra zorunluluğundan doğuyor: istekleri yanıtlarla eşleştiren bir kimlik alanı olmayınca tek dayanak varış sırası kalıyor.
• HTTP/2 çerçeveledi ama taşımayı değiştirmedi: iç içe geçen çerçeveler uygulama katmanını kurtarıyor, kaybolan tek paket yine hepsini durduruyor.
• QUIC güvenilirliği akış başına ayırdı: kayıp yalnızca o pakette verisi olan akışları bekletiyor, el sıkışma ise tek tura iniyor.

Aynı yolun üstünde artık birden çok araba var ve hiçbiri ötekini beklemiyor. İsteğin yola çıktı; peki gerçekten adres çubuğuna yazdığın makineye mi gidiyor?

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?

Bölüm 16: Diğer Uygulama Protokolleri

İsteğimiz hâlâ yolda. Ama aynı kabloda o an akan tek şey o değil: komşu dairede bir film oynuyor, bir posta sunucusu kuyruğunu boşaltıyor, biri dosya paylaşıyor.

Şimdiye kadar ağı tek bir isteğin gözünden anlattım. Bu bölümde diğerlerine bakıyoruz; ihtiyaçları bambaşka. Aynı taşımadan ne bekliyorlar?

Bir protokolü protokol yapan nedir?

Uygulama katmanında bir protokolün tanımlaması gereken dört şey var. Birincisi hangi ileti türlerinin değişileceği: istek ve yanıt. İkincisi sözdizimi, yani hangi alanların bulunduğu ve nasıl ayrıldığı. Üçüncüsü o alanların ne anlama geldiği. Dördüncüsü süreçlerin ne zaman gönderip nasıl karşılık vereceği.

Bu dördünün tanımını herkesin okuyabildiği bir belgede bulabiliyorsan elinde bir açık protokol var demektir; o belge de çoğu zaman bir RFC oluyor. Elle yazdığın istek satırının çalışma sebebi buydu: karşı taraf aynı belgeyi okumuştu. Karşısında tescilli protokoller var; görüntülü toplantı uygulamalarının çoğunda telde ne aktığını yalnızca üreticisi bilir.

İkinci ayrımı mimaride yapıyorsun. İstemci-sunucu mimarisinde bir uçta sürekli açık duran, kalıcı adresli bir makine bulunuyor. İstemciler aralıklı bağlanıyor, adresleri değişebiliyor ve birbirleriyle hiç konuşmuyor. HTTP, IMAP ve FTP bu mimarinin örnekleri.

Eşler arası mimaride sürekli açık sunucu yok. Her uç hizmeti başka uçlardan istiyor, karşılığında kendisi de veriyor; dosya paylaşımında BitTorrent böyle çalışıyor. Kazancına kendiliğinden ölçeklenme deniyor: katılan her yeni eş sisteme yeni talep getirirken aynı anda yeni kapasite de getiriyor. Bedelini ise yönetim karmaşası olarak ödüyorsun. Burada hizmeti veren uçlar da aralıklı bağlı ve adresleri değişiyor.

Zarfın üstü mektubun içiyle aynı olmak zorunda mı?

E-postayı üç parçaya ayırabilirsin: kullanıcı ajanı, posta sunucuları ve SMTP. Yazdığın ileti senin makinende durmuyor; giden de gelen de sunucuda saklanıyor. Sunucunun içinde de iki ayrı yapı buluyorsun. Kullanıcı başına bir posta kutusu gelen iletileri tutuyor, bir de giden kuyruğu var.

Kuyruktaki iletiyi taşıyan protokole SMTP deniyor. Gönderen sunucu, alan sunucuya kendisi bağlanıyor ve arada aracı bir depo bulunmuyor. Bağlantı TCP üzerinden 25 numaralı porta açılıyor ve bağlantıyı başlatan taraf istemci rolüne giriyor. O taraf da bir posta sunucusu. Aktarımı üç evrede tamamlıyorlar: selamlaşma, iletilerin aktarımı ve kapanış.

Komutları düz ASCII metin olarak yazıyorsun; yanıtlar da üç haneli bir kod ile kısa bir ifadeden oluşuyor. Belgeleme için ayrılmış adlarla oturum şöyle görünüyor:

220 mail.example.com ESMTP hazir
HELO gonderen.example.net
250 merhaba gonderen.example.net
MAIL FROM: <deniz@example.net>
250 gonderen kabul edildi
RCPT TO: <arda@example.com>
250 alici kabul edildi
DATA
354 govdeyi bekliyorum, sonu tek nokta
From: deniz@example.net
To: arda@example.com
Subject: kablo raporu

Rapor ekte.
.
250 ileti teslim icin alindi
QUIT
221 kapaniyorum

İletinin bittiğini ayrı bir uzunluk alanından değil, tek başına nokta içeren bir satırdan anlıyorsun; yani CRLF.CRLF dizisinden. Bağlantı da kalıcı kalıyor: aynı TCP bağlantısından arka arkaya birçok ileti geçebiliyor.

İki kısıt daha var. SMTP hem başlığın hem gövdenin 7 bitlik ASCII olmasını şart koşuyor. Resim ya da PDF bu boruya olduğu gibi giremiyor, önce ASCII’ye kodlanıyor. Bunu yapan katmanın adı MIME, en bilinen kodlaması base64. Base64 her üç baytı dört karaktere açtığı için gövde yaklaşık %33 şişiyor. İkinci kısıt paketleme: HTTP her nesneyi kendi yanıtında taşırken SMTP birden çok nesneyi tek bir çok parçalı iletide taşıyor. Eklerin aynı iletinin içine girmesinin sebebi bu. Yön de ters: HTTP’de istemci çeker, SMTP’de istemci iter.

Taşıyan protokolle iletinin biçimi ayrı standartlarda duruyor. Aktarımı RFC 5321 tanımlıyor, eski numarası RFC 821’di. İletinin sözdizimi ise RFC 5322’de, eski numaraları RFC 2822 ve RFC 822’ydi. İskelet tanıdık: başlık satırları, boş bir satır, sonra gövde.

Yukarıdaki oturumda iki ayrı adres kümesi geçti. MAIL FROM ile RCPT TO zarfın üstünü yazıyor. From: ve To: satırları ise mektubun içinde duruyor. İkisinin aynı olma zorunluluğu yok ve sahte gönderen sorununun kökü tam olarak burası. SMTP iletinin içeriğiyle ilgilenmiyor; tek işi onu hedef makineye ulaştırmak.

Sahte gönderen nasıl kapatıldı?

Yukarıdaki oturumda hiçbir yerde kimlik kanıtı istenmediğine dikkat et. MAIL FROM satırına istediğini yazabilirsin; SMTP sana inanır. 1982’de bu bir kusur değildi, çünkü ağdaki herkes birbirini tanıyordu. Bugün kusur.

Protokolü değiştirmek mümkün olmadı — dünyadaki her posta sunucusunu aynı gün güncelleyemezsin. Onun yerine üç ayrı katman DNS üzerinden eklendi, ve üçü de TXT kaydını kullanıyor.

SPF en basiti: alan sahibi, “benim adıma yalnızca şu IP adresleri posta gönderebilir” diye bir liste yayımlıyor.

example.net.  TXT  "v=spf1 ip4:198.51.100.0/24 include:_spf.saglayici.com -all"

Alıcı sunucu, bağlanan makinenin adresini bu listeye karşı sınıyor. Sondaki -all “listede yoksa reddet” demek. Kusuru da var: MAIL FROM alanına, yani zarfın üstüne bakıyor — kullanıcının gördüğü From: satırına değil. Üstelik ileti bir posta listesi üzerinden yönlendirilirse gönderen adres değişir ve SPF kırılır.

DKIM başka bir yerden yakalıyor: imza. Gönderen sunucu, seçtiği başlıkları ve gövdeyi özel anahtarıyla imzalayıp iletiye bir DKIM-Signature başlığı ekliyor. Açık anahtar yine DNS’te, secici._domainkey.example.net adresinde duruyor. sayısal imzanın posta zarfındaki hâli bu. Yönlendirmeye dayanıyor, çünkü imza iletiyle birlikte seyahat ediyor. Kusuru: imzayı atan alanın, kullanıcının gördüğü From: alanıyla aynı olması gerekmiyor.

İki mekanizma da aynı boşluğu bırakıyor: kullanıcının gördüğü satır hâlâ korunmuyor.

DMARC o boşluğu kapatıyor ve üçlünün çatı katı. Alan sahibi _dmarc.example.net adresinde bir politika yayımlıyor:

_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:rapor@example.net"

Şartı iki parçalı. Birincisi, SPF ya da DKIM’den en az biri geçmeli. İkincisi ve asıl yenilik: geçen mekanizmanın alanı, From: satırındaki alanla hizalı olmalı. Böylece imzayı saldirgan.com atıp From: satırına bankaniz.com yazmak işe yaramıyor. p= politikası ne yapılacağını söylüyor: none yalnızca raporla, quarantine spam klasörüne at, reject hiç kabul etme.

rua= adresi de az bilinen ama değerli bir parça: uyumlu alıcılar, alan adına kimin posta göndermeye çalıştığını özetleyen günlük raporlar yolluyor. Alan sahibi böylece kendi adının nerede kötüye kullanıldığını görebiliyor.

Üçünün ortak dersi şu: kimliği protokole ekleyemedikleri için adın yanına eklediler. Posta sunucusu değişmedi; değişen şey, o sunucunun DNS’e bir soru daha sorması oldu.

İleti sunucuda; onu kim alıyor?

SMTP çizgiyi burada çekiyor. İletiyi alıcının sunucusuna teslim ediyor ve orada bırakıyor; sunucudan almak ayrı bir erişim protokolünün işi. IMAP iletileri sunucuda tutuyor ve alma, silme, klasör yönetme işini üstleniyor; tanımı RFC 3501’de. IMAP ile POP3’ün numaraları 143 ile 110; ikisi de iyi bilinen port aralığının içinde kalıyor.

Tarayıcıdan girdiğin posta hizmetine webmail deniyor ve yeni bir protokol getirmiyor. HTTP arayüzünü göndermek için SMTP’nin, almak için IMAP ya da POP’un üstüne koyuyor.

Video akışı neden bir indirme sayılmıyor?

2020’de servis sağlayıcıların konut trafiğinin %80’i üç akış hizmetine gidiyordu. Aynı filmi isteyenlerin bağlantıları da birbirine benzemiyor: kimi fiberde, kimi hücresel veride.

Video, sabit hızda gösterilen bir görüntü dizisi. Saniyede 24 görüntü tipik bir gösterim hızı, kayıtta saniyede 30 kare de yaygın. Her görüntü bir piksel dizisi ve her piksel bitlerle temsil ediliyor. Ham hâlde bu sayı devasa. Kodlama onu, görüntü içindeki ve görüntüler arasındaki tekrarı kullanarak düşürüyor. Sabit bit hızında kodlama hızı sabit kalıyor, değişken bit hızında sahnedeki tekrara göre oynuyor. Somut karşılıkları var: MPEG 1 için 1,5 Mbit/s, MPEG2 için 3 ile 6 Mbit/s, MPEG4 için 64 Kbit/s ile 12 Mbit/s arası.

Bir hesap bunu yere indiriyor. 5 Mbit/s sabit hızda iki saatlik film 7.200 saniye × 5 Mbit, yani 36.000 Mbit tutuyor: kabaca 36 Gbit, yaklaşık 4,5 GB. İzlemeye başlamadan önce bunun inmesini beklemek kabul edilebilir bir şey değil.

Akışın tanımı da zaten bu: sen videonun başını izlerken sunucu hâlâ sonrasını gönderiyor. Kısıt sert. Oynatma zamanlaması kaydın özgün zamanlamasıyla aynı olmak zorunda, ağ gecikmesi ise değişken. Bu yüzden istemci tarafında bir tampon şart; ağın eklediği gecikmeyi ve gecikme oynamasını o karşılıyor. Üstüne duraklatma, sarma ve ortaya atlama da isteniyor.

İkinci sorun bant genişliği. Sunucudan sana kalan pay zamanla değişiyor; tıkanıklık evde de, erişim ağında da, çekirdekte de olabiliyor. Kayıp ve gecikme ya oynatmayı geciktiriyor ya da görüntüyü bozuyor.

DASH bu iki sorunu tek tasarımla karşılıyor. Sunucu dosyayı parçalara bölüyor ve her parçayı birden çok hızda kodlayıp ayrı dosyalarda saklıyor. Manifest dosyası bu parçaların adreslerini veriyor; istemcinin elindeki tek harita o. İstemci bant genişliğini düzenli aralıklarla ölçüyor, her seferinde tek bir parça istiyor ve o an sürdürebileceği en yüksek hızı seçiyor. Zekâ sunucuda değil, istemcide. Üç kararı da o veriyor: parçayı ne zaman isteyeceğini, hangi kodlama hızını isteyeceğini ve hangi sunucudan isteyeceğini.

Şimdi parça süresini 4 saniye olarak kabul edelim. İki saatlik film 1.800 parça eder, yani tek bir film için 1.800 ayrı HTTP isteği. Aynı hızda tek parça 20 Mbit, yani 2,5 MB. DASH’in açılımı da bunu söylüyor: HTTP üzerinden dinamik, uyarlanır akış. O parçaların hangi makinede durduğu ise kenar sunucularında çözülmüştü.

Aynı kablodan geçen sesler taşımadan ne istiyor?

Hepsi aynı taşıma katmanının üstünde duruyor ama ondan aynı şeyi istemiyor. İstekler dört eksende ayrışıyor: veri bütünlüğü, zamanlama, throughput ve güvenlik.

Dosya aktarımı ve web işlemleri %100 güvenilirlik istiyor; tek bayt eksik gelen arşiv bozuk arşivdir. Ses ise bir miktar kaybı kaldırıyor. Throughput tarafında da bantlar var: gerçek zamanlı ses 5 Kbit/s ile 1 Mbit/s arasında, akan video 10 Kbit/s ile 5 Mbit/s arasında çalışıyor. Elastik uygulamalar ne bulursa onu kullanıyor. Bu istekler protokol seçimine dönüşüyor:

Telefonun UDP tarafına düşebilmesi tesadüf sayılmaz: 6. bölümde bağlantısız gönderimi anlatırken geç gelen verinin hiç gelmemiş sayıldığını söylemiştim.

Listede bir de tarihsel kalıntı duruyor. Telnet uzaktaki makineye bağlanıp komut vermeyi sağlıyor; ama parolalar dahil her şey açık gidiyor. SSH aynı işi güçlü bir şifrelemeyle yapıyor. Bugün 23 numaralı portun yerini 22 almış durumda.

Bu adların hepsi kendi makinende tek bir dosyada duruyor:

grep -E '^(ftp|ssh|telnet|smtp|domain|http|pop3|imap2)[[:space:]]' /etc/services

Her satırda bir ad, bir numara ve taşıma protokolü göreceksin: smtp 25/tcp gibi. Windows tarafında aynı liste %SystemRoot%\System32\drivers\etc\services yolunda duruyor. Bu bölümde adı geçen protokollerin hemen hepsini o satırlarda bulabilirsin.

Özet

Peki, ne öğrendik?

• Bir protokol dört şeyi tanımlar: ileti türlerini, sözdizimini, alanların anlamını ve gönderme kurallarını. Açık olanın tanımı bir RFC’de durur.
• E-postanın zarfı ile mektubu ayrı yazılır: MAIL FROM ile RCPT TO zarfın üstündedir, From: ile To: mektubun içindedir, ve ikisinin uyuşma zorunluluğu yoktur.
• SMTP teslim eder, erişim protokolü alır: ileti alıcının sunucusunda kalır, oradan çekme işini IMAP ya da POP3 yapar.
• Video akışı yüzlerce küçük istektir: 4 saniyelik parçalarla iki saatlik bir film 1.800 ayrı HTTP isteğine dönüşür ve hızını istemci seçer.

Aynı kablodan geçen sesleri tek tek duydun; kimi güvenilirlik istiyor, kimi zamanında gelmeyi. Ama hepsi o kabloya girerken aynı işlemden geçiyor. İstek makineden çıkacak; peki çıkarken tam olarak neye dönüşüyor?

Bölüm 17: Katmanlı Mimari

İstek makineden çıkarken düz metin olmaktan çıkıyor ve iç içe geçmiş zarflara dönüşüyor. O zarfların bir sırası var, ve o sırayı şimdiye kadar kasten adlandırmadım.

Adı katman. Zarfları bir sonraki durakta açacağız; burada onları saran düzeni kuruyoruz. Peki bu düzen neden kuruldu, ve içinde kaç kat var?

Bir katman neyin üstüne basıyor?

Katmanlı düzenin tanımını tek cümleye sığdırabilirsin. Bir katın elinde iki şey var: kendi yaptığı iş ve hemen altındakinden aldığı hizmet; dışarıya verdiği söz bu ikisinden çıkıyor. Daha aşağısını bilmiyor, ve bilmemesini bir eksik olarak görme — tasarımın kendisi bunu istiyor.

Kazancına modülerlik deniyor. Bir katmanın hizmetini nasıl ürettiği baştan aşağı değişebiliyor ve üstteki kat bunu hiç fark etmiyor. Kablo bakırdan cama dönüyor, tarayıcı tek satırını bile değiştirmiyor. Aynı bağımsızlığı öteki yönde de göreceksin: yeni bir uygulama protokolü yazmak için yol üstündeki yönlendiricilere dokunman gerekmiyor.

Bunu bir kargo şirketinin tezgâhında kolayca görebilirsin. Tezgâhtaki görevli kutunun içine bakmıyor; üstüne bir barkod yapıştırıyor ve işi bitiyor. Ayırma merkezindeki bant barkodu okumuyor, onun tek derdi şehir etiketi. Şoför şehir etiketini de umursamıyor; elinde yalnızca bir sefer listesi duruyor. Haritalama şöyle: kutu uygulamanın mesajı, barkod taşıma başlığı, şehir etiketi ağ başlığı, sefer listesi ise bağ katmanının çerçevesi. Benzetme şurada biter: kargoda tıkanan bir gönderi için görevli kutuyu açıp içine bakabilir, hatta bakmak zorundadır. Katmanlarda o yetki yok.

Modülerliğin yanında ikinci bir kazanç daha var ve adı adlandırma. Yığın açıkça bölündüğü için her parçanın ayrı bir adı, her sınırın ayrı bir yeri oluyor. Katmanlamayı önce bir konuşma dili, sonra bir mühendislik aracı olarak düşün. Arıza da o dille bulunuyor: bağlantı var ama isim çözülmüyor cümlesi, sorunun nerede olmadığını daha kimse bakmadan söylüyor.

Kaç katman var? Üç cevap, üçü de doğru

Katman sayısını sorduğunda üç ayrı rakam duyacaksın ve üçü de aynı ağı tarif ediyor.

OSI referans modeli yedi katman sayıyor; ilan edilmiş amacı karmaşıklığı azaltmak ve ortak standart geliştirmek. TCP/IP ise dörtle yetiniyor: Application, Transport, Internet, Network Interface. En alttaki Ağ Giriş katmanı, OSI’nin veri bağı ve fiziksel katmanlarının işini tek başına görüyor; ona host-to-network da deniyor. Ders kitaplarının çoğu ise ikisinin arasında duran beş katmanlı bir yığın öğretiyor. OSI’nin veri bağı dediği kata bu kitap boyunca bağ katmanı diyeceğim.

En alttaki satırın işi kulağa fazla sade geliyor olabilir. Oysa bir tel çekilmeden önce kararlaştırılması gereken her şeyi orada bulacaksın. Standart bunları dört başlıkta topluyor ve dördünü de bir bit yola çıkmadan cevaplamış olman gerekiyor:

• Mekanik: konnektörün şekli, kaç pin taşıdığı, boyutları. RJ-45’in sekiz pini bu başlıktadır.
• Elektriksel: bir bitin kaç volt olduğu, kaç mikrosaniye sürdüğü, hattın empedansı. 100 ohm’luk twisted pair (bükümlü çift) bu başlıktadır.
• İşlevsel: hangi pinin ne anlama geldiği. 1 ve 2 numaralı pinin “gönder” çifti olması bu başlıktadır.
• Yordamsal: olayların hangi sırayla olacağı. Bağlantı algılama darbeleri ve hız pazarlığı bu başlıktadır.

İki taraf bu dört başlıkta anlaşmamışsa iletim hiç başlamıyor. Bir uç sayısal 1’i +5 volt ve 2 mikrosaniye olarak gönderirken öteki uç +7 volt ve 5 mikrosaniye bekliyorsa, kablo sapasağlam olsa bile karşıya tek bir bit geçmiyor.

Internet yığınında karşılığı olmayan iki kat

OSI’nin yedilisinde TCP/IP’de karşılığı olmayan iki kat var. İkisi de “gerçeklenmedi” diye geçiştiriliyor; oysa ikisinin de tarif ettiği iş bugün fazlasıyla yapılıyor, sadece başka bir yerde.

Sunum katmanı tek bir soruyla uğraşır: aynı bit dizisini iki makine aynı şey olarak mı okuyor? Cevap kendiliğinden evet değil. OSI bu işi ikiye böler. Soyut sözdizim verinin ne olduğunu söyler — “bu alan bir tamsayı, şu alan bir tarih”. Aktarım sözdizimi ise o soyut tanımın telde hangi baytlara döneceğini söyler. İkisini ayırmak, aynı veriyi farklı kodlamalarla göndermeyi mümkün kılıyor.

Bu ayrımın bir gösterimi var ve adı ASN.1; kodlama kuralları da BER ve DER. Kulağa müzelik geliyor, değil: tarayıcının doğruladığı X.509 sertifikası ASN.1 ile tanımlı ve DER ile kodlanmış bir yapıdır. SNMP de aynı gösterimi kullanır. Sunum katmanı ölmedi; adı unutuldu.

İkinci iş bayt sırası. Bir sayıyı belleğe yazarken kimi işlemci en anlamlı baytı başa koyar, kimi sona. İki makine bu konuda anlaşmazsa 1.000 yazan biri karşıda 59.395 okur. Ağda bu yüzden tek bir kural var ve adı ağ bayt sırası: en anlamlı bayt önce. Ağ programı yazan herkes, sayıyı sokete koymadan önce bu sıraya çevirmek zorunda — ve o çevirme tam olarak sunum katmanının işi. Üçüncü iş karakter kodlaması, dördüncüsü sıkıştırma, beşincisi şifreleme. Tarayıcının kurduğu şifreli kanal, kitap boyunca göreceğin en canlı sunum katmanı örneği.

Oturum katmanı ise iki tarafın konuşma düzenini yönetir. Üç işi var. Birincisi diyalog denetimi: sıranın kimde olduğunu belirler, çünkü yarım çift yönlü bir hatta iki tarafın aynı anda konuşması karışıklık demektir. İkincisi eşitleme noktaları: uzun bir alışverişin içine işaretler koyar, bağlantı koptuğunda taraflar en son işaretten devam eder. Üçüncüsü etkinlik yönetimi: birden çok işi tek bir oturumun içinde sıraya dizer.

İkinci iş bugün her yerde. İki saatlik bir dosya transferi %90’da koptuğunda baştan başlamıyorsan, birileri oturum katmanının işini yapıyor demektir — ve o birileri uygulamanın kendisi. HTTP’nin Range başlığı, kesilen indirmeyi kaldığı bayttan sürdüren istemci, QUIC’in bağlantı kimliği: üçü de ayrı bir kat açmadan aynı hizmeti kuruyor.

Internet yığınının kararı “bu işler gereksiz” değildi. Karar şuydu: bu işler her uygulama için aynı değil, o hâlde zorunlu bir kat yapma. Bir dosya transferi eşitleme noktası ister, bir DNS sorgusu istemez. Zorunlu kat, istemeyene de fatura keser.

Hangi cihaz hangi katmanda durur?

Sözlüğün asıl işi burada başlıyor. Bir kutunun kaçıncı katmanda çalıştığını belirleyen şey markası ya da fiyatı değil, okuduğu en derin başlıktır. Bir cihaz hangi başlığa kadar iniyorsa o katmanın cihazıdır; daha yukarısını görmez, daha aşağısını zaten taşımak zorundadır.

Aynı katmanın taşıdığı veri parçasının da her katta ayrı bir adı var. Adlar keyfî değil, konuşurken hangi zarftan bahsettiğini belirsizlikten kurtarıyor.

En üst satırdaki adlar şimdilik yabancı gelebilir; hepsi ileride tek tek açılıyor. Kabaca karşılıkları şöyle: vekil sunucu istemcinin isteğini onun adına ileten kutu, ters vekil aynı işi sunucunun önünde yapan ve istemcinin gerçekte konuştuğu kutu, yük dengeleyici ise gelen istekleri arkadaki birden çok sunucuya dağıtan kutu.

Tabloyu tersten okursan daha çok şey öğreniyorsun. En alttaki cihazın verecek hiçbir kararı yok. Hub gelen elektriği bütün portlara tekrar eder; içeride ne olduğunu bilmez, bilmesi de beklenmez. Bir üste çıktığında cihaz ilk kez bir alana bakıp bir karar veriyor: anahtar hedef MAC adresini okur ve çerçeveyi yalnızca o adresin öğrenildiği porta yollar. Bir üste daha çıktığında karar yerelden çıkar; yönlendirici hedef IP adresine bakar ve paketi başka bir ağa iletir.

Bu tırmanışın somut bir bedeli var: cihaz ne kadar yukarı çıkarsa paket başına o kadar çok iş yapar. Hub’ın gecikmesi mikrosaniyeler, anahtarınki onlarca mikrosaniye, yönlendiricininki daha fazla, istek başlıklarını ayrıştıran bir vekil sunucununki milisaniye mertebesindedir. Kutuyu yukarı taşımak her zaman gecikme satın almak anlamına geliyor.

İki uyarı da tabloyu doğru okumak için gerekiyor. Birincisi, bir cihazın kendi katmanının altındaki her katmanı da gerçeklemesi zorunludur. Yönlendirici üçüncü katman cihazıdır ama çerçeveyi çözmeden pakete ulaşamaz; her portu aynı zamanda ikinci ve birinci katmanda da çalışır. Katman numarası, cihazın tavanını söyler, tamamını değil.

İkincisi, saha adları modelin sınırlarını umursamıyor. 3. katman anahtar, anahtar donanımının hızıyla yönlendirme yapan bir kutudur; ismi ikinci katmanı, işi üçüncüyü anlatır. Ev kutun ise tek kasada modem, yönlendirici, anahtar ve access point’i birleştirir; birinci katmandan üçüncüye kadar hepsinde birden iş görür. Böyle bir kutuya tek bir numara vermek mümkün değildir — ve gerekmez de. Sorulması gereken soru “bu kutu kaçıncı katmanda?” değil, “bu kutu şu anda hangi başlığa bakıyor?” sorusudur.

Aynı harita bir arıza toplantısında da yön veriyor. Bir bağlantı hiç kurulmuyorsa sıra alttan başlar: kablo takılı mı, ışık yanıyor mu, karşı MAC öğrenilmiş mi, hedefe giden bir yol var mı, port açık mı, sunucu cevap veriyor mu. Her basamak bir katmandır ve her basamak arama alanını bir kat daraltır.

Komşuya verilen söz nedir?

Bir katmanın üç muhatabı var: altındaki, üstündeki ve karşı makinedeki eşi. İlk ikisiyle dikey, üçüncüsüyle yatay konuşuyor. Dikey ilişkinin adı hizmet, yatay ilişkinin adı protokol.

Sözleşme çift yönlü. Bir kat aynı anda hem üstüne hizmet veriyor hem altından hizmet alıyor. Hizmetin sınırını bir liste çiziyor; katmanın dışarıya açtığı temel işlemler neyse hizmet o kadar. Protokol ise iki eşin, kimin ne zaman ne göndereceğine dair önceden verdiği söz. Bu ikisini ayrı tutmak, kitabın geri kalanında çok işine yarayacak.

Bu ayrımın kolayca kaçırılan bir sonucu var: hizmet ile protokol bağımsız değişkenlerdir. Aynı hizmeti farklı protokollerle verebilirsin: taşıma katmanının “güvenilir bayt akışı” hizmetini TCP de verir, QUIC de. İkisinin içi tamamen başka, dışarıya verdikleri söz aynı. Bu yüzden bir uygulamayı TCP’den QUIC’e taşımak, üstündeki kodu baştan yazmayı gerektirmiyor.

Hizmetler ikiye ayrılır ve bu ayrım kitabın üçte birini açıklıyor. Bağlantı yönelimli hizmette önce bir kurulum yapılır, sonra veri akar, sonunda bağlantı kapatılır — telefon gibi. Bağlantısız hizmette kurulum yoktur; her birim kendi başına, kendi adresiyle yollanır — mektup gibi. 7. bölümde üç mesajlık el sıkışmayı kuran TCP birincisi, 6. bölümde hiçbir söz vermeyen UDP ikincisidir. IP de bağlantısızdır; güvenilir bir taşıma katmanının bağlantısız bir ağ katmanı üstünde durabilmesi, katmanlamanın en güçlü gösterisidir.

Bu kadar soyut bir sözleşmenin çok somut adları var. Uygulama ile taşıma arasındaki arayüz port numarasıdır; iyi bilinen iki örnek HTTP’nin 80 ve FTP’nin 21 numarasıdır. Çoklama çözme, tam olarak bu arayüzün sözleşmesi üstünde duruyor. Bağ ile ağ arasındaki arayüz ise Ethernet çerçevesinin 2 baytlık tür alanı. O alan, çerçevenin içindekinin üstteki hangi protokole teslim edileceğini söylüyor; bağ katmanının çoklama çözmesi tek bir alana sığmış durumda. Aynı işi LLC katmanında Service Access Point yapıyor.

Taşınan şeyin adı da katman katman değişiyor.

Dördünün ortak adına Protocol Data Unit deniyor; ağ katmanının birimine gündelik konuşmada paket de diyoruz. Adların değişmesini bir süs olarak görme: her kat bir öncekini yalnızca yük sayıyor. Başlık, o katın kendi hizmetini gerçeklemek için var. Bağ katmanı sararken başlığın yanına bir de kuyruk ekliyor; üstündeki katlarda böyle bir şey görmeyeceksin, onlar yalnızca başlık koyuyor.

Bu cümleyi tek bir denklemde toplayabilirsin. Üstten inen veriye o katın gözünden hizmet veri birimi (SDU) denir; kat kendi denetim bilgisini, yani protokol denetim bilgisini (PCI) ekler ve ortaya kendi protokol veri birimi (PDU) çıkar:

(N)-PDU = (N)-PCI + (N)-SDU        ve        (N)-PDU = (N−1)-SDU

İkinci eşitlik kapsüllemenin tanımını veriyor: bir katın ürettiği paket, bir alttaki katın gözünde ham veriden başka bir şey değil. Taşımanın ürettiği segment ağ katmanının SDU’su, ağ katmanının ürettiği datagram bağ katmanının SDU’sudur. Zarfın içinde zarf tam olarak budur ve bir sonraki bölümde aynı işi bayt bayt sayacağız.

Bir yer daha var ve orada tek bir kat kendi içinde ikiye bölünmüş durumda. Bağ katmanı IEEE 802 ailesinde iki alt katmandan oluşuyor. Alttaki MAC alt katmanı hattı kimin ne zaman kullanacağına karar veriyor ve fiziksel adresi taşıyor; Ethernet’in ve Wi-Fi’ın farklı olduğu yer burasıdır. Üstteki LLC alt katmanı (IEEE 802.2) ise üst katmana tek tip bir yüz gösteriyor. Bölünmenin sebebini ekonomide bulacaksın: ağ katmanı, altında bakır mı radyo mu olduğunu umursamak zorunda kalmıyor. ağ kartı denetleyicisinin çipte gerçeklediği şey tam olarak MAC alt katmanıdır.

Ayrımın en güzel sonucunu taşımada göreceksin. Taşımanın uygulamaya verdiği şeye mantıksal iletişim deniyor: iki makine doğrudan birbirine bağlıymış gibi görünüyor. Oysa arada yönlendiriciler var, ve paket anahtarlama her atlamada yeniden işliyor. Aynı datagram yol boyunca farklı bağ protokolleriyle taşınıyor. İlk atlamada onu Wi-Fi taşıyabiliyor, sonrakinde Ethernet; ikisi farklı hizmet veriyor ama datagram aradaki farkı hiç fark etmiyor.

Sınır bazen elle tutulur. Bağ katmanı çipte ya da ağ arayüz kartında gerçekleniyor, üstündeki katlar ise yazılım. Bakırdan radyoya geçtiğinde altındaki her şey değişiyor, MAC alt katmanı ise yerinde kalıyor.

Ortada neden tek bir protokol var?

Yığına yandan bakınca ortada bir daralma görüyorsun. Ağ katmanında tek bir protokol var: IP. Üstünde TCP, UDP, HTTP, SMTP ve QUIC yan yana yaşıyor. Altında Ethernet, Wi-Fi, Bluetooth ve PPP var, en altta da bakır, radyo ve fiber. Darlık yalnızca ortada, ve şekle bu yüzden kum saati deniyor.

Belin dar olmasının bedeli ağır. IP, İnternet’e bağlı milyarlarca cihazın her birinde gerçeklenmek zorunda. Karşılığında alınan şey de o kadar büyük: yeni bir bağ teknolojisi çıktığında yalnızca IP’yi taşıması yetiyor, üstündeki hiçbir protokolün haberi olmuyor.

Bunu yazıya döken belge RFC 1958 ve mimarinin üç köşe taşını sayıyor. Basit bağlanabilirlik, dar bel olarak IP, ve zekânın ağın kenarında durması. Aynı belge bir itirafı da taşıyor: mimari ilk 25 yıl boyunca hiç yazıya dökülmemişti.

Bel o günden beri kalınlaştı. Ağın içinde çalışan ara kutular araya girdi: adres çeviriciler, güvenlik duvarları, önbellekler. istek satırını okuyan bir ara kutu, tanımı gereği katman sınırını çiğniyor.

Katmanlamanın faturası

Buraya kadar hep kazancı saydım. Bedelini de saymak gerekiyor, çünkü üç kalemi var ve üçü de ölçülebilir.

Birinci kalem başlık. Her kat kendi başlığını ekliyor ve bu başlıklar veriye değil, katmanın kendi hizmetine ait. Tek bir HTTP yanıtının tam dolu bir çerçevesini say: 14 bayt Ethernet başlığı, 20 bayt IP, 20 bayt TCP, 4 bayt çerçeve sağlaması, telde ayrıca 8 bayt önsöz ve 12 bayt çerçeve arası boşluk. Toplam 78 bayt gider, 1.460 bayt veri taşınır. Telde harcanan 1.538 baytın %94,9’u işe yarıyor.

Şimdi aynı yığından tek bir tuş vuruşu geçir — uzak bir sunucuya bağlıyken bastığın bir harf. Veri 1 bayt. IP datagramı 41 bayta çıkıyor, çerçeve 59 bayt ediyor ve Ethernet’in 64 baytlık asgari çerçeve şartı yüzünden dolgu ile 64’e tamamlanıyor; telde 84 bayt. Bu kez işe yarayan oran %1,2.

Aynı yığın, aynı katmanlar, arada seksen kat fark. Katmanlamanın faturası sabit değil; paket küçüldükçe büyüyor. Protokollerin başlık sıkıştırmaya niçin bu kadar emek verdiğini bu iki sayı açıklıyor.

İkinci kalem tekrar. Aynı işin birden çok katta yapılması. Hata denetimini say: bağ katmanı çerçevenin tamamı için 4 baytlık bir CRC hesaplıyor, IPv4 kendi başlığı için ayrı bir sağlama tutuyor, TCP başlık ve veri için üçüncü bir sağlama üretiyor. Üç ayrı hesap, büyük ölçüde aynı baytların üstünde.

Gereksiz mi? Hayır, ve sebebi güzel. Uçtan uca bakınca yalnızca TCP’ninki zorunlu: veri ancak alıcı süreçte doğrulanırsa doğrulanmış sayılır, çünkü arada bozulma yalnızca telde değil bir yönlendiricinin belleğinde de olabilir. Alttaki ikisi zorunlu değil, erken. Bozuk bir çerçeveyi ilk atlamada atmak, onu kıtanın öbür ucuna taşıyıp orada attırmaktan ucuz. Buna rağmen IPv6 başlık sağlamasını tamamen kaldırdı — çünkü alttaki CRC yaygınlaştı ve o kalem artık kârını çıkarmıyordu. Bir katmanın işini gerçekten gereksiz kılan şey, ölçünün değişmesi oluyor.

Üçüncü kalem bilgi saklama ve en pahalısı bu. Bir katman altındakini bilmemeye söz verdiği için bazen yanlış karar veriyor. Klasik örneği TCP ile kablosuz: TCP paket kaybını tıkanıklık işareti sayar ve hızını keser. Oysa Wi-Fi’da bir çerçeve girişimden bozulmuş olabilir, yani ortada tıkanıklık yoktur. Bağ katmanı iki durumu ayırt edebilir ama TCP’ye söyleyecek bir kanalı yoktur; sözleşmede öyle bir alan yok. TCP hattı boş sanmayıp yavaşlar, ve boş hat boş kalır.

Bu üçüncü kalem, gerçek sistemlerin katman sınırını neden sürekli deldiğini de açıklıyor. Ağ kartının çerçeveleri işletim sistemi yerine kendisinin bölmesi, yönlendiricinin trafiği taşıma katmanı portlarına bakarak yollara dağıtması, tıkanıklığın kayıp yerine bir bit ile bildirilmesi — üçü de kasten yapılmış birer katman ihlali. Katmanlamayı bir yasa olarak değil, bir varsayılan olarak düşün; mühendislik de çoğu zaman o varsayılanın nerede bırakılacağına karar vermek anlamına geliyor.

Sınır kendi makinende nerede duruyor?

Katman sınırını kavramsal bir şey sanma; kendi makinende üç satırda görebilirsin.

$ ip -o link show wlp3s0
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... link/ether 00:00:5e:00:53:af
$ ip -o -4 addr show wlp3s0
2: wlp3s0    inet 192.0.2.37/24 brd 192.0.2.255 scope global wlp3s0
$ ss -tn state established
Recv-Q Send-Q      Local Address:Port      Peer Address:Port
0      0            192.0.2.37:41320       203.0.113.9:443

Aynı kartın üç ayrı adını görüyorsun. MAC adresi 48 bit tutuyor ve bu ağın dışında hiçbir yerde anlam taşımıyor. IP adresi 32 bit ve İnternet’in tamamında anlamlı. Port numarası 16 bit ve yalnızca senin makinende geçerli. İlk satırdaki mtu alanı da bir sözleşme: bağ katmanı üstündekine 1.500 bayttan fazlasını bir seferde taşımayacağını söylüyor. Üstteki katman buna uymak zorunda. IP’yi tanımlayan RFC 791’de başlık 20 bayt tutuyor, ve o yirmi bayt bu 1.500 baytın içinden çıkıyor.

Özet

Peki, ne öğrendik?

• Katman, altındakine dayanıp üstündekine söz veren bir kattır. Daha aşağısını bilmemesi bir eksik değil, tasarımın kendisidir.
• Katman sayısı modele göre değişir: OSI yedi, TCP/IP dört, ders kitaplarının çoğu beş sayar; sunum ile oturumun işini Internet yığınında uygulama üstlenir — sertifikanın ASN.1 kodlaması ve HTTP’nin Range başlığı bunun iki canlı örneğidir.
• Dikey ilişkinin adı hizmet, yatay ilişkinin adı protokoldür. İkisi bağımsız değişkendir: aynı hizmeti TCP de QUIC de verir. Sözleşmenin somut karşılıkları port numarası ve Ethernet’in tür alanıdır.
• Kapsülleme tek satırlık bir denklemdir: (N)-PDU = (N)-PCI + (N)-SDU ve bir katın ürettiği paket, bir alttakinin gözünde ham veridir.
• Katmanlamanın üç kalemlik bir faturası var: başlık yükü paket küçüldükçe %5’ten %99’a tırmanır, aynı iş birden çok katta tekrar edilir, ve bilgi saklama bazen yanlış karara yol açar.
• Kum saatinin beli tek bir protokolden ibarettir. IP’nin her cihazda bulunma zorunluluğu, üstündeki ve altındaki çeşitliliğin bedelidir.

Katmanları saydık, sınırlarını çizdik ve aralarındaki sözleşmenin adını koyduk. Geriye o sözleşmenin içeriği kalıyor: bir katman diğerine tam olarak ne veriyor?

Bölüm 18: Kapsülleme ve Başlıklar

Katmanların birbirine ne sözü verdiğini kurduk. Söylemediğim şey, komşuya tam olarak neyin uzatıldığıydı.

Uzatılan şey çıplak veri değil. Her katman kendisine geleni bir zarfa koyup uzatıyor, ve o zarfın adı başlık. Peki zarfın içinde kaç zarf var?

Dört basamak, tek yük

Uygulama katmanı elindeki mesajı taşımaya veriyor ve taşıma onu hiç açmıyor. İçindeki baytların ne anlama geldiğine bakmadan başına kendi başlığını ekliyor; ortaya bir segment çıkıyor.

Ağ katmanı aynı işi bir basamak aşağıda tekrarlıyor. Aldığı segmentin tamamını, taşımanın az önce yazdığı başlık dahil, tek parça yük sayıyor. Kendi başlığını onun da önüne ekliyor: datagram. Son basamak bağ katmanı; o da datagramı olduğu gibi alıp sarıyor ve ortaya çerçeve çıkıyor.

uygulama   [ mesaj ]
taşıma     [ TCP | mesaj ]                       ->  segment
ağ         [ IP  | TCP | mesaj ]                 ->  datagram
bağ        [ ETH | IP  | TCP | mesaj | FCS ]     ->  çerçeve

Kargo şirketine dönersek, her basamak yalnızca kendi etiketini yazar. Bir öncekinin etiketi artık paketin parçasıdır.

Aynı merdiveni baytlarla izlemek istersen:

Son satırdaki FCS dikkatini çekmiş olmalı. Çerçeve hem başlıkla hem kuyrukla sarılıyor; sondan yazan tek katman bağ katmanı.

Her başlık, onu ekleyen katmanın kendi hizmetini kurmak için ihtiyaç duyduğu alanları taşıyor. Üstteki katman o alanları hiç görmüyor. Alttaki katman görüyor ama anlamlarını bilmiyor. Kapsülleme dediğimiz şey tam olarak bu.

Başlıkta tam olarak ne var?

Seçenek taşımayan bir TCP başlığı 20 bayt. Başlık sabit değil; içinde head len adında bir alan var ve başlığın kendi uzunluğunu bildiriyor, çünkü seçeneklerle uzayabiliyor. Yük kısmı da değişken uzunlukta; uygulamanın sokete yazdığı kadar.

Seçeneksiz IPv4 başlığı da 20 bayt. İkisi birlikte her yükün üstüne 40 baytlık sabit bir zarf bindiriyor.

IPv4 başlığını tahmin etmeye gerek yok; RFC 791 alanları bit bit sayıyor. Başlık 32 bitlik satırlar hâlinde okunur ve seçeneksiz hâli tam beş satırdır:

Dört alan ilk okumada kolayca kayıyor, oysa dördü de kitabın başka bölümlerinde karşına çıkacak.

IHL başlığın uzunluğunu bayt değil, 32 bitlik kelime cinsinden verir. Seçeneksiz başlıkta değeri 5’tir: 5 × 4 = 20 bayt. Alan 4 bit olduğu için en büyük değeri 15, yani başlığın tavanı 60 bayt. Seçeneklere ayrılabilecek yer bu yüzden 40 baytla sınırlı — bu bir tasarım tercihi değil, dört bitin matematiği.

DSCP ve ECN aslında tek bir 8 bitlik alandan bölündü. Eski adı Hizmet Türü’ydü; RFC 2474 üstteki altı biti hizmet sınıfına, RFC 3168 alttaki iki biti tıkanıklık bildirimine ayırdı. İlki paket zamanlamada, ikincisi tıkanıklık denetiminde işe yarıyor. İkisi de aynı bayttan çıkıyor.

Bayraklardaki DF biti “bu paketi bölme” demek. Bölmesi gereken bir yönlendirici DF bitini görürse paketi düşürüp gönderene bir ICMP mesajıyla haber verir ve o mesajın içinde bir sonraki atlamanın MTU’sunu yazar. Gönderen böylece yol boyunca sığacak en büyük boyu adım adım öğrenir; yöntemin adı yol MTU keşfi. O ICMP mesajları bir güvenlik duvarı tarafından susturulursa yöntem sessizce çöker; sahadaki hâlini tünelleri kurarken adım adım izleyeceğiz.

Başlık sağlaması yalnızca başlığı korur, yükü değil. Sebep basit: TTL her atlamada değiştiği için sağlamanın da her yönlendiricide yeniden hesaplanması gerekiyor, ve yükü de kapsasaydı bu hesap her atlamada bütün paket üstünde yapılacaktı. IPv6 alanı tamamen kaldırarak aynı sorunu kökünden çözdü.

Protokol alanı küçük ama işi büyük: yükün hangi üst katman protokolüne ait olduğunu söylüyor, TCP mi UDP mi.

Çerçevenin alanları da sırayla belli; boyları toplandığında zarfın maliyeti çıkıyor:

Bu iki adresin nasıl kurulduğunu burada kasten boş bırakıyorum. Alanların genişliğini biliyorsun; içlerindeki değerin ne anlama geldiğini 21. bölümde dolduracağız.

Adresler, tür alanı ve FCS birlikte 18 bayt tutuyor. Önsöz (preamble) hariç azami sade çerçeve bu yüzden 1.518 bayt. Araya 4 baytlık bir 802.1Q etiketi girerse tavan 1.522 bayta çıkıyor; etiketin ilk iki baytı 0x8100 tür tanımlayıcısını taşır ve o tanımlayıcıyı bilmeyen bir istasyon çerçeveyi bilinmeyen tür sanıp atar.

Tür alanı (EtherType) 0x0800 ise içeride IP var, 0x0806 ise ARP. FCS’nin içine yazılan değer ise bir CRC-32 sağlaması; hesabın kendisi ilerideki bir bölümün işi.

Her zarf bir sonrakini nasıl gösteriyor?

Kapsüllemenin asıl inceliği zarfları sarmakta değil, açarken hangi sırayla açılacağını bilmekte. Alıcıya gelen şey bir bayt dizisi. Nerede bittiğini, içinde ne olduğunu ve sonraki başlığın hangi protokole ait olduğunu ona kimse söylemiyor — bunların hepsi zarfın kendi içinde yazılı.

Her başlığın içinde, bir sonraki başlığın kim olduğunu söyleyen bir alan var. Bu alanlar bir zincir kuruyor ve zincir, bayt dizisini adım adım çözüyor:

Zincirin bu kadar sıradan görünmesi aldatıcı. Bu üç alan, yığının tamamının değiştirilebilir olmasını sağlayan şey. Ethernet, içinde IP taşıdığını bilmiyor; yalnızca 0x0800 diye bir sayı taşıyor ve o sayının anlamını bir tabloya bırakıyor. IPv6 ortaya çıktığında Ethernet’in tek bir satırı bile değişmedi; tabloya yeni bir sayı eklendi. Katmanları gerçekten ayıran şey, başlıkta bir isim değil bir numara taşımaktır.

Zarfları açmanın adı kapsülleme çözme ve sarmanın tam tersi sırayla yürüyor. Alıcı kartı çerçeveyi alıyor, FCS’yi yeniden hesaplayıp yazandan farklı çıkarsa çerçeveyi sessizce atıyor. Sağlamsa 14 baytlık başlığı çıkarıp kalanı IP’ye uzatıyor. IP kendi başlığını doğruluyor, hedef adres kendisiyse başlığı çıkarıp protokol alanının gösterdiği yere — diyelim TCP’ye — uzatıyor. TCP checksum’ı denetliyor, hedef porta bakıp doğru sokete bırakıyor. Her kat kendi zarfını açıyor, kendi denetimini yapıyor ve bir üstteki katmanın zarfına hiç dokunmuyor.

Kapsüllemeyi tek cümleye indirmek gerekirse: her katman, bir üstündekinin verdiği her şeyi anlamsız bir yük sayar; ne olduğunu yalnızca bir sayıyla not eder ve o sayıyı okumayı karşı taraftaki eşine bırakır.

Yük hatta sığmazsa?

Bir bağlantı üzerinden gidebilecek en büyük çerçevenin veri alanına MTU deniyor. Ethernet’te 1.500 bayt. Bu bir ağ katmanı kararı değil, bağ katmanı kararı: değeri ikinci katmanda hangi protokolün çalıştığına göre değişiyor. Yol boyunca tek bir sabit değer yok.

Sayı yükseltilebilir de. Bir anahtar bugün 9.720 bayta kadar jumbo çerçeve taşıyabiliyor; aynı veriyi altı kat daha az çerçeveyle göndermek, çerçeve başına düşen 18 baytlık zarfı altı kat fazla verinin üstüne yaymak demek. Yine de bu yetenek standart dışı ve yerelde kalıyor. Sebebi yolun kendisinde. Bir yol, üstündeki en dar bağlantı kadar geniştir, ve yol üstündeki tek bir port jumbo çerçeveyi tanımıyorsa onu sessizce düşürüyor. Uçların birlikte büyütmeyi pazarlık edeceği bir mekanizma da yok; MTU her bağlantının kendi kararı. Büyük MTU bu yüzden ancak kapalı alanlarda işe yarıyor: veri merkezinin içi, depolama ağı, iki yönlendirici arasındaki tek bir hat. Oralarda iki uç da aynı yönetimin elinde.

Geriye kalanı hesaplamak kolay. 1.500 baytlık veri alanından IP başlığının 20 baytını ve TCP başlığının 20 baytını düşünce elde 1.460 bayt kalıyor. SYN paketiyle pazarlığa açılan en büyük segment boyunun tipik değeri de tam olarak bu.

Peki yük bu sınırı aşarsa? IPv4 datagramı bölüyor; işlemin adı parçalama. Her parça kendi başına tam bir IP datagramı ve kendi başlığını taşıyor.

Somut bir örnek kuralım. 2.048 baytlık bir datagramın yükü 2.028 bayt. MTU’su 1.500 olan bir bağlantıya girdiğinde ikiye ayrılıyor:

parça 1:  veri 1.480 bayt · ofset 0    · MF=1 · toplam uzunluk 1.500
parça 2:  veri   548 bayt · ofset 185  · MF=0 · toplam uzunluk   568

Parçaları birbirine bağlayan üç alan var ve üçü de IP başlığında duruyor. Kimlik, iki parçanın aynı datagramdan doğduğunu söylüyor. Bayrak alanındaki MF biti arkadan başka parça gelip gelmediğini bildiriyor. Ofset ise parçanın özgün veri alanındaki yerini veriyor, o da bayt cinsinden değil, 64 bitin yani 8 baytın katları cinsinden. 1.480’i sekize bölünce 185 çıkıyor. Son parça hariç her parçanın verisi bu yüzden sekizin katı olmak zorunda.

Bir ayrıntı daha: TCP başlığı yalnızca ilk parçada duruyor. IP bölerken yükün içine bakmıyor; ikinci parça onun için sıradan bir bayt dizisi.

Parçaları birleştiren tek yer hedef uç sistem. Bedeli şu: bir parça yol boyunca yalnızca küçülebiliyor. IPv6 bu işi sabit başlıktan çıkardı; 40 baytlık başlıkta ne parçalama var ne checksum, amaç yönlendiricide işlemeyi hızlandırmak. Gerekirse parçalama ayrı bir uzatma başlığına iniyor.

Bir terim notu da düşeyim. OSI belgelerinde bu işleme segmentation, TCP/IP belgelerinde fragmentation deniyor. İkisi aynı şeyi anlatıyor.

Zarfın bedeli ne kadar?

Tel üstünde bir yükün taşıdığı toplam zarf 58 bayt: 20 TCP, 20 IP, 18 Ethernet.

1.460 baytlık dolu bir yükle çerçeve 1.518 bayta çıkıyor ve zarfın payı %3,8 oluyor. Şimdi yükü küçült. İstek satırı ve başlıklarla kurulan sade bir HTTP isteği 480 bayt tutsun. Aynı 58 bayt ekleniyor, toplam 538 bayt, zarfın payı %10,8. Zarf hiç değişmedi. Yük küçüldükçe oransal olarak şişti.

Uç vakayı da görelim. Yüksüz bir ACK, 20 baytlık TCP başlığı ile 20 baytlık IP başlığından ibaret: 40 baytlık bir datagram. Ethernet veri alanının alt sınırı 46 bayt olduğu için aradaki fark dolgu ile kapatılıyor ve çerçeve 64 bayta çıkıyor. Telden geçen her şey zarf.

O dolgu baytları ağ katmanına kadar çıkıyor. Onları ayıklayan şey IP başlığındaki uzunluk alanı.

Kanalın ödediği fatura çerçeve boyuyla değil toplamla ölçülüyor. 1.500 baytlık veri taşıyan bir çerçevenin kanal maliyeti, önsöz ve çerçeveler arası boşluk dahil, 1.538 bayt. Yükün payı %97,5. 10 Mbit/s’lik bir hatta bu saniyede 812 çerçeve demek. Aynı hatta asgari boy çerçeveler saniyede 14.880 adet geçiyor ve yalnızca 5.475.840 bit veri taşıyor: kanalın %54,7’si.

Ek yükün bit karşılığı da sabit: 64 bit önsöz, 96 bit iki adres, 16 bit tür alanı, 32 bit FCS. 10 Mbit/s’te çerçeveler arası boşluk 9,6 µs, yani 96 bit süresi. Toplamı 304 bit süresi.

Küçük çerçevenin bir yararı da var. Bozulan bir çerçevede yeniden gönderilecek bit sayısı daha az. Çoklama ile tek bağlantıya sığdırılan istekler de aynı hesabın içinde; zarf yok olmuyor, yalnızca daha çok yükün üstüne yayılıyor.

Bütün bunları kendi makinende görebilirsin:

ip link show
sudo tcpdump -n -e -c 5 'tcp port 443'

İlk komut her arayüzün yanına mtu 1500 yazacak. İkincisi her satırın başında çerçevenin kaynak ve hedef adresini, ethertype IPv4 (0x0800) etiketini ve çerçevenin bayt cinsinden boyunu dökecek. Windows tarafında aynı değeri netsh interface ipv4 show subinterfaces komutu veriyor.

Özet

Peki, ne öğrendik?

• Kapsülleme dört basamaklı bir merdiven: mesaj segmente, segment datagrama, datagram çerçeveye giriyor ve her basamak bir öncekinin tamamını yük sayıyor.
• Her başlık kendi katmanının işi için var: üstteki alanları görmüyor, alttaki anlamlarını bilmiyor, ve sondan kuyruk ekleyen tek katman bağ katmanı.
• IPv4 başlığı beş satır, on üç alandır: IHL başlığın tavanını 60 bayta kilitler, DSCP ile ECN aynı bayttan bölünmüştür, DF biti yol MTU keşfini başlatır ve checksum yalnızca başlığı korur.
• Bağlayıcı alanlar zinciri kuruyor: çerçevedeki tür alanı, IP’deki Protokol ve taşımadaki port numarası yükü doğru üst katmana yönlendiriyor.
• MTU aşılırsa datagram bölünüyor: Kimlik, Bayrak ve Ofset parçaları birbirine bağlıyor, birleştirmeyi ise yalnızca hedef uç yapıyor.

Zarfları saydık, alanlarını adlandırdık, bedelini hesapladık. Ama buraya kadar hepsi anlatı olarak kaldı. Zarflar gerçekten orada mı, bunu kendi gözünle görebilir misin?

Bölüm 19: Paket Yakalama ve Çözümleme

Diyelim ki bir yakalama aracı kurdun ve açılış ekranındaki kart listesinden kendi arayüzünü seçtin. Satırlar akmaya başlıyor; her satır bir çerçeve. Kapsülleme merdivenini kurarken tek tek saydığın başlıklar şimdi o satırların içinde duruyor.

Anlatılan her zarfı yakalamak ve tek tek açıp görmek mümkün. Peki o satırları ekrana taşıyan şey tam olarak ne?

Trafiği kim kopyalıyor?

Ekranda gördüğün program yakalamayı kendisi yapmıyor. Altta, işletim sisteminin içinde duran bir paket yakalama kütüphanesi var; üstünde de senin tıkladığın çözümleyici arayüz. Arayüzün işi baytları adlandırmak.

Alt katman, kartın gönderdiği ve aldığı bütün Ethernet çerçevelerinin bir kopyasını alıyor. Kopya kelimesi burada teknik anlamıyla duruyor. Asıl trafik durmuyor, gecikmiyor, değişmiyor.

Bunun karşılığında araç yükseltilmiş yetki istiyor. Sebep tek: program doğrudan ağ kartına erişmek zorunda.

İlan edilen asgari gereksinimler şaşırtıcı derecede mütevazı: 400 MHz işlemci ve 60 MB boş disk. Üçüncü madde donanımla ilgili — karışık modu destekleyen bir ağ kartı. Asıl yük çözümlemede değil, kartın kopyaladığı trafikte.

Araç üç iş yapıyor. Trafiği anlık izliyor, izlediğini dosyaya kaydediyor, kaydı sonradan yeniden açtırıyor. Aynı ekran bu yüzden iki kaynaktan doluyor: canlı bir ağ kartından ya da daha önce kaydedilmiş bir pcap dosyasından.

Kart listesinde ne göreceğin işletim sistemine bağlı. Linux’ta eth0 ve wlan0, macOS’ta en0 ile lo0, Windows’ta üreticinin verdiği uzun ad. Fiziksel kartların yanında sanal geri döngü arayüzü de listede duruyor; makinenin kendi kendine konuşmasını oradan yakalıyorsun.

Wi-Fi kartıyla yakalayacaksan bir adım daha var: kartı izleme kipine almak. Kablolu kartta bu adım yok.

Neden komşunun paketlerini göremiyorsun?

Tehdit modelinin ilk maddesi karışık mod ve dinlemeydi; ekranda akan liste o maddenin somut hâli.

Ama dinlemeyi mümkün kılan şey ne araç ne de o mod. Ortamın yayın ortamı olması: paylaşılan Ethernet ve kablosuz bağlantı. Herkesin duyduğu bir yerde kartı susturmayı bırakmak yetiyor.

Anahtarlı bir yerel ağda hesap değişiyor. 192.0.2.10 numaralı makineden 192.0.2.11’e giden bir çerçeve, kartın karışık modda olsa bile 192.0.2.12’ye ulaşmıyor. Anahtar onu yalnızca hedefin bağlı olduğu porta gönderiyor.

İşin ters yüzü de var. Anahtarın kendi portları karışık modda çalışıyor; adres öğrenmesinin yolu tam olarak bu. Öğrendiklerini tuttuğu tablo ise sınırlı; tablo taşırılırsa anahtar çerçeveleri yeniden yayına veriyor ve dinleme geri geliyor.

Ekranda gördüğün şey bu yüzden ağın tamamı değil. Kartının duyabildiği kadarı.

Beş bölme, tek paket

Pencere beş bölmeye ayrılıyor: filtre satırı, paket listesi, seçilen paketin detay ağacı, ham bayt dökümü ve durum çubuğu. Listeden bir satır seçtiğin anda alttaki iki bölme dolmaya başlıyor.

Detay ağacı seçilen paketi katman katman açıyor. Katmanlı mimarideki sıra burada tıklanabilir bir ağaca dönüşüyor. Ağaçta bir alanı seçtiğinde aynı alan ham bayt dökümünde de işaretleniyor; iki bölme aynı paketin iki ayrı yazımı.

Aralıklar sabit. 534 baytlık bir çerçevede ilk 14 bayt Ethernet başlığı, sonraki 20 bayt IPv4, sonraki 20 bayt TCP. İlk 54 bayt zarf, gerisi uygulamanın yükü.

Ağacın dalları ile bayt aralıkları birebir örtüşüyor:

Bir dalı açtığın anda sağdaki ham dökümde o aralık işaretleniyor. Zarf elli dördüncü baytta bitiyor, gerisi yük. TLS varsa ağaç yalnızca kaydın türünü ve uzunluğunu veriyor; içerik şifreli olduğu için açılmıyor.

Çözümleyicinin bir daldan diğerine geçme yolu, başlıkların içindeki tür alanları. Ethernet tür alanındaki onaltılık 0806 değeri ARP demek. IP başlığındaki protokol alanında 1 ICMP, 6 TCP, 17 UDP demek. Ağaç bu sayılara bakarak dallanıyor.

Durum çubuğu üç sayı taşıyor: yakalanan toplam paket, o an gösterilen paket sayısı ve etkin profil adı. İkisi arasındaki fark, filtrenin ne kadarını elediğini söylüyor.

Adres çözümleme açıldığında listedeki MAC adresinin ilk 24 biti çözülüyor ve kartı üreten firmanın adı yanına yazılıyor. Bu bilgi ağa sorulmuyor. Program kendi içinde tuttuğu manuf dosyasına bakıyor. Adresin geri kalanının neyi adlandırdığı 21. bölümün işi.

Son bir ayrıntı: kayıt ekranında azami çerçeve 1.514 bayt görünüyor, oysa tel üstünde 1.518 bayt. Aradaki 4 bayt FCS alanı; kart onu doğruladıktan sonra atıyor ve kopyaya hiç koymuyor.

Kayda soru sormak

Filtre kutusu bir tane değil, iki tane. Açılış ekranındakine yazdığın filtre, çerçeveler daha diske yazılmadan alt katmanda uygulanıyor; elediği paket kayda hiç girmiyor. Yakalama sürerken kullandığın kutu ise gösterim filtresi ve elde duran kaydı süzüyor.

İkisinin dili de ayrı. Yakalama filtresi port numarası yazıyor: port 67 or port 68. Gösterim filtresi protokolün alan yolunu yazıyor: bootp.option.dhcp == 3. Aynı DHCP trafiğini seçen iki cümle, iki ayrı sözlükten.

İki dilin ayrı olmasının sebebi zevk değil, nerede çalıştıkları. Yazdığın yakalama filtresi bir metin olarak çekirdeğe gitmiyor; önce küçük bir sanal makinenin komutlarına derleniyor. O sanal makinenin adı BPF ve programı doğrudan çekirdeğin içinde, paket kullanıcı alanına kopyalanmadan önce koşuyor. Her çerçeve için birkaç düzine komut çalışıyor ve sonuç tek bir karar oluyor: kopyala ya da bırak.

Kazancın nereden geldiği buradan çıkıyor. Filtre kullanıcı alanında olsaydı, elenecek her çerçeve önce kopyalanacak, sonra atılacaktı — yani en pahalı iş, atılacak paket için de yapılacaktı. Çekirdekte elemek o kopyayı hiç yaptırmıyor.

Bedeli de dilin darlığı. BPF programı sabit bir yerden başlayıp sabit adımlarla ilerleyen bir yapıya bakabiliyor; “şu protokolün şu alanı” gibi adlandırılmış bir sözlüğü yok, çünkü çekirdek DHCP’nin ne olduğunu bilmiyor. Gösterim filtresi ise kayıt zaten diskteyken, bütün protokol ayrıştırıcıları elinin altındayken çalışıyor. Biri hızlı ve kaba, öteki yavaş ve ayrıntılı.

Aynı sanal makineyi başka yerlerde de göreceksin. tcpdump’ın filtre satırı bunu kullanıyor; komut satırından yakalama yaparken yazacağın ifade de aynı derleyiciden geçiyor.

Alan yolları sayıları da adlandırıyor. DHCP mesaj türünde 1 DISCOVER, 2 OFFER, 3 REQUEST, 4 ACK demek; ARP’ta işlem kodu 1 ise istek, 2 ise cevap anlamına geliyor. Gösterim filtreleri karşılaştırma ve mantık işleçleriyle birleşiyor: ==, !=, >, < ile and, or, xor, not. Her işlecin hem sözcük hem simge yazımı var.

Soket four-tuple’ında tanıştığın port numarası, filtre dilinde üç ayrı alana ayrılıyor. tcp.port == 80 iki yönü birden, tcp.srcport kaynağı, tcp.dstport == 443 yalnızca hedefi seçiyor. tcp.flags.syn == 1 ise kaydın içindeki bütün bağlantı kurulumlarını listeliyor.

Bunları ezberlemene gerek yok. Detay ağacındaki bir alana sağ tıklayıp Apply as Filter demek o alanı filtre satırına yazıyor. contains işleci de belirli bir protokolün gövdesinde metin arıyor.

Akış takibi aynı bağlantıya ait TCP paketlerini birleştirip tek bir konuşma olarak gösteriyor. Bayraklar tek tek okunuyor: SYN başlatır, ACK onaylar, RST ani sonlandırır, FIN düzgün kapatır. Yüksüz bir ACK satırında uygulama verisi len=0 yazıyor; o çerçeve yalnızca başlıktan ibaret. Kapanış sırasında uçlardaki durumlar CLOSE_WAIT, TIME_WAIT ve FIN_WAIT adlarını alıyor.

Konuşmanın içeriğine gelince, orada bir sınır var. TLS yoksa sokete yazılan parola İnternet’i düz metin olarak geçiyor ve ekranda da düz metin okunuyor. TLS varsa yakalayıcı yalnızca kaydın türünü ve uzunluğunu görüyor. El sıkışmada kurulan oturum anahtarı elinde olmadan içerik açılmıyor; o anahtarı araca vermeyi 60. bölüme bırakıyorum.

İstatistik ekranları kaydın bütününü sayıyor. Protokol hiyerarşisi hangi protokolden kaç paket olduğunu, IPv4 istatistiği her adresin kaç kez geçtiğini, HTTP sayacı metotları ve yanıt kodlarını veriyor; örnek bir kayıtta 165 GET isteği sayılmış. Kaydın tamamı yerine yalnızca seçtiğin paketleri ayrı bir dosyaya da yazabilirsin: numara aralığı, virgülle ayrılmış numaralar ya da işaretlediklerin.

Kendi kaydını üç komutla üretip sorgulayabilirsin:

sudo tcpdump -i eth0 -c 200 -w birinci.pcap
capinfos birinci.pcap
mergecap -w butun.pcap birinci.pcap ikinci.pcap

İlk komut aynı yakalama katmanını kullanıyor ve iki yüz çerçeveyi dosyaya yazıyor. capinfos dosyanın özetini döküyor: paket sayısı, ilk ve son paketin zamanı, yakalamanın süresi. mergecap iki kaydı tek dosyada birleştiriyor ve birleşmiş dosyanın hangi iki dosyadan geldiğini bile söylüyor.

Özet

Peki, ne öğrendik?

• Yakalama işini arayüz yapmıyor: trafiği kopyalayan katman işletim sisteminin içinde duruyor, kopya asıl akışı geciktirmiyor ve o erişim yükseltilmiş yetki istiyor.
• Karışık mod tek başına yetmiyor: dinlemeyi mümkün kılan şey ortamın yayın olması, anahtarlı bir ağda çerçeve komşunun portuna zaten hiç gitmiyor.
• Ağaç ile bayt dökümü aynı paketi gösteriyor: bir alanı seçmek onun bayt aralığını işaretliyor, ilk elli dört bayt zarf, gerisi yük.
• İki filtre iki ayrı dil konuşuyor: biri yakalama başlarken port düzeyinde eliyor, diğeri elde duran kaydı alan yollarıyla süzüyor.

Ekrandaki her satırı açtın, baytlarını saydın, hangi aralığın kime ait olduğunu gördün. Ama bu kopyayı sana veren şey hâlâ kutunun içinde duruyor: çerçeveyi tele koyacak olan tam olarak ne?

Bölüm 20: Ağ Arayüz Kartı

Yakalama arayüzünde her satırı bayt bayt sayıp zarfları tek tek gördün. Çerçeveyi tele koyacak şeyi ise henüz adlandırmadım.

O şey bir program değil. Kablonun ucundaki ağ kartı, kendi işlemcisiyle çalışan ayrı bir bilgisayar. Peki bu kartın sınırı tam olarak nerede başlıyor?

Kart tam olarak nerede duruyor?

Ağ kartı, bilgisayarı ağa fiziksel olarak bağlayan parça. Türkçe adını ağ arayüz kartı olarak göreceksin; kimi kaynakta ağ adaptörü ya da ağ arayüz denetleyicisi diye de geçiyor. Kısaltması NIC.

Kart makinenin sistem veriyoluna takılıyor ve diğer bileşenlerin gözünde sıradan bir giriş/çıkış aygıtından farkı olmuyor; klasik yuvası da PCI. Ethernet’in ilk günlerinde üstü yongalarla kaplı kocaman bir devre kartı olarak duruyordu. Bugün aynı işi tek bir yongada, ya da daha büyük bir sistem yonganın içindeki bir bölümde bitiriyorlar. Anakarta tümleşiği de var, USB’den takılanı da. Kart yine de tek bir parçadan ibaret değil; donanım, yazılım ve firmware birlikte çalışıyor.

Asıl ayrımı kartın hangi katmanları taşıdığında bulacaksın. Kart ikisini birden gerçekliyor, bağ katmanını ve fiziksel katmanı; üstündeki her şey yazılımda kalıyor. Sınırın çipte olduğunu söylemiştim, ama orada adını vermediğim bir şey vardı: bu iki katman arasındaki iç arayüz.

Soket four-tuple’ını kurarken çekirdeğin altında ne olduğunu kapalı kutu bırakmıştım. Kutuyu şimdi açıyorum. Soket katmanını kullanıcı alanı ile çekirdek alanının tam sınırında buluyorsun. Altında TCP ve UDP duruyor, onun altında IP, en altta da fiziksel ağa bakan sürücü.

Çerçeveyi kim kuruyor?

Kartın kalbinde, MAC protokolünü de taşıyan tek bir özel amaçlı denetleyici yonga var. Çerçeveleme, hatta erişim ve hata sezme bu yonganın işi. Üçünü de donanımda yapıyor.

Yonganın içi de ikiye bölünmüş durumda. MAC bölümü çerçeveyle ilgileniyor, fiziksel katman bölümü sinyalle. İşte o iç arayüzün adı hıza göre değişiyor: 100 Mbit/s’te MII, gigabitte GMII, on gigabitte XGMII. Fiziksel katman tarafı kendi içinde ayrıca katmanlı. Orada bir kodlama alt katmanı ile ortama bağlanan ve ortama bağımlı alt katmanlar duruyor.

Çerçeveleme, datagramın önüne başlık arkasına kuyruk eklemek demek. Kapsülleme merdivenini çıkarken bu basamağı dışarıdan, yani başlık ve kuyruk eklenmiş hâliyle görmüştük. Gönderme tarafında denetleyici, üst katmanların ana bellekte hazırlayıp bıraktığı datagramı oradan alıyor ve çerçeveyi kendisi kuruyor.

Ama çerçevelemenin asıl zorluğu ekleme değil, ayırma. Fiziksel katmanın alıcıya verdiği şey kesintisiz bir bit dizisi; içinde nokta, boşluk ya da satır sonu yok. Alıcı bu akışta bir çerçevenin nerede başlayıp nerede bittiğini bilmek zorunda, yoksa elindeki baytların hangisinin adres hangisinin veri olduğunu söyleyemez. Sorunun adı çerçeve sınırlandırma ve tarih boyunca dört ayrı çözümü denendi.

Bayt sayısı. Çerçevenin başına uzunluğu yazarsın, alıcı o kadar bayt sayar. Zarif ama kırılgan: o sayıyı taşıyan bayt bozulursa alıcı sınırı kaçırır ve bir daha asla bulamaz — sonraki bütün çerçeveler kayar. Tek bir bit hatası kalıcı bir hizasızlık üretiyor.

Bayrak baytı ve bayt doldurma. Çerçevenin iki ucuna özel bir bayrak baytı konur. PPP’de bu değer 0x7E. Peki veri içinde aynı bayt geçerse? Gönderen onun önüne bir kaçış baytı (0x7D) ekler ve baytı değiştirir; alıcı kaçışı görünce sonraki baytı ham veri sayar. Kaçış baytının kendisi de kaçırılır. Bedeli değişken: rastgele veride yaklaşık %1 şişme, ama en kötü durumda çerçeve iki katına çıkabilir.

Bayrak dizisi ve bit doldurma. Aynı fikrin bit ölçeğindeki hâli. HDLC’de bayrak 01111110, yani altı ardışık bir. Gönderen veride beş ardışık bir gördüğü anda araya zorla bir sıfır sokar; böylece veri içinde altı ardışık bir asla oluşamaz. Alıcı beş birden sonra gelen sıfırı sessizce atar.

veri            0 1 1 1 1 1 1 0 1 1 1 1 1 1 1 0
telde (doldurulmuş) 0 1 1 1 1 1 [0] 1 0 1 1 1 1 1 [0] 1 1 0

Köşeli parantezler gönderenin eklediği, alıcının atacağı bitler. Şişme en kötü durumda %20’de kalıyor — bit doldurmanın bayt doldurmadan üstün olduğu yer burası.

Fiziksel katman ihlali. Dördüncüsü en zarifi ve Ethernet’in kullandığı yol. Hat kodlaması bazı sinyal desenlerini veri için kullanmıyorsa, o kullanılmayan desen sınır işareti olur. Veri içinde geçmesi fiziksel olarak imkânsız olduğu için doldurmaya hiç gerek kalmıyor. Hat kodlamasına indiğimizde göreceksin: 4B/5B, 32 desenden yalnızca 16’sını veriye ayırıyor ve artan desenler tam da bunun için duruyor.

Ethernet aslında üç yöntemi birden kullanıyor. önsöz ve çerçeve başlangıç sınırlayıcısı başlangıcı, uzunluk alanı ile taşıyıcının kesilmesi sonu, çerçeveler arası boşluk da iki çerçevenin birbirine karışmamasını sağlıyor.

Hata sezme bitlerini de gönderen taraftaki denetleyici koyuyor. Alan taraftaki denetleyici aynı bitleri denetliyor. İki uçtaki yonga, işletim sistemine hiç sormadan anlaşıyor.

Yazılımın devreye girdiği tek nokta alış tarafında. Kart bir çerçeve aldığında işlemciyi kesiyor. Kesmeye yanıt veren sürücü yazılımı hata durumlarını ele alıyor ve datagramı ağ katmanına yukarı veriyor. Donanımın bittiği çizgi tam orası.

Çerçevenin üstündeki adres de kartın kendi adresi, ve kart bu kimliği üstündeki ROM’da taşıyor. Birinci katman aygıtı sayılan bir parçanın ikinci katman aygıtı olarak da anılması bu yüzden. Bu adresin nasıl kurulduğunu, yani MAC adresinin biçimini 21. bölümde tek tek açacağız.

Çekirdek işi karta nasıl devrediyor?

Paket akışı arayüze girip çıkarken doğrudan bellek erişimiyle yönetiliyor; kısaltması DMA. Kart ana belleği kendisi okuyup yazıyor. Kopyalama işini CPU yapmıyor.

İkisinin buluştuğu yer bir halka tampon. Halka, sabit sayıda tanımlayıcıdan oluşan bir dizi. Her tanımlayıcı bellekteki bir paket tamponunun adresini ve o tamponun kime ait olduğunu taşıyor. Çekirdek sıradaki boş tanımlayıcıyı dolduruyor ve sahipliği karta bırakıyor. Kart sırası gelince tanımlayıcıyı okuyor, veriyi DMA ile çekiyor, işi bitince sahipliği geri veriyor.

Tanımlayıcının kart ile çekirdek arasında nasıl el değiştirdiğini izleyelim:

Halkanın derinliği kartlarda tipik olarak 256 ile 4.096 tanımlayıcı arasında. En küçük çerçevelerle tam yükte, saniyede bir gigabit taşıyan bir hatta 256 girişli alma halkası 172 µs’de doluyor. Derinlik bellek gibi görünüyor ama çekirdeğe tanınan süreyi ölçüyor.

Süre yetmezse ne oluyor? Kuyruğa alınmış paketleri tutacak bellek dolduğunda gelen paket düşüyor. Kayıp tam olarak orada oluyor, kablonun ortasında bir yerde değil.

Halkanın öbür ucundaki kesme de bedava değil. Saniyede bir gigabit taşıyan bir hatta en küçük çerçeve 64 bayt, ama telde 84 bayt yer kaplıyor. Yanına 7 baytlık önsöz, 1 baytlık ayraç ve 12 baytlık çerçeveler arası boşluk ekleniyor. Toplamı 672 bit eder. Tam yükte saniyede 1.488.095 çerçeve geçiyor. Her çerçeve için bir kesme, saniyede 1,49 milyon kesme demek. Tek bir çekirdek için ulaşılamaz bir sayı.

Kartlar bu yüzden kesme birleştirme yapıyor: sürücü ya da kart, işlemciyi kesmeden önce birkaç çerçeve biriktiriyor. 32 çerçevede bir kesme verildiğinde aynı yük saniyede 46.503 kesmeye iniyor. Çerçeveler yine aynı halkada birikiyor. Değişen tek şey, çekirdeğin kaç kez rahatsız edildiği.

Bedeli de aynı bölme işleminden çıkıyor. 32 çerçevede bir kesme veren kart, gruptaki ilk çerçeveyi en kötü durumda 31 çerçeve süresi bekletiyor. Boş bir hatta durum daha kötü: grup hiç dolmazsa kesme de hiç gelmiyor. Yalnızca çerçeve sayan bir politika bu yüzden tek başına kullanılamıyor.

Kartlar ikinci bir politika daha taşıyor. İlk çerçeve halkaya düştüğü anda bir zamanlayıcı başlıyor ve süre dolunca kesme veriliyor, grup dolsun dolmasın. ethtool -c eth0 çıktısında yan yana duran iki ayar tam olarak bunlar: biri çerçeve sayıyor, biri mikrosaniye. 200 µs’ye ayarlanmış bir zamanlayıcı, boş bir hatta gelen tek çerçeveye 0,2 ms’ye kadar gecikme ekliyor; aynı ayar tam yükte gecikmeyi düşürüyor, çünkü işlemci kesme işlemekten kurtulunca kuyruklar daha çabuk boşalıyor. Ayarın işareti yüke bağlı.

Darboğaz gerçekten kartta mı?

Her Ethernet arayüz yongası, desteklediği ortamın tam çerçeve hızında gönderip alabiliyor. Darboğaz yongada değil.

Toplam başarımı dört şey belirliyor. İşlemci gücü, işlemci ile kart arasındaki iç sinyal yolunun hızı, kart üstündeki tampon bellek miktarı ve sürücünün kalitesi. Dördü de Ethernet standardının dışında kalıyor. Makine yetişemezse çerçeveler arayüzde düşürülüyor ya da yok sayılıyor, ve standart bunu kusur saymıyor. Sebebi açık. Standart bir bilgisayarın ne kadar hızlı olacağını tanımlamaya çalışmıyor.

Sayılar farkı gösteriyor. Az önce saydığımız 1.488.095 çerçevelik tavan en küçük çerçevelere aitti. Aynı hatta en büyük çerçevelerle tavan saniyede 81.274 çerçeveye iniyor. Çerçeve sayısı on sekiz kat azalıyor, taşınan veri artıyor.

Bir çerçevenin telde ne kadar durduğu tek bir bölmeden çıkıyor. L bitlik bir paketi R bit/s hızındaki bir hatta itmek L/R saniye sürüyor. 1.518 baytlık bir çerçeve için bu, gigabitlik hatta 12,1 µs. On kat hızlı bir hatta aynı iş 1,21 µs’ye iniyor. Gecikme bileşenlerini ayırırken buna iletim gecikmesi demiştik.

Rakamların ucu bugün bile açık. On gigabitlik bir kanalın tam çerçeve hızına piyasadaki masaüstü ve sunucuların bir kısmı hâlâ yetişemiyor.

Bu yüzden bazı üreticiler üst katman protokol işlemesini kartın üstünde yapan arayüzler satıyor. Boşaltma motorlarının çıkış noktası bu. Somut bir örnek. Çekirdek karta 65.535 baytlık tek bir tampon veriyor, kart onu 1.460 baytlık parçalara bölüyor. 44 tam parça ve 1.295 baytlık bir artık çıkıyor, toplam 45 parça. Yazılımın 45 kez yapacağı iş bir kez yapılıyor.

Kendi makinende bakmak istersen Linux’ta iki program var: mii-tool ve ethtool.

ethtool eth0
ethtool -g eth0
ethtool -c eth0
ethtool -k eth0
ip -s link show eth0

İlk komut arayüzün hızını ve çalıştığı kipi yazıyor. İkincisi halka tamponunun azami ve o anki derinliğini, üçüncüsü kesme birleştirme ayarlarını, dördüncüsü açık olan boşaltma özelliklerini döküyor. Sonuncudaki düşen çerçeve sayacı sıfırdan büyükse makinen kartın hızına yetişemiyor demektir.

İlk satırdaki kip de kendi başına bir başarım ayarı. Bir hattın verinin hangi yönde ve ne zaman akabileceğine dair üç seçeneği var, ve üçünün de adı var:

Ortadaki kip ile alttaki arasındaki fark yalnızca hız değil. Yarım çift yönlü bir hatta iki taraf aynı anda konuşabildiği için çarpışma diye bir olasılık vardır ve o olasılığı yönetecek bir kurala ihtiyaç duyulur. Tam çift yönlü hatta böyle bir kural gerekmez, çünkü gönderme ve alma ayrı yollarda yürür.

Tam çift yönlü çalışmanın iki koşulu var: ortamın aynı anda işleyen ayrı gönderme ve alma yolları olması, ve hatta tam olarak iki istasyon bulunması. Koşullar sağlanınca çarpışma diye bir olasılık kalmıyor. Kip 1997’de standartlaştı, ve bugün bağlantıların neredeyse tamamı böyle çalışıyor. Hızı ve kipi seçen şey Auto-Negotiation, yani iki cihazın da desteklediği en yükseğini kendiliğinden bulan protokol.

Bir arıza tam burada saklanıyor. Hattın yalnızca bir ucunda Auto-Negotiation açıksa, uzlaşmaya çalışan taraf yarım çift yönlü kipe düşüyor. Diğer uç elle tam çift yönlüye sabitlenmişse kip uyuşmazlığı kaçınılmaz oluyor. Bu arıza sıradan web trafiğinde hiç görünmüyor. Bandı gerçekten dolduran bir başarım testinde ortaya çıkıyor.

Özet

Peki, ne öğrendik?

• Ağ kartı iki katmanı birden gerçekliyor: bağ katmanı ile fiziksel katman kartın üstünde, geri kalan her şey yazılımda; yığının donanımla buluştuğu çizgi orası.
• Çerçeveyi denetleyici yonga kuruyor: çerçeveleme, hatta erişim ve hata sezme donanımda bitiyor ve ana işlemciye hiç uğramıyor.
• Halka tampon ile DMA işi devrediyor: çekirdek tanımlayıcıyı dolduruyor, kart veriyi bellekten kendisi çekiyor, ve halkanın derinliği aslında çekirdeğe tanınan süredir.
• Kesme birleştirme çekirdeği kurtarıyor: çerçeve başına bir kesme tam yükte ulaşılamaz bir sayıya çıktığı için kart birkaç çerçeveyi biriktirip tek kesme veriyor.

Kart hazır. Halkayı okuyor, çerçeveyi kuruyor, hatayı donanımda seziyor. Ama çerçevenin üstünde iki alan hâlâ boş duruyor. Kart oraya kimin adını yazacak?

Bölüm 21: Fiziksel Adresleme

Çerçeve kartın halka tamponunda hazır bekliyor. Tamponu da kartın kendi işlemcisini de gezdin; üstüne yazılacak iki adı ise boş bıraktım.

O ad fabrikada verilmiş, kartın belleğinde duruyor ve bu ağın dışında hiçbir anlamı yok. Fabrikanın verdiği bir ad dünyada nasıl tek kalıyor?

Bir adı dünyada tek yapan ne?

Ethernet arayüzünün adı 48 bit. Onaltılık yazımda bu 12 haneye düşüyor, çünkü her onaltılık hane tam 4 bit taşıyor. Haneler ikişer gruplanınca 6 sekizli çıkıyor, ve adresi kısa çizgilerle ayrılmış görmenin sebebi bu. Sayının adı MAC adresi; literatürde fiziksel adres ya da NIC adresi diye de anılıyor, ama bu kitapta tek biçimde kalıyor.

Adın MAC olmasının sebebi Ethernet’in ortam erişim denetimi sistemi. O sistem yalnızca kimin ne zaman konuşacağını ayarlamakla kalmıyor, çerçevenin kendisini ve adreslemesini de kapsıyor.

48 bitlik uzay 281.474.976.710.656 adres tutuyor. Bu kadar geniş bir uzayda iki üreticinin aynı sayıyı vermemesi tesadüf sayılamaz. Uzayın dağıtımını IEEE yönetiyor; kart üretecek şirket oradan bir blok satın alıyor ve ödediği ücret sembolik kalıyor. Tekliği sağlayan şey o satın alma.

Dilimin adı kurumsal tekil tanımlayıcı; Türkçe kaynaklarda Organizasyonel Tek Kimlik, kısaltmasıyla OUI. IEEE her üreticiye 24 bitlik bir OUI veriyor. Üretici adresin ilk 24 bitine kendi OUI’sini koyuyor, kalan 24 biti kendi üretim sayacıyla dolduruyor. Tek dilim 16.777.216 adres taşıyor.

Bugün dilim tek boyda satılmıyor. On altı milyon adres, yılda birkaç yüz cihaz üreten bir şirket için akıl almaz bir israftı; IEEE bu yüzden üç beden tanımladı:

Bunun pratik bir sonucu var ve arıza ararken tökezletiyor: ilk üç sekizli artık tek başına üreticiyi vermeyebilir. MA-S bloğunda ilk 36 bit, yani dört buçuk sekizli IEEE’ye ait; aynı ilk üç sekizliyi 256 ayrı şirket paylaşıyor olabilir. Adresten üretici çözen araçlar bu yüzden tam eşleşme değil, en uzun önek eşleşmesi yapıyor — yönlendirme tablosunda karşına çıkacak mantığın aynısı, başka bir uzayda.

Yine de çoğu durumda ilk üç sekizliye bakarak arayüz yongasının üreticisini bulmak mümkün. Arıza ararken işe yarıyor: elindeki adresin hangi karta ait olduğunu bilmek, o kartı binada aramaktan kolay.

Fabrikanın verdiği adın ikinci yararı, ağ yöneticisinin adres dağıtma ve yönetme işini tamamen ortadan kaldırması. İş üretim hattında bitiyor.

Neden kartın kendi adı var?

Arayüz sözleşmesi her katmana kendi adlandırma düzenini bırakıyor, ve üç katman üç ayrı ad kullanıyor. Uygulama katmanında makinenin adı, ağ katmanında IP adresi, bağ katmanında MAC adresi var. Adın sayıya nasıl çevrildiğini kök sunuculardan yetkili sunucuya kadar adım adım takip etmiştik. Oradaki ad insan içindi.

MAC adresi düz bir ad: içinde ağ kısmı, makine kısmı gibi bir bölümlenme yok. Zaten işi de dar; çerçeveyi bir arayüzden, ona fiziksel olarak bağlı başka bir arayüze ulaştırmaktan ibaret. Kart nereye giderse gitsin adresi değişmiyor. 802.11 arayüzü olan bir telefon hangi ağa girerse girsin aynı adı taşıyor. Ad kartla birlikte yolculuk ediyor.

IP adresi ise hiyerarşik. Ağ kısmı ve makine kısmı var, ve makine başka bir alt ağa taşınınca adresin değişmesi gerekiyor.

Kartlara MAC yerine doğrudan IP verilseydi ne olurdu? Başka ağ katmanı protokollerini desteklemek zorlaşırdı; MAC bilerek tarafsız bırakıldı. Kart ağ katmanı adresini tutsaydı, o adresin kart belleğinde saklanması gerekirdi. Her taşınmada ve her açılışta yeniden yapılandırılırdı.

Kartlarda hiç adres olmaması ise başka bir bedel getirirdi. Yerel ağ geniş yayın ortamı, yani ortamdaki veriyi herkes alıyor. Adres olmasaydı makine yerel ağdaki her çerçeve için kesmeye uğrardı. Adres, işletim sistemini rahatsız etmemek için var.

Kart hangi çerçeveyi açar?

Kapsülleme merdivenini çıkarken bu iki alanın genişliğini vermiş, içini kasten boş bırakmıştım. Çerçevede hedef adres önce, kaynak adres sonra geliyor ve ikisi de 6 bayt tutuyor. Sıra keyfi değil ve kartın işini doğrudan belirliyor.

Ethernet arayüzü kablodaki her çerçeveyi en azından hedef adres alanına kadar okumak zorunda. Adres tutmuyorsa geri kalanını okumadan bırakabiliyor. Hedef adres kendisininkiyle eşleşiyorsa ya da yayın adresiyse yükü ağ katmanına çıkarıyor. Eşleşme yoksa çerçeveyi atıyor ve datagramı yukarı hiç vermiyor.

Bu filtre kapatılabiliyor. Yakalamayı karışık modda yaparken kart eşleşmeyen çerçeveleri de yukarı veriyordu; ekranda gördüğün trafik o yüzden kendi adresinle sınırlı kalmıyordu.

Adres alanlarından önce önsöz duruyor: 8 baytlık bir alan. İşi alıcı ile göndericinin saat hızlarını eşitlemek. IEEE 802.3 bu alanı ikiye ayırıyor: ilk 7 bayt önsöz, son 1 bayt çerçeve başlangıç sınırlayıcısı. Desen 7 bayt boyunca 10101010, ardından bir bayt 10101011 geliyor. Sondaki iki 1 biti adres alanının başladığını işaretliyor.

Kaynak adres alanı çerçeveyi gönderen cihazın MAC adresini taşıyor. Bu alan her zaman tek bir arayüzü gösteren adres olmak zorunda, oraya yayın adresi yazılamıyor. Ethernet MAC protokolü kaynak adresi hiçbir şekilde yorumlamıyor. Alan üst katman yazılımı, arıza takibi ve anahtarlar için duruyor. Anahtar, kaynak adresleri kendi portlarıyla eşleyen tabloyu bu alandan kuruyor; anahtarın her portunun da fabrikada atanmış kendi adresi var.

Adreslerden sonra gelen tür alanı içerideki üst katman protokolünü bildiriyor. Çerçevenin sonundaki CRC ise bozulmayı sezmek için duruyor.

Kırk sekiz bitin nasıl bölündüğünü tek tek açalım:

İkinci hane ne söylüyor?

Hedef adresin tele ilk giden biti adresin kime gittiğini söylüyor. Sıfırsa tek bir arayüzün MAC adresi, birse bir gruba gönderim. Fabrikada atanan adresin teknik adı bu yüzden tekli yayın adresi. IEEE 802.3 ikinci bite ayrı bir anlam yüklüyor. Sıfırsa adres küresel yönetiliyor, yani üreticiden gelmiş. Birse yerel olarak yönetiliyor.

Bu iki bit adresin neresinde görünüyor? Sekizliler soldan sağa gönderiliyor ama bir sekizlinin içindeki bitler en anlamsızdan en anlamlıya doğru gidiyor. Sıra tersine dönüyor. Bayrak bitleri bu yüzden adresin ikinci onaltılık hanesinde okunuyor.

ilk sekizli  :  b7 b6 b5 b4 b3 b2 b1 b0
tele çıkış   :  b0 b1 b2 b3 b4 b5 b6 b7
                ^  ^
                |  +--  0: küresel yönetilen  ·  1: yerel yönetilen
                +-----  0: tekli yayın        ·  1: çoklu yayın

Kural bu yüzden tek bir haneye bakarak okunabiliyor:

Yerel yönetilen tekli yayın için 16 haneden yalnızca 4’ü uygun, yani %25.

Şu adres üstünde yürüyelim: 06-4B-7C-D2-05-9A. İlk sekizli 0x06, ikilik yazımda 0000 0110 oluyor. En anlamsız bitten gönderilince tele 0110 0000 olarak çıkıyor. İlk bit sıfır, yani tekli yayın; ikinci bit bir, yani yerel yönetilen. Bu adres tanımı gereği hiçbir üreticiye ait değil.

48 bitin hepsi bir olursa adres yayın adresine dönüşüyor: FF-FF-FF-FF-FF-FF. Gönderen kart herkesin işlemesini istiyorsa hedef adres alanına o özel değeri yazıyor. Yayın adresine gönderilen bir çerçeveyi yerel ağdaki her istasyon alıyor ve işlemek zorunda kalıyor. Bedeli herkese dağılıyor.

Yayın adresi aslında çoklu yayının özel hâli: bütün istasyonlardan oluşan grup. Bit kuralı da bunu doğruluyor, çünkü ilk bit bir olduğu için adres teknik olarak çoklu yayın. Çoklu yayın adresi tek bir çerçevenin bir istasyon grubu tarafından alınmasını sağlıyor. Arayüz, bir ya da daha fazla grup adresine gelen çerçeveleri alacak şekilde programlanabiliyor.

Ethernet’te yayın adresi tek bir sabit değer. IP’deki yayın adresi ise hangi alt ağda olduğuna göre değişiyor. Düz adres uzayı ile hiyerarşik adres uzayı arasındaki fark tam burada görünüyor.

Bir üst kattaki grup, buradaki adrese nasıl çevriliyor?

Ağ katmanı bir gruba paket yollamak istediğinde elinde bir çoklu yayın IP adresi var, ama kart yalnızca MAC adresi tanıyor. Aradaki dönüşüm bir tablo değil, doğrudan bir hesap — ve tasarımı bu kitapta göreceğin en pratik hilelerden biri.

IPv4’te kural şu: MAC adresinin ilk 25 biti sabit (01:00:5E ve ardından bir sıfır biti), kalan 23 bite IP adresinin son 23 biti kopyalanıyor.

IP  224.0.0.251   →  MAC  01:00:5E:00:00:FB
IP  239.255.255.250 →  MAC  01:00:5E:7F:FF:FA

İlk sekizli 01, yani ilk bit bir: adres tanımı gereği çoklu yayın. Hesap hiçbir sunucuya sormadan, hiçbir tablo tutmadan yapılabiliyor.

Bir kusuru var ve kasten kabul edilmiş. Çoklu yayın IP adresinin makine kısmı 28 bit ama MAC’e yalnızca 23 biti sığıyor; aradaki 5 bit düşüyor. Yani 32 ayrı IP grubu aynı MAC adresine düşüyor. Kart bunlardan birine üye olduğunda öteki 31’inin çerçevelerini de yukarı veriyor, ve ayıklamayı işletim sistemi yapıyor. Donanım filtresinin kaçırdığını yazılım filtresi topluyor.

IPv6 aynı numarayı daha bol yerle yapıyor: 33:33 ile başlıyor ve adresin son 32 bitini kopyalıyor. Çakışma ihtimali pratikte kalmıyor.

Aynı adres bir kat yukarıda yeniden doğuyor

MAC adresinin ikinci bir hayatı daha var. IPv6’da bir makine kendi adresini kendi üretiyor ve o adresin alt yarısını çoğu zaman kartın MAC adresinden çıkarıyor. Yönteme EUI-64 deniyor ve üç adımdan oluşuyor:

1. 48 bitlik adresi ortadan ikiye böl.
2. Araya FF:FE iki sekizlisini sok — 48 bit 64 bite çıkar.
3. İlk sekizlideki yerel yönetim bitini ters çevir.

MAC     00:1B:44:11:3A:B7
adım 1  00:1B:44 | 11:3A:B7
adım 2  00:1B:44:FF:FE:11:3A:B7
adım 3  02:1B:44:FF:FE:11:3A:B7      →   ::021b:44ff:fe11:3ab7

Üçüncü adım ilk bakışta keyfî görünüyor. Değil: EUI-64 uzayında bitin anlamı ters çevrilmiş — orada 1 “küresel”, 0 “yerel” demek. Aynı bit, iki farklı standartta zıt anlamlar taşıyor ve dönüşüm bunu düzeltiyor. Bir bitin anlamının bağlama göre değişmesi, bu kitapta gördüğün en sinsi uyumsuzluk olabilir.

Yöntemin bir bedeli daha vardı ve bu kez kabul edilmedi. MAC adresi değişmediği için ondan türetilen IPv6 adresinin alt yarısı da değişmiyordu; makine hangi ağa giderse gitsin adresinin yarısı aynı kalıyor, yani bu bölümün sonunda konuşacağımız iz kalıcı hâle geliyordu. RFC 8981 bu yüzden geçici adresler tanımladı ve modern işletim sistemleri dışarı çıkarken MAC’ten türetilmiş adresi değil, düzenli aralıklarla yenilenen rastgele bir adresi kullanıyor. Makinenin kendi IPv6 adresini nasıl bulduğunu anlatırken buraya geri döneceğiz.

MAC adresi yazılımla değiştirilebiliyor. Bugün kullanılan Ethernet arayüzlerinin hepsi buna izin veriyor, standart açıkça zorunlu kılmasa da uygulamada durum bu. Fabrika adı bir kilit değil, bir varsayılan.

Yerel yönetilen adresler Ethernet’te uzun süre seyrek kullanıldı. Sebebi sade: her arayüz zaten fabrikada tek bir adres alıyordu. Adres rastgeleleştirmesi tam olarak bu az kullanılan kapıdan geçiyor. İkinci biti bire çekiyor ve fabrikadan gelen adı bırakıyor. Rastgele üretilen sayının ikinci hanesi bu yüzden 2, 6, A ya da E oluyor.

İzlemeyle ilgisi doğrudan MAC’in düz yapısından geliyor. Değişmeyen bir ad, cihaz nereye giderse gitsin aynı kaldığı için tek başına bir iz. Telefonun her ağda aynı adı göstermesi, o telefonu her ağda tanınır yapıyor. Rastgeleleştirme bu izi kesiyor.

Kendi fabrika adını görmek istersen:

getmac /v /fo list

Komut her ağ kartı için bir blok döküyor: bağlantı adı, ağ bağdaştırıcısı, Fiziksel Adres ve taşıma adı. O satırdaki 12 hane, kartın ROM’una yazılmış ad. İkinci haneye bak: 0, 4, 8 ya da C ise elindeki ad gerçekten fabrikadan geliyor.

Özet

Peki, ne öğrendik?

• MAC adresi 48 bitlik ve bölümsüz: hiyerarşi taşımadığı için kart nereye taşınırsa taşınsın aynı sayıyı gösteriyor.
• Tekliği IEEE’nin dağıtımı sağlıyor: üretici 24 bitlik OUI’sini adresin ilk yarısına koyuyor, kalan yarıyı kendi üretim sayacıyla dolduruyor.
• Kart her çerçeveyi hedef adrese kadar okuyor: eşleşme ya da yayın adresi yoksa gerisini okumadan bırakıyor ve işletim sistemini hiç rahatsız etmiyor.
• Kural tek haneye iniyor: ikinci onaltılık hane tekse çoklu yayın; 2, 6, A ve E yerelde verilmiş, 0, 4, 8 ve C ise küresel tekli yayın anlamına geliyor.
• Çoklu yayın adresi hesaplanır, sorulmaz: IPv4’te 01:00:5E önekine adresin son 23 biti kopyalanır ve 32 grup aynı MAC’e düşer; ayıklamayı yazılım tamamlar.
• Aynı adres bir kat yukarıda yeniden doğuyor: EUI-64 araya FF:FE sokup yerel yönetim bitini ters çevirir, çünkü o bitin anlamı iki standartta zıttır.

Çerçevenin iki adresi de yerinde: kimin gönderdiği ve kimin alacağı yazılı. Ama bu çerçeve şimdi bakırın ya da camın içinde kilometrelerce yol alacak. Yolda tek bir bit ters dönerse bunu kim fark edecek?

Bölüm 22: Hata Sezme ve CRC

Çerçeve hazır. Fabrikadan gelen MAC adresini başına yazdık, ama yolda bir bit ters dönerse bunu kimin fark edeceğini söylemedim.

Fark eden bir gözlemci yok. Çerçevenin sonuna eklenen küçük bir sayı var ve bütün iş onda. Peki dört bayt, 1.500 baytlık bir yükü nasıl koruyabiliyor?

Bir bit neden ters döner?

Telin üstündeki sinyal yol boyunca zayıflıyor. Üstüne bir de dışarıdan gelen elektromanyetik gürültü biniyor. Alıcı eşiğe yakın bir gerilim gördüğünde yanlış karar veriyor ve gönderilen sıfır, bir olarak okunuyor. Bit hatasının fiziksel sebebi bu iki etkinin toplamı.

Olasılık kanaldan kanala değişiyor ve fiberde diğer bütün ortamlardan çok daha düşük kalıyor. Yıldırım gibi atmosferik olaylar ise hem telli hem telsiz ortamda aynı şeyi yapıyor: art arda gelen bitleri topluca bozuyor. Bu kümeye patlama hatası deniyor. Ayrım yöntem seçimini belirliyor, çünkü tek bir biti koruyan hesap on bitlik bir patlamanın karşısında çaresiz kalıyor.

Sinyalin neden zayıfladığını ve gürültünün nereden geldiğini burada bırakıyorum; ortamın kendisine kitabın sonunda bakacağız.

Bir şeyi de baştan sabitleyeyim. Hiçbir sezme yöntemi %100 güvenilir değil; her yöntem bazı hataları kaçırıyor, ama nadiren. Denetim alanı büyüdükçe hem sezme hem düzeltme gücü artıyor. Bedeli her çerçevede taşınan fazladan bit.

Sezmek ile düzeltmek aynı iş mi?

Hata denetimi iki ayrı aşamada yürüyor. Önce saptama: bir bozulma var mı? Sonra düzeltme: bozulan neydi ve doğrusu neydi? İki büyük aile bu iki aşamayı farklı paylaştırıyor.

FEC (forward error correction, ileri yönlü hata düzeltme) ikisini birlikte yapıyor. Alıcı göndericiye hiçbir şey sormadan bozulan biti geri çeviriyor. Yaygın iki algoritması Hamming kodlaması ve Reed-Solomon kodlaması; 1-2 bitlik hataları anlayıp düzeltebiliyorlar.

Asıl kazanç hızda. Alıcı hatayı yerinde düzelttiği için bir gidiş-dönüş süresi beklenmiyor. Derin uzay bağlantılarında bu belirleyici oluyor, çünkü orada bir sorunun cevabı dakikalarca yolda kalıyor. Gerçek zamanlı ses ve videoda da öyle.

Patlama hataları FEC’i zorluyor. Fiziksel katmanın çözümü, denetim bitlerini ekledikten sonra bitleri karıştırmak. Tek bir gürültü patlaması artık komşu bitleri değil, birbirinden uzak bitleri vuruyor. Alıcı sırayı geri çevirince küme dağılmış oluyor.

ARQ (automatic repeat request, otomatik tekrar isteği) daha az iddialı. Bozulan paketi yeniden gönderiyor, o kadar. Bu yüzden akış kontrolüyle birlikte çalışıyor. Veriyi paketlere bölmenin sebeplerinden biri de bu: bozulan tek paket yeniden gönderiliyor, koca dosya değil.

Bir kodun gücünü ölçen tek sayı

“Bu yöntem kaç bitlik hatayı yakalar?” sorusunun tahmine dayanmayan bir cevabı var ve tek bir büyüklüğe iniyor.

İki bit dizisi arasındaki Hamming uzaklığı, kaç konumda farklı olduklarıdır. 1011010 ile 1001110 arasındaki uzaklık ikidir; üçüncü ve beşinci bitler tutmuyor. Bir hata tam olarak bunu yapıyor: diziyi kendisinden d uzaklıktaki başka bir diziye taşıyor.

Denetim biti eklediğinde bütün bit dizileri geçerli olmaktan çıkıyor; yalnızca bir kısmı geçerli kod sözcüğü oluyor. Kodun gücünü belirleyen şey, bu geçerli sözcüklerin birbirine ne kadar uzak durduğu. En yakın iki geçerli sözcük arasındaki uzaklığa kodun asgari uzaklığı (dmin) deniyor ve her şey ondan çıkıyor:

d bitlik hatayı SEZMEK için      dmin ≥ d + 1
d bitlik hatayı DÜZELTMEK için   dmin ≥ 2d + 1

İki formülün arasındaki fark, geometrik olarak düşününce kendiliğinden anlaşılıyor. Geçerli sözcükleri bir uzayda noktalar gibi düşün. Sezmek için, d bitlik bir hatanın seni başka bir geçerli noktaya düşürmemesi yeter — arada en az bir adım daha olmalı. Düzeltmek ise daha fazlasını istiyor: bozulmuş diziye en yakın geçerli noktanın tek olması gerekiyor, yani her noktanın çevresindeki d yarıçaplı kürelerin birbirine değmemesi. İki kat yer gerekiyor, formüldeki 2 katsayısı da oradan geliyor.

Şimdi tanıdık iki kodu ölç:

Tek eşlik bitinin dmin = 2 olması, iki geçerli sözcüğün en az iki bit farklı olması demek — bir bit çevirirsen mutlaka geçersiz bir diziye düşersin, bu yüzden hatayı görürsün. Ama hangi bitin ters döndüğünü söyleyemezsin: d + 1 = 2 sağlanıyor, 2d + 1 = 3 sağlanmıyor. Bu kitapta ilerideki her yöntemin gücü aynı cetvelle ölçülüyor.

Bedeli de aynı cetvelde okunuyor. Sözcükleri birbirinden uzaklaştırmanın tek yolu daha çok denetim biti eklemek, yani her çerçevede daha az veri taşımak. Güvenilirlik ile verim aynı bütçeden besleniyor.

Saymak nereye kadar yetiyor?

En ucuz sezme tek bir bit ekliyor. Asenkron haberleşmede her karakterin yanına giden eşlik biti bu. Çift eşlikte bir’lerin sayısı çift olacak şekilde ayarlanıyor, tek eşlikte tek. Hangisinin kullanılacağına iki tarafın önceden karar vermesi gerekiyor.

Alıcının işi sayı saymak. Gelen bir’leri sayıyor; teklik ya da çiftlik tutmazsa bozulma var demektir ve karakter yeniden isteniyor. Bir baytlık 01001011 içinde dört tane bir var, o yüzden çift eşlikte eklenen bit sıfır oluyor. Bayt başına bir bit, yani %12,5 yük.

Kör noktası da aynı yerde duruyor. Çift sayıda bit ters dönerse toplam yine tutuyor ve hata görünmez kalıyor. Hatalar patlama hâlinde geldiğinde bu bir istisna olmaktan çıkıyor: tek eşlik bitiyle korunan bir çerçevede sezilemeyen hata olasılığı %50’ye yaklaşabiliyor.

İki boyutlu eşlik bir kat yukarı çıkıyor. Veri satır ve sütunlara diziliyor, her satır ve her sütun için ayrı eşlik hesaplanıyor. Tek bit bozulduğunda bozuk satır ile bozuk sütunun kesişimi hatalı biti veriyor; alıcı onu çevirip düzeltiyor. İki bit bozulduğunda ise düzeltemiyor, yalnızca sezebiliyor. Pratikte kullanılmamasının sebebi bedeli: 4x4’lük bir matriste 16 veri biti için 9 eşlik biti gerekiyor, yani %56 yük.

Checksum aynı fikri bir adım ileri taşıyor. İnternet checksum veriyi 16 bitlik tamsayılar dizisi sayıyor, bir tümleyen toplamını alıyor ve sonucu denetim alanına yazıyor. Alıcı aynı hesabı yeniden yapıp karşılaştırıyor. Eşit değilse hata sezildi. Eşitse sezilmedi, ama yine de olmuş olabilir.

Zayıflığı gösterilebilir. Üç kelime al: E38F, A51C, 4B60. Toplamları 2BF3 çıkıyor. Şimdi birinci kelimeyi bir artır, ikinciyi bir azalt. İkisi de değişti, sonuç yine 2BF3 çıkıyor. Toplama değişmeli olduğu için kelimelerin sırasını bozmak da sonucu değiştirmiyor.

TCP ve UDP checksum yalnızca 16 bit yer kaplıyor. Yükü çok düşük, koruması da o oranda zayıf. Sebep tasarımda: taşıma katmanı yazılımda çalışıyor ve ucuz bir hesap seçiyor. IPv6 başlığında bu alan hiç yok; yönlendiricide işlemeyi hızlandırmak için kaldırılmış ve koruma alt ile üst katmanlara bırakılmış.

Çerçevenin sonundaki dört bayt

Bağ katmanı aynı ödünleşimi ters yönde çözüyor. Hesap ağ kartının üstündeki özel donanımda çalışıyor, bu yüzden pahalı bir yöntem göze alınabiliyor. O yöntem CRC.

CRC (cyclic redundancy check, döngüsel artıklık denetimi) kodlarının öbür adı polinom kodları. Bit dizisi, katsayıları 0 ve 1 olan bir polinom gibi ele alınıyor. Gönderici ile alıcı önce r+1 bitlik bir üreteç deseninde anlaşıyor; desenin en soldaki biti 1 olmak zorunda ve deseni standart veriyor. Hesap mod-2 aritmetiğiyle yürüyor: elde ve borç yok, toplama ile çıkarma aynı işlem ve ikisi de bit bazında XOR.

Gönderici veriyi r bit sola kaydırıp üretece bölüyor. Kalan, veriye eklenen CRC bitleri oluyor:

D = 100110        veri, 6 bit
G = 1101          üreteç, r+1 = 4 bit   (r = 3)

100110000 ÷ G  ->  kalan 110
tele çıkan     ->  100110110
alıcıda kalan  ->  000

soldan dördüncü bit ters:  100010110  ->  kalan 011   (hata sezildi)

Alıcı ayrı bir hesap tutmuyor. Veriyi ve CRC bitlerini birlikte üretece bölüyor; kalan sıfırdan farklıysa hata var.

Uluslararası standartlarda 8, 12, 16 ve 32 bitlik üreteçler tanımlı. Ethernet’in seçtiği CRC-32’nin üreteci 33 bitlik sabit bir desen ve aynı desen bağ katmanındaki IEEE protokollerinde ortak. Her standart iki şeyi garanti ediyor: r+1 bitten kısa bütün patlamalar ve tek sayıda bit hatasının hepsi kesin yakalanıyor. Daha uzun patlamalar da yüksek olasılıkla seziliyor. 32 bitlik artıklıkta kaçırma olasılığı %0,0000000233’e iniyor.

Üç yöntemi aynı hata patlaması üstünde karşılaştıralım:

Ethernet çerçevesinin son alanı FCS (frame check sequence, çerçeve denetim dizisi). 32 bit, yani 4 bayt, ve içine CRC-32 sonucu yazılıyor. Hesap hedef adres, kaynak adres, tür alanı ve veri alanları üzerinden yapılıyor; baştaki 8 bayt, yani önsöz ile çerçeve başlangıç sınırlayıcısı, hesaba katılmıyor. Kapsülleme merdiveninde bu alanı adlandırmış ama içini boş bırakmıştım.

Bu dört baytın bedeli çerçeve boyuna göre değişiyor. 1.518 baytlık dolu bir çerçevede FCS’nin yükü %0,26 kalıyor. 64 baytlık en küçük çerçevede aynı alan %6,25’e çıkıyor. Aradaki fark kabaca yirmi dört kat.

Hesap tutmazsa çerçeve düşürülüyor ve arayüzün hata sayacı bir artıyor. Üst katmana hiçbir şey çıkmıyor. Alıcı kart göndericiye ne ACK ne NAK yolluyor; Ethernet güvenilir değildir. Düşen çerçevedeki veri ancak üst katmanda güvenilir bir protokol varsa kurtarılıyor. Bağ katmanı hatayı tespit ediyor, telafi etmiyor.

Yol üstünde iki tuzak var. Bir anahtar çerçeveyi tamponuna alıp CRC’sini denetledikten sonra iletiyorsa bozuk çerçeve orada duruyor; hedef adresi okur okumaz iletiyorsa CRC’ye hiç bakılmadan bozuk çerçeve yayılabiliyor. Bu tercihin adını anahtarı açtığımızda koyacağız. İkinci tuzak da anahtarın elinde: çerçeveye bir etiket eklendiğinde FCS baştan hesaplanıyor.

Sayacı kendi makinende görebilirsin:

ip -s link show enp3s0
ethtool -S enp3s0 | grep -i crc

İlk komut RX satırının altında errors sütununu dökecek. İkincisi sürücünün tuttuğu ayrıntılı sayaçlardan rx_crc_errors benzeri bir satır verecek. Sayı artıyorsa kablo, konnektör ya da yakındaki bir gürültü kaynağı sorguya çekilir.

Özet

Peki, ne öğrendik?

• Bozulmanın sebebi zayıflama ve gürültü: yıldırım gibi olaylar bitleri tek tek değil ardışık kümeler hâlinde deviriyor ve yöntem seçimini belirleyen şey bu.
• Saptama ile düzeltme ayrı işler: FEC ikisini birlikte yapıp gidiş-dönüş süresini kurtarıyor, ARQ ise yalnızca saptayıp bozulan paketi yeniden istiyor.
• Ucuz yöntemlerin kör noktası ölçülü: tek eşlik biti çift sayıda dönüşü, internet checksum birbirini telafi eden değişimleri kaçırıyor.
• CRC bölmeye dayanıyor: veri r bit kaydırılıp üretece bölünüyor, kalan çerçeveye ekleniyor ve alıcıda kalanın sıfırdan farklı çıkması hatayı ele veriyor.

Çerçevenin sonu artık dolu ve başındaki iki adres de yerinde. Peki oraya yazdığın MAC’i sen nereden buldun? Elinde hedefin IP adresi var; aradaki eşlemeyi kim yapıyor?

Bölüm 23: Adres Çözümleme: ARP

Çerçevenin sonuna dört baytlık FCS’yi koyduk; başındaki iki adres alanı da tanımlıydı. Elinde ise yalnızca bir IP adresi var ve aradaki eşlemeyi kimse önceden yapmadı.

Geriye tek bir iş kalıyor: sormak. Ağda sormak ise harfi harfine bağırmak demek. Peki bağırınca kim cevap veriyor?

Soru sorulmadan önce bir karar veriliyor

Makinen çerçeveyi yazmadan önce sessiz bir hesap yapıyor. Hedef IP adresini ve kendi adresini alt ağ maskesinden geçiriyor. İki sonuç aynıysa hedef aynı ağda oturuyor; farklıysa hedef uzakta kalıyor.

Somut bir örnek üstünde yürüyelim. Adresin 192.0.2.10 ve maskesi 255.255.255.0 olsun. Hedef 192.0.2.40 ise maskeden geçen iki sonuç da aynı çıkıyor; komşusun. Hedef 198.51.100.5 olsaydı sonuçlar ayrışacak ve soru o makine için hiç sorulmayacaktı.

Uzak hedefte ARP hedefin kendisi için sorulmuyor, default gateway (varsayılan geçit) için soruluyor — yani makinenin, kendi ağında olmayan her şeyi teslim ettiği çıkış kapısı için. Çerçevenin hedef MAC adresi yönlendiricinin arayüzü oluyor. Paketin içindeki hedef IP adresi ise olduğu gibi kalıyor. İki adres, iki ayrı katmanın işi; birbirlerinin yerine geçemezler.

Karar verildikten sonra ilk bakılan yer makinenin kendi ARP tablosu. Tablonun her satırı bir IP adresini bir MAC adresine eşliyor. Yeni açılmış bir makinede bu tablo boştur. Dolduran şey kullanımın kendisi: makine kiminle konuştuysa onun satırı orada durur. Kimse elle yapılandırmıyor.

Mahalle bakkalını düşün. Müşterisinin adını bilir ama kimin hangi kapıda oturduğunu ancak bir kez sorup deftere yazarak öğrenir. Defter ARP tablosu, ad IP adresi, kapı numarası MAC adresi. Benzetme şurada biter: bakkalın defteri sokağın dışına çıkmaz, ARP de kendi alt ağının dışını çözemez.

Yetkili sunucuya kadar giden ad çözme zincirini izlemiştin; burada aynı iş bir kat aşağıda, adresten karta doğru yapılıyor. Ağa yeni katılan bir makine bunu ilk saniyede yaşıyor: DNS sorgusunu taşıyacak çerçeve için yönlendiricinin MAC adresi gerekiyor. İstek, sen farkına varmadan bir soruya bağlı bekliyor.

Neden yayınla soruluyor?

Tabloda kayıt yoksa makine soruyu ağa yayınlıyor. Çerçevenin hedef MAC alanına FF-FF-FF-FF-FF-FF yazılıyor. Sebep sade: sorunun kime gideceği bilinmiyor.

Yayını yerel ağdaki bütün düğümler alıyor. Standart, hedefi tümü bir olan her çerçeveyi her istasyonun alıp işlemesini şart koşuyor. Hedef olmayan cihazlar, örneğin yönlendirici, mesajı dikkate almadan atıyor. Ama atmadan önce almış ve işlemiş oluyorlar.

Ölçek tam burada gizleniyor. Belgeleme için ayrılmış 192.0.2.0/24 bloğunu örnek alalım; içinde 254 kullanılabilir adres var. Tek bir ARP isteği, soranın dışındaki 253 komşunun kartını uyandırıyor. Ağ kartının gelen çerçeveyi halka tampona alıp çekirdeğe taşımasının bir bedeli vardı. O bedel burada 253 kez ödeniyor.

Cevap veren tek bir makine oluyor: istekteki IP adresinin sahibi. Cevap da yayınla dönmüyor, tek bir çerçeveyle geliyor. Asimetri kasıtlı; cevabı yalnızca soranın duyması yeter.

Öğrenme çift yönlü işliyor. Cevabı alan makine eşlemeyi belleğine yazıyor ve bir daha sormuyor. Cevabı veren de soranın adresini kendi tablosuna ekliyor, çünkü ARP paketi soranın kendi IP ve MAC adresini de taşıyor. Soru sorarken kendini de tanıtıyorsun.

Birbirinin yayın çerçevelerini alan düğümlerin tamamına broadcast domain (yayın alanı) deniyor. Yayın yerine çoklu yayın kullanmak daha iyi bir fikirdi; ilk biti bir olan adresler çoklu yayındı ve IPv6’nın adres çözümlemesi tam olarak oraya yaslanıyor. Bu bağırışın nereye kadar gittiğini kasten açık bırakıyorum; sınırını bir sonraki durakta çizeceğiz.

Bir yana: RARP ters yönü çözüyor, MAC adresinden IP adresini öğreniyor. Vekil ARP ise yönlendiricinin başkası adına cevap vermesi; işi yürütüyor ama ağdaki trafiği artırıyor.

Paketin içinde tam olarak ne var?

ARP’ın tanımı 1982 tarihli RFC 826. Yaptığı işin adı adres çözümleme: elindeki IP adresine karşılık gelen MAC adresini bulmak. Belgedeki paket biçimi dokuz alandan oluşuyor: donanım türü, protokol türü, iki adres uzunluğu, işlem kodu ve dört adres alanı.

Uzunluk alanları ilk bakışta fazlalık gibi duruyor. Fazlalık sayılmazlar. MAC adresi 6 bayt, IPv4 adresi 4 bayt ve ARP bu iki uzunluğu ayrı alanlarda ilan ediyor. Yani ARP IPv4’e gömülü bir protokol değil; hangi adres ailesini çözdüğünü paketin kendisi söylüyor.

ar$hrd  2 bayt  donanım türü
ar$pro  2 bayt  protokol türü
ar$hln  1 bayt  donanım adres uzunluğu   -> 6
ar$pln  1 bayt  protokol adres uzunluğu  -> 4
ar$op   2 bayt  işlem kodu               -> istek 1, cevap 2
ar$sha  6 bayt  gönderenin MAC adresi
ar$spa  4 bayt  gönderenin IP adresi
ar$tha  6 bayt  hedefin MAC adresi
ar$tpa  4 bayt  hedefin IP adresi
--------------------------------------------
                toplam 28 bayt

Alanları gerçek değerlerle doldurunca resim netleşiyor. Belgeleme için ayrılmış adresleri kullanayım. Örnek kart adresleri de uydurma sayılmaz; RFC 7042 belgeleme için 00-00-5E-00-53-00 ile 00-00-5E-00-53-FF arasını ayırmış. Soran makine 192.0.2.10, kartının adresi 00-00-5E-00-53-2A, aradığı adres ise 192.0.2.40 olsun. İstekte kendi adres ikilisini gönderen alanlarına yazıyor ve aradığı adresi hedef IP alanına koyuyor. Hedefin MAC adres alanını ise boş bırakıyor. Zaten bilseydi sormazdı.

Cevap da aynı dokuz alanı taşıyor, yalnızca roller yer değiştiriyor. Adresin sahibi kendi kartının adresini gönderen alanına yazıyor ve çerçeveyi doğrudan soranın kartına yolluyor.

istek  (op 1)  gönderen  192.0.2.10 / 00-00-5E-00-53-2A
               hedef     192.0.2.40 / boş
               çerçeve   hedef MAC  FF-FF-FF-FF-FF-FF

cevap  (op 2)  gönderen  192.0.2.40 / 00-00-5E-00-53-3C
               hedef     192.0.2.10 / 00-00-5E-00-53-2A
               çerçeve   hedef MAC  00-00-5E-00-53-2A

Ethernet’in veri alanı en az 46 bayt olduğu için araya 18 bayt dolgu giriyor. Bir ARP isteği tel üstünde bu yüzden 64 baytlık asgari çerçeve olarak gidiyor. Sorduğun soru, kablodaki en küçük çerçeve.

Çerçevenin tür alanı 0x0806. Alıcı bu değere bakıp yükü ARP modülüne veriyor. Kapsülleme merdiveninde bu tür alanını zaten görmüş ve değerini not etmiştin. ARP paketi bir bağ katmanı çerçevesinin içinde taşınıyor ama ağ katmanı adreslerini içeriyor; iki katmanın tam sınırına oturuyor.

Gelen paketi alan makine sırayla üç şey soruyor: bu donanım türünü tanıyor muyum, bu protokolü konuşuyor muyum, hedef protokol adresi ben miyim. İşlem koduna en sonda bakılıyor. Üstelik gönderenin adres çifti tabloda zaten varsa, kod okunmadan önce güncelleniyor. Yani kimse sormadan gelen bir cevap da tabloyu tazeliyor.

Tablo ne kadar hatırlıyor?

Kayıtların bir ömrü var. Tipik değer 20 dakika; süre dolunca eşleme unutuluyor. Windows dinamik bir kaydı bellekte 2 dakika tutuyor, o süre içinde yeniden konuşulursa ömür 10 dakikaya çıkıyor. Aynı protokolde ömür on kata kadar fark ediyor. Bu bir ihlal sayılmıyor, çünkü RFC 826 tablo yaşlandırmayı ve zaman aşımını zorunlu kılmıyor.

ARP tablosu bu yüzden alt ağdaki her makineyi içermez. Kimisi tabloya hiç girmemiştir, kimisinin süresi dolmuştur. Bir makine ağdan koptuğunda kaydı kendiliğinden siliniyor. Eşlemeyi elle sabitlemek de mümkün; arp -s bir satırı statik yapıyor.

Şimdi adresini yeni alan bir makineye bak. RFC 5227, bir adresi kullanmadan önce 3 yoklama paketi göndermeyi kurala bağlıyor. Yoklamada gönderen IP alanı sıfır bırakılıyor; amaç, henüz sahiplenilmemiş bir adresle komşuların önbelleğini kirletmemek. Çakışma çıkmazsa makine 2 ilan paketi yolluyor. İlan, gönderen ve hedef IP alanı aynı olan bir ARP isteği. Bedava ARP dediğimiz şey bu. Adresini savunan makine iki savunma arasında en az 10 saniye bekliyor; iki çakışan makinenin ağı doldurmasını engelleyen sınır bu.

Aynı kural kötüye de kullanılıyor. Sahte bir cevap komşunun satırını sessizce değiştiriyor ve trafik saldırganın kartına akıyor; adı ARP zehirlemesi. Resolver’ın önbelleğine sahte kayıt yerleştiren ve orayı yaşam süresi boyunca elinde tutan bir saldırı vardı. Buradaki numara aynı fikrin bir kat aşağıdaki hâli. Ortaya çıkan sonuç, adını Diffie-Hellman anlatırken koyduğumuz ortadaki adam saldırısı — bu kez yerel ağın içinde. Anahtar üstündeki dinamik ARP denetimi, MAC adresi ile IP eşleşmelerini karşılaştırıp bunu kesiyor.

Bunların hepsini kendi makinende görebilirsin. Windows’ta tablo arp -a ile geliyor, Cisco yönlendiricide karşılığı show arp oluyor. Çıktının biçimi de öğretici. Her satırda bir IP adresi, karşısında bir MAC adresi ve kaydın türü duruyor.

Arayüz: 192.0.2.10 --- 0x5
  Internet Adresi       Fiziksel Adres        Tür
  192.0.2.1             00-00-5e-00-53-01     dinamik
  192.0.2.40            00-00-5e-00-53-3c     dinamik

Listedeki ilk satır neredeyse her makinede aynı işi görüyor: geçidin kaydı. Dinamik kayıtlar zamanla silinir, statik olanlar sen silene kadar durur. En hızlı deney de burada: bir satırı arp -d ile düşür, sonra o adrese tek bir paket yolla. Tablo kendini yeniden dolduruyor ve aradaki soruyu kimse sana sormuyor.

Gösterim filtresiyle trafiği ayıklamayı öğrenmiştin; arp.opcode == 1 istekleri, arp.opcode == 2 cevapları getiriyor. Aynı adresi iki farklı kartın sahiplendiği anı ise arp.duplicate-address-detected yakalıyor.

Peki kimse cevap vermezse? Gönderen isteği tekrarlıyor, sonunda paketleri düşürüyor. Sessizlik görünür bir hataya dönüşüyor: yönlendirici kaynağa ICMP Hedef Bilgisayara Ulaşılamıyor mesajı gönderiyor.

Özet

Peki, ne öğrendik?

• ARP tek bir soruyu çözüyor: elindeki IP adresinin hangi MAC adresine ait olduğunu bulur, ve bunu yalnızca kendi alt ağının içinde yapabilir.
• Soru yayınla gidiyor, cevap tekil dönüyor: isteği bütün komşular alıp işler, cevabı ise yalnızca adresin sahibi verir.
• Öğrenilen eşleme saklanıyor: tablo kullanıldıkça dolar, kayıtların ömrü dolunca silinir, ve bu süreyi RFC 826 zorunlu kılmaz.
• Gelen her mesaj göndereni tazeliyor: bedava ARP de bu kurala yaslanır, ARP zehirlemesi de.

Soruyu sordun, cevabı aldın, eşlemeyi tabloya yazdın. İsteğin hâlâ sırada bekliyor. Bağırdın ve herkes duydu; peki “herkes” tam olarak kim?

Bölüm 24: Anahtarlama ve Ortam Erişimi

ARP isteği bütün ağa bağırıldığında o çerçeveyi gerçekten herkes duyuyordu. Duyanların sınırını kimin çizdiğini söylemedim.

Sınırı bir kural çizmiyor. Kablonun öbür ucundaki kutu çiziyor. Peki o kutu hangi çerçeveyi nereye göndereceğini nereden biliyor?

Tabloyu kim yazıyor?

Anahtar bir bağ katmanı cihazı ve hiç de edilgen bir kutu değil. Çerçeveyi alıyor, saklıyor, sonra iletiyor; kararını verirken de çerçevenin başına bakıyor.

Makinen çerçeveyi anahtara adreslemiyor; karşı makinenin fabrika adresini yazıyor ve arada bir cihaz durduğundan haberi bile olmuyor. Anahtar ağın görünmez elemanıdır.

Görünmez olduğu kadar da bakımsızdır. Kutuyu prize takar, kabloları geçirir, işine dönersin. Tablosunu kendi doldurur; hiçbir yönetici tek satır yapılandırmaz.

O tablonun her satırı üç alan taşıyor: bir MAC adresi, o adrese ulaşan arayüz ve kaydın zaman damgası. Standart metnindeki adı iletme veritabanı, sahadaki adı MAC adres tablosu.

Asıl numara satırın nereden geldiğinde. Anahtar hedef adresten hiçbir şey öğrenmez, kaynak adresten öğrenir. Gelen çerçevenin göndericisini alır, çerçevenin girdiği port numarasıyla eşler ve tabloya yazar. Konuşan herkes konuştuğu anda yerini ele veriyor.

Bunun için her port karışık modda çalışır. Yakalama arayüzünü açarken kartı bu moda almıştın; anahtarın portları zaten hep öyle durur. Kendisine gelmeyen çerçeveleri de alır, çünkü öğrenmesi gereken tam olarak onlardır. Kural çerçevenin başlığındaki kaynak adres; bazı anahtarlar bunun üstüne bir ARP çerçevesinin veri alanında duran adresi de okuyup tabloya ekler.

Mahalle bakkalı defterini nasıl tutuyorsa anahtar da tablosunu öyle tutuyor. Benzetme burada bir adım öteye gidiyor: bakkal sorup öğreniyordu, anahtar sormuyor bile.

Ölçek de dikkat ister. Adres alanı 48 bit, yani iki üzeri kırk sekiz kadar olası ad var. Bir anahtarın tablosu ise birkaç bin satır. Anahtar adres uzayını tutmuyor, yalnızca duyduklarını tutuyor.

Hedefi tanımıyorsa ne oluyor?

Çerçeve içeri girdiğinde sıra sabit: kaynak kaydı önce, hedef araması sonra. Aramanın üç sonucu var ve üçü de ayrı bir davranış üretiyor.

Hedef, çerçevenin geldiği portta görünüyorsa anahtar çerçeveyi hiç iletmez. Düşürür. İki makine aynı kabloda oturuyorsa birbirlerini zaten duymuşlardır; bu davranışın adı filtreleme.

Hedefin yeri biliniyorsa çerçeve tek bir kablodan çıkar. Ağın geri kalanı o trafiği hiç görmez. Anahtarın bütün değeri bu cümlede.

Hedef tabloda yoksa anahtar bilmediğini itiraf eder. Çerçeveyi geldiği port dışındaki bütün portlardan kopyalar. Bu davranışın adı flooding (taşkın). Kopya gönderene geri verilmez; kimse kendi çerçevesini geri almaz.

Bilinmeyen makine cevap verdiği anda çerçevesi anahtara girer, anahtar onun portunu öğrenir ve o adrese bir daha flooding (taşkın) yapmaz. Bilgisizlik tek bir çerçeve boyunca sürüyor.

Tablonun ilk çerçeveden başlayarak nasıl dolduğunu izleyelim:

Bir çerçeve türü bu kuralın dışında kalıyor. Tümü bir olan FF-FF-FF-FF-FF-FF dizisi yayın adresiydi; o adrese giden çerçeve, tablo ne kadar dolu olursa olsun bütün portlarda kopyalanır. Anahtar yayını kesmez. ARP, anahtarın ardında da bağırarak çalışmayı sürdürür.

Kasten açık bıraktığım broadcast domain sınırının cevabı tam olarak burada duruyor. Ağda yalnızca hub, köprü ve anahtar varsa ortaya tek bir broadcast domain çıkıyor. O duvarı ancak yönlendirici örüyor.

Kayıtların bir de ömrü var. Bir adresten belli bir süre çerçeve gelmezse satır silinir; bu süreye yaşlanma süresi deniyor ve tipik değeri 5 dakika, yani 300 saniye. Süre ayarlanabiliyor, ders kitabı örneklerinde 60 dakikalık anahtarlar da geçiyor. Tabloya üç tür kayıt giriyor: dinamik, sürekli ve sınırlı statik. Dinamik olanlar kullanılmayınca silinir, kalan ikisi elle kaldırılır.

Bir anahtarın konsoluna girersen tabloyu tek komutla görebilirsin:

Switch# show mac-address-table

  MAC adresi          Port   Tür
  00-00-5e-00-53-1c   3      dinamik
  00-00-5e-00-53-7b   5      dinamik
  00-00-5e-00-53-a4   1      sürekli

Anahtar ağı neye böldü?

Anahtara giden her kablo kendi başına bir collision domain (çarpışma alanı). Bağlantı tam çift yönlü çalışıyor ve o kabloda çarpışma olmuyor. 24 portlu bir anahtar 24 collision domain ve tek broadcast domain demek.

Yerini aldığı cihaza bakınca fark keskinleşiyor. Hub bir porttan aldığı sinyali, o port hariç bütün portlara güçlendirerek kopyalar. Tablosu yoktur, kararı yoktur, seçeneği yoktur. 24 portlu bir hub’da tek çerçeve 23 gereksiz kopya üretir ve kutunun tamamı tek kocaman collision domain’e dönüşür.

Aynı çerçeve öğrenmiş bir anahtarda portların yalnızca %4,2’sini meşgul ediyor. Kalan yirmi üç kablo aynı anda başka konuşmalar taşıyor.

Tek bir kanalı paylaşmanın üç ailesi

Paylaşılan kabloda çözülmesi gereken problem tek cümleyle yazılıyor: N düğüm, tek bir kanal, ve aynı anda konuşan iki düğümün mesajı da bozuluyor. Sıra kimde? Yarım yüzyıllık literatür buna üç ayrı aile hâlinde cevap veriyor.

Kanalı bölmek. Kanalı baştan paylara ayırıp her düğüme kendi payını vermek. Zamanda bölersen TDMA, frekansta bölersen FDMA olur; çoklamaya indiğimizde ikisini de ayrıntısıyla göreceğiz. Adil ve çarpışmasız; ama bir düğümün payı, o düğüm susarken de kimseye açılmıyor. Tek bir düğüm konuşuyorsa kanalın 1/N’ini kullanabiliyor.

Rastgele erişim. Payı baştan dağıtma, isteyen istediği anda konuşsun; çarpışma olursa sonrasını kurala bağla. Az yükte muhteşem — tek konuşan kanalın tamamını alıyor. Yük arttıkça çarpışmalar çoğalıyor ve verim çöküyor.

Sıra alma. Bir düzenleyici sırayı dağıtsın (yoklama), ya da konuşma hakkı bir jeton gibi düğümden düğüme dolaşsın (jeton geçirme). İki ailenin iyi yanlarını birleştiriyor, karşılığında bir düzenleyiciye ya da dolaşan bir jetona bağımlı hâle geliyor. Halka topolojisini konuşurken ikincisini göreceğiz.

Ethernet ikinci aileden ve o ailenin tarihi tek bir soyağacı çiziyor.

ALOHA’dan CSMA/CD’ye: her adım bir kayıp kapatıyor

ALOHA, 1970’te Hawaii’de doğdu: verin varsa gönder, çarpışırsa rastgele bekleyip yeniden dene. Dinleme yok, kontrol yok. Analizi klasiktir ve verimi 1/(2e), yani yaklaşık %18. Kanalın beşte dördü boşa gidiyor.

Dilimli ALOHA tek bir kural ekliyor: gönderime ancak dilim sınırında başla. Böylece iki çerçeve ya tam çakışıyor ya hiç çakışmıyor; kısmi çakışmanın yarattığı israf kalkıyor. Verim 1/e, yani yaklaşık %37. Tek bir senkronizasyon kuralı verimi ikiye katlıyor.

CSMA bir adım daha atıyor: konuşmadan önce dinle. İnsan sohbetinin kuralı. Yine de çarpışma bitmiyor, çünkü sinyalin kabloda yol alması zaman alıyor: uzaktaki bir düğüm konuşmaya başlamış olabilir ve sen henüz duymamış olabilirsin. Çarpışma penceresi, iki uç arasındaki yayılım gecikmesi kadar.

CSMA/CD son adımı atıyor: konuşurken de dinle. Çarpışmayı fark ettiğin anda sus. ALOHA bütün çerçeveyi boşa gönderirken, CSMA/CD birkaç mikrosaniye sonra kesiyor.

Paylaşılan kablonun kuralı bu sonuncusuydu ve dört adımda yürüyordu: hattı dinle, boşsa gönder, gönderirken sezmeye devam et, başka bir iletim duyarsan kes. Kesen kart bir karıştırma sinyali yolluyor, sonra ikili üstel geri çekilmeye giriyor: rastgele bir süre bekleyip yeniden deniyor. Algoritma 1.024 ayrı geri çekilme süresi ayırt ediyor ve kart bir çerçeveden ancak 16 ardışık çarpışmadan sonra vazgeçiyor.

64 baytlık asgari çerçeve nereden çıktı?

Kitap boyunca Ethernet’in en küçük çerçevesini 64 bayt diye kullandık ve bu sayıyı hiç gerekçelendirmedim. Gerekçesi tam olarak burada, çarpışma sezmede.

Bir kartın çarpışmayı fark edebilmesi için, çarpışma haberi kendisine döndüğünde hâlâ gönderiyor olması gerekiyor. Aksi hâlde çerçeveyi bitirip işine döner, çarpışmadan hiç haberi olmaz ve veri sessizce kaybolur. Şart bu yüzden zamansal:

gönderim süresi ≥ 2 × en uzak iki düğüm arasındaki yayılım gecikmesi

Sağdaki değere dilim süresi deniyor. 10 Mbit/s’lik klasik Ethernet’te, tekrarlayıcılar dahil azami 2.500 metrelik bir ağ için bu süre 51,2 µs olarak sabitlendi. Şimdi soldaki tarafa çevir:

10.000.000 bit/s × 51,2 µs = 512 bit = 64 bayt

İşte o kadar. Asgari çerçeve boyu bir veri kararı değil, ışığın kabloda ne kadar yavaş gittiğinin sonucu. Kırk baytlık bir onay paketi niçin dolguyla 64 bayta tamamlanıyordu? Sebebi kırk yıl önceki bir kablonun uzunluğu.

Geri çekilmedeki 1.024 sayısı da aynı yerden geliyor: bekleme süresi dilim süresinin katları cinsinden ölçülüyor ve 2^10 en fazla kaç dilim beklenebileceğini söylüyor.

Sayı hızla birlikte büyümek zorundaydı, çünkü hız artınca aynı 512 bit çok daha kısa sürede çıkıyor. 100 Mbit/s’te mesafe kısaltılarak çözüldü; 1 Gbit/s’te ise başka bir çare bulundu — çerçevenin arkasına, çarpışma penceresi dolana kadar anlamsız bit eklemek. Yöntemin adı taşıyıcı uzatma ve tam çift yönlü kip yaygınlaşınca kimse kullanmadı.

Tam çift yönlü kip geldiğinde bu kuralın dayanağı kalmadı. Aynı kabloda çarpışma diye bir olay olmayınca CSMA/CD standartta durmayı sürdürdü ama fiilen devre dışı kaldı.

Anahtar ile hub arasındaki farkın altında özel donanım var. Anahtar çerçeveyi genel amaçlı bir işlemcide değil, ASIC denen özel bir yongada yönlendiriyor; gecikmenin mikrosaniyeyle ölçülmesinin sebebi bu. Yongaya çerçevenin ne kadarını okutacağın ise bir tercih. Sakla-ve-ilet tamamını alıp CRC’sini denetler, kes-ve-ilet yalnızca hedef adresi okuyup yola koyulur, parçasız iletme (fragment-free) ilk 64 baytı bekler.

Küçük bir ev anahtarının veri sayfası bu tercihleri sayıya çeviriyor. MAC adres veritabanı 4.000 giriş, toplam paket tamponu 128 KB. İç gecikme 10 Mbit/s portta 30 µs, 100 Mbit/s portta 6 µs, 1000 Mbit/s portta 4 µs. Port başına iletme hızı da sırasıyla 14.800, 148.800 ve 1.480.000 paket.

Ortadaki sayı tesadüf değil. En küçük çerçeve telde 84 bayt, yani 672 bit yer kaplıyordu; aynı kanal maliyeti 100 Mbit/s’de saniyede 148.809 çerçeve veriyor. Veri sayfasındaki 148.800 tam bu sayı.

Bütün portlar aynı anda tam yüklenirse iç elektronik yetişemeyip çerçeve düşürebilir; buna bloklama, yetişebilene bloklamayan anahtar deniyor.

Flooding (taşkın) ne zaman kusura dönüşür?

Tablonun bir sınırı olduğunu söylemiştim; saldırgan da bunu biliyor. Anahtar zehirleme saldırısı sahte kaynak adresli çok sayıda çerçeveyle tabloyu doldurur, gerçek adreslere yer bırakmaz. O noktadan sonra anahtar her şeyi flooding’e (taşkına) verir. Anahtarlı ağda dinleme zorlaşıyor ama bitmiyor. Tabloda kaydı olmayan hedefler ile yayın çerçeveleri hâlâ herkese ulaşıyor.

Savunması port güvenliği. Bir porta kaç MAC adresinin ilişkilendirilebileceğini sınırlarsın; sınır aşılınca port askıya alınır, gelen veri yok sayılır ya da port tümden kapatılır.

İkinci tuzak kabloda. İki anahtar arasına yedek olsun diye ikinci bir bağlantı çekmek makul bir fikir gibi durur. Sonucu döngü yolu oluyor. Döngüye giren çerçeve sonsuza dek dolaşır, trafik hattın azami hızına tırmanır ve ağ doyar.

Kapalı bir makineye yollanan tek bir çerçeve bunu başlatmaya yetiyor. Adres hiçbir anahtarın tablosunda karşılık bulmaz, her anahtar onu flooding’le (taşkınla) çoğaltır ve döngü varsa kopyalar birikmeye başlar.

IEEE 802.1D bu yüzden Spanning Tree Protocol’ü (yayılan ağaç protokolü) tanımlıyor. Yedekli bağlantılar fiziksel olarak yerinde durur ama bazı portlar bloklanır, geriye tek bir etkin yol kalır. Köprüler birbirlerine BPDU adı verilen küçük mesajlar yolluyor; kimliği en küçük olan kök köprü seçiliyor. Kimlik, varsayılanı 32.768 olan öncelik değeri ile cihazın MAC adresinin birleşimi.

Bir port beş durumdan birinde bulunur: bloklama, dinleme, öğrenme, gönderme, kapama. Özgün protokolde dinleme ve öğrenme 30 saniye sürüyordu; bir kablo koptuğunda ağın kendine gelmesi yarım dakikayı buluyordu. Hızlı sürümü 2 saniyede bir BPDU yollayarak topolojiyi izliyor, yol koptuğunda bloklu portu açıyor.

Buraya kadar ayrı ayrı gördüğün şeyler tek bir arayüz çıktısında yan yana duruyor. MTU paketin üst sınırını çiziyordu; anahtarın portunda o sınır da, spanning tree durumu da, flooding (taşkın) anahtarı da ayrı birer satır:

Switch# show interface fastethernet 0/2

  MTU 1500 bayt
  Spanning tree durumu: gönderme
  Bilinmeyen tekli yayın flooding'i: açık

Özet

Peki, ne öğrendik?

• Anahtar kendi öğreniyor: tablosunu kaynak adreslerden kurar, tak-çalıştır çalışır, ve her satırında bir adres, bir arayüz, bir zaman damgası tutar.
• Üç karar veriyor: hedef aynı porttaysa çerçeveyi düşürür, yeri biliniyorsa tek kablodan yollar, bilinmiyorsa bütün portlara kopyalar.
• Flooding (taşkın) bilgisizliğin bedeli: yalnızca bir çerçeve sürer, ama yayın adresine giden çerçevelerde hiç bitmez.
• Anahtar çarpışmayı böler, yayını bölmez: port sayısı kadar collision domain üretir ve hepsini tek bir broadcast domain’in içinde bırakır.
• Ethernet rastgele erişim ailesinden gelir: ALOHA %18, dilimli ALOHA %37 verim verirken CSMA dinlemeyi, CSMA/CD ise konuşurken dinlemeyi ekledi; her adım bir israfı kapattı.
• 64 bayt bir veri kararı değil: çarpışmayı sezebilmek için çerçevenin, haberi geri dönene kadar sürmesi gerekiyordu ve 10 Mbit/s × 51,2 µs tam olarak 512 bit eder.
• Yedeklilik denetimsiz kurulmuyor: ikinci bir kablo döngü demektir ve Spanning Tree Protocol (yayılan ağaç protokolü) protokolü olmadan ağ kendi kopyalarında boğulur.

Anahtar artık kimin hangi kabloda olduğunu biliyor ve ağı senin adına parçalara ayırdı. Ama o kabloları kimse rastgele çekmedi. Binadaki her prizin bu kutuya nasıl ulaştığının bir düzeni var; peki o düzenin adı ne?

Bölüm 25: Ağ Topolojileri

Anahtarın portundan çıkan kabloyu eline al ve takip et. Kablo tavana çıkıyor, koridoru geçiyor, bir dolapta bitiyor. Binada döşenmiş hiçbir kablo oraya rastgele gitmiyor.

Her prizin anahtara nasıl bağlandığının bir adı, bir ölçüsü ve bir üst sınırı var. O sınırı kim koydu?

Kabloların dizilişi sinyalin yolunu vermiyor

Topoloji dediğinde aslında iki ayrı soruyu birden soruyorsun. Fiziksel topoloji kabloların nasıl döşendiğini anlatıyor ve fiziksel katmana düşüyor. Mantıksal topoloji sinyalin hangi yoldan aktığını anlatıyor; onun yeri bağ katmanı. Katmanlı mimaride bir katmanın diğerine ne vaat ettiği ayrı bir şeydi; aynı ayrım burada kabloyla sinyalin arasına düşüyor.

Bir ağın iki topolojisinin birbirine benzemesi diye bir zorunluluk yok, ve bu ilk bakışta şaşırtıcı geliyor. Kablolar yıldız gibi dizilmiş bir ağ, sinyal akışı bakımından halka ya da ortak yol gibi işleyebiliyor. 10BaseT tam olarak böyle: kablolama yıldız, akış veri yolu. Düzenin adı da ikisinden geliyor, star-bus.

Mantıksal tarafta karşına iki kalıp çıkıyor. Yayın topolojisinde gönderen sinyali ortama bırakıyor ve ilk gelen ilk hizmeti alıyor. Jetonlu geçişte iletme hakkı istasyonlar arasında dolaşan bir jetonla veriliyor. Ortamı kimin, ne zaman kullanacağını bu kalıp belirliyor.

Fiziksel tarafta klasik liste altı başlık: veri yolu, halka, yıldız, genişletilmiş yıldız, ağaç ve örgü. Altısını da eşit ağırlıkta öğrenmene gerek yok — ikisi tarihe karıştı, biri her yeri kapladı. Hangisinin kazandığını bugün masanın altına bakarak görebilirsin.

Ağı adlandıran ikinci ölçü: menzil

Şekil ağın nasıl kurulduğunu söylüyor. İkinci bir ölçü daha var ve o da ağın ne kadar uzağa yayıldığını söylüyor. Sahada duyduğun kısaltmaların çoğu bu ikinci ölçüden geliyor.

Tablonun ikinci sütunu kabaca doğru ama yanıltıcı. Sınırı çizen şey mesafe değil, sahiplik. Yerel ağda kabloyu sen döşüyorsun ve bir kez döşendikten sonra o kablodan ne kadar veri geçirdiğin kimseyi ilgilendirmiyor; kimse sana fatura kesmiyor. Geniş alan ağında ise hattı kiralıyorsun ve bant genişliği aylık bir faturaya dönüşüyor.

Bu tek fark, ağ tasarımının neredeyse tamamını açıklıyor. Yerel ağda bant genişliği bedava olduğu için israf edilebilir; sıkıştırmadan gönderirsin, yedeklemeyi gece yaparsın, gerekirse kabloyu bir üst kategoriyle değiştirirsin. Geniş alanda ise her bit para olduğu için sıkıştırmayı, önbelleklemeyi ve trafik önceliklendirmeyi mecburen kullanıyorsun. Yerel ağ hızlarının geniş alan hızlarını onlarca yıldır önde götürmesinin sebebi teknoloji değil, bu maliyet farkıdır.

Bir de bu eksene sığmayan bir tane var: depolama alanı ağı. Onu menzille değil taşıdığı yükle tanımlıyorsun; sunucuları disk dizilerine bağlıyor. Aynı odada duruyor ama yerel ağdan ayrı tutuluyor, çünkü disk trafiğinin gecikme toleransı ağ trafiğininkinden çok daha düşük.

Tek kabloya asılmak neden bitti?

Veri yolu topolojisinde bütün cihazları tek bir kabloya asıyorsun. O kabloya segment, omurga ya da trunk deniyor. Sinyal kendi başına hattın iki ucuna doğru ilerliyor. Üstünden geçtiği her istasyon adrese bakıyor ve kendisine değilse sinyali bırakıyor. Kart hedef adrese bakıyor, kendisine değilse gerisini okumadan atıyordu.

Kurulumu koaksiyel kabloyla yapıyordun. Her istasyona bir T-konnektör takılıyor, hattın ilk ve son ucuna sonlandırıcı bağlanıyordu. Sonlandırıcı dediğimiz şey, içinde 50 ohm’luk direnç bulunan bir BNC konnektör; takmayı unutursan ağ hiç çalışmıyordu.

Kırılganlığı kablonun kendisinde arayacaksın. Ana kablodaki tek bir kopma ağı ikiye bölüyor; parçalar kendi içinde konuşmayı sürdürüyor ama aralarındaki iletişim bitiyor. Arızanın yerini bulmak da kolay olmuyor.

Sınırlar da serttir. İnce koaksiyelle bir segmenti en çok 185 metre, kalın koaksiyelle 500 metre uzatabiliyordun. İnce koaksiyelde bir segmente en çok 30 istasyon bağlanıyor ve iki istasyon arasında en az 0,5 metre bırakılıyordu. Kalın koaksiyelde bir segment 100’den fazla cihaz taşımıyor, cihazlar da kabloya 2,5 metrenin katı olan noktalardan takılıyordu. Tekrarlayıcı, sinyali güçlendirip ileten birinci katman cihazı. Onlarla toplam menzil 2.500 metreye, kullanıcı sayısı 1.024’e çıkabiliyordu.

Adların kendisinde de bir şablon göreceksin.

10 Base 5
 |   |    +-- segment menzili, yaklaşık 500 metre
 |   +------- temel bant sinyalleşme
 +----------- 10 Mbit/s

10Base2’deki 2 ise 185 metreyi anlatıyor; yuvarlama cömert davranmış. Kalın koaksiyel kablo yaklaşık 1 cm kalınlığında ve sert olduğu için döşenmesi zordu. Sarı kılıfı yüzünden ona sarı Ethernet deniyordu.

Neden her şekil yıldıza döndü?

Halka topolojisinde veri, hedefine varana kadar her cihazdan geçiyor ve her cihaz sinyali güçlendirip bir sonrakine veriyor. Zayıflamanın bu yüzden en düşük düzeyde kaldığını göreceksin.

Söz sırası 3 baytlık bir jetonla dağıtılıyor. Jeton boştaysa veri ve hedef adres jetona yüklenip halkaya bırakılıyor. Jetonu olmayan cihaz konuşamıyor.

Asıl sürprizi kablolamada bulacaksın. Halka çalışırken halka gibi görünüyor ama kablolama fiilen yıldız: cihazlar merkezdeki MAU kutusuna bağlanıyor ve halka o kutunun içinde kuruluyor. IBM’in MSAU’sunda 10 bağlantı çıkışı vardı ve kutu, arızalanan istasyonu halkadan çıkarıp devreyi kapatıyordu. Ölçeği de fena değildi: UTP ile 72, STP ile 260 istasyona kadar çıkıyordu.

Token Ring IEEE 802.5 olarak standartlaştı ve 4 ya da 16 Mbit/s çalışıyordu. Halkanın hızını üstündeki en yavaş cihaz belirliyordu. Donanımı Ethernet’ten kat kat pahalı olduğu için yayılamadı.

Yıldızda her cihaz merkezdeki hub ya da anahtara kendi kablosuyla bağlanıyor. Bir cihazın merkeze uzaklığı en çok 100 metre olabiliyor. Bir bağlantının durumu da merkezdeki port ışığından okunuyor.

Arıza davranışı da veri yolunun tam tersine çalışıyor: uçtaki bir arıza yalnızca o ucu düşürüyor. Merkezdeki cihazın arızası ise tüm ağı durduruyor. Kırılganlık ortadan kalkmadı, tek noktada toplandı.

Bedeli kablo. Veri yoluna göre çok daha fazla kablo çekiliyor ve üstüne merkez cihazın maliyeti biniyor. Karşılığında kurulum, büyütme ve arıza bulma kolaylaşıyor. Hub’ın kendisi çok portlu bir tekrarlayıcı; kopyalama davranışını ve yerini anahtara neden bıraktığını biliyorsun. Bir ARP isteği bütün komşuların kartını uyandırıyordu; hub o uyandırmayı elektrik düzeyinde yapıyor. Yıldızı yayan şey bu ucuz kutu oldu.

Örgü topolojide bağlantı sayısı n(n-1)/2 ile büyüyor. 12 uçlu bir ağ 66 kablo istiyor; aynı 12 uç yıldızda 12 kabloyla bağlanıyor. Fark 5,5 kat. Karşılığı yedeklilik: bir bağlantı koptuğunda sinyal hedefine başka bir yoldan ulaşıyor. Örgü bu yüzden çoğunlukla geniş alan ağlarında kullanılıyor.

Ağaç topoloji veri yolu ile yıldızın birleşimi. Yıldız kümeleri bir omurga üstüne diziliyor ve tepede kök görevi gören bir cihaz duruyor. Bir segmentteki sorun diğerlerine bulaşmıyor ama omurgadaki arıza yine tüm ağı etkiliyor. Genişletilmiş yıldız ise küçük yıldızların yine yıldız biçiminde birbirine bağlanması. Bina kablolamasının gerçek şekli bu.

Numaraların ardındaki aile

Kitap boyunca 802 ile başlayan numaralar görüyorsun ve hepsi aynı yerden geliyor. IEEE’nin 802 numaralı komitesi yerel ve metropol alan ağlarının standartlarını yazıyor; her alt numara ayrı bir çalışma grubu.

Sahada bu numaraların kendisinden çok harfli uzantıları konuşuluyor, ve o harfler tek tek bir özellik anlatıyor: 802.1Q sanal ağ etiketi, 802.1X porta bağlanan cihazın kimlik doğrulaması, 802.1D ile ardılları döngü engelleme, 802.3af ve devamı kablodan güç besleme, 802.11’in harf dizisi de kablosuzun kuşakları.

İki şeye dikkat. Birincisi, bütün aile yalnızca iki katmanda yaşıyor: fiziksel ve bağ. 802 numarası bir teknolojiyi söyler, bir katmanı değil; hepsinin üstünde aynı IP çalışır. İkincisi, 802.2’nin ayrı bir numarası olması bir tasarım kararının izi. IEEE bağ katmanını ikiye böldü: alttaki yarı her teknolojide farklı, üstteki yarı hepsinde ortak olsun istedi. Ortak yarı beklenen ilgiyi görmedi ve Ethernet’te fiilen atlandı — ama bölünmenin kendisi, aynı üst katmanın onlarca farklı alt teknolojinin üstünde çalışabilmesinin sebebi.

Yüz metre nereden çıkıyor?

Structured cabling (yapısal kablolama), taşıma-ekleme-değiştirme döngüsünü ucuzlatmak için tasarlanıyor. Aynı altyapı masaüstünden IP telefona, kablosuz access point’e kadar her cihazı taşımak zorunda. Plansız büyümüş bir kablolama ise günün saatine ve trafiğe göre gelip giden arızalar üretiyor. Hatayı bulmak kabloyu ucundan ucuna takip etmek demek.

İki büyük standart var. Amerika’da ANSI/TIA-568 ailesi duruyor: C.0 genel kablolama, C.1 ticari bina, C.2 bakır twisted pair, C.3 fiber. Uluslararası düzeyde aynı işi ISO/IEC 11801 görüyor. TIA bileşeni kategori ile derecelendiriyor, ISO kanalı sınıf ile.

Standardın adlandırdığı altı parça var: bina giriş odası, ekipman odası, bina omurga kablolaması, telekomünikasyon odası, yatay kablolama ve iş alanı. Telekomünikasyon odasının sahadaki gündelik adı ise kat dolabı. Yatay kablolama o dolaptan iş alanındaki duvar prizine uzanıyor; parçaları priz, aradaki sabit kablo, dolaptaki patch panel ve panelle anahtar arasındaki patch kabloları.

Şimdi bütçe. Bakır twisted pair’in uçtan uca güvenle taşıdığı yol 100 metrede kesiliyor ve standardın işi o 100 metreyi paylaştırmak. Sabit kablo, standardın adıyla temel bağlantı, en çok 90 metre olabiliyor. Kalan 10 metre patch kablolarının payı: kat dolabındaki ekipman ve patch kabloları 6 metreyi, prizden bilgisayara giden patch kablosu 3 metreyi geçmemeli.

duvar prizi -> bilgisayar     3 m
kat dolabı  -> duvar prizi   90 m   sabit kablo, temel bağlantı
patch panel -> anahtar        6 m
-----------------------------------
kanal                        99 m   sınır 100 m

TIA iki ayrı ölçüm birimi tanımlıyor: temel bağlantı yalnızca duvar prizi ile dolaptaki sonlandırma arasındaki sabit kablo, kanal ise patch kabloları dahil uçtan uca giden yol. Sınırın kendisi de ölçüme dayanıyor. Ortalama bir ofis binasında masaüstlerinin ezici çoğunluğu en yakın kat dolabına 100 metreden yakın duruyor.

Prizden dolaba uzanan yolu parça parça görelim:

Geri kalan kurallar da sayıya bağlı. Her iş alanı için en az iki priz zorunlu ve bunlardan biri dört çiftli UTP olmak zorunda. Bina omurgası ise en fazla iki kademeli bir yıldızla sınırlı: ekipman odasındaki ana çapraz bağlantı ile kat dolabındaki yatay çapraz bağlantı arasında en çok bir ara nokta olabiliyor.

Bir binada en çok kablo yatay kablolamada bulunuyor. Tavanın ve duvarların içinden geçtiği için değiştirmesi omurgadan çok daha pahalı, ve en iyi malzeme bu yüzden yatay kabloya konuyor. Kategori de bant genişliği demek: Cat 5e 100 MHz, Cat 6 250 MHz, Cat 6A 500 MHz. TIA, 100 metrelik 10GBASE-T için en az Cat 6A istiyor; Cat 6 ile mesafe 37 ile 55 metreye iniyor.

Kabloyu burada yalnızca adıyla anıyorum. UTP’nin ucundaki RJ-45’in iki resmi sonlandırma şeması var: T568A ve T568B. Elektriksel olarak aynılar, fark sekiz telin renk sırasında. Kabloyu elimize kitabın sonlarında alacağız.

Özet

Peki, ne öğrendik?

• Topoloji iki ayrı sorunun cevabı: kabloların dizilişi fiziksel topoloji, sinyalin izlediği yol mantıksal topoloji, ve ikisi aynı ağda farklı olabilir.
• Veri yolu kendi sınırlarına çarptı: tek kablo, tek kopmada ikiye bölünen ağ, 185 ile 500 metrelik segmentler ve yeri zor bulunan arızalar.
• Halka fiilen bir yıldızdı: jeton halkanın içinde dolaşıyordu ama kablolar merkezdeki kutuya gidiyordu.
• Yıldız kırılganlığı merkeze topladı: uçtaki arıza tek bir ucu düşürüyor, merkezdeki arıza her şeyi durduruyor, bedeli de fazladan kablo.
• Structured cabling (yapısal kablolama) bir bütçe: bakırın 100 metrelik kanalı, 90 metrelik sabit kablo ile 10 metrelik patch payı arasında bölüşülüyor.

Binanın şekli oturdu, anahtar da kat dolabında yerinde duruyor. Aynı anahtara bağlı iki bilgisayar aynı ağda olmak zorunda mı?

Bölüm 26: Sanal Yerel Ağlar

Structured cabling’in (yapısal kablolamanın) yıldız düzeninde her priz kat dolabındaki anahtara bağlanıyordu. Geriye bir soru kalıyor: aynı anahtara takılı iki bilgisayar aynı ağda olmak zorunda mı?

Zorunda değil. Tek bir anahtar, birbirini hiç görmeyen ağları aynı anda taşıyabiliyor. Peki bunu neyle yapıyor?

Aynı kutuda kaç ağ var?

ARP isteği, broadcast domain’deki bütün komşuların kartını tek tek uyandırıyordu. Yayın yalnızca ARP değil. DHCP de, hedefi henüz öğrenilmemiş her çerçeve de aynı yolu izliyor. Hepsi LAN’ın tamamını dolaşıyor, bant genişliğini yiyor ve herkese herkesin trafiğini duyuruyor.

Sanal yerel ağ, yöneticinin çizdiği bir port kümesi ve o kümenin dışına taşmayan bir broadcast domain. Sınır tek bir kutunun içinde de durabiliyor, birkaç anahtara da yayılabiliyor. Çizgiyi donanım çekmiyor; anahtarın çerçeveyi hangi porta ileteceğine karar veren yazılım çekiyor. Kutunun içine bakarsan ikiye bölünmüş bir şey göremezsin.

Port tabanlı ayrımda arayüzleri gruplara bölen kişi ağ yöneticisi oluyor ve her grup bir VLAN sayılıyor. Sonuç trafik yalıtımı: bir gruptaki porttan çıkan çerçeve yalnızca aynı gruptaki portlara ulaşıyor. Yirmi dört portlu bir anahtarı ikiye bölmek, onu iki bağımsız on iki portlu anahtara ayırmakla aynı sonucu veriyor. Öğrenilen adresler de ayrılıyor. Bir VLAN’da görülen MAC, öbürünün tablosuna hiç yazılmıyor.

Grubu belirleyen ölçüt coğrafya olmaktan çıkıyor. Bir port, üstündeki makinenin hangi ekibe ya da hangi uygulamaya hizmet ettiğine göre VLAN’a giriyor. Eskiden bunun tek yolu makineleri aynı kat dolabına toplamaktı. Şimdi bir çalışan ekip değiştirdiğinde kablolamaya dokunulmuyor; üçüncü katman adresi bile aynı kalıyor. Değişen tek şey, portun hangi VLAN’a ait olduğu.

Ölçek tarafında da kazanç var. Altı küçük grubun her birine ayrı bir anahtar almak yerine kırk sekiz portlu tek bir kutu hepsini alabiliyor. VLAN’sız o kutu yalıtım vermez.

Yönetici her portu bir VLAN’a bildiriyor ve anahtarın içinde bir port-VLAN eşleme tablosu birikiyor. Bildirilmemiş portlar varsayılan VLAN’a düşüyor; yerel VLAN diye de anılıyor. Orası ölü bir alan değil. Anahtar kendi yönetim adresini ve komşularıyla konuştuğu keşif trafiğini orada tutuyor. Yani boş bıraktığın port, çalışan bir ağın ucunda açık duruyor.

Üyelik illa porta bağlı da değil. Statik üyelikte portu VLAN’a katan yönetici; dinamik üyelikte kararı anahtar veriyor. Takılan makinenin MAC adresine, mantıksal adresine ya da konuştuğu protokole bakıyor. MAC tabanlı üyelikte cihaz hangi porta takılırsa takılsın kendi VLAN’ına düşüyor.

Bu tabloda muhasebe masası laboratuvar makinesini hiç görmüyor. Aynı kutuya takılı olmaları bir şey değiştirmiyor.

İki anahtarı nasıl bağlarsın?

Ağ tek kutuda bitmiyor. İki anahtarda da aynı VLAN’lar varsa, aralarına VLAN başına bir kablo çekmek işe yarıyor. Ama ölçeklenmiyor. N tane VLAN, yalnızca iki anahtarı birbirine bağlamak için her anahtarda N port yiyor.

Ölçeklenen çözümün adı trunk portu. İki anahtarda birer port trunk olarak ayarlanıyor ve aralarına tek bir hat çekiliyor. Trunk’ta VLAN ayrımı yok; hangi VLAN’ın çerçevesi olursa olsun o tek hattan geçiyor. İki VLAN’lı bir kurulumda kablo sayısı ikiden bire iniyor: %50 tasarruf.

Uç cihazın takıldığı, tek bir VLAN’a ait ve etiketsiz çalışan porta erişim portu deniyor. İkisi arasındaki fark çerçevenin üstünde görünüyor.

Trunk’tan geçen çerçeve sıradan bir Ethernet çerçevesi olamaz. Üstünde hangi VLAN’a ait olduğu yazmak zorunda. Anahtar, çerçeveyi hatta vermeden önce ona küçük bir alan basıyor; karşı uçtaki anahtar o alanı okuyup söküyor. Etiketi ekleyen de söken de anahtar. Uç cihaz onu hiç görmüyor. Bu işin standart adı IEEE 802.1Q.

802.1Q 1998’de yayımlandı ve VLAN’ı üreticiden bağımsız hâle getirdi. Ondan önce etiketleme üreticiye özel yollarla yapılıyordu ve ortama göre ayrışmıştı: Fast Ethernet’te ISL, FDDI’da 802.10, ATM’de LAN Emulation. ISL veriyi kapsülleyip başına 26 baytlık bir başlık, sonuna 4 baytlık bir CRC ekliyordu. 30 bayt ek yük, 802.1Q etiketinin yedi buçuk katı.

VLAN listesinin kendisi de anahtarlar arasında dolaşabiliyor. Bir kutuyu sunucu kipine alıp listeyi orada tutuyorsun; aynı yönetim alanındaki diğerleri listeyi ondan çekiyor. Kolaylık, ama bütün ağı tek noktadan bozma yetkisi de aynı yerde.

Trunk kararının kendisi de pazarlığa açık. Bir portun trunk olup olmayacağı beş kipten biriyle ayarlanıyor ve otomatik kipteki bir port, karşı taraf istekliyse kendiliğinden trunk’a dönüşüyor. Sızma testi kitaplarının atlama saldırısı dediği şey buradan besleniyor: saldırgan kendini komşu bir anahtar gibi tanıtan bir pazarlık mesajı yolluyor, takılı olduğu erişim portunu trunk’a çevirtiyor, sonra istediği VLAN kimliğini kendi çerçevesine yazıp o broadcast domain’in içine düşüyor.

Saldırı iki ihmalin üstünde yürüyor: portun pazarlığa açık bırakılması ve varsayılan VLAN’ın dokunulmadan durması. İkisini de kapatmak zor değil. Kullanılmayan bir port ya elektriksel olarak kapatılır ya da hiçbir yere çıkmayan tek bir VLAN’a sabitlenip pazarlık dışı bırakılır.

Dört bayt nereye giriyor?

Etiket 4 bayt ve çerçevenin başına girmiyor. İki adres alanının ardından, tür alanının önüne sokuluyor. Kapsüllemede her başlık kendi yükünün önüne ekleniyordu. 802.1Q bu düzeni bozuyor.

hedef MAC      6 bayt
kaynak MAC     6 bayt
--- 802.1Q etiketi, 4 bayt --------------------------------
TPID           2 bayt   sabit 0x8100
TCI            2 bayt   3 bit öncelik + 1 bit + 12 bit kimlik
-----------------------------------------------------------
tür alanı      2 bayt
veri          46-1500 bayt
FCS            4 bayt   etiketten sonra yeniden hesaplanır

İlk iki bayta etiket protokol tanımlayıcı deniyor ve değeri hep aynı kalıyor: onaltılık 8100. Bu değeri gören alıcı, elindeki çerçevenin etiketli olduğunu anlıyor.

Sonraki iki bayt etiket denetim bilgisi. O 16 bitin 12 biti VLAN kimliği, 3 biti öncelik; geriye 1 bit kalıyor. On iki bitlik alan 4.096 farklı değer ayırt ediyor. Kullanılabilir numara sayısı 4.094; ayrılan iki değeri IEEE 802.1Q metni söylüyor. Cisco dönemi bir cihazda tanımlanabilen aralık ise 1 ile 1001 arasıydı. O, standardın sınırı değil, cihazın sınırıydı.

Öncelik bitleri 802.1p’nin hizmet sınıfı bitleri: üç bit, sekiz düzey, sıfırdan yediye. IP başlığındaki hizmet türü alanının bu kattaki karşılığı sayılabilir. Bir portta öncelik açıksa, tıkanma anında önce yüksek öncelikle işaretlenmemiş çerçeveler düşürülüyor.

Etiket eklendikten sonra çerçevenin sonundaki FCS yeniden hesaplanıyor; sebebi CRC’nin çerçevenin tamamını kapsaması. Boy da değişiyor: etiketsiz azami çerçeve önsöz hariç 1.518 bayt, etiketli 1.522 bayt. Veri alanı ise sabit: 46 ile 1.500 bayt arası.

1.522 bayt standarda IEEE 802.3ac ekiyle 1998’de girdi. 2006’daki 802.3as eki, bütün etiketleme biçimleri için sınırı 2.000 bayta çekti; zarf çerçeve azami boya 482 bayt daha ekliyor.

Etiketin asıl bedeli en küçük çerçevede görünüyor: etiketsiz asgari 64 bayt, etiketli 68 bayt. Dört baytın küçük çerçevede neden ağır bastığını FCS’nin payını hesaplarken görmüştün.

Etiketli bir çerçeve, etiket bilmeyen bir istasyona düşerse ne oluyor? O istasyon başlıkta tanımadığı bir tür değeri buluyor ve çerçeveyi sessizce düşürüyor. Böyle bir çerçevenin oraya varması da pek olmuyor, çünkü etiketi yalnızca bunun için ayarlanmış cihazlar basıyor.

Anahtarın MAC öğrenme tablosunu doldurması ve döngüyü kesen spanning tree tanıdık. Spanning tree ağaç da VLAN başına ayrı işliyor. Çoklu spanning tree 802.1s ekiyle 2003’te tanımlandı, 802.1Q’nun 2005 baskısına girdi ve her bölge 64’e kadar ayrı örnek çalıştırabiliyor.

İki VLAN nasıl konuşur?

Ayırmak kolay oldu. Ayırdıklarını tekrar konuşturmak üçüncü katmana çıkmayı gerektiriyor. Ayrı broadcast domain, ayrı IP alt ağı demek. Muhasebe 192.0.2.0/24 olsun, laboratuvar 198.51.100.0/24. Aradaki her datagramın, iki alt ağı da tanıyan bir cihaza uğraması gerekiyor. Sanki ortada bağlantısız iki anahtar var.

Yönlendiricide her VLAN için ayrı bir fiziksel arayüz tutmak pahalı. Tek arayüzün üstünde alt arayüz açılıyor; her birine ayrı bir alt ağ ve ayrı bir VLAN numarası veriliyor. Böylece tek bir kablo, kaç VLAN varsa o kadar mantıksal bacak taşıyor.

Yönlendirici çerçeveyi alıyor, etiketi söküp hangi alt ağa ait olduğunu buluyor, kararını verdikten sonra hedef VLAN’ın etiketini takıp aynı porttan geri yolluyor. Üreticiler ikisini tek kutuda birleştirip satıyor.

Bunu kendi makinende de görebilirsin. Linux’ta bir arayüzün üstüne etiketli bir alt arayüz eklemek üç satır sürüyor.

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.0.2.10/24 dev eth0.10
ip -d link show eth0.10

Son komutun çıktısında vlan protocol 802.1Q id 10 satırını görüyorsun. O arayüzden çıkan her çerçeve artık etiketli.

Özet

Peki, ne öğrendik?

• Sanal yerel ağ bir port kümesidir: anahtarın iletim yazılımı, aynı kutunun içinde birbirini görmeyen broadcast domain’ler kurar.
• Etiket dört bayttır: iki bayt sabit tanımlayıcı, iki bayt da kimlik ile önceliği taşıyan denetim alanıdır.
• Trunk tek hattır: bütün VLAN’lar aynı kablodan geçer, etiketi ise yalnızca iki uçtaki anahtarlar görür.
• VLAN’lar arası geçiş yönlendirmedir: ayrı alt ağlar ancak üçüncü katmana çıkıp geri dönerek konuşabilir.
• Boş port boş değildir: hiçbir VLAN’a bildirilmemiş bir arayüz, anahtarın yönetim trafiğini taşıyan varsayılan VLAN’da bekler.

Aynı kabloda birden çok ağ taşımayı çözdük; ayrımı dört baytlık bir etiket ile anahtarın iletim kararı yapıyor. Kablosuz bağlıysan ortada kablo yok; çerçeve o boşlukta nasıl gidiyor?

Bölüm 27: Kablosuz Erişim: 802.11

Dizüstünü toplayıp bahçeye çıktın. Çerçeve hâlâ aynı çerçeve, taşıdığı istek hâlâ aynı istek. Değişen tek şey şu: onu artık bakır bir tel değil, aradaki boşluk taşıyor.

Boşluğun da kuralı var. Ama kabloda işleyen kural burada yürümüyor: kimsenin çarpışmayı göremediği bir ortamda çarpışma nasıl önlenir?

Kablo yoksa hangi kural değişiyor?

Metal kablo elektrik akımı taşır. Havadaki taşıyıcı ise belirli bir frekanstaki elektromanyetik dalga.

Kablosuz LAN sıfırdan bir ağ da değildir. Var olan LAN teknolojisinin fiziksel katmanı ve bağ katmanının bir kısmı kablosuzlaştırılmıştır. IP ve üstü hiç değişmez. Değişen yalnızca 802.11’in MAC katmanı ile onun fiziksel katmanıdır. Yani kapsülleme merdiveninin en alt basamağı sökülüp yerine yenisi takılıyor, üstündeki basamaklar aynen kalıyor.

Bu sınır standardın kendi kapsamında da yazılı. IEEE 802 ailesinin tamamı yalnızca iki katmanı düzenler: bağ katmanı ile fiziksel katman. Ailede 802.3 CSMA/CD’ye ayrılmış, 802.11 kablosuz ağa. IEEE bu işe 1997’de başladı; ilk sürüm 2,4 GHz’de 2 Mbit/s için tasarlanmıştı. O gün bu hız bir DSL bağlantısıyla aynı mertebedeydi.

Kablosuz, ortamı paylaşan yayın bağlantılarının en saf örneği. Paylaşılan ortamın temel kuralı tek cümleyle yazılır: göndermeden önce hattı dinle, boşsa gönder, doluysa boşalmasını bekle. Bu kuralın adı CSMA.

Dinlemek tek başına yetmiyor. Birkaç makine aynı anda hattı boş görüp aynı anda gönderebilir. Üstelik çarpışma göndericinin başına gelen bir şey de değildir. Alıcının aynı anda iki ya da daha fazla sinyali üst üste almasıdır.

Anahtar her kabloyu ayrı bir collision domain’e çeviriyordu; paylaşılan kabloda ise CSMA/CD göndericiye kendi çarpışmasını sezdiriyordu. Telsizde o adım yok. Bir gönderici aynı anda hem gönderip hem dinleyemiyorsa çarpışmayı kendisi göremez, göremediğini de ortasında kesemez.

Ethernet CSMA/CD kullanır, 802.11 ise CSMA/CA. Biri çarpışmayı sezer, öteki ondan kaçınır.

Duymadığın komşu seni nasıl bozuyor?

Havada sinyal gittikçe zayıflar. Bu zayıflamanın adı yol kaybı: elektromanyetik dalganın vericiden alıcıya giderken güç yoğunluğunun düşmesi. Düşüşün hızı ortama bağlı. Yol kaybı üssü boş uzayda 2, şehir içinde 2,7 ile 3,5 arasında, bina içinde 3 ile 6 arasında. Duvarlar sinyali mesafeden daha hızlı yiyor.

Şimdi bir evi düşün. Telefon mutfakta, dizüstü balkonda, access point ikisinin ortasındaki koridorda. Mutfaktaki telefon balkondaki dizüstünü hiç duymuyor; arada iki duvar var ve mesafe yol kaybını büyütüyor. İkisi de kanalı dinlediğinde boş buluyor, çünkü kendi açılarından kanal gerçekten boş. Ama iki sinyal koridordaki access point’te üst üste biniyor. Bu duruma gizli terminal deniyor.

Kanalı boş sanmanın iki sebebi var. Karşı tarafın sinyali sana henüz ulaşmamıştır. Ya da sönümlenme yüzünden hiç ulaşmıyordur.

Koordinasyon için ayrı bir bant da yok. Kanalın nasıl paylaşılacağına dair anlaşma, paylaşılan kanalın kendisinden yapılmak zorunda. Dalganın kendi davranışını, yani yol kaybının hesabını burada kasten bırakıyorum.

Sıranı nasıl bekliyorsun?

802.11 göndericisi kanalı bir kerede boş görmekle yetinmez. DIFS adı verilen bir süre boyunca kesintisiz boş görmek zorundadır. Kanal o süre boyunca sessizse çerçevenin tamamı gönderilir. Gönderim yarıda kesilmez.

Alıcı çerçeveyi sağlam aldıysa SIFS kadar bekler ve bir ACK döner. Bu onay gizli terminal yüzünden zorunlu; gönderici çerçevesinin vardığını başka türlü bilemez.

Kanal doluysa gönderici hemen sıraya girmez. Rastgele bir geri çekilme sayacı başlatır. Sayaç yalnızca kanal boşken geri sayar. Kanal dolduğunda durur, boşalınca kaldığı yerden devam eder. Sıfıra indiğinde gönderim yapılır. Böylece sırasını bekleyen cezalandırılmaz.

ACK gelmezse gönderici çarpışma varsayar. Geri çekilme aralığını ikiye katlar ve baştan dener. Pencerenin üst sınırı fiziksel katmana göre 200 ms mertebesine kadar çıkabiliyor. Burada kabul edilmiş bir körlük var. 802.11’de kayıp ile çarpışma aynı belirtiyi verir ve ikisi birbirinden ayrılamaz.

Gizli terminali asıl çözen mekanizma rezervasyon. Gönderici önce küçük bir RTS paketiyle kanalı ayırtır. Access point CTS ile cevap verir ve bu cevabı yayın olarak gönderir. CTS’i duyan herkes, gönderici hariç, kendi gönderimini erteler. Balkondaki dizüstü mutfaktaki telefonu duymuyordu ama koridordaki access point’i duyuyor.

RTS ve CTS’in içinde, ardından gelecek gönderimin ne kadar süreceği yazılıdır. Susma süresi bir tahmin değil, ilan edilmiş bir sayıdır. RTS paketleri de çarpışabilir; kısa oldukları için kaybedilen zaman küçük kalır.

Veri çerçevesi gidip ACK döndüğünde cihaz çerçeveyi kendi kuyruğundan siler. Erişim noktası çerçeveyi ancak ondan sonra yönlendiriciye iletir.

Kanalı dinlemekten onaya kadar giden sırayı adım adım izleyelim:

Ağa ilk adım nasıl atılıyor?

Bütün bunlar cihaz ağa çoktan girmişken olup bitiyor; girmenin kendisi ayrı bir iş. Access point’le kurulan ilk bağlantı tek başına internet demek değildir. Üstünde kimlik doğrulama ve DHCP çalışır; tam erişim ancak ondan sonra gelir.

Ağı bulmanın iki yolu var. Pasif yolda cihaz kanalları dinler ve ağın varlığını ilan eden beacon çerçevelerini toplar. Aktif yolda cihaz kendisi bir yoklama isteği yayınlar, menzildeki access point’lerin hepsi yoklama cevabı gönderir. Uygulamada ikisi birden kullanılır.

Seçim yapıldıktan sonra cihaz seçtiği access point’e bir ilişkilendirme isteği yollar ve karşılığında ilişkilendirme cevabı alır. Bu aşamada henüz hiçbir kimlik ya da parola alışverişi yok. Sorulan tek şey, konuşup konuşamayacakları.

Kablosuz ağlar iki yapıda kurulur. Access point olmadan kurulanına ad-hoc kipi denir, teknik adı IBSS. Access point üzerinden yürüyene altyapı kipi denir, teknik adı temel hizmet kümesi. Evdeki modem ile ona bağlı cihazlar bir BSS. Aynı alt ağda aynı SSID’yi taşıyan birden çok BSS birleşince genişletilmiş hizmet kümesi çıkar ortaya.

Altyapı kipinde istemciler birbirleriyle doğrudan konuştuklarını sanır. Bütün paketler erişim noktasından geçer; access point kablosuz tarafta bir hub gibi davranır. Tek bir anahtar, VLAN etiketiyle birbirini hiç görmeyen ağları taşıyabiliyordu; burada tersi oluyor ve tek bir erişim noktası herkesi aynı ortama basıyor.

İlişkilendirme bittiğinde artık havaya çerçeve koyabilirsin. O çerçevenin zarfı Ethernet’inkinden geniş duruyor. İçinde dört adres alanı var ve her biri 6 bayt.

çerçeve denetimi   2 bayt        sürüm, tür, alt tür, sekiz bayrak
süre               2 bayt        RTS/CTS ile ayrılan gönderim zamanı
adres 1            6 bayt        çerçeveyi alacak taraf
adres 2            6 bayt        çerçeveyi havaya koyan taraf
adres 3            6 bayt        access point'in bağlı olduğu yönlendirici arayüzü
sıra denetimi      2 bayt        çerçeve sıra numarası
adres 4            6 bayt        yalnızca ad hoc kipinde
yük                0-2312 bayt   IP datagramı
CRC                4 bayt        bozulma denetimi

Üçüncü adres bu listenin kilidi. Kabloda iki MAC adresi alanı yetiyordu; havada üçüncüsü gerekir, çünkü çerçevenin kablolu tarafta nereye çıkacağı da yazılmak zorunda.

Çerçeve denetim alanı bit bit bölünmüştür: 2 bitlik protokol sürümü, 2 bitlik tür, 4 bitlik alt tür, ve ardından birer bitlik sekiz bayrak. Tür alanı üç değer alır: 0 yönetim, 1 denetim, 2 veri. Wi-Fi’da veri çerçevesi türlerden yalnızca biri. Alt tür alanı beacon ile ACK’i birbirinden ayırır. Denetim ve yönetim çerçeveleri ağın kendi işleyişini taşır ve okura hiç görünmez.

Zarfın bedelini hesaplayalım. Dört adres birden kullanıldığında başlık ve CRC toplam 34 bayt tutar, altyapı kipinde dördüncü adres boş kaldığı için 28 bayt; Ethernet’in sabit zarfı ise 18 bayt. Aradaki fark on bayt ve bunun altı baytı doğrudan üçüncü adres alanından geliyor. En büyük yük 2.312 bayt olduğuna göre en büyük çerçeve 2.346 bayt eder. Zarfın payı yüzde bir buçuk civarında kalır.

Peki bu çerçeve hangi frekansta gidiyor? 2,4 GHz bandı ülkeye göre 11 ile 14 arasında kanala bölünmüştür ve bu sayı teknik değil düzenleyici bir karardır. 20 MHz genişliğinde birbiriyle örtüşmeyen kanal sayısı ise yalnızca üç. Aynı apartmanda dördüncü bir access point açıldığı anda birinin kanalı zorunlu olarak bir başkasıyla örtüşür. Aynı lisanssız ISM bandında mikrodalga fırın, bebek telsizi, Bluetooth kulaklık ve garaj kapısı kumandası da çalışır; girişim bu bandın doğal hâli.

Havadaki çerçeveyi ağa dahil olmayan herhangi bir kablosuz cihaz da dinleyebilir; ortam paylaşıldığı için izleme riski baştan var. Altyapı kipinde iletişimin şifrelenmesinin sebebi bu. WEP’ten WPA2’ye, oradan 2018’de gelen WPA3’e uzanan mirasın nasıl işlediğini iki durak sonra açacağız.

Bağlandığın ağın künyesini kendi makinende görebilirsin. Linux’ta iw dev wlan0 link bağlı olduğun BSSID’yi, SSID’yi, frekansı ve sinyal gücünü basar. iw dev wlan0 scan ise beacon ve yoklama cevaplarından toplanan ağ listesini verir. Windows’ta aynı işi netsh wlan show interfaces ve netsh wlan show networks mode=bssid görür.

$ iw dev wlan0 link
Connected to 00:00:5e:00:53:0b (on wlan0)
        SSID: kat3-koridor
        freq: 2437
        signal: -58 dBm

İlk satırdaki adres, havaya koyduğun çerçevelerin birinci adres alanına yazdığın değerdir.

Özet

Peki, ne öğrendik?

• Değişen tek şey ortam: kablosuz LAN yeni bir ağ kurmaz, var olan LAN’ın fiziksel katmanını ve MAC’inin bir kısmını kablosuzlaştırır.
• Çarpışma alıcıda olur: gönderici aynı anda gönderip dinleyemediği için kendi çarpışmasını göremez, ve gizli terminal bu körlüğü kalıcı hâle getirir.
• CSMA/CA beklemeyi kurala bağlar: DIFS boyunca dinlemek, donan bir geri çekilme sayacı ve SIFS sonrasında dönen ACK, çarpışma sezmenin yerini alır.
• RTS/CTS bir rezervasyondur: susulacak süre kanalın üstünden ilan edilir, çünkü koordinasyon için ayrılmış başka bir bant yoktur.
• Dört adres zarfı genişletir: altyapı kipinde 28 bayta çıkan zarfın farkı, çerçevenin kablolu tarafta nereye çıkacağını taşıyan üçüncü adresten gelir.

Kanalın boşalmasını bekledin, sıranı aldın, çerçeveyi havaya bıraktın ve onayını geri aldın. Sıra kanalın kendisinde: oraya tam olarak kaç bit sığıyor, ve bunu ne belirliyor?

Bölüm 28: Radyo Kanalı ve Kapasite

Kanal boşaldı, çerçeveyi gönderdin. O havaya kaç bit sığdığını ise geçen sefer söylemedim.

Sığan bit sayısını üç şey belirliyor: kanalın genişliği, modülasyonun derinliği ve kaç antenle konuştuğun. Peki bu üç ayarı kim çeviriyor?

Bir kanala kaç bit sığıyor?

Bir kanalın taşıyabileceği en yüksek hızın adı Shannon kapasitesi. Girdisi yalnızca iki tane: kanalın bant genişliği ve sinyal-gürültü oranı. İkincisini kısaca SNR diye anacağım.

SNR bir oran ve desibelle yazılıyor: alınan sinyal gücünü gürültü gücüne bölüyorsun, onluk logaritmasını alıp onla çarpıyorsun. 0 dB ikisinin eşit güçte olması demek. Aynı ölçek mutlak güç için de çalışıyor. 1 mW’a bölünmüş hâline dBm deniyor; tipik bir mobil vericinin tepe gücü 250 mW, yani 24 dBm.

İki girdi aynı biçimde davranmıyor ve aradaki fark bütün radyo tasarımını belirliyor. SNR sabitken kapasite bant genişliğiyle doğrusal büyüyor. SNR tarafı ise logaritmik çalışıyor: gücü artırmanın getirisi belli bir noktadan sonra neredeyse kayboluyor. Hız arayan radyo bu yüzden önce banda bakıyor, sonra güce.

Sayıya dökelim. 20 MHz’lik bir kanalda 25 dB SNR ile Shannon kapasitesi 166 Mbit/s çıkıyor. Kanalı 40 MHz’e çıkarıp SNR’yi sabit varsayarsan sonuç 332 Mbit/s oluyor, tam iki kat.

O varsayımın tutmadığı yer tam olarak burası. Gürültü gücü bant genişliğiyle doğru orantılı; kanalı genişletmek sinyalle birlikte gürültüyü de içeri alıyor. Bandı ikiye katlamanın SNR maliyeti 3 dB; desibel ölçeğinde 3 dB tam iki kat demek ve 10 × log10(2) bunu veriyor. 25 dB düşüp 22 dB’ye iniyor ve 40 MHz’deki gerçek sonuç 293 Mbit/s oluyor. İki kat değil, 1,76 kat.

Kanal genişliği basamakları 20, 40, 80, 160 ve 320 MHz. 20 MHz’den 160 MHz’e sekiz kat spektrum var, 320 MHz’e on altı kat. Her basamakta aynı üç desibellik vergi de ödeniyor.

Vergiyi sonuna kadar işlet: 20 MHz’den 160 MHz’e üç ikiye katlama var, toplam 9 dB. SNR 25 dB’den 16 dB’ye düşüyor ve kapasite 856 Mbit/s çıkıyor. Sekiz kat spektrum karşılığında 5,15 kat hız aldın. Basamak çıktıkça getiri eriyor.

Shannon’un verdiği sayı zaten teorik bir üst sınır. Pratikte ulaşılan hız her zaman bunun altında kalıyor.

Bir sembol kaç bit taşıyor?

Genişlik hikâyenin yarısı. Öteki yarısı, o kanalda gönderilen her sembolün kaç bit taşıdığı.

Modülasyon, taşıyıcı bir sinüs dalgasının genliğini, frekansını ya da fazını değiştirerek bit taşımak demek. Temel üç yöntemin adı ASK, FSK ve PSK. Üstlerinde QPSK ve QAM duruyor. QPSK aynı taşıyıcı frekansında dört ayrı faz kullanıyor ve veri hızını BPSK’ya göre ikiye katlıyor. Frekans değişmiyor, sembolün taşıdığı bit sayısı değişiyor.

Aynı fikri iki eksene birden yayan biçimin adı m-QAM ve m tane farklı genlik-faz bileşimi tanımlıyor. Bileşim sayısı her ikiye katlandığında sembol bir bit daha taşıyor; taşınan bit sayısına modülasyon derinliği deniyor.

Bir sembol pratikte 2 ile 8 bit arasında taşıyor. Alıcı tarafta iş bir yuvarlamaya iniyor. Gelen sinyalin genliğini ve fazını ölçüyor, sonra en yakın sembole yuvarlıyor. Bit hatası tam olarak bu yuvarlamanın yanlış komşuya düşmesi. Derinlik arttıkça noktalar birbirine yaklaşıyor ve yanlış komşu daha kolay kazanıyor.

Her basamağın bir SNR faturası var ve fatura hızla büyüyor. 16-QAM’in eşiği yaklaşık 12 desibel, 64-QAM’inki 18, 256-QAM’inki 24. Aradaki düzen sabit: sembol başına iki bit eklemek, kabaca altı desibel daha temiz bir kanal istiyor. Desibel çarpan ölçüsü olduğu için altı desibel dört kat daha güçlü bir sinyal demek. Derinliği bir basamak artırmanın bedeli, hızın kazandığından çok daha dik yükseliyor.

Derinlik bu yüzden sabit seçilmiyor. Uyarlamalı modülasyon, SNR değiştikçe şemayı ve gücü uçuş sırasında değiştiriyor ve kabul edilebilir hata oranındaki en yüksek hızı arıyor. Aynı kanalda, aynı anda, 16-QAM 11,5 Mbit/s verirken 64-QAM 26,9 Mbit/s veriyor. Tek değişen sembol başına bit.

Wi-Fi radyoları için pratik alt sınır 20 dB SNR; hücresel radyolar -10 ile -6 dB kadar aşağıda çalışabiliyor. O sınır 64-QAM’in faturasını karşılıyor, 256-QAM’inkini karşılamıyor. Tavan da kuşakla yükseldi: 802.11n’de 64-QAM olan üst sınır 802.11ac’de 256-QAM’e çıkarıldı. Modülasyonun matematiğini burada kesiyorum; dalga biçimlerini ve türetmeyi 48. bölümde açacağım.

Havayı kiminle paylaşıyorsun?

SNR’yi düşüren şey her zaman mesafe olmuyor. Wi-Fi lisanssız bantta çalışıyor: kurallara, özellikle güç sınırlarına uyan herkese açık. Komşunun ağı da bu yüzden senin havanı paylaşıyor ve bunun için senden izin almıyor.

2,4 GHz’in kaç kanala bölündüğünü ve o bandı hangi cihazlarla paylaştığını saymıştık; çıkış yolu yukarı taşınmak. 802.11ac 5 GHz’de birbiriyle örtüşmeyen 23 kanal buluyor. Seçilebilir kanal sayısı da bantla büyüyor: 5 GHz’de 150’yi, en son eklenen 6 GHz’de 250’yi aşıyor. Bunun bedeli menzilden ödeniyor; hesabını spektrumu açtığımızda yapacağım.

Anahtar her portu ayrı bir collision domain’e çevirip ortamı bölüyordu. Havada böyle bir bölme yok. İkinci bir access point eklemek de yardım etmiyor; yalnızca aynı SSID’yi taşıyan bir küme kuruyor. Aynı üçüncü katman alt ağındaki bu kümenin adı genişletilmiş hizmet kümesi. İçinde access point değiştirirken IP adresin değişmiyor, çünkü 802.11 hareketliliğe bağ katmanından bakıyor. Dolaşımı hızlandıran mekanizmalardan ikisi standartta tanımlı: hızlı yeniden kimlik doğrulama, ve access point’in cihaza yeni access point’ler önerebilmesi. Üstüne bir de üreticiye özel çözümler biniyor.

Kanal nasıl bölüşülüyor?

Kanal tek bir taşıyıcı değil. İçi, alt taşıyıcı denen ince şeritlere bölünmüş durumda.

Klasik frekans bölmeli çoklamada bu şeritler birbirine karışmasın diye aralarına koruma bandı konuyor. Koruma bandı harcanmış spektrum demek: taşıyıcı yok, bit yok, boşluk var. OFDM o boşluğu kaldırıyor. Alt taşıyıcılar dikey seçiliyor; hafifçe üst üste binseler de her alt taşıyıcının merkezinde komşusunun etkisi sıfırlanıyor. Koruma bandına gerek kalmıyor.

Şerit sayısı kanalın genişliğine bağlı. 4G’de 5 MHz’lik bir kanalda 300 alt taşıyıcı var, 20 MHz’de 1.200. Alt taşıyıcı aralığı 15 kHz, bir sembol 66,6 µs sürüyor; iki sayı birbirinin tersi.

Bir kullanıcıya atanabilen en küçük parçanın adı kaynak bloğu: 12 alt taşıyıcı üzerinde 7 sembollük bir dilim. Frekans ekseninde 180 kilohertz, zaman ekseninde yarım milisaniye tutuyor. 20 megahertzlik bir kanal bu bloklardan yüz tane çıkarıyor ve hepsi orta derinlikte dolduğunda taşıyıcının tepe hızı yüz megabit mertebesine geliyor.

Baz istasyonu hangi bloğun hangi cihaza gideceğine 1 ms’lik aralıklarla karar veriyor. Kanal tek bir kullanıcıya sonuna kadar bırakılmıyor. Devre anahtarlama hattı tek konuşmaya ayırıyor, paket anahtarlama ise talebe göre bölüştürüyordu. Buradaki ızgara aynı fikrin frekans eksenli hâli.

Bu bölüştürmenin protokol adı OFDMA ve onu 4G, 5G ile Wi-Fi 6 kullanıyor. OFDM’den farkı eksen sayısı: OFDM yalnızca frekansta bölüyor, OFDMA aynı ızgarayı zamanda da bölüyor. Kanalın boşalmasını bekleyen CSMA/CA, sırayı tek bir gönderene veriyordu. OFDMA aynı anda birden çoğuna veriyor. Wi-Fi tarafında bir ek adım var. Access point gönderimden önce MU-RTS yolluyor; içinde hangi cihazın hangi kaynak birimini dinleyeceği yazılı. Her alıcı da kendisine atanmış alt kanaldan CTS ile cevap veriyor.

Wi-Fi 6 ve 7 access point’ler yine de OFDM konuşmak zorunda, çünkü eski cihazlar OFDMA bilmiyor. Geriye uyumluluğun bedeli bu.

Izgaranın frekans ve zaman eksenlerinde nasıl bölündüğünü görelim:

Kaç antenle konuşuyorsun?

Üçüncü ayar anten sayısı. MIMO, aynı anda birden çok anten üzerinden göndermek demek. Tek kullanıcılı hâlinde yaygın yapılandırma iki gönderici ve iki alıcı antenle 2x2.

Aynı donanım iki ayrı işe koşulabiliyor. Uzamsal çeşitleme aynı bilgiyi farklı yollardan paralel gönderiyor. Hız artmıyor; artan şey güvenilirlik ve menzil, çünkü bütün yolların aynı anda bozulması olası değil.

Radyo sinyali nesnelerden yansıyıp alıcıya farklı zamanlarda varıyor; buna çok yollu yayılım deniyor. Çeşitleme bunu kusur saymıyor, kaynak sayıyor. Anten eklemek iki uç arasındaki yol sayısını artırıyor. İki antenli gönderici ile iki antenli alıcı arasında on iki ayrı yol sayılabiliyor. Alıcı bu kopyaları birleştirince SNR yükseliyor ve buna anten kazancı deniyor.

Uzamsal çoklama ise aynı yolda aynı anda farklı veri akışları gönderiyor. Hızı gerçekten katlayan bu. 64-QAM ile dört akışta sembol başına 24 bit taşınıyor. Tavanı zorla: 802.11ac’nin sekiz akışı 256-QAM ile sembol başına 64 bit taşıyor. Aynı sembolde 2x2 ve 64-QAM 12 bitte kalıyor. Kanal genişliği ikisinde de aynı, fark 5,33 kat.

Kazancın bedeli alıcıda ödeniyor. Karışmış gelen akışları ayırmak için denklem çözmek gerekiyor ve katsayılar zamanla değişen rastlantısal büyüklükler. Ayrıştırma her zaman temiz çıkmıyor.

Çok kullanıcılı MIMO’da access point aynı anda farklı cihazlara gönderiyor. Anten sayısı sabitken kapasite kullanıcılar arasında bölünüyor. İş hüzme biçimlendirmeye dayanıyor ve cihazların coğrafi olarak ayrışmış olmasını gerektiriyor. Aynı masada oturan iki telefonda kazanç kayboluyor. Anten sayıları da kuşakla arttı: 802.11n 4x4’e, 802.11ac 8x8’e kadar destekliyor ve MU-MIMO ilk kez o kuşakta geldi.

Yirmi beş yılda teorik tepe hız 11 Mbit/s’den 30 Gbit/s’e, yaklaşık 2.727 kat arttı. Tablodaki sayılar teorik tavan; gündelik hız hep altında. Denemelerden bildirilen sayılar ise bu tavanın üstüne bile çıkabiliyor: 802.11ax için 5 GHz bandında 10,53 Gbit/s ölçüldüğü bildirildi. Bu sayıya hangi yapılandırmada ulaşıldığı kaynakta yazmıyor; ikisi aynı ölçüde karşılaştırılamaz. Wi-Fi 7’nin standart adı IEEE 802.11be ve 26 Eylül 2024’te onaylandı. Sıradaki kuşak IEEE 802.11bn, hedef yayım Mart 2028.

Hangi ayarların şu an açık olduğunu kendi makinende görebilirsin. Windows’ta netsh wlan show interfaces çıktısı radyo türünü, bandı, kanalı ve o anki alma-gönderme hızını yan yana veriyor.

Radio type            : 802.11ac
Band                  : 5 GHz
Channel               : 44
Receive rate (Mbps)   : 866.7
Transmit rate (Mbps)  : 866.7
Signal                : 84%

Aynı satırların Linux tarafındaki karşılığını iw dev wlan0 link veriyor. iw dev wlan0 station dump bir adım ileri gidiyor. Hızın yanına o hızı üreten üç ayarı da yazıyor.

tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2

Satırdaki üç alan bu bölümün üç sorusu. 80MHz kanal genişliği, VHT-MCS modülasyon derinliği, VHT-NSS ise akış sayısı. Hızın gün içinde oynadığını görürsen sebebi bu bölümün tamamı. Kanal yerinde duruyor, derinlik değişiyor.

Özet

Peki, ne öğrendik?

• Kapasitenin iki girdisi var: Shannon bant genişliğini ve SNR’yi alır, ve bandı büyütmek doğrusal kazandırırken gücü büyütmek logaritmik kazandırır.
• Genişletmenin vergisi gürültü: gürültü de bantla büyüdüğü için 20 MHz’den 40 MHz’e geçmek hızı iki katına değil 1,76 katına çıkarır.
• Derinliği kanalın kalitesi seçer: her sembol 2 ile 8 bit arasında taşır, ve uyarlamalı modülasyon bu sayıyı uçuş sırasında değiştirir.
• Aynı kanal aynı anda bölüşülür: OFDMA ızgarayı kaynak bloklarına ayırır, MIMO ise aynı bloğun üstünde birden çok akış taşır.

Kanalın kaç bit taşıdığını artık uçtan uca sayabiliyorsun. O bitler havada ilerlerken menzildeki her radyo onları duyuyor. Peki duyan neden okuyamıyor?

Bölüm 29: Kablosuz Ağ Güvenliği

Menzildeki her radyo o çerçeveyi duydu. Duymak ile okumak arasındaki farkı yaratan şey mesafe değildir; bağlanırken üretilmiş ortak bir sırdır.

O sır hiçbir zaman havaya çıkmadı. Peki iki taraf ona nasıl vardı?

Şifrelenen tam olarak ne?

Ağa yeni giren bir cihazın üç işi var ve üçü de sen parolayı yazdıktan sonra, saniyenin içinde bitiyor: access point’le ilişkilendirilecek, ağla karşılıklı kimlik doğrulayacak, çerçevelerini şifreleyecek. Üçüncüsü sanıldığından geniş. Şifrelemenin yalnızca kullanıcı verisini kapsadığını sanma; doğrulama sırasında giden çerçeveleri de içine alıyor.

Pazarlık bir keşif adımıyla başlıyor: access point beacon yayınlıyor, ya da cihazın kendisi bir yoklama isteği gönderiyor. Bu iki yol ağı bulup ilişkilendirmeye kadar götürüyordu; aynı çerçeveler bir menü de taşıyor. Access point sunduğu kimlik doğrulama ve şifreleme biçimlerini ilan ediyor, cihaz da içlerinden birini istiyor. Dikkat et: o anda cihaz henüz doğrulanmış değil ve anahtar iki tarafta da yok.

Wi-Fi kartını izleme kipine alıp yanından geçen her çerçeveyi kaydetmeyi öğrenmiştin. Menzilde duran bir yabancı da aynı şeyi senden izin almadan yapar; kaydedilen trafik şifreliyse eldeki dosya anlaşılmaz kalır.

Şifrelemenin açık olup olmadığını frame control alanındaki tek bitlik WEP bayrağından okuyabilirsin. Başlığın kendisi korunmuyor: dört adres alanı açıkta gidiyor, şifrelenen kısım yalnızca yük. Her adres alanı 6 bayt; üç adresli bir başlık toplamda 24 bayt tutar. Şifrelenen yük ise 0 ile 2.312 bayt arasında değişir. Dinleyen biri içeriği okuyamaz, kimin kiminle konuştuğunu yine de görür. Kanal genişliği ve modülasyon derinliği taşınan bit sayısını belirliyordu; şifreleme o sayıya dokunmaz.

Bütün bu işler tek bir soy ağacında duruyor: WEP’ten WPA’ya, oradan WPA2’ye ve WPA3’e. En eski adın açılımı hedefini de söylüyordu. WEP, kablolu ortamla eşdeğer bir mahremiyet vaat ediyordu. Eski access point kataloglarında güvenlik satırı 64, 128 ve 152 bitlik WEP seçenekleriyle reklam ediliyordu. Güvenlik bir kutu özelliğiydi. WPA ile WPA2 2004’te geldi, WPA3 ise 2018’de. Aradaki on dört yıl boyunca WPA2 el sıkışması sahadaki tek seçenek olarak kaldı. Bir güvenlik protokolü için uzun bir süre bu, ve o sürenin sonunda ne olduğunu birazdan göreceksin.

Parola hattan geçmeden anahtar nasıl doğuyor?

Evinde ve küçük bir ofiste çalışan kipin adı kişisel kip. Access point’e tek bir parola girilir ve bütün cihazlar onu paylaşır. Parolayı yalnızca cihaz ile access point bilir. Parola bağlantıdan önce cihazlarda bulunduğu için bu düzenin adı önceden paylaşılan anahtar.

WPA2-PSK doğrulaması iki aşamadan oluşur ve aşamalar birbirinden bağımsız çalışır. Birinci aşamada istemci bir 802.11 Authentication çerçevesi gönderip Open System ister. Adı kimlik doğrulamaya benziyor ama sana parola sormuyor. Access point Status Code alanına Successful yazıyor ve iş bitiyor. O başarı damgasına aldanma; hiçbir sırrın doğrulandığı anlamına gelmiyor.

Birinci aşama bittiğinde cihaz ilişkilendirilmiştir, ama gerçek doğrulama hiç olmamıştır. İkinci aşama 802.1X üstünde koşar ve yalnızca o oturuma ait taze bir AES anahtarı üretir. Adı dört adımlı EAPOL el sıkışması. EAPOL, genişletilebilir kimlik doğrulama protokolünün yerel ağ üstünde taşınan biçimi.

Sırayı adım adım izleyelim. Access point ilk nonce’u gönderiyor. İstemci paylaşılan sır ile o nonce’u birleştirip bir MIC (bütünlük kodu) üretiyor ve kendi nonce’unu ekliyor. Access point kodu doğruluyor, karşı tarafın canlı olduğunu ölçüyor ve AES oturum anahtarını üretiyor. İstemci de kodu doğruluyor, onayını gönderiyor ve anahtarı kuruyor. Paylaşılan sır iki işe birden yarıyor: şifrelemeye ve bu MIC’in (bütünlük kodunun) üretilmesine.

Nonce’lar kaydedilmiş bir mesajın yeniden oynatılmasını da engelliyor. Her oturuma yeni bir anahtar üretmek, paylaşılan sırra kaba kuvvet uygulamayı zorlaştırıyor. El sıkışma bittiğinde anahtarı iki tarafta hazır buluyorsun, ama paylaşılan sır hiçbir zaman hatta çıkmamış oluyor. Üretilen anahtar AES’e ait. Simetrik şifrelemenin anahtar dağıtımı sorunu tanıdık; burada o anahtarı elden veren bir merci yok, iki tarafın ortak parolası var.

Bağlanma izini paket paket sayabilirsin: beacon’dan son ACK’e kadar dokuz paket geçiyor ve bunun son dördü EAPOL el sıkışması. Adres alma sırası ondan sonra geliyor, çünkü kimlik doğrulanmadan DHCP bile çalışamıyor.

El sıkışmanın kendisi de bir açık taşıyordu

WPA2’nin dört adımlı el sıkışması on üç yıl boyunca sağlam sayıldı. 2017’de bulunan kusur şifrede değil, sıralamadaydı.

Üçüncü mesaj yolda kaybolabiliyor. Protokol bunu öngörmüş: access point cevap gelmezse aynı mesajı yeniden gönderiyor. İstemci de her aldığında anahtarı yeniden kuruyor — ve anahtarı yeniden kurmak, yanındaki sayaçları da sıfırlamak demek.

Sayaç kipinin en tehlikeli hatası tanıdık: aynı anahtarla aynı sayacı iki kez kullanmak, iki şifreli metnin XOR’unun iki açık metnin XOR’unu vermesi demek. Saldırgan üçüncü mesajı kaydedip yeniden oynattığında tam olarak bunu tetikliyor. Anahtar kırılmıyor, tahmin edilmiyor, hesaplanmıyor; yalnızca ikinci kez kullanılıyor. Saldırının adı da bunu söylüyor: anahtarın yeniden kurulması.

Düzeltmeyi protokolde değil gerçeklemelerde arayacaksın; istemciler aynı anahtarı ikinci kez kurmayı reddeder hâle getirildi. Yani telde giden mesajlar aynı kaldı, değişen şey o mesajlara verilen tepki oldu.

Geçiş kipi eski açığı geri getiriyor

WPA3’e geçişin de bir pürüzü var ve bu kez kusur uyumlulukta. Bir access point hem WPA3 hem WPA2 kabul edecek şekilde ayarlanabiliyor; adı geçiş kipi ve amacı eski cihazları dışarıda bırakmamak.

Sorun şu: hangi kipin kullanılacağına istemci ile access point el sıkışmanın başında karar veriyor, ve o pazarlık henüz korunmuyor. Araya giren biri istemciyi WPA2 tarafına düşürebiliyor. Bu olduğunda birazdan göreceğin bütün WPA3 kazanımları — özellikle kaydedilmiş el sıkışmadan parolayı deneme imkânının kapanması — geri geliyor.

WPA3 el sıkışmayı nasıl değiştirdi?

WPA3’ün getirdiği asıl değişim el sıkışmanın kendisinde. WPA2’nin dört adımı menzilde duran biri tarafından kaydedilebiliyordu. Kayıt eldeyse parola havuzunu denemek ağla hiç konuşmadan, saldırganın kendi makinesinde yapılır; bunun adı çevrimdışı sözlük saldırısı. WPA3’ün kullandığı SAE, Dragonfly ailesinden geliyor: parolayla doğrulanan ve bu saldırıya dayanıklı bir anahtar değişimi. Ailenin tanımı RFC 7664’te yazılı; belgeyi Harkins kaleme aldı, IRTF’in CFRG grubu Kasım 2015’te yayımladı.

Değişim iki adımda kuruluyor. Commit adımında iki taraf da parolaya dair tek bir tahmine bağlanır. Birer skaler ve eleman üretip değiş tokuş eder, ortak sırrı hesaplar. Confirm adımında ise aynı sırrı türettiklerini, dolayısıyla aynı parolaya sahip olduklarını birbirine kanıtlarlar. Her taraf birer Commit ve birer Confirm gönderdiği için değişim dört çerçeve eder. Diziliş WPA2’nin dört adımına benziyor, üretilen şey benzemiyor.

Ortak sır tek parça da bırakılmaz. Bir doğrulama anahtarı ile bir ana anahtar olmak üzere ikiye gerilir. Skaler ve eleman üretildikten sonra ara değer geri dönülemez biçimde yok edilmek zorundadır. Karşı taraf aynı skaler ve elemanı olduğu gibi geri gönderirse bu bir yansıtma saldırısı işaretidir. Değişim orada durur.

İki tarafın parolayı hiç göndermeden nasıl anlaştığını izleyelim:

Kurumsal kipte parola nereye gitti?

Kurumsal kipte parola kullanıcı başına ayrışır ve kimlik olarak sertifika da kullanılabilir. Protokol iki taraf yerine üç taraf arasında koşar: cihaz, access point ve RADIUS gibi bir kimlik doğrulama sunucusu. Access point bu konuşmada neredeyse tamamen bir aktarıcıdır. Kimlik bilgileri istemci ile sunucuda durur, access point’te değil.

Bu düzenin adı 802.1X, resmî adı ise port tabanlı ağ erişim denetimi. Adında ne kablosuz ne parola geçer. Kablolu ve kablosuz yerel ağa ortak bir kimlik denetimi getirmek için tasarlandı. Erişim portunu baştan kapalı sayan aynı denetim kabloda da vardı; burada kapı bekçisi erişim noktasında duruyor.

Kimlik denetleyici ayrı bir kutu değildir; anahtarın ya da access point’in üstlendiği bir roldür. İstemciden gelen kimlik yanıtını alır, bir RADIUS Erişim İsteği paketine kapsülleyip sunucuya iletir. Aynı EAP verisi iki ayrı zarfla taşınır: cihazla access point arasında EAPOL, access point’le sunucu arasında RADIUS. Sunucunun işi kimlik doğrulamayı, yetkilendirmeyi ve hesap kaydını tek merkezde toplamaktır.

Doğrulamayı istemci de başlatabilir. Bir EAPOL-Start çerçevesi gönderir, doğrulayıcı kimlik isteğiyle yanıt verir. Oturumu kapatırken EAPOL-Logoff gider ve port yeniden yetkisiz duruma düşer. EAP’in kendisi kimlik doğrulamaz; yöntemleri taşır. Tanımlanmış yaklaşık 40 yöntem var ve aralarındaki fark kullandıkları kimlik malzemesi: parola, sertifika, SIM kartı ya da donanım tokeni. Adlar bunu söyler; EAP-TLS sertifikaya dayanır, EAP-SIM telefonun SIM kartına. İstemci önerilen yöntemi reddedip kendi listesini önerebilir ve bu pazarlık adımının adı NAK.

EAP-TTLS iki aşamada çalışır ve RFC 5281’de tanımlanır. Önce istemci sunucuyu doğrular ve aralarında bir TLS tüneli kurulur. Sonra sunucu istemciyi o şifreli tünelin içinde doğrular, ardından tünel yıkılır. Parola hiçbir zaman açıktan geçmez. Oturum anahtarı el sıkışma sırasında kuruluyordu; burada aynı tünel tek bir parolayı taşımak için kuruluyor.

Sonucu sunucu access point’e bildirir ve kanal şifrelemesi için gereken malzemeyi de ona gönderir. Kurumsal kipte de sonunda aynı dört adımlı el sıkışma koşar, ama artık kimlik için değil kanalı şifrelemek için.

Access point’in ilan ettiği menüyü kendi makinende de görebilirsin. Linux’ta nmcli -f SSID,SECURITY,CHAN dev wifi list menzildeki her ağın yanına o satırı basar.

$ nmcli -f SSID,SECURITY,CHAN dev wifi list
SSID              SECURITY      CHAN
kat3-koridor      WPA2          6
lab-3b            WPA3          36
kampus-net        WPA2 802.1X   11

Üçüncü satırdaki 802.1X işareti o ağın kurumsal kipte koştuğunu söyler.

Özet

Peki, ne öğrendik?

• Şifrelenen kısım yüktür: başlıktaki adres alanları açıkta gittiği için dinleyen biri içeriği okuyamasa bile kimin kiminle konuştuğunu görür.
• İlişkilendirme kimlik doğrulama değildir: Open System isteğine dönen Successful damgası hiçbir sırrın doğrulandığını göstermez.
• Anahtar oturuma özeldir: dört adımlı el sıkışma paylaşılan sır ile nonce’ları birleştirip her bağlantıya yeni bir AES anahtarı üretir, sırrı hatta hiç koymaz.
• SAE tahmini pahalılaştırır: Commit ile Confirm üstüne kurulan değişim, kaydedilmiş bir el sıkışmadan parola havuzunu denemeyi işe yaramaz hâle getirir.
• Kurumsal kipte kimlik başka yerde durur: access point aktarıcıdır, karar kimlik doğrulama sunucusundadır ve el sıkışma yalnızca kanalı şifrelemeye yarar.

Evdeki ağın kapısını kimin, neyle ve hangi sırayla açtığını artık biliyorsun. Sokağa çıkınca o kapı arkanda kalıyor. Peki hiçbir kablosuz ağ yokken telefonun neye bağlanıyor?

Bölüm 30: Hücresel Ağlar

Evden çıktın. Sokakta yürüyorsun, telefonun hâlâ bağlı ve ortada tanıdığın hiçbir ağ adı yok.

Bağlandığın şey bir hücre: kilometrelerce öteye kadar planlanmış bir örgünün tek bir gözü. Peki o hücre seni nasıl tanıdı?

Hücre neden hücre?

Operatör kapsayacağı coğrafyayı dairesel ya da altıgen alanlara böler. Her alanın ortasına, komşularından bağımsız çalışan bir düğüm koyar. O düğümün adı baz istasyonu, alanın adı hücre.

Baz istasyonu bir cihaz türü değil, bir rol. Kendi alanındaki kablosuz uçlarla kablolu ağ arasında paket taşır. Evdeki 802.11 access point de aynı rolü oynar. Aradaki farkı alanın büyüklüğü yaratıyor. İç mekânda kablosuz menzil 10 ile 30 m arasında kalır, hücre kulesi ise 4 ile 15 km arasında bir alanı kapsayabilir. Operatör bu alanları yan yana dizerek onlarca kilometreyi örter ve onlarca Mbit/s mertebesinde hız verir.

Menzil merdiveninde arada iki basamak daha var. Kısa mesafeli dış mekân bağlantısı 50 ile 200 m arasında kalır, orta mesafeli olan 200 m ile 4 km arasında. Hücrenin hangi basamağa kurulacağını kapsanacak alan ve oradaki cihaz yoğunluğu belirler. Şehir merkezinde hücre küçülür, kırda büyür.

Küçük hücrenin asıl sebebi kapsama değil, kapasite

Buraya kadar hücreyi bir kapsama aracı gibi anlattım. Değil. Bir operatör isterse şehrin ortasına tek bir yüksek kule dikip yüz kilometrekareyi tek seferde örtebilirdi. Bunu yapmamasının sebebi başka ve bütün hücresel fikri o sebepten doğdu.

Operatörün elinde sabit bir spektrum dilimi var; diyelim 20 MHz. Tek bir dev kule kurarsan o 20 MHz’i şehirdeki herkes paylaşır. Frekans sonlu, abone sonsuz.

Hücresel fikir tek bir hamleyle bunu tersine çeviriyor: gücü düşür, kapsamayı küçült, ve aynı frekansı uzaktaki başka bir hücrede yeniden kullan. Sinyal zaten mesafeyle sönümlendiği için, yeterince uzaktaki iki hücre birbirini duymuyor. Şehirde 100 hücre varsa ve her frekans 14 ayrı yerde tekrar kullanılabiliyorsa, toplam kapasite 14 katına çıkıyor. Spektrum hiç büyümedi; yeniden kullanıldı.

Bedava değil. İki hücre aynı frekansı kullandığında birbirine gürültü olur; buna ortak kanal girişimi deniyor. Bu yüzden aynı frekans komşu hücrede kullanılamıyor, belli bir uzaklık bırakmak gerekiyor.

Bu uzaklığı belirleyen sayının adı küme boyu (N): kaç hücrelik bir grubun, spektrumun tamamını aralarında bölüştüğü. Her hücreye toplam kanalın 1/N’i düşüyor ve aynı desen şehir boyunca tekrarlanıyor.

Altıgen bir ızgarada N rastgele bir sayı da olamıyor. Deseni boşluk bırakmadan tekrarlayabilmek için yalnızca belli değerler işe yarıyor: 3, 4, 7, 9, 12, 13, 19 ve devamı. Sahada en yaygın seçim yedi.

Küme büyüdükçe aynı frekansı kullanan iki hücre birbirinden uzaklaşıyor. Yedi hücrelik bir kümede o uzaklık, hücrenin yarıçapının kabaca dört buçuk katı oluyor — yani bir frekansı yeniden kullanabilmek için dört beş hücre ötesine gitmek gerekiyor.

Şimdi ödünleşim çıplak. N küçüldükçe kapasite artıyor, girişim de artıyor. N = 3 her hücreye spektrumun üçte birini verir ama ortak kanal hücreleri iyice yakınlaşır; N = 12 temiz bir sinyal verir, karşılığında her hücre spektrumun on ikide birine razı olur. Şebeke planlamacısının işi tek bir cümleye iniyor: girişimin kabul edilebilir olduğu en küçük N’i bulmak.

İkinci kapasite hamlesi anteni bölmek. Baz istasyonuna her yöne yayan tek bir anten yerine, 120 derecelik üç yönlü panel koyarsın; her panel kendi frekans grubunu kullanır ve tek bir kule üç ayrı hücre gibi davranır. Buna sektörleme deniyor. Bir kulede üç panelin farklı yönlere baktığını gördüysen, o üç panel kapasiteyi üçe katlayan tasarımın kendisi.

Talep yine de aşarsa üçüncü hamle var: hücreyi ikiye bölmek. Gücü düşürüp yarıçapı yarıya indirirsen aynı alana dört kat hücre sığar. Şehir merkezindeki hücrelerin niçin bu kadar küçük olduğunun cevabı bu — kapsama yetmediği için değil, kapasite yetmediği için.

Bir düzeltme. Yukarıdaki klasik plan 2G ve 3G’nin dünyasıdır. 4G ve 5G çoğu zaman N = 1 ile çalışır: bütün hücreler aynı frekansı kullanır. Girişim ortadan kalkmadı; onunla baş etme yöntemi değişti. Komşu baz istasyonları hangi zaman-frekans bloklarını kime vereceklerini birbirleriyle koordine ediyor, hatta bazen aynı cihaza birlikte gönderiyor. Yani planlama, kâğıt üstündeki bir frekans deseninden gerçek zamanlı bir zamanlama kararına taşındı.

Hücrelerin toplamına radyo erişim ağı deniyor, kısaca RAN. Kenar ağdır: cihazı baz istasyonuna bağlar, kapsamı coğrafyayla sınırlıdır ve tek bir servis sağlayıcının denetimindedir. Verdiği hizmet bağ katmanı hizmetidir. Cihaz ile daha büyük ağ arasındaki ilk sıçrama orasıdır.

3GPP’nin adlandırması sabit ve bu bölümde onu kullanacağım. Cihaz User Equipment (UE), radyo kanalı New Radio (NR), baz istasyonu gNodeB (gNB).

Telefonun tarafında iş tek bir radyoya da düşmez. Bir telefonda yaklaşık on bir ayrı radyo bulunur; beşi hücreseldir, kalanı Wi-Fi, Bluetooth, UWB, uydu, NFC ve GPS içindir. Hücresel bağlantı ayrıca tam çift yönlü çalışır. Veri gönderirken aynı anda karşı yönden veri alırsın.

Baz istasyonunun arkasında ne var?

Baz istasyonu tek başına bir ağ değil. Arkasında çekirdek ağ durur; bağlantılardan, yönlendiricilerden ve sunuculardan oluşur, hem cihazlara hem baz istasyonlarına hizmet verir. Sayı ilişkisi de tek yönlü işliyor: çekirdek ağ tek, RAN ise çok sayıda.

5G çekirdeğinin en görünür tasarım kararı düzlem ayrımı; adı CUPS. Denetim düzlemi kimin bağlandığına ve hangi yolun kurulacağına karar verir. Kullanıcı düzlemi yalnızca paket taşır.

Paketi taşıyan işlevin adı Kullanıcı Düzlemi İşlevi (UPF). Her cihaza bir UPF atanır ve o UPF cihazla internet arasında röle gibi çalışır. Politika uygulama, yasal dinleme, trafik kullanım ölçümü ve QoS denetimi orada oturur. Kotanı sayan yer orasıdır.

UPF ile baz istasyonu arasındaki arayüzün adı N3. Trafik o arayüzde tünellenir: IP datagramı bir UDP paketinin içine girer, o paket de bir başka IP paketinin içine. Kapsülleme her katmanda bir başlık ekliyordu; tünel aynı işi bir kat fazlasıyla yapıyor. Kullanıcı düzlemi tünelinin adı GTP-U.

Denetim düzlemindeki işlevlerin de adı var. Erişim ve Hareketlilik Yönetimi İşlevi (AMF) bağlantı, erişilebilirlik ve hareketlilik yönetimini, erişim yetkilendirmesini ve konum hizmetlerini üstlenir. Oturum Yönetimi İşlevi (SMF) her cihaz oturumunu yönetir; IP adresini de o tahsis eder. AUSF cihazları doğrular, UDM ise kullanıcı kimliğini ve kimlik doğrulama gizlerini üretip yönetir. Bu bölümlemenin tarifi 3GPP TS 23.501’de duruyor.

Kart seni nasıl tanıtıyor?

Kartın işi ad taşımak değil, sır taşımak. SIM kartı ya da sanal SIM seni ve ev ağını dünyadaki bütün hücresel ağlara tanıtır. İçinde yalnızca ev ağının bildiği bir kriptografik anahtar vardır. Ziyaret ettiğin ağda alacağın hizmet de ev ağındaki ücretli aboneliğine bağlıdır.

Kimliğin havada açık gitmez. TS 33.501’e göre abonenin kalıcı kimliği SUPI’dir ve ev ağının açık anahtarıyla şifrelenip SUCI olarak taşınır. Kartın fabrikadan gelen adını gizlemek için adres rastgeleleştirme çıkmıştı; burada aynı sorun şifrelemeyle çözülüyor.

Yordamın adı 5G-AKA ve iki yönlü çalışır. Kayıt sırasında ziyaret edilen AMF, cihazın ev ağındaki AUSF’unu bulur ve oraya şifreli, doğrulanmış bir TLS tüneli açar. Oradaki UDM, kartın anahtarıyla bir kimlik doğrulama jetonu ve nonce üretip imzalar. Aynı anda cihazın üretmesi beklenen yanıtı önceden hesaplayıp saklar.

Cihaz da boş durmaz. Kartındaki paylaşılan gizle, jetonun gerçekten kendi ev ağından geldiğini doğrular. Doğrulama bittiğinde ev ağındaki AUSF bir anchor key (çapa anahtarı) üretip ziyaret edilen ağa gönderir; cihaz aynı anahtarı kendi başına hesaplar. Ziyaret edilen ağ kartın kendi anahtarını hiç görmez.

Wi-Fi parolası, SAE el sıkışması sırasında ele verilmeden doğrulanıyordu. Hücresel ağda aynı işi kartın içindeki anahtar yapıyor.

Ağa katılmak iki aşamalı. Önce kayıt gelir, yani karşılıklı kimlik doğrulama. Sonra PDU oturumu kurulur: cihaza IP adresi tahsis edilir ve veri düzlemi yolu açılır.

İkisinden de önce bir taşıyıcı gerekir. Cihaz radyo bağlantısını bir RRC connection setup isteği ve yanıtıyla açar. Kimlik bilgisi henüz o adımda gitmez.

Telefonun hücreye tutunma sırasını baştan sona izleyelim:

Radyo zamanı kime bölüşülüyor?

Baz istasyonunun elindeki kaynak zaman ve frekanstan ibaret. OFDMA kanalı bir zaman-frekans ızgarasına bölüyordu ve o ızgaranın en küçük dağıtım birimi kaynak bloğuydu. Hücresel ağda o bloğu dağıtan baz istasyonudur.

Ölçeği somut bir kanalda görmek daha kolay. 10 MHz’lik bir kanalda 50 kaynak bloğu vardır ve her blok 180 kHz’lik bir alt kanalı kaplar. Elli blok 9 MHz eder. Kalan 1 MHz koruma bandına ve denetim taşımasına gider.

Dağıtım kararı sürekli yenilenir. Baz istasyonu hangi bloğun hangi cihaza gideceğine 1 ms aralıklarla karar verir. Bu, saniyede 1.000 zamanlama kararı demek.

Blokların genişliği alt taşıyıcı aralığına bağlı. 4G’de o aralık 15 kHz’de sabittir. 5G’de 15, 30, 60 ve 120 kHz arasından seçilir; 30 kHz seçilirse bir blok 360 kHz’lik alt kanalı kaplar. Taşıyıcının kendi genişliğinin kuşakla nasıl büyüdüğünü bir sonraki durakta açacağım.

Tek taşıyıcı yetmediğinde taşıyıcılar birleştirilir. Taşıyıcı toplama 3GPP Release 10 ile LTE-Advanced’e girdi. En çok beş bileşen taşıyıcı toplanır, her biri en çok 20 MHz, toplamda 100 MHz.

Dağıtımı cihaz da besliyor. Aldığı referans sinyalinin kalitesini ölçer ve baz istasyonuna 4 bitlik bir Kanal Kalite Göstergesi (CQI) değeri bildirir. O değer kullanılacak modülasyonu ve beklenen verimi belirler.

Kararı veren yazılım baz istasyonunun radyo yığınında oturur ve iş bölümü nettir. PDCP IP başlıklarını sıkıştırır ve şifreler. RLC çerçeveyi parçalayıp ARQ ile güvenilir kılar. MAC tamponlar, çoklar ve o 1 ms’lik zamanlama kararını verir. O-RAN yaklaşımı bu yığını üç parçaya böler: Central Unit, Distributed Unit ve Radio Unit.

Standart yığının arayüzlerini ve üst düzey işlevlerini sabitler. Kaynak bloğu atamasının ve çerçeve zamanlamasının nasıl yapılacağını ise operatöre bırakır. İki operatörün aynı bantta farklı hissettirmesinin sebebi orada.

Bağlantı ayakta kalırken ne oluyor?

Radyonun bedeli pilde ölçülür. LTE radyosu verici ya da alıcı konumdayken 1000 mW ile 3500 mW arasında çeker. Kapalıyken tüketim 15 mW’ın altına iner, yani açık durumun %1 ile %2 arasına.

Bu fark uykuyu zorunlu kılar. Cihaz DRX uykusundayken gelen trafik, geçerli DRX döngüsü bitene kadar baz istasyonunda tamponlanır. Uzun uyku enerji kazandırır, gecikme ekler. Kuyruk gecikmesi, paketin sırada beklediği süreydi. DRX o kuyruğu kasten uzatıyor.

Bir de yürürken olan var. Bağlanma noktan değiştiğinde veri akışı kaynak baz istasyonundan hedefe geçiyor. Bu devrin adını ve kopmadan nasıl yürüdüğünü iki durak sonra açacağım.

Bağlandığın hücrenin künyesini kendi makinende görebilirsin. Linux’ta ModemManager kuruluysa mmcli -L takılı modemleri listeler, mmcli -m 0 ise kayıt durumunu, operatör adını ve sinyal kalitesini basar.

$ mmcli -m 0
  Status   |          state: connected
           |    power state: on
           | signal quality: 58% (recent)
  3GPP     |  operator name: ornek-operator
           |   registration: home

Son satırdaki home, kartın kendi ev ağında olduğunu söyler. Orada roaming yazsaydı anchor key’i üreten ağ ile seni taşıyan ağ farklı olurdu.

Özet

Peki, ne öğrendik?

• Hücre bir plandır: dairesel ya da altıgen alanların her birinde bağımsız bir baz istasyonu durur ve o istasyon, kablosuz uçlarla kablolu ağ arasında paket taşıyan bir roldür.
• Çekirdek ağ işi ikiye böler: CUPS ile denetim düzlemi kimin bağlanacağına ve yolun nasıl kurulacağına karar verir, kullanıcı düzlemindeki UPF ise trafiği N3 üzerinden tünelleyip internete çıkarır.
• Kimliği kart taşır: karttaki anahtarın kopyası yalnızca ev ağında bulunur, kalıcı kimlik havada SUCI olarak şifreli gider ve ziyaret edilen ağ o anahtarı hiç görmez.
• Zaman kaynak bloğuyla dağıtılır: 180 kHz’lik bir blok 1 ms aralıklarla bir cihaza verilir; hangi bloğun kime gideceğine ise operatörün yazılımı karar verir.
• Uyku bir ödünleşimdir: radyo kapalıyken tüketim açık durumun yüzde biri ile ikisi arasına iner, karşılığında gelen trafik baz istasyonunda bekler.

Hücre seni tanıdı, kartını doğruladı ve sana zaman dilimi ayırdı. Peki bütün bu trafik hangi frekansta gidiyor, ve o frekansı kim dağıtıyor?

Bölüm 31: Spektrum ve Kuşaklar

Telefonun bir hücreye bağlandı ve trafiğin akmaya başladı. Hangi frekansta aktığını söylemedim.

Frekans sınırlı bir kaynak. Bir bandı kullanmak, o bandın sahibinden izin almak demek. Peki sahibi kim?

Frekansı kim dağıtıyor?

Radyo spektrumu ulusal bir varlık sayılıyor ve sahibi ülkenin kendisi oluyor. Bandın hangi hizmete açılacağına ulusal hükûmet karar veriyor. Aynı frekans iki ülkede iki ayrı işe tahsis edilmiş olabiliyor.

Bu yüzden bir üst kat var. ITU Telsiz Tüzüğü dünyayı üç bölgeye ayırıyor ve tahsis tabloları bölgeden bölgeye değişiyor. Türkiye Bölge 1’de, Amerika kıtası Bölge 2’de. Bir bandın hücresel hizmete açılması işte bu ölçekte bir karar. WRC-27’nin 1.2 numaralı gündem maddesi 6,425 ile 7,125 GHz arasını ve 10 ile 10,5 GHz arasını tartışıyor.

Ülke içinde dağıtımı düzenleyici kurum yapıyor; Türkiye’de bu işi BTK yürütüyor. IMT hizmetleri için yapılan yetkilendirme ihalesi 26 Ağustos 2015’te sonuçlandı ve hizmet 1 Nisan 2016’da başladı. Baz istasyonu seni tanıyıp çekirdek ağa bağlıyordu; o bağlantının hangi frekansta kurulduğuna karar veren zincir buraya kadar uzanıyor.

Kullanım hakkının verilme biçimi üçe ayrılıyor ve üçü ayrı bir bedelle geliyor.

Lisanslı bantta tek sahip var ve o sahip tipik olarak bir hücresel operatör. Başka kimse orada yayın yapmadığı için operatör girişimi kendi ağının içinde tutuyor. 3,5 GHz civarındaki paylaşımlı bant ise özel 5G kurulumlarına örnek: bir fabrika lisans satın almadan kendi hücresel ağını burada kurabiliyor.

Lisanssız bant herkese açık ama kuralsız değil. Kuralların ilki verici gücüne konan sınır. Bedelini de ödüyorsun: 2,4 GHz’te mikrodalga fırınla bebek telsizinin işareti seninkine karışıyor ve bunu engelleyen kimse yok.

Lisanssız bantta çözüm, girişimi önlemek yerine ondan kaçmak oluyor. Bluetooth bunu açıkça yapıyor. 2,4 ile 2,5 GHz arasını 1 MHz’lik 79 kanala bölüyor. Her zaman diliminden sonra başka bir kanala atlıyor. Girişim yapan cihaz tek bir kanalı tutuyorsa, atlama dizisinde o kanala ara sıra denk geliyorsun. Bozulan çerçeve bir sonraki dilimde başka bir frekanstan gidiyor.

Bandın içi nasıl bölünüyor?

Spektrum üç basamaklı bir hiyerarşi. Bant içinde birden çok kanal var, her kanalın içinde de birden çok alt kanal.

Kanal dediğimiz şey, taşıyıcı frekansın çevresinde ortalanmış belirli bir bant genişliği. Bant genişliği burada birebir bandın genişliği demek: sinyalin kapladığı frekans aralığının Hz cinsinden eni. Aynı terimi gecikme bileşenlerini ayırırken saniyede taşınan bit sayısı diye ölçmüştük. Aynı kelime, iki ayrı büyüklük.

Bandı kanallara bölmek fiziğin değil düzenlemenin işi. 2,4 GHz bandı ülkeye göre 11 ile 14 arası kanala bölünüyor; sayının ülkeden ülkeye değişmesi bunu kanıtlıyor.

Kanalı büyütmek doğrudan komşusundan yer almak demek. 2,4 GHz’in üç örtüşmeyen kanalını ve 5 GHz’in 23 kanalını saymıştık. Yanlarına genişliklerini yazınca fark ortaya çıkıyor: üç kanal 60 MHz eder, yirmi üç kanal 460 MHz. Aynı 20 MHz’lik kalıpla 5 GHz bandı 7,7 kat daha fazla yer veriyor.

İlan edilen genişliğin tamamı da veriye gitmiyor. Komşu kanallar birbirine karışmasın diye aralarına koruyucu bant bırakılıyor. O boşluk hiçbir veri taşımadan bandın bir kısmını yiyor.

Sayıya dökelim. 10 MHz’lik bir hücresel kanal 50 kaynak bloğuna bölünüyordu. Her blok frekansta 180 kHz yer tutuyor. Elli blok 9 MHz eder. İlan edilen genişliğin %90’ı veriye gidiyor; kenarda kalan 1 MHz koruyucu bandın bedeli.

İlk iki basamağı kendi makinende görebilirsin. Linux’ta tek komut menzildeki her ağı frekansıyla birlikte listeliyor:

nmcli -f SSID,CHAN,FREQ,SIGNAL device wifi list

FREQ sütunu taşıyıcı frekansı megahertz cinsinden veriyor, CHAN ise aynı taşıyıcının bant içindeki kanal numarasını. Üçüncü basamak o çıktıda görünmüyor; alt kanalları yalnızca radyonun kendisi biliyor.

Hücresel tarafta aynı işi modem yöneticisi görüyor ve tek satır yetiyor:

mmcli -m 0

Çıktı modemin bağlandığı operatörü, kullandığı erişim teknolojisini ve o an üstünde durduğu bandı yazıyor. Kanalı Wi-Fi’da sen seçiyorsun. Hücresel bantta o seçimi şebeke yapıyor.

İki yön aynı spektrumu nasıl paylaşıyor?

Kanalları saydık ama bir soruyu atladım: aynı anda hem gönderip hem alman gerekiyor. Bu iki yön spektrumu nasıl bölüşüyor?

İki cevap var ve ikisi de bu kitapta tanıdık bir ayrımın tekrarı — frekansta mı bölersin, zamanda mı?

Frekans bölmeli çift yönlülük (FDD) iki ayrı bant kullanıyor: biri upstream, biri downstream (aşağı yön). İkisi arasında bir de çift yönlülük boşluğu bırakılıyor, çünkü kendi vericinin kendi alıcını sağır etmemesi gerekiyor. Kazancı gerçek eşzamanlılık; bedeli spektrumun çift olarak tahsis edilmesi ve bölüşümün sabit kalması.

Zaman bölmeli çift yönlülük (TDD) tek bir bant kullanıyor ve yönler sırayla konuşuyor. İki kazancı var. Birincisi eşleştirilmemiş spektrum yetiyor — ki yüksek bantlarda bulunan neredeyse hep budur. İkincisi ve daha önemlisi, bölüşüm ayarlanabilir: trafik indirme ağırlıklıysa zaman dilimlerinin dörtte üçünü downstream’e verirsin.

Bu ikinci nokta kablo şebekesinin derdinin tam çözümü. Orada upstream ile downstream arasındaki bölüşüm spektrumun içine donanımla gömülü ve değiştirmek için her yükseltece kamyon çıkması gerekiyor. TDD’de aynı bölüşüm bir yazılım ayarı.

Bedava değil. TDD’de komşu baz istasyonlarının saatleri birbirine kilitli olmak zorunda: biri yayın yaparken öteki aynı frekansta dinliyorsa, komşusunun sinyali kendi alıcısını boğar. Bu yüzden TDD şebekeleri GPS ya da benzeri bir zaman kaynağıyla senkronize çalışır ve komşu operatörler bölüşüm desenini bile birbirine uydurmak zorunda kalır. FDD böyle bir koordinasyon istemiyordu.

Kuşakların tercihi de buradan okunuyor: alt bantlarda eski FDD tahsisleri sürüyor, 5G’nin orta ve yüksek bantları ise ezici çoğunlukla TDD. Eşleştirilmiş spektrumun kıt ve pahalı olmasının sebebi de bu.

Yukarı çıkmanın bedeli ne?

Radyo sinyali yayıldıkça güç kaybediyor. Sebebi bir engel değil; sinyal gittikçe daha geniş bir alana yayılıyor. Yol kaybı frekans ile mesafenin çarpımına bağlı büyüyor. Kaybın formülünü 48. bölüme bırakmıştım; burada yalnızca sonucunu kullanıyorum.

Sonuç şu. 3,5 GHz yerine 26 GHz kullanmak aynı mesafede yaklaşık 55 kat daha fazla yol kaybı demek. Aynı kaybı korumak istersen menzil 7,43 kat kısalıyor, yani %13,5’e iniyor: 1 km yerine 135 m. Kapsanan alan yarıçapın karesiyle orantılı olduğu için aynı coğrafi alanı örtmek yaklaşık 55 kat daha fazla hücre istiyor. Fatura doğrudan direk sayısına yazılıyor.

Elindeki cihaz bu hesabı kurtarmıyor. Bir mobil cihazın tipik azami verici gücü 250 mW, yani 24 dBm. Bant yükseldikçe bu sayı büyümüyor. Kaybı aynı ölçekte yazalım: 55 kat 17,4 dB’ye karşılık geliyor. Gücün sabitken bu farkı anten kazancından ya da kısalan mesafeden bulmak zorundasın.

Sektör bantları üç sınıfta konuşuyor. Bu üçlü ayrım kesin bir standart değil, sektörün konuşma dili.

Düşük bantta uzağa gitmenin bedeli doğrudan hızdan ödeniyor. Orta bant ikisini dengeliyor ve 1,8 GHz ile 3,3-3,8 GHz arası bu aralığın en çok kullanılan yeri. Yüksek bandın adı milimetre dalga; 26, 40, 50 ile 66 GHz bu aralıkta yaygın olan bantlar. Adın kendisi bir ölçüden geliyor ve hesabı basit. Dalga boyu, ışık hızının frekansa bölümü. Işık saniyede 300.000 km gidiyor; 26 GHz’te dalga boyu 11,5 mm çıkıyor, 71 GHz’te 4,2 mm’ye iniyor. Aynı bölme 3,5 GHz’te 86 mm veriyor. Milimetre dalga görüş hattı istiyor, yani ağaç ve bina arkasına geçemiyor. Wi-Fi da bunu denedi: 60 GHz’te çalışan 802.11ad 7 Gbit/s’e ulaşıyor ve odadan çıkamadığı için yaygınlaşamadı.

Aynı bedeli evinde de ödüyorsun. 2,4 GHz’te yayın yapan bir access point kapalı alanda onlarca metre, açık alanda bunun birkaç katı kadar kapsıyor. 5 GHz’te yapılan yayın duvar gibi engellerce daha fazla emiliyor ve aynı cihazın kapalı alandaki kapsaması düşük kalıyor.

Cetvelin neresinde duruyoruz?

Sektörün konuşma dilinin karşısında bir de belge dili var. 3GPP TS 38.104 frekans aralıklarını isimlendiriyor: FR1 410 MHz ile 7,125 GHz arasını, FR2 ise 24,25 GHz ile 71 GHz arasını kapsıyor. Sınırlar belirtimde 5.1-1 numaralı çizelgede duruyor ve hepsi megahertz cinsinden yazılı: 410 MHz’ten 7.125 MHz’e, 24.250 MHz’ten 71.000 MHz’e. İki aralığın arasında bir boşluk kalıyor ve o boşluğun adı sonradan kondu. 7,125-24,25 GHz dilimi FR3, yani üst orta bant. 6G tartışmalarında “altın bant” diye anılan yer burası.

O sıfat bir hesabın kısaltması. Yol kaybı karşılaştırmasını 10 GHz için tekrarlayalım: 3,5 GHz’e göre 8,2 kat kayıp çıkıyor, 26 GHz’teki 55 katın yerine. Aynı kaybı korursan menzil 1 km yerine 350 m oluyor. 26 GHz’te 135 m’ye inmişti. FR3 kapasiteyi mmWave’in fiyatına almıyor.

Genişlikleri yan yana koyunca fark ortaya çıkıyor: FR1’in tamamı 6,715 GHz tutuyor. FR3 tek başına 17,125 GHz, yani FR1’in 2,55 katı. FR2 ise 46,75 GHz eder ve FR1’in yaklaşık 7 katına çıkıyor. Bugünkü hücresel şebekelerin üstünde durduğu aralık, cetvelin en dar ucu.

Kuşakların cetvel üstünde nereye düştüğünü yan yana görelim:

Kuşak atlamak radyo tarafında ne değiştiriyor? En somut karşılığı taşıyıcı genişliğinde görüyorsun. Tek bir taşıyıcının azami genişliği 4G’de 20 MHz, 5G’de 100 MHz: radyoya verilen frekans dilimi 5 kat genişledi. İkincisi alt taşıyıcı aralığı. 4G’de bu aralık tek bir değere, 15 kHz’e sabitlenmişti; 5G onu 15, 30, 60 ve 120 kHz arasında seçilebilir yaptı, çünkü yüksek bantta dar alt taşıyıcı işe yaramıyor.

Özet

Peki, ne öğrendik?

• Spektrumun sahibi devlettir: bir bandı kullanmak ulusal bir izne bağlıdır, ve o izin lisanslı, paylaşımlı ya da lisanssız biçimde verilir.
• Lisanssızın bedeli girişimdir: bant bedavadır ama davranış kurallıdır, ve aynı frekansta konuşan cihazları kimse birbirinden ayırmaz.
• Yukarı çıkmak menzil yakar: 3,5 GHz yerine 26 GHz seçmek yol kaybını 55 kat artırır ve aynı alanı örtmek 55 kat hücre ister.
• Kuşak bir frekans dilimidir: 4G’nin 20 MHz’lik taşıyıcısı 5G’de 100 MHz’e çıktı ve alt taşıyıcı aralığı sabit olmaktan çıktı.

Frekansın nereden geldiğini ve neyin karşılığında geldiğini artık biliyorsun. Bandı seçtin, hücreye bağlandın, sonra yürümeye başladın. Peki attığın her adımda bağlandığın hücre değişirken bağlantın neden kopmuyor?

Bölüm 32: Hareketlilik ve Aktarma

Otobüs kalkıyor ve sayfayı yeni açtın. Birkaç yüz metre sonra bağlandığın hücre değişecek, ama isteğin kopmayacak.

Kopmamasının sebebi şans değil. Hücreler arasında el değiştirmek yönetilen bir iş. Peki o devri kim yönetiyor?

Yer değiştirmek adresi neden bozuyor?

Hareketlilik tek bir durum adı taşımıyor; dört kademeli bir yelpaze oluşturuyor ve her kademenin bedeli farklı.

Yelpazenin kolay ucunda ayakta tutulacak bir şey yok. Cihaz yeni yerde sıfırdan bağlanıyor. Zorluk oturum açıkken yer değiştirmekten doğuyor.

Kökü de adreste. Her IP adresi iki parça taşıyor: birinci parça hangi ağda olduğunu, ikinci parça o ağın neresinde olduğunu söylüyor. Adres yer bilgisi taşıdığı için yer değiştiren, adresini de değiştirmek zorunda kalıyor.

Bu tek başına felaket sayılmaz. Felaket, üstteki katmanın o adrese yaslanmasıyla başlıyor. Bir bağlantı soket four-tuple’ıyla tanınıyordu: kaynak IP, kaynak portu, hedef IP, hedef portu. Four-tuple’ın herhangi bir üyesi değişirse alıcı gelen segmenti aynı sokete yönlendiremiyor. Bağlantı kopmuş sayılıyor.

Somut bir vakaya bakalım. Tarayıcın 203.0.113.9:51820 adresinden 192.0.2.30:443 sunucusuna bağlandı. Başka bir alt ağa geçtiğin anda cihaza 198.51.100.7 düşüyor. Four-tuple’ın ilk üyesi değişti, kalan üçü aynı kaldı. Sunucudaki tabloda bu yeni four-tuple’ın karşılığı yok. Gelen segment bir sokete değil, bir RST yanıtına gidiyor.

Buradan yalnızca iki çıkış var. Ya ağ değişikliği gizler ve üst katman adresin değiştiğini hiç görmez, ya da bağlantı adresle tanınmaktan vazgeçer. Hücresel ağ birinci yolu seçti, QUIC ikinciyi.

Aktarmayı kim başlatıyor?

Aktarma, cihazın ağa bağlanma noktasının değişmesi. Cihaza giden veri akışı kaynak baz istasyonundan hedef baz istasyonuna aktarılıyor. Gerekçesi her zaman zayıflayan sinyal olmuyor. İkinci gerekçe yük: hedef daha az cihaz ve daha az trafik taşıyorsa karar onun lehine çıkabiliyor.

Kararı veren de cihaz değil. Hâlâ bağlı olduğun kaynak baz istasyonu hedefi seçiyor ve ona bir Handover Request iletisi gönderiyor. Cihazın işi ölçmek. Modülasyonu seçen 4 bitlik CQI raporu tanıdık; aynı rapor aktarma kararının da girdisi.

Rapor sürekli bir ölçek taşımıyor, basamaklı bir ölçek taşıyor. 4 bitlik alan 16 ayrı seviye kodluyor. Ölçmenin bir de pil bedeli var. LTE radyosu iletirken ya da almayı beklerken 1000-3500 mW harcıyor. Kapalıyken 15 mW’ın altına iniyor, yani açık hâlin %1 ile %2’si kadar.

Gelen rapor tek başına aktarmayı başlatmaya yetmiyor. Cihaz komşu hücreyi kendi hücresinden bir tık iyi buldu diye karar tetiklenmiyor; komşunun belirgin biçimde iyi olması ve bu üstünlüğün bir süre devam etmesi aranıyor. Aradaki paya histerezis deniyor ve olmadığında iki hücrenin sınırında duran bir telefon aralarında gidip geliyor. Her gidiş gelişte yeni bir aktarma yükü doğuyor; sahadaki adı ping-pong aktarma.

Hedef baz istasyonu, cihaz daha oraya geçmeden radyo zaman dilimlerini ayırıyor ve gereken bilgiyi taşıyan bir HR ACK ile yanıt veriyor. Yer önce hazırlanıyor, cihaz sonra taşınıyor.

Sıranın her adımının bir adı var. Ölçüm raporu, aktarma isteği ve isteğin onayı; ardından cihaza giden RRC yeniden yapılandırma iletisi. Cihazı asıl yerinden oynatan ileti bu. Cihaz yeni istasyona tutununca bir yeniden yapılandırma tamam iletisi dönüyor. Hedef de kaynağa aktarmanın başarılı olduğunu bildiriyor.

Asıl incelik kaynak tarafta. Kaynak baz istasyonu cihaza doğrudan göndermeyi bıraktığı anda elindeki datagramları atmıyor; onları hedefe iletiyor, hedef de radyo kanalından cihaza ulaştırıyor. Cihaz iki istasyon arasında havadayken hedef o veriyi tamponda bekletiyor. Kaybı önleyen şey bu yönlendirme.

Cihaz açısından iş burada bitmiş sayılıyor. Yeni istasyondan gönderebildiği anda aktarma tamamlanmış görünüyor. Oysa çekirdek tarafındaki yol hâlâ eski istasyona bakıyor.

Devrin hangi adımda kimin elinde olduğunu izleyelim:

Bu sıranın ne kadar sık tekrarlandığını hücrenin boyutu belirliyor. Yukarı bantlar kapsamayı daraltıyordu; hücre küçüldükçe aynı yolda daha çok aktarma oluyor. 300 m yarıçaplı, yani 600 m çaplı bir hücreyi 5 km/sa hızla yürüyen biri 432 saniyede, yani 7,2 dakikada kat ediyor. Aynı hücre 100 km/sa giden bir araç için 21,6 saniyeye iniyor.

Bağlantı koparak mı devrediliyor, kopmadan mı?

Aktarmanın nasıl yapıldığının iki klasik cevabı var ve aralarındaki fark tek bir sözcükte: sıra.

Sert aktarma (break-before-make) önce eski bağı bırakır, sonra yenisini kurar. Arada kısa bir boşluk oluşur. Basit, ucuz ve tek bir radyo yeter — cihaz aynı anda iki hücreyle konuşmak zorunda değil. Bedeli o boşluk.

Yumuşak aktarma (make-before-break) tersini yapar: yeni bağ kurulmadan eskisi bırakılmaz. Geçiş süresince cihaz iki hücreyle birden konuşur ve aynı veriyi iki yoldan alır. Boşluk yoktur; karşılığında cihaz iki radyo zinciri, şebeke de iki kat kaynak ayırmak zorundadır. 3G’nin kod bölmeli tasarımı bunu ucuza yapabiliyordu, çünkü komşu hücreler aynı frekansı kullanıyordu.

LTE ve 5G sert aktarmaya döndü — ama boşluğu neredeyse görünmez kılarak. Hazırlığın tamamı kesinti başlamadan önce yapılıyor:

1. Cihaz komşu hücrelerin sinyal gücünü sürekli ölçüp kaynak baz istasyonuna raporluyor.
2. Kaynak, hedef baz istasyonuyla doğrudan konuşup yer ayırtıyor. İki baz istasyonu arasındaki bu arayüzün adı LTE’de X2, 5G’de Xn — trafik çekirdek ağa hiç uğramıyor.
3. Kaynak, cihaza “şu hücreye geç” komutunu yolluyor.
4. Cihaz yeni hücreye bağlanırken, kaynakta biriken paketler hedefe tünellenerek aktarılıyor. Böylece geçiş anında sırada bekleyen veri kaybolmuyor.

Kalan kesinti tipik olarak on milisaniyeler mertebesinde ve bir görüşmede duyulmuyor. Ama hâlâ sıfır değil, ve en kritik anda — sinyal zayıfken — o komutun cihaza ulaşması gerekiyor. 5G bunun için üçüncü bir yol getirdi: koşullu aktarma. Şebeke hedefi ve tetikleyici koşulu önceden cihaza veriyor, cihaz koşul sağlandığında komut beklemeden kendisi geçiyor. Karar anındaki gidiş-dönüş tamamen ortadan kalkıyor.

Çekirdek neden yerinde duruyor?

Radyo tarafı değişirken sabit duran bir taraf var. Her cihaza bir UPF atanıyordu; o UPF cihazla internet arasında röle gibi çalışıyor ve trafiği N3 arayüzünde tünelliyordu. İnternetin gördüğü sabit nokta orası.

Aktarmada değişen şey de cihazın adresi değil, o tünelin ucu. Radyo tarafı bittikten sonra SMF, UPF’ye tünelin ucunu yeni hedef baz istasyonu olacak biçimde değiştirmesini söylüyor. Hedef, aktarmanın tamamlandığını kaynağa bildirince kaynak taraf ayırdığı radyo kaynaklarını serbest bırakıyor.

Çekirdek yarısının da kendi ileti sırası var. Hedef istasyon çekirdeğe bir yol değiştirme isteği yolluyor, çekirdek PDU oturumunu güncelliyor ve isteği onaylıyor. Eski yola en sonda bir veri sonu işareti düşüyor. O işaretten sonra o tünelden veri gelmiyor. Kaynak istasyona giden son ileti cihaz bağlamını kapatıyor.

Adres vererek bakınca daha keskin. Cihazın adresi 203.0.113.9, UPF’nin adresi 198.51.100.5, kaynak baz istasyonu 198.51.100.20 ve hedef istasyon 198.51.100.21. İnternetteki gönderen 192.0.2.30 olsun. İki zarfı yan yana koyalım:

önce   dış zarf: 198.51.100.5 -> 198.51.100.20   iç zarf: 192.0.2.30 -> 203.0.113.9
sonra  dış zarf: 198.51.100.5 -> 198.51.100.21   iç zarf: 192.0.2.30 -> 203.0.113.9

İç zarfta tek bir bayt bile oynamıyor. Gönderen tarafta bu devri gösteren hiçbir iz yok.

Tünelin ucu neden hep aynı kutuda kalıyor? Çünkü UPF yalnızca röle değil. Politika uygulaması, yasal dinleme, trafik kullanım ölçümü ve hizmet kalitesi denetimi de orada yürüyor. Bunların hepsi akışın tamamını tek noktadan görmeyi istiyor. Çapayı oynatmak, bu dört işi birden taşımak demek olurdu.

Zaman çizgisi bu yüzden iki yarıya bölünüyor: önce radyo erişim ağındaki ayrılma ve tutunma, sonra çekirdekteki yol değiştirme. Cihaz için kesinti yalnızca ilk yarıdaki ayrıl-tutun aralığı.

Cihazın nerede olduğunu AMF takip ediyor: sen hücre değiştirirken ağa tutunmanın ve erişim yetkinin sürmesinin kaydını o tutuyor. Bir operatörde tek bir çekirdek ağ çok sayıda radyo erişim ağına hizmet ediyor.

Yelpazenin en zor ucunda sağlayıcı da değişiyor. Hücresel dünyada kimliğin bir kullanıcı adı taşımıyor, bir abonelik taşıyor: parasını ödediğin bir ev ağın var ve seni asıl tanıyan orası. Karşılaştırmayı ev tarafı yapıyor ve ziyaret edilen ağa yalnızca anchor key gönderiliyordu. 5G’nin getirdiği fark tam burada: 4G’de aynı karşılaştırma ziyaret edilen ağın kendisinde yapılıyordu.

Wi-Fi aynı sorunu neden ucuza çözüyor?

Hücresel tarafın bunca iş yapmasının sebebi, sorunu üçüncü katmanda çözmek zorunda olması. 802.11 bir bağ katmanı standardı ve dolaşımı da o katmanda ele alıyor. Üst katmanlar olan bitenden habersiz kalıyor.

Genişletilmiş hizmet kümesinin içinde access point değiştirirken IP adresi değişmiyordu; komşuya geçmek yalnızca ilişkilendirmeyi yenilemek demek. Dolaşımı hızlandıran üç ek çalışma grubunun kendi tarihi var: 802.11k-2008 komşu ölçümünü, 802.11r-2008 hızlı yeniden kimlik doğrulamayı, 802.11v-2011 ise ağın cihaza aday access point önermesini getirdi.

Bu iddiayı kendi makinende birkaç komutla doğrulayabilirsin. Windows’ta netsh wlan show interfaces, Linux’ta iw dev wlan0 link bağlı olduğun access point’i yazıyor:

SSID   : kampus-ag
BSSID  : 00:1a:2b:3c:4d:5e

Binanın öbür ucuna yürü ve komutu tekrarla. SSID satırı aynı, BSSID satırı başka. ipconfig ya da ip addr ile baktığında IPv4 adresin de değişmemiş olacak.

Ucuzluğun sınırı da burada. Alt ağın kenarını geçtiğin anda adresin değişiyor ve bağ katmanının hilesi bitiyor.

Adres değişince bağlantı neden ölmüyor?

İkinci çıkış yolu bağlantıyı adresten koparmak. QUIC bağlantıyı four-tuple’la değil bir bağlantı kimliğiyle tanıyordu ve buna bağlantı göçü deniyordu. Kimliğin birincil işi, alt katmanlardaki adres değişikliklerinin paketleri yanlış uca göndermesini engellemek.

Kimliğin bir de boyu var. QUIC sürüm 1’de bağlantı kimliği en çok 20 bayt tutuyor. Daha uzununu gören uç paketi düşürmek zorunda.

Değişikliklerin hepsi kasıtlı da değil. NAT yeniden bağlama, aradaki kutunun akışa yeni bir çıkış portu ya da yeni bir çıkış adresi vermesiyle oluyor. Uç, karşı tarafın adresinde herhangi bir değişiklik sezerse yol doğrulaması yapmak zorunda.

Yol doğrulaması, yeni adresten gelen paketlerin sahte kaynak taşımadığını sınıyor. Gönderen, tür kodu 0x1a olan PATH_CHALLENGE çerçevesinin 8 baytlık veri alanına 64 bitlik rastgele bir değer koyuyor. Alıcı aynı veriyi taşıyan bir PATH_RESPONSE üretmek zorunda. Datagram ayrıca en az 1.200 bayta genişletiliyor, böylece yeni yolun bu boyutu taşıyabildiği de sınanmış oluyor. Gerçek yük datagramın %0,67’si, kalanı dolgu.

Göç serbest de değil. El sıkışma doğrulanmadan göç başlatılamıyor ve başlatma sorumluluğu istemcide. Sunucu, bir istemci adresinden yoklama dışı paket görmeden o adrese yoklama dışı paket göndermiyor. Bu sınama tek yönü kanıtlıyor; ters yönü karşı taraf kendi başına yapıyor.

Doğrulama bitince uç, tıkanıklık denetleyicisini ve gidiş-dönüş süresi kestiricisini yeni yol için başlangıç değerlerine sıfırlamak zorunda. Tek istisna yalnızca portun değiştiği durum; o genelde NAT yeniden bağlamasıdır ve eski durum korunabiliyor. Bir kural daha var. Uç, birden fazla yerel adresten gönderirken aynı bağlantı kimliğini yeniden kullanamıyor. Sebep gizlilik: sabit bir kimlik, pasif bir gözlemcinin iki ayrı ağdaki etkinliği aynı kişiye bağlamasına izin verirdi.

Özet

Peki, ne öğrendik?

• Hareketlilik bir yelpaze: kapalı cihazı taşımak bedava, açık oturumu taşımak pahalı, ve pahalı olanın kökü adresin yer bilgisi taşımasıdır.
• Aktarmayı kaynak yönetir: hedefi seçen ve isteği gönderen kaynak baz istasyonudur, cihaz yalnızca ölçüm raporu üretir.
• Yer önce hazırlanır: hedef radyo dilimlerini cihaz gelmeden ayırır ve kaynak biriken datagramları atmak yerine hedefe iletir.
• Çekirdek yerinde durur: aktarmada değişen şey UPF’ye giden tünelin ucudur, cihazın adresi değil.
• Bağlantı kimliği adresin yerini alır: QUIC bağlantıyı four-tuple’la tanımadığı için adres değişse de bağlantı yaşar, ama yeni yol önce doğrulanır.

Yer değiştirirken bağlantının neden ayakta kaldığını artık iki ayrı katmanda izleyebiliyorsun. İkisinin de dayandığı şey aynı: cihazın elinde bir adres olması. Telsiz de olsan telli de olsan bağlandın; peki bağlanır bağlanmaz aldığın o adresi sana kim verdi?

Bölüm 33: Adres Kiralama: DHCP

Bir önceki durakta hücreden hücreye geçtin ve bağlantın kopmadı. O bağlantının dayandığı adresi sana kimin verdiğini ise erteledim.

Adresi veren bir sunucu var. Verirken yalnızca adresi söylemiyor; ağdan çıkış kapısını da aynı cevaba koyuyor. Peki adresi olmayan bir makine o cevabı nasıl isteyebiliyor?

Adresi elle yazmaktan neden vazgeçildi?

Adres makineye iki yoldan geliyor: ya elle bir yapılandırma dosyasına yazıyorsun, ya da makine ağa katıldığı anda ağdaki bir sunucudan alıyor.

Elle yazmak tek satırlık bir iş de değil. Dört alanı birden doldurman gerekiyor: IP adresi, alt ağ maskesi, default gateway ve DNS sunucusu. Üçünü doğru girip birini yanlış girdiğinde makine yarım çalışıyor — arızası da en can sıkıcı türden, çünkü bazı şeyler yürüyor. DHCP bu dördünü tek cevapta dağıtır.

Dinamik adreslemenin üç tarihsel uygulaması var: RARP, BOOTP ve DHCP. Sonuncusu BOOTP’nin gelişmiş hâli ve paket biçimini ondan devraldı. BOOTP diski olmayan makineler için tasarlanmıştı ve sunucuda her makine için önceden bir kayıt açmayı şart koşuyordu. DHCP o şartı kaldırdı. Yerine yeniden kullanılabilir adres dağıtımını ve ek yapılandırma seçeneklerini koydu. Standardı 1997 yılında yayımlanan RFC 2131’dir ve o belge kendinden önceki tanımı geçersiz kılar.

Dağıtılan adresler bir adres havuzundan gelir. Havuz sunucuda elle tanımlanır ve ağın tamamı kadar geniş olmak zorunda değildir. Örnek bir ev ağı düşün: 192.168.42.0/24 bloğunda makinelere verilebilecek 254 adres var. Havuza .100 ile .199 arasını verirsen 100 adres dağıtılabilir hâle gelir, yani kullanılabilir adreslerin %39,4’ü. Kalanı statik yapılandırmaya kalır.

Bir de zincirin ucu var. Adres dağıtan sunucunun kendi adresi statiktir, çünkü adres dağıtan makinenin adresini kimse dağıtamaz.

Dört mesaj neden dört?

Kiralama dört mesajdır: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST ve DHCPACK. İki taraf da iki kez konuşur.

İlk mesaj bir yayındır, çünkü istemci sunucunun adresini bilmez. Hedef IP adresi 255.255.255.255 olur, hedef MAC adresi FF-FF-FF-FF-FF-FF. En baştaki adres hiçbir makineye verilmez ve anlamı “bu ağdaki herkes”tir.

İstemci kendi adres alanına 0.0.0.0 yazar ve adresini bilmediğini paketin içinde açıkça ilan eder. İstekle cevabı eşleştiren şey bu yüzden adres olamaz. Eşleştirmeyi 4 baytlık rastgele bir işlem kimliği yapar, alanın adı xid.

Taşıma tarafında DHCP, UDP kullanır. İstemciden sunucuya giden mesajlar 67 numaralı porta, sunucudan istemciye dönenler 68 numaralı porta gider. İki ayrı port, cevabın da yayın olarak dönebilmesi içindir.

İkinci mesajda sunucu havuzdan bir adres seçer ve teklif eder. Teklifin içine kendi kimliğini de koyar. Sunucunun verdiği adresi taşıyan alanın adı yiaddr, açılımı “senin adresin” ve genişliği 4 bayt.

Üçüncü mesaj kabuldür ve o da yayındır. Aynı ağda teklif veren başka sunucular varsa reddedildiklerini duymak zorundadır. Dördüncü mesaj geldikten sonra adres kiralanmış olur.

Dört mesajın sırasını ve her birinin ne taşıdığını görelim:

İlk iki adım her zaman gerekmez. İstemci önceki adresini hatırlıyor ve onu tekrar kullanmak istiyorsa dörtlünün başını atlayıp doğrudan DHCPREQUEST’ten başlar. İki mesaj kısalır.

Mesajın türü başlıkta durmaz. Tanımlı 8 tür, 53 numaralı seçenekte tek bayt olarak taşınır.

Reddin anlamı dardır. İstemcinin elindeki adres yanlıştır, örneğin başka bir alt ağa taşınmıştır, ya da kirası bitmiştir.

Seçenekler yalnızca tür taşımaz. Her yapılandırma parçası numaralı bir seçenektir, ve istemci istediği numaraları bir liste hâlinde sayar.

Sıralamanın da bir kuralı var. Cevapta hem maske hem geçit varsa maske önce gelmek zorundadır. Geçit seçeneği tercih sırasına dizilmiş bir yönlendirici listesi taşıyabilir; ev ağında liste tek satırlıktır.

Adres neden kiralık?

Adres kalıcı değildir. Kiralanır. Kira yenilenebilir, cihaz kapanınca adres havuza döner. “Kira” burada bir benzetme de sayılmaz; standardın kendi terimidir.

Kira süresi 51 numaralı seçenekte 32 bitlik bir sayı olarak gelir. Diyelim ki ev yönlendiricin 24 saatlik kira veriyor. İstemci sürenin bitmesini beklemez, iki zamanlayıcı tutar. İlki sürenin %50’sinde, ikincisi %87,5’inde dolar.

İlk zamanlayıcı dolunca istemci yenileme durumuna geçer ve adresi veren sunucuya tek hedefli bir istek yollar. İkincisi dolunca yeniden bağlanma durumuna geçer ve artık herhangi bir sunucuya yayın yapar. İki kademenin sebebi basit: adresi veren sunucu ölmüş olabilir.

Örneğimizde ilk zamanlayıcı 12. saatte, ikincisi 21. saatte dolar. Geriye üç saatlik bir tampon kalır.

Zamanlayıcılar tam bu değerlerde de kurulmaz. Standart, sabit değerin etrafına rastgele bir sapma eklenmesini ister. Sebebi ölçek: aynı anda kiralanan bütün adresler aynı anda yenilenmek isterse sunucu tek seferde boğulur. Sapma bunu dağıtır.

Aynı kaygı açılışta da var. İstemci ilk mesajı göndermeden önce 1 ile 10 saniye arasında rastgele bekler. Elektrik geldiğinde evdeki bütün cihazların aynı saniyede konuşmasını engelleyen şey bu bekleme.

Cevap gelmezse istemci pes etmez. Yeniden gönderim gecikmesi 4 saniyeden başlar, her denemede ikiye katlanır ve 64 saniyede tavan yapar. Beşinci denemeye kadar geçen toplam bekleme 60 saniyedir.

Adresin gerçekten boş olduğunu iki taraf da ayrı ayrı sınar. Sunucu teklif edeceği adresi bir ICMP yankı isteğiyle yoklayabilir, çünkü havuzda boş görünen adres ağda kullanılıyor olabilir. İstemci de teklif edilen adres için bir ARP isteği yayınlar; cevap gelirse adres kullanımdadır ve reddini göndermek zorundadır.

Adres kesinleşince istemcinin son bir işi kalır. Bedava ARP komşuların eski kayıtlarını temizletiyordu; makine yeni adresini duyurmak için tam onu yapar.

Sunucunun da istemciye verdiği iki söz vardır. Kira boyunca adresi başkasına vermez, ve aynı istemciye her seferinde aynı adresi vermeye çalışır. İkincisi bir garanti değil, bir gayrettir.

Evdeki kutu kaç iş yapıyor?

Evdeki kutu tek cihaz gibi görünür. İçinde dört ayrı iş vardır.

Modem, kablo ya da DSL hattını sayısal veriye çevirir. Yönlendirici paketleri ağlar arasında iletir; güvenlik duvarı ve adres çevirisi de onun tarafındadır. Anahtar kablolu portları birbirine bağlar. Access point kablosuz tarafı taşır. Dördünü tek kasada birleştirmek bir üretim tercihidir, protokol zorunluluğu değil.

Katman karşılıkları da farklıdır. Yönlendirici ağ katmanında, anahtar bağ katmanında, ağ kartı ile tekrarlayıcı fiziksel katmanda çalışır. Ev kutusu üç katmanda birden iş görür. Yıldız topolojinin merkezine bir cihaz konuyordu; evdeki kutu tam o merkezde durur. İlişkilendirme tek bir access point’le kuruluyordu; o access point de aynı kasanın içindedir.

Adres dağıtan sunucu da genelde ayrı bir makine değildir. Yönlendiricinin içinde durur ve yönlendiricinin bağlı olduğu bütün alt ağlara hizmet eder.

Geçit görevini de yönlendirici üstlenir. Default gateway, bir bilgisayarın paketlerini başka bir alt ağa iletmek için kullandığı adrestir. Makinelerin de yönlendirme tablosu vardır ama ağa bağlı tek yönlendirici varsa seçilecek bir şey yoktur, ve ev ağının hâli tam budur.

Tablonun ilk satırı varsayılan yoldur: hedefi eşleşmeyen bütün paketler geçidin adresine iletilir. Windows’ta bu tabloyu route print ile görürsün. Öteki satırların nereden geldiğini yönlendiricinin içine indiğimizde açacağım.

Geçit tanımlanmadığında belirti nettir. Makineler birbirine ulaşır, ağın dışıyla iletişim başarısız olur. Geçide bloğun ilk kullanılabilir adresini vermek zorunlu değil ama yaygın bir alışkanlıktır. Örnek ağımızda geçit 192.168.42.1 adresinde oturur.

IANA üç bloğu özel adres bloğu olarak yerel ağlara ayırmıştır: 10/8, 172.16/12 ve 192.168/16. Bu adresler internette yönlendirilmez. Dışarı çıkarken bu adreslerin nasıl geçerli birer adrese çevrildiğini burada bırakıyorum; çeviri tablosuyla birlikte açacağım.

Hiçbir sunucu cevap vermezse makine boş kalmaz. 169.254.0.0/16 bloğundan kendine bir adres uydurur; bunun adı bağ-yerel adresleme, yaygın adı APIPA. Ekranda o adresi görmek, kiralamanın hiç gerçekleşmediğini söylemenin başka bir yoludur.

Kiranın kimden alındığını kendi makinende görebilirsin. Windows’ta ipconfig /all çıktısı IP adresini, MAC adresini, DNS sunucusunu ve adresi veren sunucuyu birlikte listeler. Yönlendirici tarafında show dhcp lease kiralanmış adreslerin tablosunu döker. Yakalama filtresi yazmayı öğrenmiştin; aynı araç bu dört mesajı hâlâ eski adıyla, bootp diye ayırır.

Özet

Peki, ne öğrendik?

• Adres iki yoldan gelir: ya elle yazılır ya da ağa katılma anında bir sunucudan alınır, ve ikinci yol dört alanı birden doldurur.
• Kiralama dört mesajdır: istemci yayınla arar, sunucu teklif eder, istemci yine yayınla kabul eder, sunucu onaylar.
• Tür seçenekte taşınır: mesajın hangi adım olduğunu 53 numaralı seçenekteki tek bayt söyler, başlıktaki ayrı bir alan değil.
• Adres kiralıktır: istemci ilk zamanlayıcıda kendi sunucusuna, ikincisinde herhangi bir sunucuya dönerek kirayı tazeler.
• Ev kutusu dört iştir: modem, yönlendirici, anahtar ve access point aynı kasada birleşmiştir, ve default gateway olarak yazılan adres o kasanındır.

Artık makinen adresi nereden aldığını ve dışarı çıkarken hangi kapıya yöneleceğini biliyor. Geriye tek bir soru kalıyor. Paketin hedefi elinde; makinen o hedefin bu ağda olmadığına nasıl karar verdi?

Bölüm 34: Adresin Anatomisi

Ev yönlendiricisi sana bir adres, bir maske ve bir default gateway vermişti. Maskeyi kullanmadan bıraktım.

Makinen hedefin bu ağda olmadığını işte o maskeyle anladı. Yaptığı iş tek bir şeyden ibaret: iki sayıyı karşılaştırmak. Peki neyi neyle karşılaştırıyor?

Bir adres kaç parçadan oluşur?

IPv4 adresi aslında tek bir sayı. Uzunluğu 32 bit, yani 4 bayt. Kimse otuz iki basamaklı bir ikili diziyi gözüyle okuyamadığı için adres 8 bitlik dört parçaya bölünüp noktayla ayrılıyor. Her parçanın adı oktet.

Bir oktet 256 farklı değer taşır: en küçüğü 0, en büyüğü 255. Üst sınır keyfi bir seçim değil, sekiz bitin tamamının bir olması: 11111111. Okteti 256 olan bir adres hiçbir arayüze girmez.

Dört oktet tek bir isim taşımıyor. Adres iki bilgiyi birden söylüyor: makinenin hangi ağda olduğunu ve o ağın içindeki yerini. İlkine ağ parçası, ikincisine makine parçası deniyor.

Posta kodunu düşün. Kod mektubu doğru dağıtım merkezine götürür, kapı numarası o merkezin içinde tek bir kapıyı bulur. IP adresi aynı iki işi tek bir sayıya sıkıştırıyor: ağ parçası merkezi söylüyor, makine parçası kapıyı. Benzetme şurada biter: posta kodu ile kapı numarası zarfın üstünde ayrı ayrı yazılıdır, IP adresinde ise tek bir sayı vardır ve sınırın nereye düştüğünü adres sana söylemez.

Bu dört oktet, kapsüllemede üçüncü zarfın başlığına, kaynak ve hedef alanlarına yazılıyor. MTU o zarfın boyunu sınırlar, içindeki adresin yapısına karışmaz.

Sınırı kim çiziyor?

Sınırı söyleyen şey alt ağ maskesi. Maske de 32 bittir ve dört okteti vardır. Ama bir adres değildir. Hiçbir makineye atanmaz, hiçbir paketin üstüne yazılmaz.

Maskenin deseni serbest de değil. Solda kesintisiz bir dizi bir, sağda kesintisiz bir dizi sıfır bulunur. Birler ağ parçasını işaretler, sıfırlar makine parçasını. Bu kural yüzünden bir maske oktetinde topu topu dokuz ondalık değer görünebilir.

0   128   192   224   240   248   252   254   255

Adresle maskeyi buluşturan işlem bitsel VE. Adresin her biti maskedeki karşılığıyla eşleşir ve maskenin sıfır olduğu her yerde sonuç sıfırlanır. Geriye yalnızca ağ parçası kalır. Çıkan değerin adı ağ adresi.

Somut bir vaka kuralım. Örneği ev ağından belge blokuna taşıyorum; alt ağa bölmeyi 203.0.113.0/24 üstünde göstermek daha temiz. Belgelemeye ayrılmış o bloktan 203.0.113.70 adresini alıyorum, maskeyi de 255.255.255.192 seçiyorum.

adres    203.0.113.70      11001011 00000000 01110001 01000110
maske    255.255.255.192   11111111 11111111 11111111 11000000
                                                      --------
VE       203.0.113.64      11001011 00000000 01110001 01000000

Hesabın tamamı son oktette olup bitiyor: 70 ile 192’nin VE’si 64. İlk üç oktet maskede baştan sona bir olduğu için olduğu gibi geçiyor. Şimdi aynı adresi daha kısa bir maskeden geçir. 255.255.255.0 ile sonuç 203.0.113.0 çıkar. Adres değişmedi, maske değişti, ağ değişti.

Aynı adresi iki farklı maskeden geçirince ne olduğunu görelim:

Makine bu işlemi her paket için iki kez yapıyor. Önce hedef adresi kendi maskesinden geçiriyor, sonra kendi adresini aynı maskeden. İki sonuç eşitse hedef aynı ağdadır ve çerçeve doğrudan ona yazılır. Eşit değilse paket varsayılan geçide çıkar.

Bir önceki durağın borcu tam burada kapanıyor. Adresi 203.0.113.70/26 olan makine 198.51.100.9 numaralı hedefe paket yazacak. Hedefi kendi maskesinden geçirince 198.51.100.0 buluyor, kendi ağı ise 203.0.113.64. İkisi eşleşmiyor. Çerçeve bu yüzden geçide, yani 203.0.113.65 adresine yazılıyor.

Aynı hesap daha eski bir borcu da kapatıyor. Makine ARP’ı yalnızca kendi ağındaki komşular için soruyordu. Kimin komşu sayılacağına karar veren işlem buydu.

Sınır bazen çok yakından geçer. 203.0.113.130 aynı maskeden 203.0.113.128 olarak çıkıyor ve bu değer 203.0.113.64 ile eşit değil. İki makine kâğıt üstünde komşu görünse de aynı alt ağda değil.

Her ağın iki adresi baştan gider. Makine bitlerinin tamamı sıfır olan değer ağ adresidir, tamamı bir olan değer yayın adresidir. Atanabilir ilk adres ağ adresinden bir sonraki, son adres yayın adresinden bir öncekidir.

Kartın fabrikadan gelen adresi ve bütün komşuları birden uyandıran yayın adresi tanıdık. Buradaki yayın adresi onun üçüncü kattaki karşılığı. Geçide ağ adresinden sonraki ilk adresi vermek ise bir kural değil. Yerleşmiş bir gelenek, çoğu ağda öyle bulursun.

Bir bloğu nasıl bölersin?

Maskeyi noktalı ondalık yazmak yerine kaç bitinin bir olduğunu söylemek daha kısa. Eğik çizgili gösterimin tamamı bu: /20 demek, maskenin ilk 20 biti bir ve kalan 12 biti sıfır demek. Çizgiden sonraki sayının adı önek uzunluğu.

RFC 4632 yazımı sabitliyor: dört oktetlik bir değer, eğik çizgi, sonra sıfır ile otuz iki arasında bir tam sayı. Tanımlı önek uzunluğu sayısı böylece 33 oluyor.

Alt ağ kurmak, makine bitlerinden bir kısmını ödünç bit olarak ağ parçasına almaktır. Ağ bitleri hiç değişmez; uzayan şey maskedir. Denklem sabit: ağ bitleri artı ödünç bitler artı makine bitleri 32 eder.

Bütün alt ağ hesabı iki formüle iniyor. b ödünç alınan bit sayısı, h geriye kalan makine bit sayısı olsun:

alt ağ sayısı      = 2^b
alt ağ başına adres = 2^h
atanabilir adres    = 2^h − 2

Sondaki iki, her alt ağın yuttuğu ağ adresi ile yayın adresi. Üç formülden yalnızca ikisini ezberlemek yeter, üçüncüsü çıkarma.

Tersinden de çalışıyor ve sahada asıl kullanılan yön bu: elinde makine sayısı var, önek arıyorsun. “Bana 50 adres lazım” dediğinde 2^h − 2 ≥ 50 eşitsizliğini sağlayan en küçük h değerini bulursun. h=5 için 30, yetmiyor; h=6 için 62, yetiyor. Önek 32 − 6 = /26.

Son okteti kullanan öneklerin tamamı tek bir merdivene sığıyor ve bu merdiveni akılda tutmak alt ağ hesabının yarısıdır:

Merdiven her satırda ikiye bölünüyor: maskeye bir bit eklemek blok büyüklüğünü yarıya indiriyor. Sağdaki iki sütunun /31 ve /32 satırlarında birbirine eşit olmasının ayrı bir hikâyesi var; ona birazdan geleceğiz.

203.0.113.0/24 bloğunu dört parçaya bölmek istiyorsun. Dört parça 2 bit ödünç almak demek. Yeni önek /26 ve maske 255.255.255.192 oluyor. Makine parçası 6 bit kalıyor, yani her alt ağda 64 adres var ve bunun 62’si atanabilir.

Sınırları ikili yazmadan bulmanın kısayolu blok büyüklüğü. Maskenin son oktetteki değerini 256’dan çıkarırsın: 256 eksi 192, 64. Alt ağlar son oktette 64’er adımla ilerler.

Aynı hesap başka bir blokta da yürüyor. 198.51.100.0/24 sekiz parçaya bölünürse önek /27 olur, maske 255.255.255.224 çıkar ve blok büyüklüğü 32’ye iner. Her parçada 30 atanabilir adres kalır.

Bölmenin bir bedeli var. Tek bir /24 bloğunda 256 adresin ikisi kaybolur; kayıp oranı %0,8’de kalır. Aynı blok dört /26’ya ayrılınca kayıp sekize çıkar ve oran %3,1 olur.

Bedel en uçta çıplak görünür. İki yönlendiriciyi bağlayan noktadan noktaya bir hat için /30 kullanılır ve dört adresin yalnızca ikisi işe yarar. Verim %50.

Bu israfın bir çaresi var ve merdivenin sondan ikinci satırında duruyor. RFC 3021, noktadan noktaya hatlarda /31 kullanmayı serbest bırakıyor. Mantığı şu: ağ adresi ile yayın adresi ancak bir alt ağda “ötekiler” varken anlamlıdır. Bir hattın iki ucu varsa yayın yapmaya gerek yok — karşı taraf zaten tek bir makine. Öyleyse iki adresi de arayüze verebilirsin ve verim %50’den %100’e çıkar. Bir operatörün binlerce hattı olduğunda kazanılan adres sayısı ciddi. Merdivenin son satırındaki /32 ise bir ağ değil, tek bir makineye giden bir yol; geri döngü arayüzlerinde ve yönlendirme tablosunda karşına çıkacak.

Bir tasarım problemi: aynı blok, dört farklı beden

Şimdiye kadar blokları hep eşit parçalara böldük. Gerçek bir ağda departmanlar eşit büyüklükte olmuyor ve eşit bölmek adres israf ediyor. Çözümün adı değişken uzunluklu maske (VLSM): aynı blok içinde farklı öneklere sahip alt ağlar kurmak.

Elinde 192.168.10.0/24 var ve dört ihtiyaç bekliyor:

Kural tek: en büyükten başla. Küçükten başlarsan büyük blok için hizalı bir yer kalmaz, çünkü her alt ağ kendi büyüklüğünün katı olan bir adreste başlamak zorunda.

Satış, 50 makine. 2^6 − 2 = 62 ≥ 50, önek /26, blok 64. İlk boş adres .0. → 192.168.10.0/26, kullanılabilir .1-.62, yayın .63.

Muhasebe, 25 makine. 2^5 − 2 = 30 ≥ 25, önek /27, blok 32. İlk boş adres .64 ve 64, 32’nin katı — hizalı. → 192.168.10.64/27, kullanılabilir .65-.94, yayın .95.

Depo, 10 makine. 2^4 − 2 = 14 ≥ 10, önek /28, blok 16. İlk boş adres .96, 16’nın katı. → 192.168.10.96/28, kullanılabilir .97-.110, yayın .111.

Hat, 2 adres. 2^2 − 2 = 2, önek /30, blok 4. İlk boş adres .112. → 192.168.10.112/30, kullanılabilir .113-.114, yayın .115.

Sonuç tabloya döküldüğünde:

Geriye 192.168.10.116 ile 192.168.10.255 arası, yani 140 adres boşta kalıyor. Yarın beşinci bir bölüm eklendiğinde yer var.

Şimdi aynı işi eşit bölmeyle yapmayı dene. Dört bölüm için dört alt ağ, yani /26. Satış sığar, ama Depo 62 adreslik bir bloğun içinde 10 makineyle oturur ve 52 adres ölür; iki adreslik hat 60 adres yakar. Toplam boş: 121 adres, ve elinde beşinci bir alt ağ için hiç yer kalmaz. VLSM’in kazandırdığı şey adres değil, gelecekte manevra alanı.

Bir uyarı da düşeyim: VLSM’in çalışabilmesi için yönlendirme protokolünün maskeyi ilanla birlikte taşıması gerekiyor. Taşımayanlar — birazdan göreceğin sınıflı düzenin kalıntıları — aynı ağda iki farklı önek gördüklerinde yanlış karar veriyor. Yönlendirme protokollerini karşılaştırırken bu ayrımı tekrar kullanacağız.

Bölmenin sebebi adres tasarrufu mu?

Alt ağın tanımı aslında topolojik. Arada yönlendirici olmadan birbirine ulaşabilen arayüzler bir alt ağ oluşturur. Adresin yapısı bu fiziksel gerçeği yazıya dökmekten ibaret.

Bölmenin ilk gerekçesi de adres tasarrufu değil, yayın trafiği. Ağ büyüdükçe yayın etki alanı büyür ve bütün makineler yoğun yayının ortasında kalır. İkinci gerekçe yönetim: farklı yerlerdeki bölümler birbirini etkilemez ve tek bir ağ numarası içeriden bölünebilir.

Bu esneklik sonradan kazanıldı. 1990’lardan önce sınırı maske değil, adresin ilk okteti çiziyordu. Üç beden vardı ve arada kalan kurumların hiçbirine uymuyordu. Sınırı sınıftan alıp maskeye taşıyan sınıfsız gösterim bu üç bedeni ortadan kaldırdı; eğik çizgili yazım da oradan geliyor.

Bölmenin tersi de var. Komşu ağları tek bir kısa önekte birleştirmeye üst ağ oluşturma deniyor; öneki 3 bit kısaltmak sekiz komşu ağı tek satıra indiriyor. RFC 4632’ye göre paket anahtarlamalı bir ağda yönlendirme durumunu küçültmenin bilinen tek yolu bu.

Uzayın her köşesi de bölünmeye açık değil. Dört milyarlık alanın içinden bazı bloklar kesilip özel işlere ayrıldı, ve bir adresin hangi bloğa düştüğünü tanımak arıza ararken ilk adımdır: