Ağlar'a “Sen”i Katmak

Giriş: 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, transport layer’ında, bir switch’in MAC tablosunda, bir router’ın 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 yetmiş 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, kitabın farklı yerlerinde tek tek kapatacağız; son sözde de üçünü birlikte toparlayacağız.

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?

Okumadan önce

Bölümler birbirine sorularla bağlı: her biri bir öncekinin sonunda sorulan soruyla açılıyor, o yüzden sıra bozulmadan okumak en kolayı. Konuyu zaten biliyorsan yol haritasından istediğin durağa atlayabilirsin; bir bölüm önceki bir durağa dayanıyorsa oraya bağlantı veriyor.

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.

Bazı terimleri İngilizce bıraktım: switch, router, frame, flow ve OSI katmanlarının adları (application layer, transport layer gibi). Komut çıktılarında, belgelerde ve iş ilanlarında karşına bu adlarla çıkacaklar. Her birini ilk ele aldığım yerde Türkçe açıklıyorum; Türkçesi yerleşmiş olanlarda (adres, bağlantı, önbellek) Türkçeyi kullanıyorum.

Kod bloklarındaki komutları çalıştırmak zorunda değilsin; çıktılarını metnin içinde gösteriyorum. Denemek istersen komutların çoğu Linux ve macOS’ta olduğu gibi çalışıyor; Windows’ta farklı olanların bir kısmının karşılığını da yanlarına yazdım.

Her bölümün başlığının altında okuma süresi yazılı. Klavyede j bir sonraki, k bir önceki bölüme geçiriyor.

Yolun haritası

Bölümleri on iki kısma ayırdım. İlk dokuz kısım yolculuğun kendisi; her birinin adı isteğin o sırada nerede olduğunu söylüyor. Yolculuk 70. bölümde bitiyor, kitap bitmiyor. Son üç kısım aynı fikirleri yolun kenarındaki başka ağlarda sürdürüyor: isteği tarayıcı olmadan kendi kodunla göndermek ve bir protokol tasarlamak, ses ve görüntünün ağdan nasıl aktığı, pille yaşayan kablosuz sensör ağları. En sonda da bütün kitabı toparlayan bir kapanış bölümü var.

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 RFC 3986 tanımlıyor ve belgenin kendisi de “adres” demiyor: URI, açılımıyla Uniform Resource Identifier, tekbiçimli kaynak tanımlayıcısı. Gündelik dilde aynı şeye URL deniyor; standart URL’yi, kaynağın yerini de söyleyen URI alt kümesi olarak tanımlıyor ve adres çubuğuna yazdığın her şey o alt kümeye giriyor.

Ş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 (authority) makineyi gösteriyor ve yanında isteğe bağlı bir port taşıyabiliyor: aynı makinede çalışan programlardan hangisine gidileceğini söyleyen bir sayı. Portu 6. bölümde ayrıntısıyla açacağız. 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 bedeli, bağlantıların uyarı vermeden kırılması. 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ı sunucunun 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ış:

Tablodaki 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 proxy’ler daha erken kesebiliyor; 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 ve her satırı yolun başka bir durağı kullanır: şehri ayırma merkezi, sokağı dağıtım şubesi, kapı numarasını postacı. Adres de böyle katmanlı. Şemayı tarayıcı okuyor, makine adını resolver (ad çözümleyici), yolu karşıdaki sunucu. Benzerlik gizlilikte kırılıyor: zarfın her satırını eline alan herkes okuyabilir, oysa https ile giden bir istekte yol ve sorgu şifreli taşınıyor. Aradaki cihazlar en fazla makine adını görebiliyor.

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ı (IDN). Tarayıcı böyle bir adı Punycode adlı bir kodlamayla ASCII’ye çeviriyor 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. Alan adlarında büyük-küçük harf farkı olmadığı için ad kodlanmadan önce küçük harfe indiriliyor. Unicode’un dile bakmayan kuralında noktalı büyük İ’nin küçüğü düz i değil, i ile üstüne binen ayrı bir nokta işareti. Kodlama o noktayı da taşıyor, bu yüzden İstanbul.com ile istanbul.com iki ayrı alan adı: ikincisi olduğu gibi ASCII kalıyor, birincisi xn-- ile başlıyor. Yoldaki büyük-küçük harf tuzağında gördüğün Türkçe i, burada alan adının içine taşınmış oluyor.

Unicode’un zenginliği bir güvenlik sorunu da 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 alfabeleri karıştırıyorsa ya da tanınmış bir adı taklit ediyorsa, adres çubuğunda okunur hâli yerine xn-- hâli gösteriliyor. Çirkin görünmesi de kasıtlı.

Tarayıcı önce kendi cebine bakıyor

Tarayıcının ilk işi ağa çıkmak değil. Önce bu yolculuğu hiç yapmadan kurtulup kurtulamayacağına, kurtulamıyorsa yolu nasıl kısaltacağına bakıyor. Dört cebi var ve biri Enter’a basmadan önce bile devrede.

İlki 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. Enter’a bastığında yolun bir kısmı çoktan yürünmüş oluyor. Tahmin yanlışsa gitmek istemediğin bir sunucu senin geldiğini görmüş oluyor.

İkincisi 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. Mekanizmanın adı HSTS (HTTP Strict Transport Security): site bu isteği bir yanıt başlığıyla bildiriyor, tarayıcı da onu süresi dolana kadar hatırlıyor. Kuralın bir kör noktası var: siteye ilk kez gidiyorsan o başlığı henüz hiç görmedin. İlk isteği de korumak için tarayıcılar, kendi içlerine gömülü bir ön yükleme listesiyle (preload list) geliyor.

Adres kesinleşince sıra kopyalara geliyor. 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 kopyayı çöpe atmıyor: isteğe elindeki kopyanın tarihini ekleyip “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ı 14. bölümde web önbelleğini kurarken açacağız.

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; her birinin de kendi adresi var.

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. Etikete async ya da defer ekleyen geliştirici bu beklemeyi kaldırmış oluyor: betik arka planda iniyor, ayrıştırma durmuyor.

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 round-trip time (gidiş-dönüş süresi) istiyor; kısaca RTT.

İ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 metinden ibaret:

GET /bolum/yol?dil=tr HTTP/1.1
Host: aglar.emircandemir.com
Accept: text/html
Accept-Language: tr
If-Modified-Since: Thu, 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 burada.

Aynı sorun şifreli bağlantılarda bir kez daha çıkıyor. Sunucu, kimliğini kanıtlayan bir belge sunuyor; adı sertifika ve her site için ayrı. Hangi sertifikayı sunacağına karar verebilmesi için siteyi bilmesi gerekiyor, ama sertifika gelmeden istek de şifrelenemiyor. Bu düğümü 11. bölümde şifreli bağlantıyı kurarken çözeceğiz.

Metin bir sokete yazılacak. Soket, işletim sisteminin uygulamaya verdiği bir tutamak; uygulama oraya yazıyor, gerisini işletim sisteminin çekirdeği, yani kernel hallediyor. Bu tutamağın kernel 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

