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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tarayıcı önce kendi cebine bakıyor

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

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

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

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

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

Sayfa tek dosya değil

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Özet

Peki, ne öğrendik?

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

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