• 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: tahmin, güvenli bağlantı listesi, bellek ve disk. 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 bir ihmal değil, ölçek. Yolu baştan sona bilen bir merkez yok; her kutu yalnızca paketi hangi komşusuna vereceğini biliyor. İsimle çalışan bir ağda her kutunun dünyadaki bütün isimlerin nerede durduğunu bilmesi gerekirdi.

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 (forwarding) diyoruz. İletirken bakılan tabloya da iletme tablosu (forwarding table) deniyor; Türkçede çoğu zaman yönlendirme tablosu diye de geçiyor. O tabloyu doldurmak ise küresel bir iştir, yavaştır, kutuların birbiriyle konuşmasıyla yürür; buna da routing diyoruz. İletmeyi 39., routing’i 42. bölümde ayrı ayrı açacağız. Kutuların adını da burada verelim. Bunlara router (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. 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ü hız; onu görmek için önce yoldaki kutunun nasıl çalıştığına bakmak gerekiyor.

Kutu, paketin tamamı kendisine ulaşmadan onu bir sonraki kabloya itmeye başlamıyor; paketin sonuna eklenen hata denetimini ancak paket bütünüyle gelince yapabiliyor. Bu çalışma biçiminin adı store-and-forward, yani sakla ve ilet: her durakta paketin tamamı bir kez daha kabloya itiliyor.

Mesaj bölünmeseydi bu bedel ağır olurdu. 10 megabitlik bir mesajı, saniyede 10 megabit taşıyan üç hattan geçirdiğini düşün. Bütün hâlinde gönderilen mesaj her durakta bir saniye bekliyor ve varış üç saniye sürüyor. Bin pakete bölündüğünde ise ilk paket üçüncü milisaniyede varıyor, arkadakiler onu boşluk bırakmadan izliyor ve son paket bir saniyeyi iki milisaniye geçe varıyor. Aynı hatlar, aynı mesaj, neredeyse üç kat hızlı varış. Sebep, bölünmüş mesajın aynı anda birden fazla kabloda bulunabilmesi: baştaki paket üçüncü hattayken sondaki hâlâ birincide ilerliyor.

Mesajı paketlere bölüp her paketi durak durak sakla ve ilet kuralıyla taşıyan bu düzenin adı paket anahtarlama (packet switching). Router, bu düzenle çalışan kutudur: paketin tamamı gelmeden onu bir sonraki kabloya itmez, çıkış kablosunu da iletme tablosundan seçer.

Ö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. Bu yüzden devre anahtarlama garantili bant genişliği veriyor: hatta başkaları ne yaparsa yapsın senin hızın değişmiyor. Garanti bağlantı kurulurken veriliyor; yolda ayrılacak pay kalmadıysa bağlantı hiç kurulmuyor.

Payı ayırmanın iki klasik yolu var ve ikisi de tek bir hattı birden çok devreye bölüyor. Frekans bölmede (FDM) 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 (TDM) 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. İkisini 54. bölümde ayrıntısıyla göreceksin.

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. Şerit hattın kapasitesine, ayrılmış şerit devreye, giriş rampasındaki bekleme kuyruk gecikmesine, yolun en dar kesiti ise darboğaza karşılık geliyor. Benzetmenin tutmadığı yer taşma anı: 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 multiplexing. 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:

İletimle yayılım arasındaki 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.

İletimle yayılımın farkını zaman ekseninde görmek istersen:

Kuyruk neden birden büyü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 bilerek basitleştiriyorum: tıkanıklığı “kuyruk dolar, paket silinir” diye geçiyorum. Uçların buna nasıl tepki verdiği ayrı bir konu; 68. bölümde 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.

Evindeki hattı yükselttiğin hâlde hiçbir şeyin hızlanmaması çoğu zaman bununla açıklanıyor. 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 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 ilk durakta gördüğün 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

• Yol, iki ucu olan bir tel değil; bağımsız kararlar veren kutuların ağı. Karar paket başına, iletme tablosuna bakılarak verildiği için sıra bile garanti değil.
• Mesaj paketlere bölünüyor: kablo paylaşılabiliyor, bozulan parça tek başına yeniden gönderiliyor ve store-and-forward’ın her durakta ödettiği bekleme, paketler art arda aktıkça neredeyse kayboluyor.
• Devre anahtarlama garantili bant genişliği veriyor, karşılığında boş kapasite tutuyor ve payı frekansta (FDM) ya da zamanda (TDM) bölüyor. Paket anahtarlamanın kazancı istatistiksel multiplexing, bedeli garantisizlik.
• Dört gecikme üst üste biniyor: işleme, kuyruk, iletim ve yayılım. İletim paket boyu bölü hat hızı, yayılım mesafe bölü ortamdaki hız; hattı hızlandırmak yalnızca iletimi 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.

Bu çözüm gerçekten denendi ve birkaç yüz makine için işe yaradı. 1980’lerin ortasına kadar ağdaki bütün makinelerin adı HOSTS.TXT adlı tek bir dosyada duruyordu. Dosyayı Kaliforniya’daki SRI’ın ağ bilgi merkezi tutuyordu ve herkes onu düzenli aralıklarla oradan indiriyordu. Bugün her işletim sisteminde duran hosts dosyası o düzenin kalıntısı. Milyarlarca kayıt için ise işe 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. Ortaya çıkan sisteme DNS (Domain Name System, alan adı sistemi) deniyor. 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. Telde her etiketin önünde uzunluğunu söyleyen tek bir bayt duruyor ve o baytın en üst iki biti başka bir işe, adların tekrarını kısaltan bir sıkıştırma işaretine ayrılmış. Geriye kalan altı bit en fazla 63 sayabiliyor. 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: posta da adresi genelden özele, şehirden kapıya doğru okur; alan adı da sağdan sola, en genel parçadan başlayarak okunuyor. Fark şu: zarftaki bütün durakları tek bir kurum işletir, burada her durağın sahibi ayrı.

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 çoğu sitede 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; 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 stub resolver denen ç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; bu bilgiyi kimin dağıttığını 36. bölümde göreceğiz. 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ı porta, bağlantısız taşımayla, yani UDP ile 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 7. 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. EDNS(0) adlı bir uzantıyla bu sınır pazarlıkla büyütülebiliyor; 5. bölümde göreceğimiz imzalı cevaplar 512 bayta sığmadığı için o uzantı olmadan imzalama pratikte çalışmıyor. Bugün yaygın değer 1.232 bayt. 2020’de resolver ve sunucu yazılımlarının ortak kararıyla seçildi, çünkü bu boydaki bir cevap IPv6’nın en küçük paket boyuna bile bölünmeden sığı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 parçası 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 yukarıdaki tablonun kendisi: qr cevap olduğunu, rd özyineleme istendiğini, ra resolver’ın bunu yapabildiğini söylüyor. aa yok, demek ki cevabı alanın sahibi değil, aradaki resolver verdi. Resolver cevabı ister önbelleğinden bulsun ister o an zinciri yürüyerek, bu işareti hiçbir zaman koymuyor.

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, cevabın ek bölmesine, ns1.ornek.com için bir de A kaydı koyuyor ve döngü kırılıyor. Yetkili sunucu alanın dışında, mesela ns1.baskadns.net olsaydı, 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.

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

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

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ı 5. bölümde ölçeceğiz.

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

• 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.
• 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.
• Zincir kendi kendini kilitlemiyor: sunucu adının yanına iliştirilen tutkal kaydı ile yazılıma gömülü kök ipuçları, bir adı çözmek için önce başka bir adı çözme zorunluluğunu ortadan kaldırıyor.

Resolver zinciri yürüdü ve cevabı sana getirdi. Getirdiği şey çıplak bir sayı değil, türü ve ömrü olan bir satırdı. Peki aynı ada adresten başka neler yazılabiliyor?

Bölüm 4: DNS Kayıtları

Resolver’ın getirdiği şey çıplak bir sayı değildi, bir satırdı. O satırın bir türü vardı ve adres, türlerden yalnızca biri.

Aynı ada posta sunucusu da yazılıyor, takma ad da, port numarası da, hatta kimin sertifika verebileceği de. Peki bir ada kaç çeşit cevap asılabiliyor ve her biri kime ne söylüyor?

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 (TTL, saniye cinsinden), sınıf, tür, değer. Adın sonundaki nokta önceki bölümde 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ı. Kalıntısı hâlâ duruyor: 1970’lerin Chaosnet ağından kalan CH sınıfı bugün yalnızca bir sunucuya hangi yazılımı çalıştırdığını sormak için kullanılıyor (dig CH TXT version.bind). 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 NS ya da Windows’ta nslookup -type=MX ornek.com bu satırların türe göre süzülmüş hâlini döküyor. Eskiden hepsini tek seferde getiren ANY sorgusunu çoğu sunucu artık cevaplamıyor; RFC 8482 onu fiilen emekliye ayırdı, çünkü küçük bir soruya kocaman bir cevap döndürmek yükseltme saldırısının en sevdiği şeydi.

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 üçü ötekilere göre 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; 6. 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. Sitenin kimliğini kanıtlayan sertifikaları sertifika makamları basıyor; zincirin nasıl işlediğini 12. bölümde göreceğiz. Her 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 kullanılıyor, varsa şifreli istemci merhabası için hangi açık anahtar gerekiyor. 15. bölümde 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ı 38. 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. Sondaki /24, adresin ilk 24 bitinin, yani ilk üç sayısının sabit olduğunu söylüyor; blok, son sayısı 0 ile 255 arasında değişen 256 adresten oluşuyor. Bu yazımı 37. bölümde açacağız.

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öndericiye şüpheyle bakılır ve postası çoğu zaman spam klasörüne düşer.

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

Özet

• Her cevap bir kaynak kaydıdır: adı, yaşam süresi, türü ve değeri olan bir satır; sınıf alanı bugün pratikte hep IN.
• 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.
• Ters yön ayrı bir ağaçta yürüyor: adres ters çevrilip in-addr.arpa altına asılıyor; iki yönün uyuşması zorunlu değil, çünkü sahipleri farklı.
• Yetki bölgeye aittir: bölgenin künyesi SOA kaydıdır ve ikincil sunucular kopyayı ancak seri numarası büyüdüğünde çeker.

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 5: Ö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ı. Tarayıcının ya da işletim sisteminin deposundan gelen cevap sıfır tur harcıyor, resolver’ın deposundan gelen bir tur. 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 (TTL, time to live).

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 pencerenin süresi 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 kullanıcıya hiçbir bedel ödetmeden kullanabiliyor; faturayı kendi yetkili sunucuları ödüyor ve karşılığında hızlı taşınma esnekliği 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 aktığına da bakmak gerekiyor. 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, iki sorgu arasında geçen yedi saniye. 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ç olarak 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 ucuz bir hile daha eklendi: resolver sorulan adın harflerini rastgele büyük-küçük yazıyor ve cevapta aynı yazımı birebir geri bekliyor. Yönteme 0x20 deniyor, çünkü ASCII’de büyük ve küçük harf arasındaki fark tam bu değer, tek bir bit. Üçü birlikte 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. Buradaki imza kâğıttakine benziyor ama ondan güçlü: yalnızca alan sahibinin elindeki gizli bir anahtarla üretilebiliyor, herkesin görebildiği bir açık anahtarla ise doğrulanabiliyor. Kaydın tek bir harfi değişirse imza tutmuyor. Bunun matematiğini 10. bölümde göreceksin; burada ne işe yaradığı yetiyor. İ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. APNIC’in ölçümüne göre kullanıcıların yaklaşık %36’sı imzayı doğrulayan bir resolver’ın arkasında. Öteki uçta tablo tersine dönüyor. Cloudflare’in 1.1.1.1 resolver’ının verdiği cevapların yalnızca %8 kadarı imzalı bir bölgeden geliyor ve bu oran yıllardır yerinde sayıyor. Hem alanın imzalı olduğu hem de istemcinin cevabı korumalı istediği sorguların payı ise aynı resolver’da Temmuz 2026’da %0,62’ydi.

İ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, yani o anahtardan hesaplanan kısa ve pratikte taklit edilemeyen bir parmak izini 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ı. İkinci değişim 11 Ekim 2026’da: Ocak 2025’ten beri kök bölgesinde yayımlanan yeni anahtar o gün tek imzalayan anahtar oluyor. Yeni anahtarı tanımayan doğrulayıcı bir resolver o günden sonra hiçbir adı çözemiyor.

İ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.

Sızıntının bir kısmını resolver kendi başına küçültebiliyor. Zinciri yürürken köke www.ornek.com adının tamamını sormak zorunda değil; köke yalnızca com alanını, com sunucusuna yalnızca ornek.com’u soruyor. Her basamak yalnızca kendi işini yapmaya yetecek kadarını görüyor. Yönteme QNAME minimization deniyor ve bugün yaygın resolver’ların çoğunda varsayılan olarak açık.

Sorguyu yoldaki gözlemciden gizlemek içinse onu şifrelemek gerekiyor. Bunun için birkaç taşıma önerildi ve hepsine birden şifreli DNS diyoruz.

Fark son sütunda. İlkinin kendi portu 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; 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 11. 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ı. Cloudflare’in 1.1.1.1 resolver’ına gelen sorgularda 2026’nın ikinci çeyreğinde DoT’un payı %6,33, DoH’unki %5,75’ti; DoH bir yılda yaklaşık üçe katlandıktan sonra tırmanışı duraksadı. Şifreli sorguyu en baştan destekleyen bir resolver’da bile sorguların sekizde yedisi hâlâ açık gidiyor.

Özet

• 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. İsabet oranını ise sürenin kendisi değil, süre içinde gelen soru sayısı belirliyor.
• Cevap varsayılan hâlde imzasız. İmzalama kaynağı doğruluyor ama gizlemiyor; imzalayan taraf da 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 6: 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. Bina makinenin adresine, daire numarası porta, dairede oturan kişi ise o portu dinleyen sürece karşılık geliyor.

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.

Port numarasını taşıyan katmanın adı transport layer (taşıma katmanı): veriyi bir makineden ötekine değil, bir programdan ötekine ulaştıran katman. Ağın bütün katmanlarını 18. bölümde sırayla göreceğiz; şimdilik adını bilmek yetiyor.

Programın bu katmana açılan ucuna soket deniyor: işletim sisteminin bir program için açtığı, adresi ve portu olan bir uç. Bir konuşmanın iki ucunda iki soket durur. Soket iki cihazı değil iki programı birbirine bağlar; uçlar çoğu zaman iki ayrı makinede olur, ama aynı makinedeki iki program da birbirine soketle bağlanabilir. 71. bölümde yazacağın örneklerin çoğu tam da böyle, tek bir makinenin içinde konuşuyor.

Numaranın kaç basamak olabileceği de bu katmanın başlığındaki alanın genişliğine bağlı. Her parçanı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ı port.

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 portta oturduğunu bilmek, bir firewall (güvenlik duvarı, 49. bölüm) 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.

Kural, çok kullanıcılı eski Unix makinelerinden kalma. O dönemde bazı hizmetler, düşük numaralı bir porttan gelen bağlantının karşı makinenin yöneticisi tarafından açıldığını varsayıp ona parola sormadan güveniyordu. O güven çoktan geçersiz; bugün sınır bir ayar hâline geldi. Linux’ta aşağı çekilebiliyor, macOS ise 2018’den beri çoğu durumda bu kısıtı uygulamıyor.

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 portun açık olması orada beklediğin hizmetin çalıştığını kanıtlamıyor; yalnızca bir şeyin dinlediğini gösteriyor.

Aynı porttan 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 router port numarasına bakmak zorunda değil. Port, yalnızca iki uçta anlam taşıyor.

Cevap, transport layer’ı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 demultiplexing deniyor. Gönderen taraftaki karşılığı, pek çok soketin verisini aynı kablodan çıkarmak, yani multiplexing.

Dörtlü ayrım, bağlantı kuran taşımanın kuralı. Bağlantısız taşımada kernel, parçayı teslim edeceği soketi çoğu zaman yalnızca hedef adres ile hedef porta bakarak seçiyor; farklı istemcilerden gelen parçalar aynı sokete düşüyor ve kimden geldiklerini uygulama kendisi ayıklıyor. İki taşımanın farkını 7. bölümde açacağız.

Four-tuple’da görünmeyen gizli bir beşinci sütun daha var: protokol. Port numarası transport layer’a ait ve her taşıma protokolünün kendi numara uzayı var. Yani TCP’nin 443’ü ile UDP’nin 443’ü aynı port değil, birbirinden tamamen bağımsız iki port. Aynı makinede biri açık öbürü kapalı olabilir; ikisini iki ayrı süreç dinleyebilir. “53 açık” cümlesi bu yüzden eksik: hangi protokolde açık olduğunu söylemeden bir şey ifade etmiyor. HTTPS’in hem TCP hem UDP 443’te yaşayabilmesi de bu sayede 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 firewall’da 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                    socket()
2. yerel adres ve porta bağla          bind()     -> 203.0.113.9:443
3. gelen bağlantıları beklemeye başla  listen()
4. bekleyeni kabul et                  accept()   -> YENİ bir soket doğar

Asıl nokta son adımda. 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; port numarası ise hâlâ tek. Bu dört çağrıyı 71. bölümde kendi yazdığın bir sunucuda çalıştıracaksın.

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 interface’ler (ağ arayüzleri)” 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 interface’lere açılan bir yönetim paneli, olması gerekenden çok daha geniş bir kitleye görünür oluyor.

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. Firewall’ları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 kernel 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.

Tavan yalnızca açık bağlantıları saymıyor. Yukarıdaki çıktıda görünen TIME-WAIT durumu, kapanan bir bağlantının four-tuple’ının hemen serbest bırakılmadığını, bir süre beklemede tutulduğunu gösteriyor. 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. Standardın öngördüğü sürenin neden dört dakika olduğunu 8. bölümde el sıkışmayı kurarken hesaplayacağız; Linux bu süreyi 60 saniyede tutuyor.

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 proxy düşün. Linux’taki 60 saniyelik beklemeyle aynı anda beklemede duran four-tuple sayısı 500 × 60 = 30.000 eder; havuzda ise 28.232 numara var. Havuz bir dakika dolmadan tükenir ve yeni bağlantı açılamaz. Hata iletisi “Cannot assign requested address” olur, oysa hedef sunucu turp gibi ayaktadır. Sıradan bir kullanıcı bunu hiç görmez; tek bir arka uca saniyede yüzlerce bağlantı açan bir proxy görür.

Soketin kernel tarafını burada kapalı kutu bırakıyorum: tamponların nerede durduğunu ve kopyalamanın maliyetini 22. bölümde ağ kartına indiğimizde, gelen verinin hangi kuyruklardan geçip uygulamaya vardığını da 66. bölümde açacağız.

Özet

• 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 port var.
• Numara ile hizmet arasındaki bağ gelenek. Standart üç aralık tanımlıyor ama açık bir port, 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 kernel seçiyor, dinamik aralıktan ve tahmin edilemez biçimde; havuzun sonu, beklemedeki bağlantılar da sayıldığı için, tek bir hedefe açılan bağlantı sayısına sınır koyuyor.

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

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

Vermiyor. Taşıma protokollerinin kimi teslimi, sırayı ve hızı üstleniyor, kimi hiçbirini. En kolayı hiçbir vaatte bulunmayanı: isim sorgusunun 53 numaralı porta “bağlantısız taşımayla”, yani UDP ile gittiğini söyleyip geçmiştim.

UDP’nin tanımı 1980 tarihli RFC 768’de duruyor ve belgenin tamamı üç 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. IPv4’te tavan biraz daha aşağıda, 65.507 bayt, çünkü IP paketinin kendi uzunluk alanı da 16 bit ve kendi başlığını da aynı sayının içine sığdırmak zorunda. Pratikte bu sınıra hiç yaklaşılmıyor: yol üstündeki en küçük frame’e (ç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 (Türkçesiyle sağlama toplamı) ve ilginç olan o. Kitabın geri kalanında iki adı da göreceksin; ikisi aynı şey.

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ı pseudo-header 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 router’ın belleğinde hedef adres bozulursa paket yanlış makineye düşer; o makinenin UDP katmanı, kendi adresini pseudo-header’a koyup hesapladığında checksum tutmaz ve paketi atar. Adresi hesaba katmayan bir checksum bu hatayı hiç göremezdi.

Bunun bir bedeli var ve adını koymak gerekiyor: transport layer, 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 transport layer checksum’ı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.

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; IPv6 üstünde ise checksum zorunlu, çünkü orada IP başlığının kendi sağlaması yok.

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: 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. Stream 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: kernel artık o sokete hangi hataların ait olduğunu bilebiliyor ve karşı makinenin “bu portta kimse yok” cevabını sana iletebiliyor. Sabitlemezsen o cevap Linux’ta ve BSD ailesinde sessizce düşüyor. Windows bu konuda ayrışıyor ve hatayı sabitlenmemiş sokete de iletiyor; 71. bölümde bunu çalışan bir kodda göreceksin.

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 kernel’da değil uygulamada. Sebebini 15. 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

• 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; mesaj sınırları da 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 8: Üç Adımlı El Sıkışma

Portu 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. Bu işi bağlantı kuran taşıma yapıyor ve adı TCP (Transmission Control Protocol).

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 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 bunun karşılığı. İ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ı adres ve 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 67. 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. Ardından gelen dört bit ayrılmış (reserved) ve bugün kullanılmıyor. 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 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 router tarafından da bildirilebiliyor. Mekanizmanın adı ECN ve 40. bölümde kuyrukları yönetirken açılıyor; ECE ile CWR o bildirimin transport layer’daki 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 67. bölümde kayan pencereyi kurarken, zaman damgası ise 69. 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. Eski sistemlerde bu kuyruk yalnızca birkaç düzine kayıt tutabiliyordu. Bugün yüzlerle binler arasında ama saldırganın saniyede gönderebildiği SYN sayısının yanında yine küçük. Saldırının ucuzluğu buradan geliyor.

Kayıt sonsuza kadar durmuyor. Linux, cevapsız kalan SYN-ACK’i beş kez yeniden gönderiyor ve her seferinde bekleme süresini ikiye katlıyor; kayıt ancak bir dakika kadar sonra düşüyor. Ama o süre 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ı. Linux bu yüzden SYN cookie’yi varsayılan olarak yalnızca kuyruk taştığında devreye sokuyor. 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 14. bölümde yeniden göreceğiz.

Bu üç mesajın faturası ne kadar?

Bedeli ölçmenin birimi belli: 1. bölümde tanıştığın RTT, yani gidiş-dönüş süresi. El sıkışmanın maliyeti bir 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 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 QUIC gibi protokoller ve oturum biletiyle kurulumu sıfır gidiş-dönüşe indiren yöntemler bu bedeli hedef alıyor; ikisini de 15. bölümde göreceğiz.

İ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 router’dan router’a 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ı, kernel 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 (MSL) iki katı kadar bekliyor. RFC 9293 o ömrü 2 dakika sayıyor, yani bekleme 4 dakika. Linux bu süreyi pratikte fazla uzun bulup 60 saniyeye sabitlemiş.

Bu beklemenin 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. 6. bölümdeki geçici port tükenmesinin arkasında da bu bekleme duruyor.

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

• Üçü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 9: 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.

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ğ interface’i, yanından geçen bütün paketleri okuyup kaydediyor; parolalar dahil. Herkesin aynı ortamı paylaştığı yerlerde bu doğrudan çalışıyor: bir kablodan gelen sinyali bütün kablolara tekrarlayan hub’lı eski Ethernet’te ve şifresiz kablosuz ağda. Bugün kabloların birleştiği yerde bir switch duruyor ve frame’i yalnızca alıcısının kablosuna iletiyor; bunu nasıl öğrendiğini 27. bölümde göreceğiz. Switch’li bir ağda kart çoğu zaman yalnızca kendisine ve herkese gönderilenleri görüyor; saldırganın önce trafiği kendine çekmesi gerekiyor.

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. TLS’i bu bölümde ve sonraki üç bölümde parça parça kuracağız.

Ş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. Kasanın mekanizması algoritmaya, kombinasyon anahtara, içine koyduğun belge açık metne, kilitli kasa ise şifreli metne karşılık geliyor. Benzetmenin çöktüğü yer kombinasyonun yolculuğu: 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ı kısa: 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, her seferinde 128 bitlik tek 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. Yayma (diffusion), açık metnin tek bir bitindeki değişikliğin çıktının her bitine dağılması; karıştırma (confusion) ise anahtar ile şifreli metin arasındaki ilişkinin istatistiksel olarak izlenemez olması. Tek bir tur zayıf; on turdan sonra girdiyle çıktı arasındaki bağı izlemek 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.

Aşağıdaki tabloda geçen 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. Aşağıdaki üç kare aynı resmin piksel baytları: solda özgün hâli, ortada AES-128 ile ECB kipinde şifrelenip yeniden resim olarak okunmuş hâli, sağda aynı işlemin CBC kipindeki sonucu.

Ortadaki karede renkler gitti ama kilit yerinde duruyor. Aynı renkteki bölgede aynı 16 baytlık bloklar tekrar ediyor ve ECB her birini hep aynı şifreli bloğa çeviriyor; zemin, halka ve gövde birer desene dönüşüyor ve resmin hatları şifreli çıktıda okunmaya devam ediyor. Şifreleme yapıldı ama içerik hâlâ tanınıyor. CBC her bloğu şifrelemeden önce bir öncekinin şifreli hâliyle karıştırdığı için tekrar eden şifreli blok kalmıyor ve çıktı düz gürültüye dönüyor.

Deney sıkıştırılmamış piksellerle yapılıyor. Sıkıştırılmış bir PNG ya da JPEG’de tekrar eden bayt dizileri zaten ayıklandığı için sızacak desen de çok azalır. Gerçek mesajlar ise tekrarla dolu: aynı başlıklar, aynı alan adları, aynı dolgu. Bu yüzden ECB mesaj şifrelemek için hiçbir güncel protokolde yer almı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 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; üstelik 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 havada ne parola ne de oturum anahtarı dolaşıyor: iki taraf taze AES anahtarını, paroladan ve havada açıkça takas edilen rastgele sayılardan kendi başına türetiyor. O türetmenin adımlarını 32. bölümde açacağım. Uzaktaki bir sunucu için cevabı 10. 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: 1977’de FIPS 46 olarak yayımlanan bir ABD federal standardı. NIST onu son kez 1999’da yeniden onayladı ve 2005’te geri çekti. 56 bitlik bir anahtar kullanıyor ve girdiyi 64 bitlik açık metin blokları hâlinde alıyor.

DES de bir blok şifresi ve o da çıplak kullanılmıyor; yukarıdaki tablodan tanıdığın CBC kipi ilk kez onun etrafına sarıldı.

1999’da RSA şirketinin açtığı bir yarışmada (DES Challenge III), 56 bitlik anahtarla şifrelenmiş bir cümle kaba kuvvetle 22 saatte çö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 yeni standardı kapalı kapılar ardında yazmadı; 1997’de dünyaya açık bir yarışma düzenledi ve üç yıllık elemenin sonunda Belçikalı iki kriptografın Rijndael adlı tasarımını seçti. AES adını alan bu şifre DES’in yerini aldı ve bugün hâlâ orada. Blok boyu iki katına, anahtar ise en az 128 bite çıktı; 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ı anahtar altında aynı başlangıç değerini iki kez kullanmamak. Bunun aracı nonce, yani ömür boyu yalnızca bir kez kullanılan sayı. Yukarıda CTR kipinde tekrarlanan sayacın içeriği nasıl açığa çıkardığını gördün; nonce o kazayı imkânsız kılıyor. Nonce kaydın sıra numarasına bağlandığında bir kazanç daha doğuyor: kaydedilip sonra yeniden gönderilen bir kayıt, alıcının beklediği numarayla eşleşmediği için doğrulamadan geçemiyor. Tekrar oynatma (replay) saldırısını kıran şey bu.

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 aynı anahtar altında yaklaşık 24 milyon tam boy kayıt şifrelenebiliyor; sonrasında anahtarın tazelenmesi gerekiyor ve TLS 1.3 bunu bağlantıyı kesmeden yapabiliyor. 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. Dikkatli bakarsan şifreli çıktının başında yine de bir ad seçeceksin: example.com. O ad bağlantı kurulurken düz metin gidiyor; sebebini 11. bölümde göreceğiz.

Özet

• 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; paylaşılan bir ortamda onu okumak için karışık moda alınmış bir interface 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 aynı anahtarla ş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 10: 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. Benzetmenin tutmadığı yer ters yön: kasada açan kombinasyonla kilitlemek anlamsızdır, burada ise özel anahtarla kilitlenen şeyi herkes açık anahtarla açabiliyor. Bu tuhaflık bölümün sonunda imzayı doğuracak.

Ş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 birkaç yıl önce Birleşik Krallık’ın istihbarat kurumu GCHQ’da da bulunmuştu ama 1997’ye kadar 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 443 numaralı porta 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 2048 bitlik bir anahtar için asalların her biri 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 4.782.969 ediyor ve 143’e bölündüğünde kalan 48. Şifreleme yalnızca n’den küçük m için tanımlı; RSA’nın uzun veriyi doğrudan şifrelemek için kullanılmamasının sebeplerinden biri bu.

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. Açık yarışmalarda bugüne kadar çarpanlarına ayrılabilen en büyük RSA sayısı 829 bit; o da 2020’de, binlerce işlemci yılı harcanarak çözüldü.

Varsayımı sarsabilecek tek aday kuantum bilgisayar. Yeterince büyük bir kuantum bilgisayar, Shor algoritmasıyla hem çarpanlara ayırmayı hem de birazdan göreceğin Diffie-Hellman’ın dayandığı problemi çözebilir. Böyle bir makine henüz yok ama bugün kaydedilen trafik yarın çözülebilir; bu yüzden anahtar uzlaşması şimdiden kuantuma dayanıklı algoritmalarla eşleniyor.

İ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ü 11. bölümde açacağız.

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

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.

İkisi de bugün kırık: aynı özeti veren iki ayrı girdi üretmek MD5’te saniyeler, SHA-1’de büyük ama satın alınabilir bir hesap gücü istiyor. Bugünkü imzalar ve sertifikalar bu yüzden 256 bitlik SHA-256 ile atılıyor; iki eski ad burada yalnızca fikri anlatmak için duruyor.

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 şartlarda. Checksum’da aynı değeri veren ikinci bir mesaj üretmek kolaydır; kriptografik özette ise bu hesap açısından yapılamaz olmalıdır. Aynı özeti veren herhangi iki mesajı bulmak da öyle; MD5 ile SHA-1’i emekliye ayıran şey bu ikinci şartın çökmesiydi. 16 bitlik bir toplam iki şartı da 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. “Özeti özel anahtarla şifrelemek” anlatımı RSA’ya özgü; eliptik eğri imzaları aynı sonuca başka bir hesapla varıyor ama sözleşme aynı kalıyor: imzayı yalnızca özel anahtar üretebilir, herkes açık anahtarla doğrulayabilir.

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 MITM 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 12. bölümde kuracağız.

Özet

• 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 11: 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 neyi pazarlıyor?

Kilit nereye takılıyor?

Kilidin adı TLS (Transport Layer Security) ve adındaki “transport layer” yanıltıcı: kilit transport layer’ın içine takılmıyor, onun bir üstünde, programların kendi dilini konuştuğu application layer’da (uygulama katmanı) kuruluyor. Uygulama bir TLS kitaplığı çağırıyor, kitaplık da TCP’yi çağırıyor; sıra 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 router’lar 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 MITM 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.

ClientHello’nun bir uzantısı daha var ve ilk durakta bıraktığım düğümü o çözüyor: SNI (Server Name Indication, server_name uzantısı). Aynı adres ve portta yüzlerce siteyi barındıran bir sunucu hangi sertifikayı sunacağına ancak istenen adı görerek karar verebilir; ama sertifika gelmeden şifreleme de kurulamaz. Çözüm, adı ilk mesajda, henüz şifresizken göndermek. Bedeli şu: ClientHello açıkta gittiği için yolun üstündeki herkes hangi siteye bağlandığını görüyor. Şifreli ad çözmenin kapatamadığı sızıntı buydu. Onu da kapatan uzantının adı ECH (Encrypted Client Hello): sunucunun açık anahtarı DNS’teki HTTPS kaydından alınıyor ve ad o anahtarla şifrelenip gönderiliyor. Yol üstündeki kutu artık yalnızca barındırma sağlayıcısının herkese açık ön adını görüyor, asıl adı değil.

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 12. 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. 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ı, TLS 1.2 standardının kendi metninde tanımladığı 37 takımdan 5’e indi; sonradan eklenenlerle o sürümün kayıt defteri yüzlerce takımı buluyordu. 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 (forward secrecy) 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 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; POODLE ve Lucky Thirteen o sınıfın en bilinen örnekleri.

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 o kuralı 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. 10. bölümdeki openssl s_client komutunu grep olmadan çalıştır ve tam çıktıda üç satıra bak: Protocol, Cipher ve Negotiated TLS1.3 group (eski OpenSSL sürümlerinde sonuncusunun adı Server Temp Key). Sırasıyla pazarlıkla seçilen sürümü, şifre takımını ve anahtar uzlaşma grubunu gösteriyorlar.

Özet

• Kilit application layer’ı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ı stream’i 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 12: 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 router 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ıyla sertifikanın imzasını doğruluyor; imza tutuyorsa belgede açıkça yazan açık anahtarın gerçekten o varlığa ait olduğuna güvenebiliyor. Kazancı 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 çakışmaya dayanıklı olmasını şart koşuyordu ve bu şartın sertifikada neden hayati olduğu 2008’de görüldü. Araştırmacılar aynı MD5 özetini veren iki belge üretti, zararsız olanını bir otoriteye imzalattı ve imzayı ötekine, kendi yazdıkları sahte bir ara otorite sertifikasına taşıdı. 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.

MITM saldırısında matematik doğru çalışıyordu; yanlış olan, açık anahtarın sahibiydi. Sertifikanın kapattığı boşluk 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 çıpaları 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 çıpalarını kim koyuyor? Somut bir liste var. Mozilla’nın CCADB üstünden yayımladığı kök deposu raporunda Ağustos 2026 itibarıyla 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. Firefox ve bu listeyi kullanan pek çok Linux dağıtımı, senin adına kırk yedi kuruluşa güveniyor. Chrome, Apple ve Microsoft kendi depolarını tutuyor ama listeler büyük ölçüde örtüşüyor. 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 çıpası 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. Yine de verildiği oluyor: Hollandalı DigiNotar 2011’de sahte Google sertifikaları yüzünden depolardan düştü ve birkaç hafta içinde iflas etti. Symantec’in ve Entrust’ın sertifikaları da yıllar içinde aynı yoldan geçti.

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 (Online Certificate Status Protocol). Üç 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; geçerlilik süresi de cevabın içinde yazılı olduğu için eskisini sonsuza kadar süremiyor. 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. Saldırgan da bunu kullanabilirdi: zımbayı yutması yeterliydi. OCSP Must-Staple uzantısı bu açığı kapatmak için sertifikaya “benim cevabım her zaman zımbalanmış gelecek” diye yazıyordu; cevap gelmezse tarayıcı bağlantıyı reddediyordu.

İ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. Chrome 2018’den beri günlüğe yazıldığını kanıtlamayan bir sertifikayı hiç kabul etmiyor. Kendi alan adını crt.sh gibi bir arama sitesinde sorgularsan o ada verilmiş her sertifikayı listelenmiş görürsün.

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.

OCSP’nin hikâyesinin sonu beklenmedik oldu: emekliye ayrılıyor. Otoritelerin ortak kurallarını yazan CA/Browser Forum 2023’te kararı tersine çevirdi; Mart 2024’ten beri iptal listesi yayımlamak zorunlu, OCSP ise isteğe bağlı. En çok sertifika veren otorite olan Let’s Encrypt, zirvede ayda 340 milyar sorgu karşılayan OCSP hizmetini Ağustos 2025’te tamamen kapattı ve Must-Staple taşıyan sertifika vermeyi bıraktı. Gerekçe ikinci kusurdu: sorguyu kim işletirse işletsin, kimin hangi siteye girdiğini görüyor.

İptali tarayıcılar kendi üstüne aldı. Firefox, CT günlüklerindeki bütün sertifikaların iptal durumunu sıkıştırılmış tek bir yapıda (CRLite) kullanıcıya indiriyor; günde ortalama 300 kilobayt. Tarayıcı artık kimseye soru sormadan, kendi elindeki tabloya bakarak karar veriyor. Chrome da seçtiği iptalleri benzer bir listeyle (CRLSet) dağıtıyor.

İptalin yavaş ve güvenilmez olduğu kabul edilmiş durumda; asıl çözüm başka yerden geliyor. Sertifika ömrü hızla kısalıyor. 15 Mart 2026’dan önce azami ömür 398 gündü, bugün 200 gün. Takvim 15 Mart 2027’den sonra 100 güne, 15 Mart 2029’dan 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.

Bu takvim elle yenilenen sertifikayla yaşanamaz; onu mümkün kılan şey yenilemenin protokolleşmesi. ACME (RFC 8555) sertifika istemeyi, alan adının sahipliğini kanıtlamayı ve süresi dolmadan yenilemeyi bir istemcinin kendi başına yürüttüğü bir akışa çevirdi. Let’s Encrypt’in ücretsiz sertifikaları bu protokolle veriliyor ve web’in büyük bölümü bugün o zincirin altında; kısa ömür, insan eli değmeyen bir yenileme varsa sorun olmaktan çıkıyor.

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 birkaç satır bu bölümün özeti: belge kime verildi, kim imzaladı, hangi tarihler arası geçerli, hangi adları taahhüt ediyor.

Özet

• 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 çıpalarını 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.
• Anlık iptal sorgusu emekliye ayrılıyor: OCSP’nin mahremiyet bedeli ağır bulundu; iptal bilgisini tarayıcılar toplu hâlde kendileri dağıtıyor.
• İ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 ne göndereceksin?

Bölüm 13: 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 application layer 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 stream’i, 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, boşluk, sürüm ve satırı kapatan CR LF, yani 13 ve 10 numaralı iki satır sonu baytı. Hedef çoğu zaman adresin yalnızca yolu; 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 6. bölümde 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ı 15. bölümde 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. Küme genişletilebilir: sonradan eklenen PATCH ya da WebDAV’ın dosya işlemleri için tanımladığı metotlar IANA’nın metot defterinde kayıtlı. Yine de yeni metot nadiren icat ediliyor, çünkü anlamı herkesçe bilinmeyen bir metodu yoldaki proxy’ler ve önbellekler tanımıyor. 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 pseudo-header’ı 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: stream 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 bu bilgi önbelleğin anahtarını (cache key) 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. Bir dosyayı birden çok bağlantıyla paralel indiren araçlar da her bağlantıya farklı bir aralık veriyor.

18. bölümde katmanları sayarken, ağın yedi katmanlı klasik modeli olan OSI’nin session layer’ı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 RTT 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 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 ile kaynağın sürüm etiketini (ETag) taşıyorsa alıcı tarihi yok saymak zorunda. Etiket üzerinden kurulan koşul daha doğru kabul ediliyor. Koşullu isteğin amacı şu: 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 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

• İ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 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 14: 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; 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ş bu. Durumu sunucunun belleğinde tutmak yerine senin makinene yazıyor ve her istekte onu geri getirtiyor. Fikir yeni değil: 8. bölümdeki SYN cookie, yarı açık bağlantı durumunu ikinci mesajın sıra numarasına kodlayıp kuyruğu tümden ortadan kaldırıyordu. Çerez aynı işi bir kat yukarıda, application layer’da 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ı şu: gelen satırdaki değeri okumak ve veritabanındaki kaydı bulmak. Tanıdığı şey sen değilsin, taşıdığın numara. Temel mekanizmayı tanımlayan belge RFC 6265, Nisan 2011 tarihli ve tam adı HTTP State Management Mechanism. Aşağıda göreceğin SameSite ve ad önekleri o belgede yok; tarayıcıların çoktan uyguladığı ama yıllardır taslak olarak bekleyen yenisinden (6265bis) geliyor.

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 bu.

Secure yazan çerez yalnızca şifreli kanaldan, yani HTTPS üstünden 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 bir ödünleşim ve Chrome’da 2020’den beri, öznitelik hiç yazılmamışsa varsayılan: başka bir siteden gelen bir bağlantıya tıkladığında oturumun açık kalıyor, ama başka bir 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 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.

Güzelliği ş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; izleme dediğimiz şey de 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; 11. 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ı proxy.

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; 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; 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, 5. bölümdeki ad önbelleklerinde de 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 -sI https://example.com/
curl -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

• 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 15: 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 RTT’yle ölçebilirsin. Kalıcı olmayan kipte her nesne iki tur yiyor: biri bağlantı kurulumu, biri istek ve yanıtın ilk baytları. 8. bölümde üç adımlı el sıkışmanın 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 RTT 40 ms olsun. Bağlantılar teker teker açılırsa 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ı kurulum turunu bir kereye indiriyor: aynı sayfa bir kurulum artı altmış istek, yani 61 tur ve 2.440 ms sürüyor. Süre yarıya indi ama her nesne hâlâ kendi turunu bekliyor, çünkü istemci bir yanıtı almadan sıradaki isteği göndermiyor.

Sıra zorunluluğu kimi bekletiyor?

HTTP/1.1 bu yüzden bir de boru hattını (pipelining) getirdi. İstemci yanıtı beklemeden istekleri arka arkaya gönderebiliyor. Altmış isteğin hepsi aynı turda yola çıkarsa sayfa iki gidiş-dönüşe, yani 80 ms’ye iniyor: biri kurulum, öbürü bütün nesneler için. İlk hesaba göre fark 60 kat. 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, application layer’daki baş engellemesi. Boru hattı standartta yer aldığı hâlde tarayıcıların hiçbiri onu varsayılan olarak açmadı; bu engelleme ve yoldaki hatalı proxy’ler kazancından fazla sorun çıkarıyordu.

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ümü paralel bağlantı sayısını ikiyle sınırlıyordu. O tavan kaldırıldı, çünkü pek çok uygulama için pratik değildi; yerine ölçülü olma öğüdü kaldı. Tarayıcılar bugün aynı sunucuya en fazla altı bağlantı açıyor.

Ö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ından fazlası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.

Frame’e 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 framing geldi. Nesneler frame’lere bölünüyor ve frame’ler 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 HPACK adlı bir yöntemle sıkıştırılarak kodlanıyor.

HTTP/2 bir yenilik daha getirmişti: sunucu itmesi (server push). Sunucu, tarayıcının birazdan isteyeceğini tahmin ettiği nesneleri istenmeden gönderebiliyordu. Pratikte tarayıcının önbelleğinde zaten duran nesneleri de yeniden yolladığı için kazançtan çok israf üretti ve Chrome 2022’de desteği kaldırdı.

Paralellik sayıyla korunuyor. SETTINGS_MAX_CONCURRENT_STREAMS için önerilen alt sınır 100 eşzamanlı stream ve gerekçesi açık: paralelliği gereksiz yere kısmamak. Her stream 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 application layer’daki baş engellemesini çözüyor, transport layer’dakini çö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.

Multiplexing’i application layer’a 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 stream multiplexing’i ve stream başına flow control taşıma protokolünün kendi işi. Güvenilir aktarım stream başına ayrı tutuluyor, tıkanıklık denetimi ise ortak: bütün stream’ler tek bir bütçeyi paylaşıyor. Paket kaybında yalnızca o pakette verisi bulunan stream’ler 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. Multiplexing, farklı stream’lerin STREAM frame’lerini aynı QUIC paketlerine iç içe koyuyor. Tek pakete birden çok stream’in verisi konabiliyor. O paketin kaybı hepsini birden durduruyor. Gerçekleştirimlere pakete gereğinden fazla stream koymamaları öğütleniyor.

El sıkışma da tek tura indi. QUIC, TLS 1.3’ü transport layer’ı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; 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 stream’inde gidiyor ve bir stream’de yalnızca tek bir istek gönderilebiliyor. İkinci istek yeni stream demek. Stream kimliği 62 bitlik bir tam sayı; en düşük bit stream’i kimin açtığını, ikinci bit tek yönlü mü çift yönlü mü olduğunu söylüyor. İki bit dört stream türü üretiyor.

HTTP/3 mesajının parçaları        frame      tür kodu
  başlık bölümü                   HEADERS      0x01
  gövde                           DATA         0x00
  kuyruk alanları (trailers)      HEADERS      0x01
  bağlantı ayarları               SETTINGS     0x04
  kapanış duyurusu                GOAWAY       0x07

Gövdesi olmayan bir yanıtta DATA frame’i hiç gönderilmiyor; gövde 0 bayt ise ortada frame de yok. Her uç ayrıca en az 3 tek yönlü stream’e izin vermek zorunda: bir HTTP denetim stream’i ve başlıkları sıkıştıran QPACK’in iki stream’i. Bu stream’lere 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.

Alt-Svc’nin kusuru ilk bağlantıda görünüyor: duyuru bir yanıt başlığında geldiği için tarayıcı onu ancak eski protokolle bir tur attıktan sonra öğreniyor. 4. bölümde DNS kayıtlarını sayarken andığım HTTPS kaydı o turu siliyor. Kayıt, DNS cevabının içinde “bu sunucu h3 konuşuyor” diyor ve tarayıcı daha ilk bağlantısını QUIC ile açı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 frame’leriyle ş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ünce her yolda taşınacağı garanti edilen UDP yükü 1.232 bayt çıkıyor. IPv4 başlığı daha kısa olduğu için orada bu sayı 1.252 bayt.

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

QUIC de 443’ü kullanıyor, ama UDP üstünde. UDP’nin engellendiği 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

• 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 veriyi frame’lere böldü ama taşımayı değiştirmedi: iç içe geçen frame’ler application layer’ı kurtarıyor, kaybolan tek paket yine hepsini durduruyor.
• QUIC güvenilirliği stream başına ayırdı: kayıp yalnızca o pakette verisi olan stream’leri 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 16: İçerik Dağıtım Ağları

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

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

Tek büyük sunucu neden yetmiyor?

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

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

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

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

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

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

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

İsteği kim yönlendiriyor?

Adı devreden zincir

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

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

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

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

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

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

Sorana göre değişen cevap

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

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

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

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

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

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

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

Standart burada durmuyor ve kendi önerdiği özelliği açıkça eleştiriyor. Seçenek açıkken çözüm zincirindeki her sunucu senin ağ adresini görüyor. RFC bu yüzden özelliğin ad sunucusu yazılımlarında varsayılan olarak kapalı gelmesini tavsiye ediyor. Açık resolver’lar da bu yüzden ikiye ayrılıyor: Google’ın 8.8.8.8’i seçeneği destekleyen yetkili sunuculara gönderiyor, Cloudflare’in 1.1.1.1’i mahremiyet gerekçesiyle hiç göndermiyor. Desteklenmediğinde de dünya durmuyor: en kötü sonuç yanlış bir konum tahmini.

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

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

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

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

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

Kenarda seni karşılayan şey bir önbellek

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

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

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

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

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

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

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

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

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

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

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

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

Vary: Accept-Encoding

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

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

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

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

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

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

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

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

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

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

Özet

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

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

Bölüm 17: 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?

Application layer’da bir protokolün tanımlaması gereken dört şey var. Birincisi hangi ileti türlerinin değiş tokuş edileceğ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. Bu ölçeklenmenin hesabını ve BitTorrent’in içini 72. bölümde göreceksin.

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. Özgün SMTP hem başlığın hem gövdenin 7 bitlik ASCII olmasını şart koşuyordu. Sonradan eklenen uzantılar sekiz bitlik gövdeye ve UTF-8 adreslere izin veriyor ama ekler hâlâ eski kurala göre hazırlanıyor: 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ü 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önlendirmeden sağ çıkı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. İsteğe bağlı başlayan bu katmanlar artık fiilen zorunlu: Gmail ile Yahoo, 2024’ten beri günde binlerce ileti gönderen alanlardan üçünü birden istiyor ve eksik olanın postasını teslim etmiyor.

İ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; bugünkü tanımı RFC 9051’de, eski numarası 3501. 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. Tarayıcıya HTTP ile sunduğu arayüzün arkasında göndermek için SMTP’yi, almak için IMAP ya da POP’u kullanıyor.

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

16. bölümde konut trafiğinin büyük kısmının üç akış hizmetine gittiğini görmüştün. 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, MPEG-2 için 3 ile 6 Mbit/s, MPEG-4 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: Dynamic Adaptive Streaming over HTTP, HTTP üzerinden dinamik, uyarlanır akış. O parçaların hangi makinede durduğu ise 16. bölümde kenar sunucularında çözülmüştü. İstemcinin hızı nasıl seçtiği, tamponun hesabı ve canlı yayının gecikmesi 73. bölümün konusu.

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

Hepsi aynı transport layer’ı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: 7. bölümde bağlantısız gönderimi anlatırken geç gelen verinin hiç gelmemiş sayıldığını söylemiştim. Jitter’dan RTP’ye gerçek zamanlı sesin geri kalanı 74. bölümde.

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

• 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 neye dönüşüyor?

Bölüm 18: 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 bilerek 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ı kısa. 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. 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 router’lara 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. Kutu uygulamanın mesajına, barkod transport layer başlığına, şehir etiketi network layer başlığına, sefer listesi ise data link layer’ın frame’ine karşılık geliyor. Benzerlik arıza anında bozuluyor: 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 Network Interface katmanı, OSI’nin data link ve physical layer’larının işini tek başına görüyor; ona host-to-network ya da network access da deniyor. Ders kitaplarının çoğu ise ikisinin arasında duran beş katmanlı bir yığın öğretiyor. Türkçe kaynaklarda veri bağı katmanı diye geçen kata bu kitap boyunca data link layer diyeceğim; tablolarda yer darlığından kısaca bağ olarak geçecek.

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.

Presentation layer 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. Presentation layer ö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; OSI’nin diliyle o çevirme presentation layer’ı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ı presentation layer örneği.

Session layer 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 session layer’ı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 connection ID’si: üçü 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: proxy istemcinin isteğini onun adına ileten kutu, reverse proxy aynı işi sunucunun önünde yapan ve istemcinin gerçekte konuştuğu kutu, load balancer 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. Medya dönüştürücü de yalnızca sinyalin taşındığı ortamı değiştirir; bakırdan gelen biti fibere, fiberden geleni bakıra aktarır. İkisi de içeride ne olduğunu bilmez, bilmesi de beklenmez. Bir üste çıktığında cihaz ilk kez bir alana bakıp bir karar veriyor: switch hedef MAC adresini okur ve frame’i yalnızca o adresin öğrenildiği porta yollar. Aynı satırdaki bridge switch’in atasıdır ve o kararı ilk veren cihazdır; ikisinin arasındaki farkı switch’i tanıdıktan sonra ayrı ayrı sereceğim. Bir üste daha çıktığında karar yerelden çıkar; router hedef IP adresine bakar ve paketi başka bir ağa iletir.

Ders kitaplarındaki kısa tanım da buradan çıkıyor: switch aynı ağın içindeki makineleri birbirine bağlar, router ise ayrı ağları birbirine bağlar. Başka kaynaklardaki şemalarda ikisini adından önce şeklinden tanırsın. Cisco’nun simgelerinde ve ders kitaplarının çoğunda router yuvarlak çizilir, üstten bakılmış yassı bir silindir gibi; switch ise köşeli bir kutudur ve ikisinin de üstünde oklar çizilidir. Bu kitabın şemaları kutunun adını üstüne yazıyor, ama bir ders slaytında yalnızca bir daire ile bir kare görürsen hangisinin hangisi olduğunu artık biliyorsun.

Bu tırmanışın somut bir bedeli var: cihaz ne kadar yukarı çıkarsa paket başına o kadar çok iş yapar. Hub’ın gecikmesi nanosaniyeler, switch’inki mikrosaniyeler mertebesinde; routing’i donanımda yapan bir kutu da mikrosaniyelerde kalıyor. İstek başlıklarını yazılımda ayrıştıran bir proxy’ninki ise milisaniyeye çıkabiliyor. Kutuyu yukarı taşımak çoğu 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. Router üçüncü katman cihazıdır ama frame’i çö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 switch, switch donanımının hızıyla routing yapan bir kutudur; ismi ikinci katmanı, işi üçüncüyü anlatır. Ev kutun ise tek kasada modem, router, switch 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, 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.

Özet

• 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; presentation ile session katlarının işini Internet yığınında application layer üstlenir. Sertifikanın ASN.1 kodlaması ve HTTP’nin Range başlığı bunun iki canlı örneğidir.
• Fiziksel katman dört başlıkta anlaşmaktır: mekanik, elektriksel, işlevsel ve yordamsal; biri tutmazsa sapasağlam bir kablodan bile tek bit geçmez.
• Bir cihazın katmanı okuduğu en derin başlıktır: hub hiçbir alana bakmaz, switch hedef MAC adresine, router hedef IP adresine bakar; kutu yukarı çıktıkça paket başına daha çok iş yapar.
• Switch aynı ağın içini, router ağları birbirine bağlar: şemalarda switch köşeli bir kutu, router yuvarlak bir silindir olarak çizilir.

Katmanları saydık ve her kutuyu kendi katına oturttuk. İki katın arasındaki anlaşmayı ise henüz adlandırmadım. Peki bir kat altındakinden ne alıyor ve karşı makinedeki eşine ne söz veriyor?

Bölüm 19: Hizmet ve Protokol

Katlar sayıldı, kutular yerine oturdu. Geriye aralarındaki anlaşma kalıyor ve o anlaşma iki ayrı yöne uzanıyor: biri aşağıya ve yukarıya, öteki karşıdaki makineye.

Peki bu iki yön neden ayrı adlar taşıyor ve ayrımı bilmek sana ne kazandırıyor?

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: transport layer’ı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 HTTP’yi TCP’den QUIC’e taşımak, 15. bölümde gördüğün gibi, HTTP’nin anlamlarına hiç dokunmadı.

İki ilişkiyi ve aradaki kutuların kaç kat çıktığını tek figürde görelim:

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, tıpkı telefon gibi. Bağlantısız hizmette kurulum yoktur; her birim kendi başına, kendi adresiyle yollanır, tıpkı mektup gibi. 8. bölümde üç mesajlık el sıkışmayı kuran TCP birincisi, 7. bölümde hiçbir söz vermeyen UDP ikincisidir. IP de bağlantısızdır; güvenilir bir transport layer’ının bağlantısız bir network layer ü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 interface (arayüz) port numarasıdır; iyi bilinen iki örnek HTTP’nin 80 ve FTP’nin 21 numarasıdır. 6. bölümdeki demultiplexing bu interface’in sözleşmesi üstünde duruyor. Data link ile network layer arasındaki interface ise Ethernet frame’inin 2 baytlık tür alanı. O alan, frame’in içindekinin üstteki hangi protokole teslim edileceğini söylüyor; data link layer’ın demultiplexing’i tek bir alana sığmış durumda. Aynı işi LLC katmanında Service Access Point yapıyor.

Taşınan şeyin adının katman katman değiştiğini önceki bölümdeki tabloda gördün: segment, datagram, frame, bit. Bu birimlerin ortak adına Protocol Data Unit deniyor; network layer’ı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. Data link layer 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 encapsulation’ın 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 network layer’ın SDU’su, network layer’ın ürettiği datagram data link layer’ın SDU’sudur. Zarfın içinde zarf 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. Data link layer 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: network layer, altında bakır mı radyo mu olduğunu umursamak zorunda kalmıyor. Ağ kartı denetleyicisinin çipte gerçeklediği şey de MAC alt katmanıdır.

Ayrımın en somut 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 router’lar 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. Data link layer çipte ya da ağ interface 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. Network layer’ı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; ş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, firewall’lar, önbellekler. İstek 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 frame’ini say: 14 bayt Ethernet başlığı, 20 bayt IP, 20 bayt TCP, 4 bayt frame sağlaması, telde ayrıca 8 bayt önsöz ve 12 bayt frame 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: şifresiz bir uzak oturumda, Telnet’te bastığın bir harf. Veri 1 bayt. IP datagramı 41 bayta çıkıyor, frame 59 bayt ediyor ve Ethernet’in 64 baytlık asgari frame ş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: data link layer frame’in 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; sebebi de 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 router’ın belleğinde de olabilir. Alttaki ikisi zorunlu değil, erken. Bozuk bir frame’i 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 frame girişimden bozulmuş olabilir, yani ortada tıkanıklık yoktur. Data link layer iki durumu ayırt edebilir ama TCP’ye söyleyecek bir kanalı yoktur; sözleşmede öyle bir alan yok. TCP hattı dolu sanı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 segmentleri işletim sistemi yerine kendisinin bölmesi, router’ın trafiği transport layer portlarına bakarak yollara dağıtması, tıkanıklığın kayıp yerine bir bit ile bildirilmesi: üçü de bilerek 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: data link layer ü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

• 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.
• Hizmet ya bağlantı yönelimlidir ya bağlantısız: TCP önce kurulum yapar, UDP ile IP her birimi kendi adresiyle yollar; güvenilir bir taşıma bağlantısız bir ağın üstünde durabilir.
• Encapsulation 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.
• Data link layer iki alt kattan oluşur: MAC hattı kimin ne zaman kullanacağına karar verir, LLC üst kata tek tip bir yüz gösterir.
• 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 ne veriyor?

Bölüm 20: Encapsulation ve Başlıklar

Katmanların birbirine ne sözü verdiğini kurduk. Söylemediğim şey, komşuya 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

Application layer 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.

Network layer 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 data link layer; o da datagramı olduğu gibi alıp sarıyor ve ortaya frame (çerçeve) çıkıyor.

application  [ mesaj ]
transport    [ TCP | mesaj ]                       ->  segment
network      [ IP  | TCP | mesaj ]                 ->  datagram
data link    [ ETH | IP  | TCP | mesaj | FCS ]     ->  frame

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ı. Frame hem başlıkla hem kuyrukla sarılıyor; sondan yazan tek katman data link layer.

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. Encapsulation dediğimiz şey bu.

Başlıkta ne var?

Seçenek taşımayan bir TCP başlığı 20 bayt. Başlık sabit değil; içinde başlık uzunluğu (data offset) 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:

Birkaç alan ilk okumada kolayca kayıyor, oysa hepsi 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 router 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 firewall tarafından susturulursa yöntem sessizce çöker; sahadaki hâlini 48. bölümde 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 router’da yeniden hesaplanması gerekiyor; 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.

Frame’in alanları da sırayla belli; boyları toplandığında zarfın maliyeti çıkıyor:

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

Adresler, tür alanı ve FCS birlikte 18 bayt tutuyor. Önsöz (preamble) hariç azami sade frame 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 frame’i 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 24. bölümün işi.

Her zarf bir sonrakini nasıl gösteriyor?

Encapsulation’ın 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ı encapsulation çözme (decapsulation) ve sarmanın tam tersi sırayla yürüyor. Alıcı kartı frame’i alıyor, FCS’yi yeniden hesaplayıp yazandan farklı çıkarsa frame’i 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.

Encapsulation’ın özeti: 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 frame’in veri alanına MTU deniyor. Ethernet’te 1.500 bayt. Bu bir network layer kararı değil, data link layer 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. Switch’lerin çoğu bugün 9.000 bayt veri taşıyan jumbo frame’leri kabul ediyor; aynı veriyi altı kat daha az frame’le göndermek, frame 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; yol üstündeki tek bir port jumbo frame’i 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 router 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 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ç router’da 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 frame 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 frame 64 bayta çıkıyor. Telden geçen her şey zarf.

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

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

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 frame’ler arası boşluk 9,6 µs, yani 96 bit süresi. Toplamı 304 bit süresi.

Küçük frame’in bir yararı da var. Bozulan bir frame’de yeniden gönderilecek bit sayısı daha az. Multiplexing 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 interface’in yanına mtu 1500 yazacak. İkincisi her satırın başında frame’in kaynak ve hedef adresini, ethertype IPv4 (0x0800) etiketini ve frame’in bayt cinsinden boyunu dökecek. Windows tarafında aynı değeri netsh interface ipv4 show subinterfaces komutu veriyor.

Özet

• Encapsulation dört basamaklı bir merdiven: mesaj segmente, segment datagrama, datagram frame’e 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; sondan kuyruk ekleyen tek katman da data link layer.
• 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: frame’deki 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 21: Paket Yakalama ve Çözümleme

Diyelim ki bir yakalama aracı kurdun ve açılış ekranındaki kart listesinden kendi interface’ini seçtin. Satırlar akmaya başlıyor; her satır bir frame. Encapsulation 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 ne?

Trafiği kim kopyalıyor?

Bu işin en yaygın aracı Wireshark ve bölüm boyunca ondan söz edeceğim. Ekranda gördüğün program yakalamayı kendisi yapmıyor. Altta, işletim sistemiyle konuşan bir paket yakalama kütüphanesi var: Linux ve macOS’ta libpcap, Windows’ta Npcap. Üstünde de senin tıkladığın çözümleyici arayüz duruyor ve onun işi baytları adlandırmak.

Alt katman, kartın gönderdiği ve aldığı bütün Ethernet frame’lerinin 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.

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 ya da enp3s0, kablosuz için wlan0 ya da wlp3s0 gibi adlar; macOS’ta en0 ile lo0; Windows’ta üreticinin verdiği uzun ad. Fiziksel kartların yanında sanal geri döngü interface’i de listede duruyor; makinenin kendi kendine konuşmasını oradan yakalıyorsun.

Wi-Fi kartıyla yakalayacaksan bir adım daha var: kartı monitor mode’a (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 broadcast ortamı olması: paylaşılan Ethernet ve kablosuz bağlantı. Herkesin duyduğu bir yerde kartı susturmayı bırakmak yetiyor.

Switch’li bir yerel ağda hesap değişiyor. 192.0.2.10 numaralı makineden 192.0.2.11’e giden bir frame, kartın karışık modda olsa bile 192.0.2.12’ye ulaşmıyor. Switch onu yalnızca hedefin bağlı olduğu porta gönderiyor.

İşin ters yüzü de var. Switch’in kendi portları karışık modda çalışıyor; adres öğrenmesinin yolu bu. Öğrendiklerini tuttuğu tablo ise sınırlı; tablo sahte adreslerle taşırılırsa (MAC flooding) switch frame’leri yeniden herkese dağıtmaya başlıyor ve dinleme geri geliyor. Kurumsal ağlarda dinlemenin meşru yolu da switch’in kendisinde: bir portun trafiğini başka bir porta kopyalayan port yansıtma (port mirroring, SPAN) ayarı.

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 frame’de 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 yakalanan toplam paketi, o an gösterilen paket sayısını ve etkin profilin adını taşıyor. İlk iki sayı 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ığı 23. bölümün işi.

Son bir ayrıntı: kayıt ekranında azami frame 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. Kendi gönderdiğin trafikte 1.514’ü çok aşan “frame”ler görürsen de şaşırma. Kart segmentleri bölme işini üstlendiği için, 19. bölümdeki katman ihlali yüzünden, yakalama o parçayı bölünmeden önceki büyük hâliyle görüyor.

Kayda soru sormak

Filtre kutusu bir tane değil, iki tane. Açılış ekranındakine yazdığın filtre, frame’ler 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: dhcp.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 kernel’a gitmiyor; önce küçük bir sanal makinenin komutlarına derleniyor. O sanal makinenin adı BPF ve programı doğrudan kernel’ın içinde, paket kullanıcı alanına kopyalanmadan önce koşuyor. Her frame 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 frame önce kopyalanacak, sonra atılacaktı; yani en pahalı iş, atılacak paket için de yapılacaktı. Kernel’da 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ü kernel 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. Fikir o kadar iyi çalıştı ki Linux’ta büyüyüp eBPF adını aldı: bugün kernel’ın içinde güvenli küçük programlar çalıştırmanın genel yolu, paket süzmekten performans ölçmeye kadar.

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 frame yalnızca başlıktan ibaret. Uçlardaki durumları, yani CLOSE-WAIT ya da TIME-WAIT’i yakalamada göremezsin, çünkü telden geçmiyorlar; onlar 8. bölümdeki ss çıktısında, makinenin kendi tablosunda duruyor.

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 69. 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. 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 frame’i 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ı, paketleri zaman sırasına dizerek tek dosyada birleştiriyor.

Özet

• Yakalama işini ekrandaki program yapmıyor: trafiği kopyalayan katman işletim sisteminin yanında 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 broadcast ortamı olması; switch’li bir ağda frame 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: frame’i tele koyacak olan ne?

Bölüm 22: Ağ Interface Kartı

Yakalama aracında her satırı bayt bayt sayıp zarfları tek tek gördün. Frame’i 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ı nerede başlıyor?

Kart nerede duruyor?

Ağ kartı, bilgisayarı ağa fiziksel olarak bağlayan parça. Tam adı ağ interface kartı (network interface card); Türkçe kaynaklarda ağ arayüz kartı, ağ adaptörü ya da ağ bağdaştırıcısı 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ı PCI, bugünkü karşılığı PCI Express. 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 yongasını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, data link layer’ı ve physical layer’ı; üstündeki her şey yazılımda kalıyor. 19. bölümde 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ç interface.

Soket four-tuple’ını kurarken kernel’ın altında ne olduğunu kapalı kutu bırakmıştım. Kutuyu şimdi açıyorum. Soket katmanını kullanıcı alanı ile kernel 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ü.

Frame’i kim kuruyor?

Kartın kalbinde, MAC protokolünü de taşıyan tek bir özel amaçlı denetleyici yonga var. Framing, 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ü frame’le ilgileniyor, physical layer bölümü sinyalle. İşte o iç interface’in adı hıza göre değişiyor: 100 Mbit/s’te MII, gigabitte GMII, on gigabitte XGMII. Physical layer tarafı kendi içinde ayrıca katmanlı. Orada bir kodlama alt katmanı ile ortama bağlanan ve ortama bağımlı alt katmanlar duruyor; standarttaki adları PCS, PMA ve PMD.

Framing, datagramın önüne başlık arkasına kuyruk eklemek demek. Encapsulation 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 frame’i kendisi kuruyor.

Ama framing’in asıl zorluğu ekleme değil, ayırma. Physical layer’ı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 stream’de bir frame’in nerede başlayıp nerede bittiğini bilmek zorunda, yoksa elindeki baytların hangisinin adres hangisinin veri olduğunu söyleyemez. Sorunun adı frame sınırlandırma ve tarih boyunca dört ayrı çözümü denendi.

Bayt sayısı. Frame’in 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 frame’ler kayar. Tek bir bit hatası kalıcı bir hizasızlık üretiyor.

Bayrak baytı ve bayt doldurma. Frame’in 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 frame 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ı.

Physical layer ihlali. Dördüncüsü 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. 53. bölümde blok kodlamaya indiğimizde göreceksin: 4B/5B, 32 desenden yalnızca 16’sını veriye ayırıyor ve artan desenlerin bir kısmı bunun için duruyor.

Ethernet aslında üç yöntemi birden kullanıyor. Önsöz ile frame başlangıç sınırlayıcısı başlangıcı işaretliyor, uzunluk alanı ile taşıyıcının kesilmesi sonu; frame’ler arası boşluk da iki frame’in 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 frame aldığında işlemciyi kesiyor. Kesmeye yanıt veren sürücü yazılımı hata durumlarını ele alıyor ve datagramı network layer’a yukarı veriyor. Donanımın bittiği çizgi orası.

Frame’in üstündeki adres de kartın kendi adresi ve kart bu kimliği üstündeki ROM’da taşıyor. Kartın hem birinci hem ikinci katmanın aygıtı sayılması bu yüzden: sinyali o üretiyor, frame’in adresini de o taşıyor. Bu adresin nasıl kurulduğunu, yani MAC adresinin biçimini 23. bölümde tek tek açacağız.

Kernel işi karta nasıl devrediyor?

Paket stream’i interface’e girip çıkarken doğrudan bellek erişimiyle yönetiliyor; kısaltması DMA (Direct Memory Access). 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. Kernel 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 kernel 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 frame’lerle 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 kernel’a 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 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 frame 64 bayt, ama telde 84 bayt yer kaplıyor. Yanına 7 baytlık önsöz, 1 baytlık ayraç ve 12 baytlık frame’ler arası boşluk ekleniyor. Toplamı 672 bit eder. Tam yükte saniyede 1.488.095 frame geçiyor. Her frame için bir kesme, saniyede 1,49 milyon kesme demek. Tek bir işlemci çekirdeği zamanının çoğunu yalnızca kesmeye cevap vermekle geçirirdi.

Kartlar bu yüzden kesme birleştirme yapıyor: sürücü ya da kart, işlemciyi kesmeden önce birkaç frame biriktiriyor. 32 frame’de bir kesme verildiğinde aynı yük saniyede 46.503 kesmeye iniyor. Frame’ler yine aynı halkada birikiyor. Değişen tek şey, kernel’ın kaç kez rahatsız edildiği.

Bedeli de aynı bölme işleminden çıkıyor. 32 frame’de bir kesme veren kart, gruptaki ilk frame’i en kötü durumda 31 frame süresi bekletiyor. Boş bir hatta durum daha kötü: grup hiç dolmazsa kesme de hiç gelmiyor. Yalnızca frame sayan bir politika bu yüzden tek başına kullanılamıyor.

Kartlar ikinci bir politika daha taşıyor. İlk frame 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 bunlar: biri frame sayıyor, biri mikrosaniye. 200 µs’ye ayarlanmış bir zamanlayıcı, boş bir hatta gelen tek frame’e 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ı.

Linux bunun üstüne bir adım daha atıyor. Yük yükseldiğinde kesmeleri tümden kapatıp halkayı kendisi yokluyor ve bir turda onlarca frame topluyor; yük düşünce kesmelere geri dönüyor. Bu karma düzenin adı NAPI. Kesme, trafik seyrekken tepki hızı veriyor; yoklama, trafik yoğunken verim.

Darboğaz gerçekten kartta mı?

Her Ethernet interface yongası, desteklediği ortamın tam frame 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 frame’ler interface’te düşürülüyor ya da yok sayılıyor; 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 frame’lik tavan en küçük frame’lere aitti. Aynı hatta en büyük frame’lerle tavan saniyede 81.274 frame’e iniyor. Frame sayısı on sekiz kat azalıyor, taşınan veri artıyor.

Bir frame’in 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 frame için bu, gigabitlik hatta 12,1 µs. On kat hızlı bir hatta aynı iş 1,21 µs’ye iniyor. 2. bölümde 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 frame 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 interface’ler satıyor. Boşaltma motorlarının (offload) çıkış noktası bu. Somut bir örnek, TCP segmentasyon boşaltması (TSO): kernel 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 ethtool bu işin aracı.

ethtool eth0
ethtool -g eth0
ethtool -c eth0
ethtool -k eth0
ip -s link show eth0

İlk komut interface’in 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 frame sayacı sıfırdan büyükse bu çoğu zaman makinenin kartın hızına yetişemediğini gösteriyor.

İ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şmaya kalkabildiği için collision 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 yalnızca iki istasyon bulunması. Koşullar sağlanınca collision 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

• Ağ kartı iki katmanı birden gerçekliyor: data link layer ile physical layer kartın üstünde, geri kalan her şey yazılımda; yığının donanımla buluştuğu çizgi orası.
• Frame’i denetleyici yonga kuruyor: framing, hatta erişim ve hata sezme donanımda bitiyor ve ana işlemciye hiç uğramıyor.
• Halka tampon ile DMA işi devrediyor: kernel tanımlayıcıyı dolduruyor, kart veriyi bellekten kendisi çekiyor; halkanın derinliği de aslında kernel’a tanınan süredir.
• Kesme birleştirme çekirdeği kurtarıyor: frame başına bir kesme tam yükte ulaşılamaz bir sayıya çıktığı için kart birkaç frame’i biriktirip tek kesme veriyor.

Kart hazır. Halkayı okuyor, frame’i kuruyor, hatayı donanımda seziyor. Ama frame’in üstünde iki alan hâlâ boş duruyor. Kart oraya kimin adını yazacak?

Bölüm 23: Fiziksel Adresleme

Frame 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 interface’inin 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 oktet, yani sekizer bitlik 6 grup çıkıyor; adresi kısa çizgilerle ya da iki noktayla 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, frame’in 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 ücretli bir blok satın alı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 (Organizationally Unique Identifier). 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 üç oktet artık tek başına üreticiyi vermeyebilir. MA-S bloğunda ilk 36 bit, yani dört buçuk oktet IEEE’nin dağıttığı önek; aynı ilk üç okteti 4.096 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; routing tablosunda karşına çıkacak mantığın aynısı, başka bir uzayda.

Yine de çoğu durumda ilk üç oktete bakarak interface 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?

Interface sözleşmesi her katmana kendi adlandırma düzenini bırakıyor ve üç katman üç ayrı ad kullanıyor. Application layer’da makinenin adı, network layer’da IP adresi, data link layer’da 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; frame’i bir interface’ten, ona fiziksel olarak bağlı başka bir interface’e ulaştırmaktan ibaret. Kart nereye giderse gitsin adresi değişmiyor. 802.11 interface’i 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; 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 network layer protokollerini desteklemek zorlaşırdı; MAC bilerek tarafsız bırakıldı. Kart network layer 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. Ethernet paylaşılan bir kablo olarak doğdu; ortamdaki veriyi herkes alıyordu. Adres olmasaydı makine yerel ağdaki her frame için kesmeye uğrardı. Adres, işletim sistemini rahatsız etmemek için var.

Kart hangi frame’i açar?

20. bölümde encapsulation merdivenini çıkarken bu iki alanın genişliğini vermiş, içini bilerek boş bırakmıştım. Frame’de 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 interface’i kablodaki her frame’i 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 broadcast adresiyse yükü network layer’a çıkarıyor. Eşleşme yoksa frame’i atıyor ve datagramı yukarı hiç vermiyor.

Bu filtre kapatılabiliyor. Yakalamayı karışık modda yaparken kart eşleşmeyen frame’leri 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 frame 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ı frame’i gönderen cihazın MAC adresini taşıyor. Bu alan her zaman tek bir interface’i gösteren adres olmak zorunda, oraya broadcast adresi yazılamıyor. Ethernet MAC protokolü kaynak adresi hiçbir şekilde yorumlamıyor. Alan üst katman yazılımı, arıza takibi ve switch’ler için duruyor. Switch, kaynak adresleri kendi portlarıyla eşleyen tabloyu bu alandan kuruyor; switch’in her portunun da fabrikada atanmış kendi adresi var.

Adreslerden sonra gelen tür alanı içerideki üst katman protokolünü bildiriyor. Frame’in 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 interface’in MAC adresi, birse bir gruba gönderim. Fabrikada atanan adresin teknik adı bu yüzden unicast 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? Oktetler soldan sağa gönderiliyor ama bir oktetin 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 oktet    :  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: unicast        ·  1: multicast

Kural bu yüzden tek bir haneye bakarak okunabiliyor:

Yerel yönetilen unicast için 16 haneden yalnızca 4’ü uygun, yani %25.

Şu adres üstünde yürüyelim: 06-4B-7C-D2-05-9A. İlk oktet 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 unicast; 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 broadcast 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. Broadcast adresine gönderilen bir frame’i yerel ağdaki her istasyon alıyor ve işlemek zorunda kalıyor. Bedeli herkese dağılıyor.

Broadcast adresi aslında multicast’in ö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 multicast. Multicast adresi tek bir frame’in bir istasyon grubu tarafından alınmasını sağlıyor. Interface, bir ya da daha fazla grup adresine gelen frame’leri alacak şekilde programlanabiliyor.

Ethernet’te broadcast adresi tek bir sabit değer. IP’deki broadcast 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?

Network layer bir gruba paket yollamak istediğinde elinde bir multicast IP adresi var, ama kart yalnızca MAC adresi tanıyor. Aradaki dönüşüm bir tablo değil, doğrudan bir hesap.

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 oktet 01, yani ilk bit bir: adres tanımı gereği multicast. Hesap hiçbir sunucuya sormadan, hiçbir tablo tutmadan yapılabiliyor.

Bir kusuru var ve bilerek kabul edilmiş. Multicast IP adresinin grup 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 frame’lerini de yukarı veriyor ve ayıklamayı işletim sistemi yapıyor. Donanım filtresinin kaçırdığını yazılım filtresi topluyor. Anlatılana göre sebep bütçeydi: 28 bitin hepsini karşılayacak on altı OUI yerine tek bir blok alınabildi ve onun da yalnızca yarısı IP multicast’e ayrıldı.

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 oktetlerini sok; 48 bit 64 bite çıkar.
3. İlk oktetteki 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      ->   interface kimliği 21b:44ff:fe11:3ab7

Üçüncü adım ilk bakışta keyfî görünüyor. Değil: IPv6, EUI-64’ün değiştirilmiş bir sürümünü kullanıyor ve o sürümde bitin anlamı ters çevrilmiş; 1 “küresel”, 0 “yerel” demek. Sebebi pratik: elle yazılan ::1 gibi kısa kimliklerin bu biti sıfırda kalıyor ve böylece kendiliğinden “yerel” sayılıyorlar. Aynı bit iki standartta zıt anlamlar taşıyor, dönüşüm de bunu düzeltiyor.

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. Kalıcı adres için de çoğu sistem artık MAC’i kullanmıyor; ağdan ağa değişen ama aynı ağda sabit kalan bir sayı üretiyor (RFC 7217). Makinenin kendi IPv6 adresini nasıl bulduğunu 38. bölümde anlatırken buraya geri döneceğiz.

MAC adresi yazılımla değiştirilebiliyor. Bugün kullanılan Ethernet interface’lerinin 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 interface zaten fabrikada tek bir adres alıyordu. Adres rastgeleleştirmesi 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; Android 2019’dan, iOS 2020’den beri her Wi-Fi ağına varsayılan olarak ayrı, rastgele bir adresle bağlanıyor.

Kendi kartının adını görmek istersen Windows’ta:

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ı. Linux’ta aynı bilgi ip link çıktısındaki link/ether satırında, macOS’ta ifconfig çıktısındaki ether satırında duruyor. O 12 haneye bak ve ikinci haneyi oku: 0, 4, 8 ya da C ise elindeki ad gerçekten fabrikadan geliyor; 2, 6, A ya da E ise kart o ağa rastgele bir adla bağlanmış.

Özet

• 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 frame’i hedef adrese kadar okuyor: eşleşme ya da broadcast 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 multicast; 2, 6, A ve E yerelde verilmiş, 0, 4, 8 ve C ise küresel unicast anlamına geliyor.
• Multicast 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.

Frame’in iki adresi de yerinde: kimin gönderdiği ve kimin alacağı yazılı. Ama bu frame ş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 24: Hata Sezme ve CRC

Frame 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. Frame’in 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 55. bölümde 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 frame’de 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 kodu ile Reed-Solomon kodu. İlki tek bitlik hatayı düzeltir; ikincisi bit yerine sembol düzeltir ve bu yüzden patlama hatalarına dayanır. CD’nin çiziğini, QR kodunun kirlenmiş köşesini ve eski uydu yayınlarını ayakta tutan kod odur.

Asıl kazanç hızda. Alıcı hatayı yerinde düzelttiği için bir RTT 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. Physical layer’ın çözümü, denetim bitlerini ekledikten sonra bitleri karıştırmak (interleaving). 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. Bunun için alıcının geri bildirim göndermesi, göndericinin de paketleri numaralayıp birer kopyasını tutması gerekiyor; TCP’nin bunu nasıl yaptığını 67. bölümde göreceğiz. 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 hatanın yaptığı da bu: 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 frame’de 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 frame’de 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, birler tümleyeni toplamını alıyor ve sonucun tersini 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. Birler tümleyeni toplamları D40C, tersi olan checksum da 2BF3 çıkıyor. Şimdi birinci kelimeyi bir artır, ikinciyi bir azalt. İkisi de değişti, checksum 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: transport layer yazılımda çalışıyor ve ucuz bir hesap seçiyor. IPv6 başlığında bu alan hiç yok; router’da işlemeyi hızlandırmak için kaldırılmış ve koruma alt ile üst katmanlara bırakılmış.

Frame’in sonundaki dört bayt

Data link layer 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 data link layer’daki IEEE protokollerinde ortak. r bitlik bir CRC, r+1 bitten kısa bütün patlamaları kesin yakalıyor. Daha uzun patlamalar da yüksek olasılıkla seziliyor: 32 bitlik artıklıkta kaçırma olasılığı %0,0000000233’e iniyor. Ethernet’in deseni ayrıca en büyük frame boyuna kadar, frame’in neresine düşerse düşsün üç bite kadar her hatayı yakalıyor.

Üç yöntemi aynı hata patlaması üstünde karşılaştıralım:

Ethernet frame’inin son alanı FCS (frame check sequence, frame denetim dizisi). 32 bit, yani 4 bayt; 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 frame başlangıç sınırlayıcısı, hesaba katılmıyor. 20. bölümde encapsulation merdiveninde bu alanı adlandırmış ama içini boş bırakmıştım.

Bu dört baytın bedeli frame boyuna göre değişiyor. 1.518 baytlık dolu bir frame’de FCS’nin yükü %0,26 kalıyor. 64 baytlık en küçük frame’de aynı alan %6,25’e çıkıyor. Aradaki fark kabaca yirmi dört kat.

Hesap tutmazsa frame düşürülüyor ve interface’in 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 frame’deki veri ancak üst katmanda güvenilir bir protokol varsa kurtarılıyor. Data link layer hatayı tespit ediyor, telafi etmiyor.

Yol üstünde iki tuzak var. Bir switch frame’i tamponuna alıp CRC’sini denetledikten sonra iletiyorsa bozuk frame orada duruyor; hedef adresi okur okumaz iletiyorsa CRC’ye hiç bakılmadan bozuk frame yayılabiliyor. Bu tercihin adını 27. bölümde switch’i açtığımızda koyacağız. İkinci tuzak da switch’in elinde: frame’e bir etiket eklendiğinde FCS baştan hesaplanıyor. Frame o anda zaten bozuksa ve switch onu denetlemeden etiketliyorsa, yeni ve kusursuz bir FCS bozuk içeriği aklamış oluyor.

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

• 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 RTT’yi 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 frame’e ekleniyor ve alıcıda kalanın sıfırdan farklı çıkması hatayı ele veriyor.

Frame’in 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 25: Adres Çözümleme: ARP

Frame’in 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 frame’i yazmadan önce sessiz bir hesap yapıyor. Hedef IP adresini ve kendi adresini alt ağ maskesinden geçiriyor. Maske, adresin hangi kısmının ağı, hangi kısmının makineyi gösterdiğini söyleyen bir sayı; ayrıntısını 37. bölümde açacağız. İ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. Frame’in hedef MAC adresi router’ın interface’i 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 tablosuna, ad IP adresine, kapı numarası MAC adresine karşılık geliyor. Sınırları da aynı: 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 frame için router’ın MAC adresi gerekiyor. İstek, sen farkına varmadan bir soruya bağlı bekliyor.

Neden broadcast’le soruluyor?

Tabloda kayıt yoksa makine soruyu ağa broadcast ediyor. Frame’in hedef MAC alanına FF-FF-FF-FF-FF-FF yazılıyor. Sebep sade: sorunun kime gideceği bilinmiyor.

Broadcast’i yerel ağdaki bütün düğümler alıyor. Standart, hedefi tümü bir olan her frame’i her istasyonun alıp işlemesini şart koşuyor. Hedef olmayan cihazlar, örneğin router, 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 frame’i halka tampona alıp kernel’a 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 broadcast’le dönmüyor, tek bir frame’le 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.

Sorunun kaç kapıya çarptığını ve cevabın kaç kapıdan döndüğünü görelim:

Birbirinin broadcast frame’lerini alan düğümlerin tamamına broadcast domain (yayın alanı) deniyor. Broadcast yerine multicast kullanmak daha iyi bir fikirdi; ilk biti bir olan adresler multicast’ti ve IPv6’nın adres çözümlemesi, Neighbor Discovery, oraya yaslanıyor. Bu bağırışın nereye kadar gittiğini açık bırakıyorum; sınırını bir sonraki durakta çizeceğiz.

Bir yana: RARP ters yönü çözüyordu, MAC adresinden IP adresini öğreniyordu. Bu işi bugün 36. bölümde göreceğin DHCP yapıyor.

Paketin içinde 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 frame’i 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ş
               frame   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
               frame   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 frame olarak gidiyor. Sorduğun soru, kablodaki en küçük frame.

Frame’in tür alanı 0x0806. Alıcı bu değere bakıp yükü ARP modülüne veriyor. Encapsulation merdiveninde bu tür alanını zaten görmüş ve değerini not etmiştin. ARP paketi bir data link layer frame’inin içinde taşınıyor ama network layer 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 ama ne kadar olduğu sistemden sisteme çok değişiyor. Eski BSD sistemleri eşlemeyi 20 dakika hatırlıyordu, Cisco router’lar varsayılan olarak 4 saat hatırlıyor. Linux ve bugünkü Windows ise kaydı yalnızca yarım dakika kadar “erişilebilir” sayıyor; sonra onu bayat işaretleyip ilk kullanımda sessizce yeniden doğruluyor. Aynı protokolde ömür yüzlerce kat 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. Ağdan kopan bir makinenin kaydı da süresi dolunca 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 (gratuitous 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ı 10. bölümde koyduğumuz MITM saldırısı; bu kez yerel ağın içinde. Switch üstündeki dinamik ARP denetimi (Dynamic ARP Inspection), MAC adresi ile IP eşleşmelerini bilinen kayıtlarla karşılaştırıp bunu kesiyor.

Başkasının adresine cevap vermek her zaman saldırı sayılmıyor. Router aynı şeyi bilerek ve açıkça yapabiliyor: kendi ağında olmayan bir adres için sorulan ARP isteğine kendi MAC adresiyle cevap veriyor, yani “onu bana ver, ben iletirim” demiş oluyor. Adı proxy ARP. Soran makine hedefi komşusu sanıyor, frame’i router’a yazıyor ve paketi farkında olmadan geçitten geçiriyor.

Fikir, maskesi yanlış ayarlanmış ya da alt ağ kavramını hiç tanımayan eski makineleri kurtarmak için doğdu. Bugün açık bırakılması tavsiye edilmiyor ve sebebi öğretici: proxy ARP ile zehirleme aynı hamleyi yapıyor. Biri meşru, öteki saldırı, ama kabloda ikisi de “benim değil ama bana yolla” diyen bir cevap. Açık bırakılan bir proxy, gerçek bir zehirlemeyi de göze normal gösteriyor.

Bunların hepsini kendi makinende görebilirsin. Windows’ta tablo arp -a ile geliyor, Linux’ta ip neigh ile, Cisco router’da 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.

Interface: 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.

21. bölümde 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: soruyu soran bir router’sa kaynağa ICMP Hedef Bilgisayara Ulaşılamıyor (Destination Host Unreachable) mesajı gönderiyor, senin makinense aynı hatayı sana kendisi veriyor.

Özet

• 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 broadcast’le gidiyor, cevap unicast 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; bu süreyi RFC 826 zorunlu kılmaz, sistemler yüzlerce kat farklı süreler seçer.
• Proxy ARP zehirlemenin meşru ikizidir: ikisi de başkasının adresine cevap verir; bu yüzden açık bırakılan bir proxy gerçek bir saldırıyı da göze normal gösterir.
• 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” kim?

Bölüm 26: Ortam Erişimi: CSMA/CD

Ethernet’in ilk yıllarında “herkes” kelimenin tam anlamıyla herkesti. Bütün kartlar aynı kabloya bağlıydı ve kabloya konan her frame, o kablodaki her kartın önünden geçiyordu.

Herkesin her şeyi duyduğu bir kabloda asıl sorun duymak değil, konuşmak. İki kart aynı anda konuşmaya başlarsa ne oluyor ve sıra kime, nasıl veriliyor?

Aynı kabloyu paylaşmak

Klasik Ethernet’te kartlar tek bir koaksiyel kabloya boncuk gibi dizilirdi. Bir kart gönderdiğinde sinyal kablonun iki ucuna doğru yayılıyor ve yol üstündeki her karta ulaşıyordu; her kart frame’in hedef adresine bakıp kendisine ait olmayanı atıyordu. 25. bölümdeki ARP isteğinin herkese ulaşması bu yüzden özel bir çaba istemiyordu. Kablonun doğası buydu.

Kablo sonradan bükümlü çifte geçtiğinde görünüş değişti, öz değişmedi. Kartlar artık ortadaki bir hub’a bağlanıyordu. Hub bir porttan aldığı sinyali, o port hariç bütün portlara güçlendirerek kopyalar. Tablosu yoktur, kararı yoktur, seçeneği yoktur. Kablolar yıldız biçimini aldı ama ortam hâlâ tek parçaydı.

Tek parça ortamın kuralı basit: aynı anda yalnızca bir kart konuşabilir. İki kartın sinyali kabloda üst üste binerse ikisi de bozulur; bu olaya collision (çarpışma) deniyor. Aynı collision’a düşebilecek kartların oluşturduğu alanın adı collision domain. Koaksiyel Ethernet’te kablonun tamamı, hub’lı bir ağda hub’a bağlı bütün kartlar tek bir collision domain’dir.

Tek bir kanalı paylaşmanın üç ailesi

Paylaşılan kabloda çözülmesi gereken problem şu: 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; 54. bölümde multiplexing’e indiğimizde ikisini de ayrıntısıyla göreceğiz. Adil ve collision olmadan; 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; collision 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 collision’lar ç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. 28. bölümde 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 frame 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 (Carrier Sense Multiple Access) bir adım daha atıyor: konuşmadan önce dinle. Adındaki carrier sense, hatta başka birinin sinyali olup olmadığını dinlemek demek; insan sohbetinin kuralı. Yine de collision bitmiyor, çünkü sinyalin kabloda yol alması zaman alıyor: uzaktaki bir düğüm konuşmaya başlamış olabilir ve sen henüz duymamış olabilirsin. Collision penceresi, iki uç arasındaki yayılım gecikmesi kadar.

CSMA/CD son adımı atıyor: konuşurken de dinle. Sondaki CD, collision detection; collision’u fark ettiğin anda sus. ALOHA bütün frame’i 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 frame’den ancak 16 ardışık collision olmadan sonra vazgeçiyor.

64 baytlık asgari frame nereden çıktı?

Kitap boyunca Ethernet’in en küçük frame’ini 64 bayt diye kullandık ve bu sayıyı hiç gerekçelendirmedim. Gerekçesi burada, collision sezmede.

Bir kartın collision’u fark edebilmesi için, collision haberi kendisine döndüğünde hâlâ gönderiyor olması gerekiyor. Aksi hâlde frame’i bitirip işine döner, collision olmadan 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, repeater’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 frame boyu bir veri kararı değil, sinyalin 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: frame’in arkasına, collision penceresi dolana kadar anlamsız bit eklemek. Yöntemin adı taşıyıcı uzatma (carrier extension) 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 collision diye bir olay olmayınca CSMA/CD standartta durmayı sürdürdü ama fiilen devre dışı kaldı.

Özet

• Paylaşılan ortamda herkes her şeyi duyar: koaksiyel Ethernet’te kablo, hub’lı ağda hub tek bir collision domain’dir ve aynı anda yalnızca bir kart konuşabilir.
• Çoklu erişimin üç ailesi var: kanalı bölmek, rastgele erişim ve sıra alma; Ethernet ikinci aileden gelir.
• Her adım bir israfı kapattı: ALOHA %18, dilimli ALOHA %37 verim verirken CSMA dinlemeyi, CSMA/CD ise konuşurken dinlemeyi ekledi.
• 64 bayt bir veri kararı değil: collision’u sezebilmek için frame’in, haberi geri dönene kadar sürmesi gerekiyordu ve 10 Mbit/s × 51,2 µs = 512 bit eder.
• Tam çift yönlü kip collision’u bitirdi: kart aynı anda gönderip alabilince CSMA/CD standartta kaldı ama fiilen devre dışı kaldı.

Paylaşılan kabloda sıra bir kuralla dağıtılıyordu ve her collision bir bekleme demekti. Bugün kabloların çoğunun öbür ucunda hub değil, frame’i yalnızca gereken kabloya veren bir kutu duruyor. Peki o kutu hangi frame’i nereye göndereceğini nereden biliyor?

Bölüm 27: Switch'ler

Kimse ona söylemiyor. Kutu, üstünden geçen frame’leri dinleyerek öğreniyor ve öğrendikçe herkese bağırmayı bırakıyor.

Kutunun adı switch ve bir yerel ağda kimin neyi duyacağını bugün artık kablo değil, onun tablosu belirliyor. Peki o tabloyu kim, ne zaman yazıyor?

Tabloyu kim yazıyor?

Switch bir data link layer cihazı ve hiç de edilgen bir kutu değil. Frame’i alıyor, saklıyor, sonra iletiyor; kararını verirken de frame’in başına bakıyor.

Makinen frame’i switch’e adreslemiyor; karşı makinenin fabrika adresini yazıyor ve arada bir cihaz durduğundan haberi bile olmuyor. Switch 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 interface ve kaydın zaman damgası. Standart metnindeki adı iletme veritabanı, sahadaki adı MAC adres tablosu ya da, tutulduğu hızlı bellek türünden, CAM tablosu.

Asıl numara satırın nereden geldiğinde. Switch hedef adresten hiçbir şey öğrenmez, kaynak adresten öğrenir. Gelen frame’in göndericisini alır, frame’in 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. 21. bölümde yakalama yaparken kartı bu moda almıştın; switch’in portları zaten hep öyle durur. Kendisine gelmeyen frame’leri de alır, çünkü öğrenmesi gereken onlardır.

Mahalle bakkalı defterini nasıl tutuyorsa switch de tablosunu öyle tutuyor. Benzetme burada bir adım öteye gidiyor: bakkal sorup öğreniyordu, switch sormuyor bile.

Ölçek de dikkat ister. Adres alanı 48 bit, yani iki üzeri kırk sekiz kadar olası ad var. Bir switch’in tablosu ise ev tipinde birkaç bin, büyük kurumsal modellerde birkaç yüz bin satır. Switch adres uzayını tutmuyor, yalnızca duyduklarını tutuyor.

Hedefi tanımıyorsa ne oluyor?

Frame içeri girdiğinde sıra sabit: kaynak kaydı önce, hedef araması sonra. Aramanın üç sonucu var ve üçü de ayrı bir davranış üretiyor.

Hedef, frame’in geldiği portta görünüyorsa switch frame’i hiç iletmez. Düşürür. İki makine aynı kabloda oturuyorsa birbirlerini zaten duymuşlardır; bu davranışın adı filtreleme.

Hedefin yeri biliniyorsa frame tek bir kablodan çıkar. Ağın geri kalanı o trafiği hiç görmez. Switch’in bütün değeri bu cümlede.

Hedef tabloda yoksa switch bilmediğini itiraf eder. Frame’i 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 frame’ini geri almaz.

Bilinmeyen makine cevap verdiği anda frame’i switch’e girer, switch onun portunu öğrenir ve o adrese bir daha flooding yapmaz. Bilgisizlik tek bir frame boyunca sürüyor.

Tablonun ilk frame’den başlayarak nasıl dolduğunu izleyelim:

Bir frame türü bu kuralın dışında kalıyor. Tümü bir olan FF-FF-FF-FF-FF-FF dizisi broadcast adresiydi; o adrese giden frame, tablo ne kadar dolu olursa olsun bütün portlarda kopyalanır. Switch broadcast’i kesmez. ARP, switch’in ardında da bağırarak çalışmayı sürdürür.

Açık bıraktığım broadcast domain sınırının cevabı burada duruyor. Ağda yalnızca hub, bridge ve switch varsa ortaya tek bir broadcast domain çıkıyor. O duvarı ancak router örüyor.

Kayıtların bir de ömrü var. Bir adresten belli bir süre frame gelmezse satır silinir; bu süreye yaşlanma süresi deniyor ve tipik değeri 5 dakika, yani 300 saniye. Süre ayarlanabiliyor. Tablodaki satırların çoğu dinamik, yani switch’in kendi öğrendikleri; yaşlanma yalnızca onlara işler. Yönetici elle statik satır da ekleyebilir. Statik satır yaşlanmaz, silinene kadar tabloda kalır.

Neden beş dakika? Süre kısa olursa switch sessiz duran makineleri unutur ve onlar için gereksiz yere flooding yapar. Uzun olursa, yeri değişip henüz hiç konuşmamış bir makineye giden frame’ler eski portuna gönderilmeye devam eder. Makine konuştuğu anda switch satırı hemen düzeltir; yaşlanmayı beklemez.

Bir Cisco switch’in konsoluna girersen tabloyu tek komutla görebilirsin:

Switch# show mac address-table
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    0000.5e00.531c    DYNAMIC     Gi0/3
   1    0000.5e00.537b    DYNAMIC     Gi0/5
   1    0000.5e00.53a4    STATIC      Gi0/1
Total Mac Addresses for this criterion: 3

Cisco adresi noktayla ayrılmış dörtlü gruplar hâlinde yazar; 0000.5e00.531c, tireli yazımla 00-00-5e-00-53-1c. İlk sütundaki VLAN’ı 29. bölümde açacağız: switch bir adresi VLAN’ıyla birlikte öğrenir ve aynı MAC iki VLAN’da iki ayrı satır olabilir.

İki makine aynı ağda nasıl konuşuyor?

Parçalar tamamlandı. Kartın kendi adı, komşunun sorulması ve switch’in öğrenmesi ayrı ayrı duruyordu; şimdi üçünü tek bir konuşmada birden yürütelim.

Sahneyi sade tutalım. Aynı switch’e bağlı iki makine var: A’nın adresi 192.0.2.10, B’ninki 192.0.2.40, maske ikisinde de 255.255.255.0. Switch yeni açılmış, yani tablosu boş. A, B’ye bir istek gönderecek.

Karar. A hedef adresi kendi maskesinden geçiriyor ve iki sonucun aynı çıktığını görüyor; B komşu olduğuna göre frame geçide değil, doğrudan B’ye yazılacak.

Komşunun donanım adresi. A’nın ARP tablosunda B’nin satırı yok. A bir ARP isteğini broadcast ediyor; frame’in hedef MAC alanında FF-FF-FF-FF-FF-FF, sorusu “192.0.2.40 kimde?”.

Switch’in ilk öğrenmesi. Frame switch’e giriyor. Switch kaynak MAC alanına bakıp A’yı geldiği portla eşliyor; tablonun ilk satırı böyle yazılıyor. Hedef broadcast adresi olduğu için frame’i giriş portu dışındaki bütün portlara kopyalıyor.

Cevap. Soruyu ağdaki herkes duyuyor, yalnızca B cevaplıyor. Cevabı broadcast’le değil, doğrudan A’ya yazıyor. Bu frame switch’e girdiğinde tabloya ikinci satır düşüyor ve cevap yalnızca A’nın portundan çıkıyor.

Asıl veri. A artık B’nin MAC adresini biliyor. İsteği yazıyor, frame’in hedefine B’nin adresini koyuyor. Switch tablosuna bakıp tek bir porta iletiyor. Ağdaki üçüncü bir makine bu frame’i hiç görmüyor.

Konuşmanın tamamında dikkat etmen gereken şey şu: switch paketin içindeki IP adresine bir kez bile bakmadı. Bütün kararlarını frame’in iki MAC alanıyla verdi. A ile B’nin gözünde aradaki switch yok gibi duruyor; ikisi de karşısındakiyle doğrudan konuştuğunu sanıyor.

Yerel ağın tanımını da buradan çıkarabilirsin: aynı ağda olmak, frame’in araya bir router girmeden karşı tarafa varabilmesi demek. Peki hedef başka bir ağdaysa? Bu beş adımın yalnızca ilki değişiyor, ama sonrası tamamen başka bir hikâyeye dönüşüyor.

Switch ağı neye böldü?

Switch’e giden her kablo kendi başına bir collision domain. Bağlantı tam çift yönlü çalışıyor ve o kabloda collision olmuyor. 24 portlu bir switch 24 collision domain ve tek broadcast domain demek.

Yerini aldığı cihaza bakınca fark keskinleşiyor. Önceki bölümdeki hub her sinyali bütün portlara kopyalıyordu: 24 portlu bir hub’da tek frame 23 gereksiz kopya üretir ve kutunun tamamı tek kocaman collision domain’e dönüşür.

Aynı frame öğrenmiş bir switch’te portların yalnızca %4,2’sini meşgul ediyor. Kalan yirmi üç kablo aynı anda başka konuşmalar taşıyor.

Switch ile hub arasındaki farkın altında özel donanım var. Switch frame’i genel amaçlı bir işlemcide değil, ASIC denen özel bir yongada yönlendiriyor; gecikmenin mikrosaniyeyle ölçülmesinin sebebi bu. Yongaya frame’in ne kadarını okutacağın ise ayrı bir tercih ve onu birazdan göreceğiz.

Küçük bir ev switch’inin 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 frame telde 84 bayt, yani 672 bit yer kaplıyordu; aynı kanal maliyeti 100 Mbit/s’de saniyede 148.809 frame veriyor. Veri sayfasındaki 148.800 bu sayının yuvarlanmış hâli: switch en küçük frame’lerle bile hattın tamamını taşıyabiliyor.

Bütün portlar aynı anda tam yüklenirse iç elektronik yetişemeyip frame düşürebilir; buna bloklama, yetişebilene bloklamayan switch deniyor.

Bridge ile switch arasındaki fark ne?

Peki switch nereden çıktı? Birdenbire ortaya çıkmadı: ondan önce üç cihaz vardı ve her biri bir öncekinin tek bir eksiğini kapattı. Sırayı bir kez görürsen switch’in ne olduğunu da kendiliğinden anlıyorsun.

Repeater en basiti ve en dürüstü. İki portu var, tek işi de zayıflamış sinyali tazeleyip öbür tarafa geçirmek. İçinden ne geçtiğini bilmiyor; frame diye bir kavramı da yok, adres diye bir kavramı da. Kablonun boyunu uzatıyor, başka hiçbir şey yapmıyor.

Hub çok portlu bir repeater’dan ibaret. Aynı işi ikiden fazla kabloya yayıyor: bir porttan aldığı elektriği kalan bütün portlara kopyalıyor. Tablosu yok, kararı yok; bütün portlar tek bir collision domain’in içinde kalıyor.

Bridge zincirin kırıldığı yer. İlk kez bir cihaz frame’i okuyor: hedef MAC adresine bakıyor, kendi öğrendiği tabloya danışıyor ve frame’i ancak gerekiyorsa öbür tarafa geçiriyor. Bu bölümün başında anlattığım üç karar, yani öğrenme, flooding ve iletme, bridge’le doğdu. İki kablo parçasını tek bir broadcast domain’de birleştirirken collision alanlarını ayrı tutuyor.

Switch ise çok portlu bir bridge. Kavram olarak yeni bir şey getirmiyor; getirdiği şey ölçek ve hız.

Peki ikisi aynı işi yapıyorsa neden iki ad taşıyorlar? Dürüst cevap şaşırtıcı: standart hâlâ ikisine birden bridge diyor. Bu işi ilk tarif eden IEEE 802.1D’nin başlığı “MAC Bridges”, bugün onun yerini alan 802.1Q’nunki “Bridges and Bridged Networks”; switch’in yaptığı iş bu belgelerde bridging diye tanımlı. Bölümün sonunda göreceğin Spanning Tree Protocol’ün mesajlarına BPDU, seçtiği cihaza da kök bridge denmesinin sebebi budur; kutunun üstünde switch yazsa bile standart onu bridge sayıyor.

Yine de aradaki farkı önemsiz sayma, çünkü aynı işi başka türlü yapıyorlar. Bridge’in iki ile on altı arası portu olurdu; switch’te yirmi dördü, kırk sekizi geçtiğini görürsün. Bridge kararını genel amaçlı bir işlemcide yazılımla verirdi, switch özel bir yongada veriyor. Sonuç da buradan çıkıyor: bridge frame’leri sırayla işlerken switch bütün portlarda aynı anda hat hızında çalışabiliyor.

Switch frame’i ne zaman iletmeye başlıyor?

Hızın ikinci kaynağını da kararın ne kadar erken verildiğinde bulacaksın. Üç ayrı davranış var, ama aralarındaki bütün farkı tek bir soruda toplayabilirsin: iletmeye başlamadan önce frame’in ne kadarını okuyorsun?

Store-and-forward (sakla ve ilet) frame’in tamamını bekliyor. Sonunda FCS’yi hesaplayıp kuyruktaki değerle karşılaştırıyor, tutmuyorsa frame’i atıyor. 64 bayttan kısa ve 1.518 bayttan uzun frame’ler de burada eleniyor. Bedeli gecikme: frame uzadıkça bekleme de uzuyor. Buna karşılık giriş ile çıkış portunun hızı farklı olduğunda tek çalışan kip bu, çünkü frame zaten baştan sona tamponda duruyor.

Cut-through (kes ve geç) hedef MAC adresini okur okumaz iletmeye başlıyor. Adres frame’in ilk altı baytı olduğu için karar neredeyse anında veriliyor ve gecikme frame’in boyundan bağımsız hâle geliyor. Karşılığında FCS hiç kontrol edilmiyor: bozuk frame de aynı hızla öbür tarafa geçiyor ve ancak varış makinesinde eleniyor. Switch burada hatayı gidermiyor, yalnızca taşıyor.

Fragment-free (parçasız) ikisinin ortasında duruyor. İlk 64 baytı okuyup öyle başlıyor. O sayı sana tanıdık gelmeli: önceki bölümde dilim süresinden türettiğimiz asgari frame boyu. Collision’ların bıraktığı bozuk parçalar o pencerenin içinde kaldığı için, 64 baytı bekleyen bir switch onların hemen hepsini yakalıyor.

Bugün karşına çıkan switch’lerin neredeyse hepsinde varsayılan kipi store-and-forward olarak bulacaksın. Çünkü hatalı frame’i ağa hiç salmamak, kazanılan birkaç mikrosaniyeden değerli sayılıyor; üstelik hızlar arttıkça o birkaç mikrosaniye zaten küçülüyor. Cut-through ise gecikmenin paraya çevrildiği yerlerde yaşamaya devam ediyor: yüksek başarımlı hesaplama kümeleri ve borsa işlem sistemleri.

Flooding ne zaman kusura dönüşür?

Tablonun bir sınırı olduğunu söylemiştim; saldırgan da bunu biliyor. MAC flooding saldırısı sahte kaynak adresli çok sayıda frame’le tabloyu doldurur, gerçek adreslere yer bırakmaz. O noktadan sonra switch her şeyi flooding’e verir. Switch’li ağda dinleme zorlaşıyor ama bitmiyor. Tabloda kaydı olmayan hedefler ile broadcast frame’leri 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 switch arasına yedek olsun diye ikinci bir bağlantı çekmek makul bir fikir gibi durur. Sonucu döngü yolu oluyor. Döngüye giren frame sonsuza dek dolaşır, trafik hattın azami hızına tırmanır ve ağ doyar.

Kapalı bir makineye yollanan tek bir frame bunu başlatmaya yetiyor. Adres hiçbir switch’in tablosunda karşılık bulmaz, her switch onu flooding’le çoğaltır ve döngü varsa kopyalar birikmeye başlar. Frame’lerde, IP’deki TTL gibi bir ömür alanı yok; döngüdeki bir kopya kendi kendine hiç ölmüyor.

IEEE 802.1D bu yüzden Spanning Tree Protocol’ü (STP, yayılan ağaç protokolü) tanımladı. Yedekli bağlantılar fiziksel olarak yerinde durur ama bazı portlar bloklanır, geriye tek bir etkin yol kalır. Bridge’ler birbirlerine BPDU adı verilen küçük mesajlar yolluyor; kimliği en küçük olan kök bridge 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ı, bazen daha fazlasını buluyordu. Hızlı sürümü (RSTP) zamanlayıcı beklemek yerine komşularla doğrudan el sıkışıyor ve yol koptuğunda bloklu portu çoğu zaman bir saniyenin altında açıyor.

Buraya kadar ayrı ayrı gördüğün şeyler tek bir interface çıktısında yan yana duruyor. MTU paketin üst sınırını çiziyordu; switch’in portunda o sınır da, spanning tree durumu da, flooding ayarı da ayrı birer satır:

Switch# show interface fastethernet 0/2

  MTU 1500 bayt
  Spanning tree durumu: gönderme
  Bilinmeyen unicast flooding'i: açık

Özet

• Switch kendi öğreniyor: tablosunu kaynak adreslerden kurar, tak-çalıştır çalışır ve her satırında bir adres, bir interface, bir zaman damgası tutar.
• Üç karar veriyor: hedef aynı porttaysa frame’i düşürür, yeri biliniyorsa tek kablodan yollar, bilinmiyorsa bütün portlara kopyalar.
• Flooding bilgisizliğin bedeli: yalnızca bir frame sürer, ama broadcast adresine giden frame’lerde hiç bitmez.
• Aynı ağda konuşmak tek frame’dir: hedef komşuysa frame doğrudan ona yazılır ve switch paketin içindeki IP adresine hiç bakmadan iletir.
• Switch collision’u böler, broadcast’i bölmez: port sayısı kadar collision domain üretir ve hepsini tek bir broadcast domain’in içinde bırakır.
• Switch çok portlu bir bridge’dir: repeater sinyali tazeler, hub onu bütün portlara yayar, bridge ilk kez frame’i okur; switch’in eklediği şey kavram değil, ölçek ve hız.
• İletme kipi ne kadar okunduğuyla belirlenir: store-and-forward frame’in tamamını alıp FCS’yi denetler, cut-through ilk altı bayttan sonra başlar, fragment-free ise collision penceresi olan 64 baytı bekler.
• Yedeklilik denetimsiz kurulmuyor: ikinci bir kablo döngü demektir ve Spanning Tree Protocol olmadan ağ kendi kopyalarında boğulur.

Switch 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 28: Ağ Topolojileri

Switch’in 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 switch’e 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 physical layer’a düşüyor. Mantıksal topoloji sinyalin hangi yoldan aktığını anlatıyor; onun yeri data link layer. 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. Hub’lı 10BASE-T 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ğı (SAN). 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; 23. bölümde kartın hedef adrese bakıp gerisini okumadan attığını görmüştün.

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. Repeater, 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 (baseband)
 +----------- 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 switch’e 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 repeater; kopyalama davranışını ve yerini switch’e 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; 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: physical ve data link. 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 data link layer’ı 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: .0 genel kablolama, .1 ticari bina, .2 bakır twisted pair, .3 fiber; numaranın sonundaki harf revizyonu gösteriyor. 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 switch 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 -> switch        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ı; 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 56. bölümde elimize alacağız.

Özet

• Topoloji iki ayrı sorunun cevabı: kabloların dizilişi fiziksel topoloji, sinyalin izlediği yol mantıksal topoloji; 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, switch de kat dolabında yerinde duruyor. Aynı switch’e bağlı iki bilgisayar aynı ağda olmak zorunda mı?

Bölüm 29: Sanal Yerel Ağlar

Structured cabling’in (yapısal kablolamanın) yıldız düzeninde her priz kat dolabındaki switch’e bağlanıyordu. Geriye bir soru kalıyor: aynı switch’e takılı iki bilgisayar aynı ağda olmak zorunda mı?

Zorunda değil. Tek bir switch, 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. Broadcast yalnızca ARP değil. DHCP de, hedefi henüz öğrenilmemiş her frame 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ğ (virtual LAN, kısaca VLAN), 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ç switch’e de yayılabiliyor. Çizgiyi donanım çekmiyor; switch’in frame’i 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 interface’leri 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 frame yalnızca aynı gruptaki portlara ulaşıyor. Yirmi dört portlu bir switch’i ikiye bölmek, onu iki bağımsız on iki portlu switch’e 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 switch 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 switch’in içinde bir port-VLAN eşleme tablosu birikiyor. Bildirilmemiş portlar varsayılan VLAN’a düşüyor; çoğu cihazda bu VLAN 1. Orası ölü bir alan değil. Switch fabrika ayarında 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ı switch 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 switch’i nasıl bağlarsın?

Ağ tek kutuda bitmiyor. İki switch’te de 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 switch’i birbirine bağlamak için her switch’te N port yiyor.

Ölçeklenen çözümün adı trunk portu. İki switch’te birer port trunk olarak ayarlanıyor ve aralarına tek bir hat çekiliyor. Trunk’ta VLAN ayrımı yok; hangi VLAN’ın frame’i 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 access port (erişim portu) deniyor. İkisi arasındaki fark frame’in üstünde görünüyor.

Trunk’tan geçen frame sıradan bir Ethernet frame’i olamaz. Üstünde hangi VLAN’a ait olduğu yazmak zorunda. Switch, frame’i hatta vermeden önce ona küçük bir alan basıyor; karşı uçtaki switch o alanı okuyup söküyor. Etiketi ekleyen de söken de switch. Uç cihaz onu hiç görmüyor. Bu işin standart adı IEEE 802.1Q. Trunk’ta bir VLAN’ın frame’leri istisna olarak etiketsiz taşınıyor; o VLAN’a yerel VLAN (native VLAN) deniyor ve fabrika ayarında o da çoğu zaman VLAN 1.

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 switch’ler arasında dolaşabiliyor; Cisco’nun VTP’si bunu yapıyor. 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 VLAN atlama saldırısı (VLAN hopping) dediği şey buradan besleniyor: saldırgan kendini komşu bir switch gibi tanıtan bir pazarlık mesajı yolluyor, takılı olduğu access port’u trunk’a çevirtiyor, sonra istediği VLAN kimliğini kendi frame’ine yazıp o broadcast domain’in içine düşüyor. Saldırının ikinci türü frame’e iki etiketi üst üste koyuyor: ilk switch yerel VLAN’ın etiketini söküp frame’i trunk’a etiketsiz veriyor, bir sonraki switch de alttaki ikinci etiketi okuyup frame’i hedef VLAN’a teslim ediyor.

Saldırı iki ihmalin üstünde yürüyor: portun pazarlığa açık bırakılması ve yerel VLAN’ın fabrika ayarında 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 frame’in başına girmiyor. İki adres alanının ardından, tür alanının önüne sokuluyor. Encapsulation’da 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 frame’in etiketli olduğunu anlıyor.

Sonraki iki bayt etiket denetim bilgisi. O 16 bitin 12 biti VLAN kimliği, 3 biti öncelik; kalan 1 bit (DEI) tıkanma anında önce atılabilecek frame’i işaretliyor. On iki bitlik alan 4.096 farklı değer ayırt ediyor. Kullanılabilir numara sayısı 4.094, çünkü iki değer ayrılmış: 0 “yalnızca öncelik taşıyorum” demek, 4.095 ise kullanılmıyor. Cisco’nun eski cihazlarında normal aralık 1 ile 1005 arasındaydı ve 1002-1005 de FDDI ile Token Ring mirasına ayrılmıştı. O sınır standardın 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ş frame’ler düşürülüyor.

Etiket eklendikten sonra frame’in sonundaki FCS yeniden hesaplanıyor; sebebi CRC’nin frame’in tamamını kapsaması. Boy da değişiyor: etiketsiz azami frame ö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 frame azami boya 482 bayt daha ekliyor.

Etiketin asıl bedeli en küçük frame’de görünüyor; dört baytın küçük frame’de neden ağır bastığını 24. bölümde FCS’nin payını hesaplarken görmüştün.

Etiketli bir frame, etiket bilmeyen bir istasyona düşerse ne oluyor? O istasyon başlıkta tanımadığı bir tür değeri buluyor ve frame’i sessizce düşürüyor. Böyle bir frame’in oraya varması da pek olmuyor, çünkü etiketi yalnızca bunun için ayarlanmış cihazlar basıyor.

Switch’in MAC öğrenme tablosunu doldurması ve döngüyü kesen spanning tree tanıdık. Klasik spanning tree bütün VLAN’lar için tek bir ağaç kuruyor ve bazı VLAN’ların trafiğini gereksiz yere uzun yollara itiyor. Çoklu spanning tree (MSTP) 802.1s ekiyle 2003’te tanımlandı, 802.1Q’nun 2005 baskısına girdi ve VLAN gruplarına ayrı ağaçlar kurabiliyor; 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 switch var.

Router’da her VLAN için ayrı bir fiziksel interface tutmak pahalı. Tek interface’in üstünde alt interface 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.

Router frame’i 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. Sahada bu düzene, tek bir kabloya asılı router anlamında router on a stick deniyor.

Üreticiler ikisini tek kutuda da birleştiriyor ve o kutunun bir adı var: 3. katman switch. Dışarıdan sıradan bir switch gibi duruyor, portları da öyle; farkı, VLAN’lar arası kararı kendi içinde verip trafiği hiç dışarı çıkarmaması. Router’dan ayrıldığı yer ise interface çeşitliliği: 3. katman switch Ethernet portlarıyla ve kendi bacakları arasında çalışır, farklı türden hatları birbirine bağlamak hâlâ router’ın işidir.

Bunu kendi makinende de görebilirsin. Linux’ta bir interface’in üstüne etiketli bir alt interface 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 interface’ten çıkan her frame artık etiketli.

Özet

• Sanal yerel ağ bir port kümesidir: switch’in 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 switch’ler görür.
• 3. katman switch ikisini tek kutuda toplar: VLAN’lar arası kararı kendi içinde verir, ama farklı türden hatları bağlamak hâlâ router’ın işidir.
• VLAN’lar arası geçiş routing’dir: 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 interface, switch’in 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 switch’in iletim kararı yapıyor. Kablosuz bağlıysan ortada kablo yok; frame o boşlukta nasıl gidiyor?

Bölüm 30: Kablosuz Erişim: 802.11

Dizüstünü toplayıp bahçeye çıktın. Frame hâlâ aynı frame, 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 collision’u göremediği bir ortamda collision 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 physical layer’ı ile data link layer’ının bir kısmı kablosuzlaştırılmıştır. IP ve üstü hiç değişmez. Değişen yalnızca 19. bölümde ayırdığımız MAC alt katmanı ile onun altındaki physical layer’dır; LLC yerinde kalır. Yani encapsulation 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: data link layer ile physical layer. Ailede 802.3 Ethernet’e ayrılmış, 802.11 kablosuz ağa. IEEE bu işe 1990’da başladı ve ilk sürümü 1997’de yayımladı; 2,4 GHz’de 1 ve 2 Mbit/s için tasarlanmıştı. Aynı yıllarda kablolu Ethernet 10 ve 100 Mbit/s hızındaydı; kablosuz ağ yarışa çok geriden başladı.

Kablosuz, ortamı paylaşan broadcast bağlantılarının en saf örneği. Paylaşılan ortamın temel kuralını 26. bölümde CSMA adıyla görmüştük: göndermeden önce hattı dinle, boşsa gönder, doluysa boşalmasını bekle.

Dinlemek tek başına yetmiyor. Birkaç makine aynı anda hattı boş görüp aynı anda gönderebilir. Üstelik collision 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.

Switch her kabloyu ayrı bir collision domain’e çeviriyordu; paylaşılan kabloda ise CSMA/CD göndericiye kendi collision’unu sezdiriyordu. Telsizde o adım yok. Vericinin kendi anteninden çıkan sinyal, uzaktan gelen bir sinyalden milyonlarca kat güçlüdür; gönderirken başkasını duymaya çalışmak, bağırırken fısıltı dinlemeye benzer. Aynı anda hem gönderip hem dinleyemeyen bir gönderici collision’u kendisi göremez, göremediğini de ortasında kesemez.

Ethernet CSMA/CD kullanır, 802.11 ise CSMA/CA. Sondaki iki harf farkı özetliyor: CD collision detection, yani collision’u sezmek; CA collision avoidance, yani ondan kaçınmak.

Duymadığın komşu seni nasıl bozuyor?

Havada sinyal gittikçe zayıflar. Bu zayıflamanın adı path loss: elektromanyetik dalganın vericiden alıcıya giderken güç yoğunluğunun düşmesi. Düşüşün hızı ortama bağlı. Path loss üssü boş uzayda 2, şehir içinde 2,7 ile 3,5 arasında, duvarların araya girdiği bina içinde 3 ile 6 arasında. Duvarlar sinyali mesafeden daha hızlı yiyor. Tersine bir istisna da var: düz bir koridor dalgayı bir kılavuz gibi taşıdığı için orada üs 2’nin altına, 1,6 ile 1,8’e iner.

Ş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 path loss’u 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 path loss’un hesabını 34. bölüme 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 frame’in tamamı gönderilir. Gönderim yarıda kesilmez.

Alıcı frame’i sağlam aldıysa SIFS kadar bekler ve bir ACK döner. Bu onay gizli terminal yüzünden zorunlu; gönderici frame’inin vardığını başka türlü bilemez.

İki sürenin boyu bilerek farklı seçilmiş. SIFS 10 ile 16 mikrosaniye, DIFS ise 28 ile 50 mikrosaniye arasında. Onay gönderecek alıcı kanalı herkesten önce boş görür; yeni bir gönderime hazırlanan cihazlar ise daha uzun beklemek zorundadır. Böylece bir veri frame’i ile onun ACK’i arasına kimse giremez. Öncelik bir kuralla değil, beklemenin uzunluğuyla verilmiş. Aynı fikir sonra ses ve görüntüye öncelik tanımak için de kullanıldı: 802.11e ile gelen düzende ses trafiği daha kısa, arka plan trafiği daha uzun bekler.

Kanal doluysa gönderici, kanal boşaldığı an atılmaz. Bekleyen herkes o an atılsaydı hepsi birden çarpışırdı. Bunun yerine her biri rastgele bir geri çekilme sayacı çeker. 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 uzun süredir bekleyen, sayacı donduğu için sırasını kaybetmez.

ACK gelmezse gönderici collision varsayar. Geri çekilme aralığını ikiye katlar ve baştan dener. Pencere 15 ya da 31 dilimden başlar, en fazla 1.023 dilime çıkar. Bir dilim physical layer’a göre 9 ya da 20 mikrosaniye; en kötü durumda bu, 9 ile 20 milisaniyelik bir bekleme demek.

Burada kabul edilmiş bir körlük var. 802.11’de kayıp ile collision aynı belirtiyi verir ve ikisi birbirinden ayrılamaz. Körlüğün bir bedeli de var: gönderim hızını sinyale göre ayarlayan algoritmalar, collision yüzünden kaybolan frame’i zayıf sinyale yorup hızı gereksiz yere düşürebilir.

Gizli terminali asıl çözen mekanizma rezervasyon. Gönderici önce küçük bir RTS (Request to Send) frame’iyle kanalı ayırtmak ister. Access point CTS (Clear to Send) ile cevap verir; cevap göndericiye adreslidir ama havada herkes onu duyar. 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; onu duyan her cihaz kendi içinde bir sayaç (NAV) kurup o süre boyunca kanalı dolu sayar. RTS frame’leri de çarpışabilir; kısa oldukları için kaybedilen zaman küçük kalır. Aynı hesap ters yönde de işliyor: küçük bir veri frame’i için rezervasyon, verinin kendisinden pahalıya gelir. Bu yüzden RTS/CTS her gönderimde kullanılmaz; cihazlar onu bir boyut eşiğinin üstündeki gönderimlere saklar.

Veri frame’i gidip ACK döndüğünde cihaz frame’i kendi kuyruğundan siler. Access point de aldığı frame’i kablolu tarafa, router’a doğru 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 36. bölümde göreceğimiz 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 frame’lerini toplar; access point’ler beacon’ı varsayılan olarak 102,4 ms’de bir, yani saniyede yaklaşık on kez yayınlar. Aktif yolda cihaz kendisi bir yoklama isteğini (probe request) broadcast eder; menzildeki access point’lerin hepsi yoklama cevabı gönderir. Uygulamada ikisi birden kullanılır.

Aktif yoklamanın bir gizlilik geçmişi var. Cihazlar eskiden daha önce bağlandıkları ağları adlarıyla tek tek sorardı. Havayı dinleyen biri bu listeden sahibinin evini, işini ve kaldığı otelleri çıkarabiliyordu. Bugünkü telefonların yoklamada ağ adı vermemesi ve 23. bölümde gördüğümüz rastgele MAC adresini kullanması bu yüzden.

Seçim yapıldıktan sonra cihaz seçtiği access point’e bir ilişkilendirme (association) isteği yollar ve karşılığında ilişkilendirme cevabı alır. Sorulan şey, konuşup konuşamayacakları: iki taraf ortak destekledikleri hızlarda ve özelliklerde burada anlaşır. İlişkilendirmeden hemen önce iki frame’lik bir authentication adımı da geçer; adına rağmen WPA2’de hiçbir sırrı doğrulamaz. Parolanın gerçekten nerede sınandığını 32. bölümde açacağız.

Kablosuz ağlar iki yapıda kurulur. Access point üzerinden yürüyene altyapı kipi denir. Bir access point ile ona bağlı cihazların oluşturduğu kümenin teknik adı temel hizmet kümesi (BSS); evdeki kablosuz modem ile ona bağlı cihazlar bir BSS’tir. Access point olmadan, cihazların doğrudan birbirine bağlandığı yapıya ad-hoc kipi denir; teknik adı IBSS, yani bağımsız BSS.

Bir BSS’i ötekilerden ayıran kimlik BSSID’dir ve çoğu zaman access point’in MAC adresidir. Ağın insanların gördüğü adı ise SSID. Aynı SSID’yi aynı alt ağda yayınlayan birden çok BSS birleşince genişletilmiş hizmet kümesi (ESS) çıkar ortaya. Bir okulda ya da ofiste aynı adı taşıyan onlarca access point bu yüzden tek bir ağ gibi görünür. Koridorda yürürken cihaz bir BSS’ten ötekine geçer ve ağın adı değişmez; bu geçişin nasıl işlediğini 35. bölümde göreceğiz.

Altyapı kipinde istemciler birbirleriyle doğrudan konuştuklarını sanır; oysa aynı odadaki iki cihaz arasındaki frame bile access point’ten geçer ve havayı iki kez meşgul eder. Ortam açısından access point bir hub’a benzer: havaya konan her frame’i menzildeki herkes duyar. Tek bir switch, VLAN etiketiyle birbirini hiç görmeyen ağları taşıyabiliyordu; burada tersi oluyor ve tek bir access point herkesi aynı ortama basıyor.

İlişkilendirme bittiğinde artık havaya frame koyabilirsin. O frame’in zarfı Ethernet’inkinden geniş duruyor. İçinde dört adres alanına kadar yer var ve her biri 6 bayt.

frame denetimi     2 bayt        sürüm, tür, alt tür, sekiz bayrak
süre               2 bayt        kanalın ardından ne kadar dolu kalacağı
adres 1            6 bayt        frame'i havadan alacak cihaz
adres 2            6 bayt        frame'i havaya koyan cihaz
adres 3            6 bayt        kablolu taraftaki uç; internete giden trafikte router
sıra denetimi      2 bayt        frame sıra numarası
adres 4            6 bayt        yalnızca iki access point arasında köprü kurulunca
yük                0-2312 bayt   LLC/SNAP başlığı ve IP datagramı
CRC                4 bayt        bozulma denetimi

Üçüncü adres bu listenin kilidi. Kabloda iki MAC adresi alanı yetiyordu; havada üçüncüsü gerekir, çünkü havadaki alıcı ile asıl hedef artık farklı cihazlar. Dizüstünden internete giden bir frame’de birinci adres access point’tir, ikinci adres dizüstünün kendisi, üçüncü adres de frame’in kablolu tarafta varacağı router. Access point frame’i Ethernet’e geçirirken üçüncü adresi hedef, ikinciyi kaynak yapar; kendi adresi frame’den düşer.

Frame 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ı pratikte üç değer alır: 0 yönetim, 1 denetim, 2 veri. Wi-Fi’da veri frame’i türlerden yalnızca biri. Alt tür alanı beacon ile ACK’i birbirinden ayırır. Denetim ve yönetim frame’leri ağın kendi işleyişini taşır ve kullanıcıya hiç görünmez.

Bayrakların ilk ikisi, To DS ve From DS, adres alanlarının nasıl okunacağını söyler. DS, access point’leri birbirine bağlayan dağıtım sistemi; çoğu zaman kablolu ağın kendisi. İstemciden access point’e giden frame’de ilk bayrak, access point’ten istemciye gelende ikincisi 1’dir. İkisi birden 1 olduğunda frame iki access point arasında taşınıyordur; dördüncü adres alanı ancak o zaman frame’e eklenir. Tek access point’li bir evde bu alan hiç görünmez; mesh sistemlerinde ise access point’ler arasındaki trafik tam bu biçimle taşınır.

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 alanı frame’e hiç konmadığı 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 frame 2.346 bayt eder. Zarfın payı yüzde bir buçuk civarında kalır.

Hesabın dışında kalan iki kalem var. Listede Ethernet’teki tür alanının karşılığı yok; 802.11 yükün başına 23. bölümde gördüğümüz 8 baytlık LLC/SNAP başlığını koyar ve IP taşıdığını orada söyler. Bugünkü ağlarda veri frame’lerine 2 baytlık bir öncelik alanı (QoS Control) da eklenir.

Asıl bedel ise zarfta değil beklemede. Her frame için DIFS, geri çekilme, SIFS ve ACK harcanıyor; hızlı bir bağlantıda bunlar frame’in kendisinden uzun sürebilir. 802.11n’den bu yana birçok frame tek seferde art arda gönderilir (A-MPDU) ve tek bir toplu onayla (Block Ack) karşılanır. Hızlı Wi-Fi’ın sırrının önemli bir kısmı daha hızlı bit göndermekte değil, daha az beklemekte.

Peki bu frame 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; Türkiye, Avrupa gibi 13 kanal kullanır. Kanal merkezleri 5 MHz arayla dizilmiş ama her kanal 20 ile 22 MHz genişliğinde. Bu yüzden birbirine hiç değmeyen yalnızca üç kanal seçilebilir: 1, 6 ve 11. 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. Sensör ağlarının 802.15.4 radyosu da bu bandı paylaşıyor; Wi-Fi’ın 1, 6 ve 11 kanallarının arasında kalan boşlukları 75. bölümde göreceksin.

Havadaki frame’i 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 32. bölümde göreceğiz.

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; arayüzün adı sende wlp2s0 gibi farklı olabilir, iw dev hepsini listeler. 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 BSSID, yani havaya koyduğun frame’lerin birinci adres alanına yazdığın değer. 2437 MHz, 6. kanalın merkez frekansı.

Özet

• Değişen tek şey ortam: kablosuz LAN yeni bir ağ kurmaz; var olan LAN’ın physical layer’ını ve MAC alt katmanını kablosuzlaştırır, IP ve üstü aynen kalır.
• Collision alıcıda olur: gönderici aynı anda gönderip dinleyemediği için kendi collision’unu göremez; 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, collision sezmenin yerini alır. SIFS’in DIFS’ten kısa olması onaya öncelik tanı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.
• Üçüncü adres zarfı genişletir: altyapı kipinde 28 bayta çıkan zarfın Ethernet’ten farkının çoğu, frame’in kablolu tarafta nereye çıkacağını taşıyan üçüncü adresten gelir.
• Asıl bedel beklemedir: her frame’in DIFS, geri çekilme ve ACK maliyeti var; 802.11n’den beri frame’ler toplu gönderilip toplu onaylanır.

Kanalın boşalmasını bekledin, sıranı aldın, frame’i havaya bıraktın ve onayını geri aldın. Sıra kanalın kendisinde: oraya kaç bit sığıyor ve bunu ne belirliyor?

Bölüm 31: Radyo Kanalı ve Kapasite

Kanal boşaldı, frame’i 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. Formül tek satır:

C = B × log2(1 + SNR)

B hertz cinsinden bant genişliği, SNR ise desibele çevrilmemiş düz oran. Denklemin nereden geldiğini 53. bölümde açacağım; burada ne söylediğine bakalı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; bir 4G ya da 5G telefonunun izin verilen en yüksek gönderme gücü 200 mW, yani 23 dBm. 30. bölümdeki iw çıktısında gördüğün -58 dBm ise yaklaşık 1,6 nanowatt: access point’in gönderdiği gücün on milyonlarca kat zayıflamış hâli.

İ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 burası. Verici gücü düzenleyici sınır yüzünden çoğu bantta toplam olarak sabit, gürültü gücü ise bant genişliğiyle doğru orantılı. Kanalı genişletmek aynı sinyali daha geniş bir alana yayıyor, içeri giren gürültüyü de büyütüyor. Bandı ikiye katlamanın SNR maliyeti 3 dB; desibel ölçeğinde 3 dB 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’ın 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. Hangisinin değiştirildiğine göre üç temel yöntemin adı ASK, FSK ve PSK: genlik, frekans ve faz kaydırmalı modülasyon. Faz yönteminin en sade hâli BPSK iki faz kullanır ve her sembolde bir bit taşır. 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, genliğe ve faza birden yayan biçimin adı QAM (quadrature amplitude modulation). m-QAM, 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 1 ile 12 bit arasında taşıyor; en alt basamak BPSK, en üstteki Wi-Fi 7’nin 4096-QAM’i. 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ı 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. Kural yukarıda da sürüyor: Wi-Fi 6’nın getirdiği 1024-QAM en az 30, Wi-Fi 7’nin 4096-QAM’i en az 36 desibel istiyor. İkisi de pratikte yalnızca access point’le aynı odadayken devreye giriyor.

Derinlik bu yüzden sabit seçilmiyor. Uyarlamalı modülasyon, SNR değiştikçe şemayı uçuş sırasında değiştiriyor ve kabul edilebilir hata oranındaki en yüksek hızı arıyor. Değişen yalnızca derinlik de değil. 24. bölümde gördüğümüz ileri hata düzeltme, gönderilen bitlerin bir kısmını yedeğe ayırıyor; bu oranın adı kodlama oranı. 3/4 kodlama, her dört bitin üçünün veri, birinin yedek olduğu anlamına geliyor.

Wi-Fi’da ikisi birlikte seçiliyor ve bileşimin adı MCS (modulation and coding scheme). 20 MHz’lik bir kanalda tek akışla 16-QAM ve 1/2 kodlama 26 Mbit/s veriyor, 64-QAM ve 5/6 kodlama 65 Mbit/s. Sembol başına bit 1,5 kat arttı ama hız 2,5 kat; farkın geri kalanı, temiz kanalda yedeğe daha az bit ayrılmasından geliyor.

Rahat bir Wi-Fi bağlantısı için genellikle en az 20 dB SNR öneriliyor; bu değer 64-QAM’in faturasını karşılıyor, 256-QAM’inkini karşılamıyor. En yavaş MCS ise birkaç desibelde bile çalışıyor. Hücresel radyolar daha da aşağı inebiliyor: gürültünün sinyalden güçlü olduğu -6 ile -10 dB’de bile bağlantı sürüyor, karşılığında hız çok düşüyor. Tavan da kuşakla yükseldi: 802.11n’de 64-QAM olan üst sınır 802.11ac’de 256-QAM’e, 802.11ax’te 1024-QAM’e, 802.11be’de 4096-QAM’e çıkarıldı. Modülasyonun matematiğini burada kesiyorum; dalga biçimlerini 52. bölümde, kanalın tavanını 53. 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ı 30. bölümde saymıştık; çıkış yolu yukarı taşınmak. 5 GHz bandında birbiriyle örtüşmeyen 20 MHz’lik kanal sayısı ülkeye göre değişiyor: Türkiye’nin de uyduğu Avrupa kurallarında 19, ABD’de 25’i aşıyor. 2020’den beri açılan 6 GHz bandı Avrupa’da 24, ABD’de 59 kanal daha ekledi. Bunun bedeli menzilden ödeniyor; hesabını 34. bölümde spektrumu açtığımızda yapacağım.

Switch her portu ayrı bir collision domain’e çevirip ortamı bölüyordu. Havada böyle bir bölme yok. İkinci bir access point eklemek ancak başka bir kanaldaysa kapasite katıyor. Aynı kanaldaki iki access point birbirini duyduğu sürece aynı havayı sırayla kullanıyor; ikinci cihaz kapsamayı genişletiyor, hızı değil. Kalabalık binalarda access point’lerin gücü bu yüzden bilerek kısılıyor ve kanallar komşusununkiyle çakışmayacak biçimde dağıtılıyor.

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 multiplexing’de 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 (orthogonal frequency-division multiplexing) o boşluğu kaldırıyor. Alt taşıyıcılar birbirine dik, yani ortogonal seçiliyor: spektrumları yarı yarıya üst üste binse de her alt taşıyıcının tam merkezinde komşularının katkısı sıfıra iniyor. Koruma bandına gerek kalmıyor.

Izgarayı en açık hâliyle 4G’de görmek mümkün; telefon şebekesinin kendisini 33. bölümde açacağız, burada yalnızca kanalın nasıl bölündüğüne bakıyoruz. Ş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,7 µs sürüyor; iki sayı birbirinin tersi.

Bu terslik bir tasarım kolu. Her sembolün başına, bir önceki sembolün yansımaları üstüne taşmasın diye kısa bir koruma aralığı ekleniyor ve bu aralık boşa geçen zaman. Wi-Fi 6 kolu kendi lehine çevirdi: alt taşıyıcı aralığını dörtte birine indirip sembolü dört kat uzattı. Koruma aralığı aynı kalınca onun toplam süredeki payı küçüldü ve verim arttı.

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; atama, zamanda art arda gelen iki bloklu çiftler hâlinde yapılıyor. Kanal tek bir kullanıcıya sonuna kadar bırakılmıyor. 2. bölümde gördüğümüz 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 adı OFDMA (orthogonal frequency-division multiple access). OFDM’den farkı, alt taşıyıcıların kime verildiğinde. OFDM de kanalı alt taşıyıcılara bölüyor ama bir anda bütün alt taşıyıcılar tek bir cihaza gidiyor. OFDMA alt taşıyıcı gruplarını aynı anda farklı cihazlara dağıtıyor. Kanalın boşalmasını bekleyen CSMA/CA, sırayı tek bir gönderene veriyordu; OFDMA aynı anda birden çoğuna veriyor.

4G onu baz istasyonundan telefona giden yönde kullanıyor, 5G ve Wi-Fi 6 iki yönde. 4G’de telefondan baz istasyonuna giden yön, pili daha az yoran bir akrabasını (SC-FDMA) seçti.

Wi-Fi 6’da en küçük parça 26 alt taşıyıcı, yani yaklaşık 2 MHz; 20 MHz’lik bir kanal aynı anda dokuz cihaza bölünebiliyor. Access point’ten cihazlara giden yönde iş kolay: access point tek bir gönderimin içine her cihaza ayrı bir parça koyuyor ve hangi parçanın kime ait olduğunu gönderimin başına yazıyor. Ters yön daha zor, çünkü cihazlar birbirinden habersiz. Wi-Fi 6 bunu bir tetik frame’iyle (Trigger frame) çözdü: access point hangi cihazın hangi parçada göndereceğini ilan ediyor, cihazlar da aynı anda kendi parçalarında gönderiyor. O gönderim için bekleme de collision da ortadan kalkıyor.

Wi-Fi 6 ve 7 access point’leri eski cihazlarla konuşurken yine OFDM’e dönmek 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 (multiple-input multiple-output), aynı anda birden çok anten üzerinden gönderip birden çok antenle almak 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: iki antenli gönderici ile iki antenli alıcı arasında dört anten çifti var ve her çiftin sinyali duvarlardan yansıyarak birden çok yoldan geliyor. Alıcı bu kopyaları birleştirince SNR yükseliyor; buna çeşitleme kazancı deniyor.

Uzamsal multiplexing ise aynı kanalda, aynı anda, her antenden ayrı bir veri akışı gönderiyor. Hızı gerçekten katlayan bu. Çok yollu yayılım burada da kusur değil: akışları alıcıda birbirinden ayırmayı mümkün kılan, her birinin başka yollardan gelmesi. Yansımasız, dümdüz bir hatta uzamsal multiplexing çalışmaz. 64-QAM ile dört akış, her alt taşıyıcıda sembol başına 24 bit taşıyor. Tavanı zorla: 802.11ac’nin sekiz akışı 256-QAM ile 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 (MU-MIMO) 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 (beamforming) dayanıyor: access point her antenden çıkan sinyalin fazını, sinyaller hedef cihazda güçlenip öbür cihazda birbirini söndürecek biçimde ayarlıyor. Bunun için cihazların access point’e göre farklı yönlerde durması gerekiyor; aynı masada oturan iki telefonda kazanç kayboluyor. Anten sayıları da kuşakla arttı: 802.11n 4x4’e, 802.11ac 8x8’e kadar destekliyor. MU-MIMO 802.11ac’de yalnızca access point’ten cihazlara giden yönde geldi, ters yön 802.11ax’i bekledi.

Kuşak numaralarını Wi-Fi Alliance 2018’de koydu ve geriye doğru yalnızca 802.11n’e kadar uyguladı. Yirmi beş yılda teorik tepe hız 11 Mbit/s’den 23 Gbit/s’e, yaklaşık 2.100 kat arttı. Wi-Fi 7 için sık rastlanan 46 Gbit/s sayısı 16 akış varsayıyordu; o özellik 2024’te standarttan çıkarıldı ve tavan sekiz akışla 23 Gbit/s’te kaldı.

Ders kitaplarında 802.11n için 450 Mbit/s yazdığını da görürsün. Çelişki yok: 450, 40 MHz’lik kanalda üç akışın tavanı ve piyasadaki hızlı 802.11n cihazların çoğu üç akışlıydı; tablodaki 600 ise standardın izin verdiği dört akışla çıkıyor.

Tablodaki sayılar teorik tavan; gündelik hız hep altında. Telefonların çoğu iki akışlı, kanalı başkalarıyla paylaşıyor ve 30. bölümde saydığımız bekleme bedelini her frame’de ödüyor. Wi-Fi 7’nin standart adı IEEE 802.11be ve 26 Eylül 2024’te onaylandı. Sıradaki kuşak Wi-Fi 8, yani IEEE 802.11bn; 2028’de tamamlanması hedefleniyor. Kuşakların standarttaki adları yönü gösteriyor: 802.11ax High Efficiency, 802.11be Extremely High Throughput, 802.11bn ise Ultra High Reliability. Hedef bu kez tepe hız değil, kalabalık ortamlarda gecikmeyi ve kaybı azaltmak.

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.

    Band                   : 5 GHz
    Channel                : 44
    ...
    Radio type             : 802.11ac
    ...
    Receive rate (Mbps)    : 866.7
    Transmit rate (Mbps)   : 866.7
    Signal                 : 84%

Linux’ta iw dev wlan0 link daha açık konuşuyor; hızın yanına o hızı üreten ayarları da yazıyor:

tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2

Satırdaki alanlar bu bölümün soruları. 80MHz kanal genişliği. VHT-MCS 9, modülasyon derinliği ile kodlama oranının birlikte adı; burada 256-QAM ve 5/6. VHT-NSS 2 akış sayısı. VHT, 802.11ac’nin standarttaki adı (Very High Throughput). short GI ise koruma aralığının 800 nanosaniyeden 400’e kısaltıldığını söylüyor; hızın yüzde 11’i oradan geliyor. 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

• Kapasitenin iki girdisi var: Shannon bant genişliğini ve SNR’yi alır; 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 1 ile 12 bit arasında taşır; uyarlamalı modülasyon bu sayıyı ve kodlama oranını, yani MCS’i, 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.
• Tavan kuşakla, gündelik hız paylaşımla belirlenir: 802.11be’nin teorik tavanı 23 Gbit/s; iki akışlı telefonlar ve paylaşılan hava gerçek hızı bunun çok altında tutar.

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 32: Kablosuz Ağ Güvenliği

Menzildeki her radyo o frame’i 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ı?

Havada ne şifreleniyor, ne açık kalıyor?

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, frame’lerini şifreleyecek. Üçüncüsü sanıldığından geniş. Koruma yalnızca kullanıcı verisini kapsamıyor. Bağlantıyı koparan deauthentication frame’ini eskiden menzildeki herkes sahte olarak üretebiliyordu; tek bir komutla komşunun bağlantısını düşürmek mümkündü. WPA3’ün zorunlu kıldığı korumalı yönetim frame’leri (PMF) bu tür frame’leri de doğrulamaya bağladı.

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. 30. bölümde bu iki yol ağı bulup ilişkilendirmeye kadar götürüyordu; aynı frame’ler 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ı monitor mode’a alıp yanından geçen her frame’i kaydetmeyi 21. bölümde görmüştük. 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 denetim alanındaki tek bitlik Protected Frame bayrağından okuyabilirsin; bitin eski adı, doğduğu protokolden kalma, WEP biti. Başlığın kendisi şifrelenmiyor: adres alanları açıkta gidiyor, şifrelenen kısım yalnızca yük. Dinleyen biri içeriği okuyamaz, kimin kiminle konuştuğunu yine de görür.

Başlık yine de korumasız değil. WPA2’nin şifreleme düzeni CCMP, yani AES’in sayaç kipiyle bir bütünlük kodunun birleşimi; başlığın yolda değişmeyen alanlarını da bu koda katıyor. Biri yolda adresi değiştirirse alıcı frame’i atar. Şifreleme kanalın hızına dokunmaz, yalnızca her frame’e 16 baytlık bir ek getirir: 8 baytlık bir şifreleme başlığı ve 8 baytlık bir bütünlük kodu.

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: Wired Equivalent Privacy, yani kablolu ortamla eşdeğer bir mahremiyet. Eski access point kataloglarında güvenlik satırı 64, 128 ve 152 bitlik WEP seçenekleriyle reklam ediliyordu. Bu sayıların 24 biti anahtar değildi; her frame’de açıkta giden bir başlangıç vektörüydü. 64 bitlik WEP’in gerçek anahtarı 40 bitti. WEP’in yapısal kusurları 2001’de yayımlandı, 2007’de anahtar bir dakikadan kısa sürede çıkarılır hâle geldi.

WPA 2003’te, eski donanımda çalışsın diye aceleyle hazırlanmış bir ara çözüm olarak geldi; WPA2 2004’te, WPA3 ise 2018’de. Aradaki on dört yıl boyunca WPA2 el sıkışması sahadaki tek ciddi 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 (pre-shared key, PSK).

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 frame’i 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 yalnızca o bağlantıya ait taze bir AES anahtarı üretir. Adı dört adımlı el sıkışma (4-way handshake); mesajları EAPOL frame’leriyle taşınır. EAPOL, genişletilebilir kimlik doğrulama protokolünün (EAP) yerel ağ üstünde taşınan biçimi ve adını kurumsal kipte göreceğimiz 802.1X’ten alıyor.

Sırayı adım adım izleyelim. Birinci mesajda access point rastgele bir sayı, bir nonce gönderiyor. İstemci kendi nonce’unu üretiyor; paroladan türeyen ortak sırrı, iki nonce’u ve iki MAC adresini birleştirip oturum anahtarını hesaplıyor. İkinci mesajda kendi nonce’unu, bu anahtarla hesaplanmış bir MIC (bütünlük kodu) ile birlikte gönderiyor. Access point artık aynı hesabı yapabiliyor; MIC tutuyorsa karşı tarafın parolayı bildiğini anlıyor. Üçüncü mesajda kendi MIC’ini ve broadcast frame’lerinde herkesin ortak kullanacağı grup anahtarını şifreli olarak yolluyor. Dördüncü mesaj istemcinin onayı; iki taraf da anahtarı kuruyor.

Nonce’lar kaydedilmiş bir mesajın yeniden oynatılmasını engelliyor ve her bağlantının anahtarını farklı kılıyor. El sıkışma bittiğinde anahtarı iki tarafta hazır buluyorsun, ama parola hiçbir zaman hatta çıkmamış oluyor. 9. bölümde simetrik şifrelemenin anahtar dağıtımı sorununu görmüştük; burada o anahtarı elden veren bir merci yok, iki tarafın ortak parolası var.

Bu düzenin bir zaafı da var. Nonce’lar ve MAC adresleri açıkta gidiyor; eksik olan tek parça parola. Parolayı bilen biri, yani aynı kafenin ağına bağlı herhangi biri, başka bir cihazın el sıkışmasını kaydederse o cihazın oturum anahtarını hesaplayıp trafiğini çözebilir. WPA2-PSK’da aynı parolayı paylaşanlar birbirine karşı korunmaz.

Bağlanma izini frame frame sayabilirsin: bir beacon, iki authentication, iki ilişkilendirme ve dört EAPOL frame’i, toplam dokuz; her birinin ardından dönen ACK’ler bu sayıya dahil değil. Adres alma sırası ondan sonra geliyor, çünkü el sıkışma bitip anahtar kurulmadan access point cihazın veri frame’lerini geçirmiyor; 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ı; 2005’te matematiksel bir güvenlik kanıtı bile yayımlanmıştı. Mathy Vanhoef’un 2017’de bulduğu kusur şifrede değil, sıralamadaydı. Kanıt anahtarın gizli kaldığını gösteriyordu, ama anahtarın ne zaman ve kaç kez kurulacağını hiç modellemiyordu.

Üçü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. Anahtarı yeniden kurmak, yanındaki sayacı da sıfırlamak demek: nonce olarak kullanılan paket numarası başa dönüyor.

9. bölümde sayaç kipinin en tehlikeli hatasını görmüştü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 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ı, kısaltmasıyla KRACK (Key Reinstallation Attack). En çarpıcı durum Linux ve Android 6’daki istemci yazılımındaydı: yeniden kurulan anahtar tamamen sıfırlanıyor, trafik sıfırlardan oluşan bir anahtarla şifreleniyordu.

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.

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ı. 2018’de bulunan bir yöntemle tam el sıkışmaya bile gerek kalmadı: access point’in ilk mesajına eklediği tek bir alan (PMKID) denemeye yetiyordu, ortada bağlanan bir istemci olmasa bile.

WPA3’ün kullandığı SAE (Simultaneous Authentication of Equals), 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. Her taraf birer skaler ile eleman üretip değiş tokuş eder ve ortak sırrı hesaplar; skaler büyük bir sayı, eleman ise eliptik eğri üzerinde bir nokta. 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 frame eder. Diziliş WPA2’nin dört adımına benziyor, üretilen şey benzemiyor.

Ortak sır tek parça da bırakılmaz; ondan iki anahtar türetilir. Biri Confirm adımındaki kanıtı üretir (KCK), öteki bağlantının ana anahtarı olur (PMK). 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.

SAE bittiğinde dört adımlı el sıkışma yine koşar; ama bu kez paroladan değil, SAE’nin ürettiği ve her bağlantıda farklı olan ana anahtardan başlar. İki kazanç buradan çıkıyor. Parolayı bilen biri bile, kaydettiği başka bir cihazın trafiğini artık çözemez. Parola ileride sızsa bile eski kayıtlar açılmaz; 11. bölümde TLS için gördüğümüz forward secrecy havaya da gelmiş olur.

İki tarafın parolayı hiç göndermeden nasıl anlaştığını izleyelim:

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. Aynı ağ adıyla yalnızca WPA2 sunan sahte bir access point açan biri, istemciyi WPA2 tarafına düşürebiliyor. Bu olduğunda az önce gördüğün WPA3 kazanımı kayboluyor: kaydedilmiş el sıkışmadan parolayı deneme imkânı geri geliyor. Vanhoef ile Ronen bunu 2019’da Dragonblood adıyla yayımladı. Bugünkü çözümlerden biri, WPA3’le bir kez bağlanan cihazın o ağ için WPA2’yi bir daha kabul etmemesi.

Aynı çalışma SAE’nin kendisinde de bir sızıntı buldu: parolayı eğri üzerindeki bir noktaya çeviren adımın süresi paroladan parolaya değişiyordu ve bu süre ölçülebiliyordu. Sonradan eklenen ve 6 GHz bandında zorunlu olan yöntem (hash-to-element) bu adımı her parola için aynı sürede yapıyor.

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. İlk hâli 2001’de kablolu Ethernet portları için yazıldı: port, kimlik doğrulanana kadar yalnızca doğrulama trafiğini geçirir. 802.11i aynı denetimi kablosuza taşıdı; burada kapı bekçisi access point’te duruyor.

Standart üç rol tanımlar: kimliğini kanıtlayan istemci (supplicant), kapıyı tutan kimlik denetleyici (authenticator) ve kararı veren sunucu. Kimlik denetleyici ayrı bir kutu değildir; switch’in ya da access point’in üstlendiği bir roldür. İstemciden gelen kimlik yanıtını alır, bir RADIUS Access-Request paketine koyup 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 frame’i 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. 11. bölümdeki TLS tüneli burada bir web sayfasını değil, tek bir parolayı taşımak için kuruluyor. Sahada en yaygın akrabası PEAP; üniversitelerin ortak ağı eduroam da bu tünelli yöntemlere dayanır.

Tünelin bir şartı var ve en sık atlanan ayar o. İstemci sunucunun sertifikasını denetlemezse, aynı ağ adını yayınlayan sahte bir access point kendi sunucusuyla tüneli kurar ve parolayı toplar. Kurumsal Wi-Fi’da en yaygın yapılandırma hatası bu: sertifika denetimi kapalı bırakılmış istemci.

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

• Ş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. Ama WPA2-PSK’da parolayı bilen, kaydettiği el sıkışmadan o anahtarı hesaplayabilir.
• KRACK anahtarı kırmadı, yeniden kurdurdu: yeniden gönderilen üçüncü mesaj sayacı sıfırlıyordu; düzeltme protokolde değil gerçeklemelerde yapıldı.
• 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 ve her bağlantıya parolayı bilenin bile hesaplayamadığı bir ana anahtar verir.
• 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 33: 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; hız 4G’de onlarca, 5G’de yüzlerce Mbit/s mertebesindedir.

Ders kitapları bu ikisini kablosuz erişimin iki ailesi olarak sayar: bina içinde kalan kablosuz yerel ağlar (WLAN) ve operatörün kurduğu geniş alan hücresel erişim. Türkçede ikincisine çoğu zaman GSM denir. GSM aslında ikinci kuşağın, 2G’nin standardının adı ve Türkiye’de 1994’te açıldı; bugün verini 4G ve 5G taşıyor, ad ise ilk sayısal kuşaktan kalma bir alışkanlık.

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ı. Hepsi i² + ij + j² biçiminde yazılabilen sayılar; i ve j, bir hücreden aynı frekansı kullanan en yakın hücreye gitmek için iki yönde atılan adım sayısı. Sahada en yaygın seçim yedi: i = 2, j = 1.

Küme büyüdükçe aynı frekansı kullanan iki hücre birbirinden uzaklaşıyor. Uzaklığın yarıçapa oranı √(3N); yedi hücrelik bir kümede bu, hücrenin yarıçapının kabaca dört buçuk katı ediyor. Yürüyerek söylersek: bir hücreden iki hücre ilerleyip 60 derece dönmek ve bir hücre daha gitmek, aynı frekansı kullanan en yakın hücreye varmaya yetiyor.

Ş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; tek bir kule üç ayrı hücre gibi davranır. Buna sektörleme deniyor. Yönlü bir panel yalnızca önündeki komşuları duyduğu için girişim azalıyor ve bu, daha küçük bir N’e izin veriyor. 4G ve 5G’de her sektör bütün spektrumu kullanan ayrı bir hücre; bir kulede farklı yönlere bakan üç panel gördüysen, o kule gerçekten üç hücrenin kapasitesini taşıyor.

Talep yine de aşarsa üçüncü hamle var: hücreyi 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 data link layer hizmetidir. Cihaz ile daha büyük ağ arasındaki ilk sıçrama orasıdır.

Hücresel standartları 3GPP adlı uluslararası ortaklık yazıyor; onun adlandırması sabit ve bu bölümde onu kullanacağım. Cihaz User Equipment (UE), 5G’nin radyo kanalı New Radio (NR), baz istasyonu gNodeB (gNB). 4G’de baz istasyonunun adı eNodeB idi.

Telefonun tarafında iş tek bir radyoya da düşmez. iPhone 16’da yaklaşık on bir ayrı radyo var; beşi hücresel, kalanı Wi-Fi, Bluetooth, UWB, uydu, NFC ve GPS için. 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, router’lardan ve sunuculardan oluşur, hem cihazlara hem baz istasyonlarına hizmet verir. Bir operatörün mantıken tek bir çekirdek ağı, ona bağlı binlerce baz istasyonu var.

5G çekirdeğinin en görünür tasarım kararı düzlem ayrımı; adı CUPS (Control and User Plane Separation). Fikir 4G’nin son sürümlerinde başladı, 5G’de temel ilke oldu. 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). Cihazın her veri oturumuna 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 interface’in adı N3. Trafik o interface’te tünellenir: cihazın IP datagramı önce kısa bir tünel başlığıyla sarılır, sonra bir UDP paketinin, o da bir başka IP paketinin içine girer. Encapsulation 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 ve UDP’de 2152 numaralı portu kullanır. Tünellerin genel mantığını 48. bölümde açacağız.

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 telefona gömülü eSIM 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 ve anahtar kartın dışına hiç çıkmaz; onunla yapılan hesap da kartın içindeki yongada yürür, telefonun işlemcisi bile anahtarı görmez. Ziyaret ettiğin ağda alacağın hizmet de ev ağındaki ücretli aboneliğine bağlıdır.

5G’de 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. 4G’ye kadar kalıcı kimlik (IMSI) ilk bağlantıda açıkta gidebiliyordu; sahte baz istasyonu kurup çevredeki telefonların kimliğini toplayan IMSI catcher cihazları bu açığı kullanıyordu. Kartın fabrikadan gelen adını gizlemek için 23. bölümde 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ı, 32. bölümdeki 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ı, radyo kaynaklarını yöneten RRC (Radio Resource Control) protokolünün kurulum 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. 31. bölümde 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 iki kenarda koruma bandı olarak boş kalır; denetim kanalları ise bu 9 MHz’in içinde, her dilimin ilk sembollerinde taşınır.

Dağıtım kararı sürekli yenilenir. 4G’de 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. Aralık büyüdükçe sembol kısalıyor ve karar sıklığı artıyor: 30 kHz’de her 0,5 ms’de, 120 kHz’de her 0,125 ms’de bir karar veriliyor. 5G’nin düşük gecikme iddiasının bir ayağı bu. Taşıyıcının kendi genişliğinin kuşakla nasıl büyüdüğünü 34. bölümde 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. Sonraki sürümler bu sınırı büyüttü; Release 13 32 taşıyıcıya kadar izin verdi.

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 kodlama oranını, yani 31. bölümdeki MCS seçimini besler.

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 frame’i parçalayıp ARQ ile güvenilir kılar. MAC tamponlar, çoklar ve o 1 ms’lik zamanlama kararını verir. Bugünkü baz istasyonları bu yığını üç parçaya bölüyor: Central Unit, Distributed Unit ve Radio Unit. O-RAN girişimi parçalar arasındaki interface’leri açık standart yaparak farklı üreticilerin parçalarını aynı istasyonda birleştirmeyi hedefliyor.

Standart yığının interface’lerini ve üst düzey işlevlerini sabitler. Kaynak bloğu atamasının ve frame zamanlamasının nasıl yapılacağını ise üreticiye ve 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 1.000 mW ile 3.500 mW arasında çeker. Kapalıyken tüketim 15 mW’ın altına iner, yani açık durumun yüzde birinin civarına: 70 ile 230 kat daha az.

Bu fark uykuyu zorunlu kılar. Cihaz DRX (discontinuous reception) uykusundayken gelen trafik, geçerli DRX döngüsü bitene kadar baz istasyonunda tamponlanır. Uzun uyku enerji kazandırır, gecikme ekler. 2. bölümde kuyruk gecikmesi, paketin sırada beklediği süreydi. DRX o kuyruğu kasten uzatıyor. Pille yıllarca çalışması beklenen sensör düğümleri aynı ödünleşimi çok daha uç bir noktada yaşıyor; radyonun zamanın %99’unda kapalı kaldığı protokoller 76. bölümde.

Ters yönde de bir tuzak var. Son paketten sonra radyo birkaç saniye daha açık bekler, çünkü hemen ardından yeni bir paket gelme ihtimali yüksektir. Arka planda sık sık küçük paket gönderen bir uygulama radyoyu hiç uyutmaz; pili büyük bir indirmeden daha hızlı bitirebilir.

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ü 35. bölümde 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
           |    access tech: lte
           | 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

• 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 birinin civarı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 34: 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. Birleşmiş Milletler’in telekomünikasyon kuruluşu ITU’nun 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 ve dört yılda bir toplanan Dünya Radyokomünikasyon Konferansı’nda (WRC) veriliyor. Aralık 2023’teki WRC-23, 6,425 ile 7,125 GHz arasını Bölge 1’de hücresel kullanıma ayırdı. 2027’deki WRC-27’nin 1.7 numaralı gündem maddesi ise 4,4-4,8 GHz, 7,125-8,4 GHz ve 14,8-15,35 GHz aralıkları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. 4.5G diye pazarlanan LTE ihalesi 26 Ağustos 2015’te sonuçlandı ve hizmet 1 Nisan 2016’da başladı. 5G ihalesi 16 Ekim 2025’te yapıldı: 700 MHz ve 3,5 GHz bantlarındaki paketler üç operatöre toplam 2,945 milyar dolara verildi ve 5G hizmeti yine bir 1 Nisan’da, 2026’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.