Bu yazıda, kullanıcı tarayıcıya bir web adresi yazdığı andan sayfanın ekranda görünmesine kadar geçen teknik süreç ayrıntılı biçimde açıklanır. DNS çözümleme, IP bulma, TCP bağlantısı kurma, TLS el sıkışması, HTTP isteği gönderme, sunucu yanıtı alma, HTML indirme, kaynak yükleme, DOM ve CSSOM oluşturma, JavaScript çalıştırma ve tarayıcı rendering aşamaları örnek bir istek akışı üzerinden teknik sırayla ele alınır. Başlangıç ve orta seviye kullanıcıların web'in çalışma mantığını sağlam temellerle anlaması hedeflenir.
Tarayıcıya Adres Yazdıktan Sonra Ne Olur? DNS, TCP/IP, TLS, HTTP ve Rendering Süreci
Bir kullanıcı tarayıcıya bir alan adı yazıp Enter tuşuna bastığında, arka planda saniyeler içinde çok sayıda teknik işlem gerçekleşir. Kullanıcı açısından bu yalnızca bir sayfanın açılması gibi görünse de, gerçekte ağ, güvenlik, sunucu ve tarayıcı tarafında birbirine bağlı pek çok katman çalışır. Web'in neden bazen hızlı, bazen yavaş hissettirdiğini anlamak için bu zinciri adım adım bilmek oldukça değerlidir.
Bu yazıda bir web sayfasına erişim sürecini baştan sona teknik sırayla inceleyeceğiz. DNS lookup aşamasından başlayıp TCP/IP bağlantısı, TLS güvenliği, HTTP isteği, sunucu yanıtı, HTML indirme ve tarayıcı rendering aşamasına kadar tüm süreci örnek bir istek üzerinden takip edeceğiz.
Sürecin Genel Özeti: Kullanıcı Enter'a Bastığında Başlayan Zincir
Basit bir örnek üzerinden ilerleyelim: kullanıcı tarayıcıya 'https://www.ornek-site.com/blog/web-nasil-calisir' adresini yazıyor. Bu noktada tarayıcı önce URL'yi parçalar ve hangi protokolün kullanılacağını, hangi domaine gidileceğini ve hangi kaynağın isteneceğini anlar. Yani burada 'https' protokoldür, 'www.ornek-site.com' host adıdır, '/blog/web-nasil-calisir' ise sunucudan istenecek path bilgisidir.
Tarayıcı bu adresin hangi sunucuya karşılık geldiğini doğrudan bilmez. Önce domain adını IP adresine çevirmesi gerekir, ardından ilgili sunucu ile ağ bağlantısı kurar, gerekiyorsa güvenli oturum başlatır ve HTTP isteğini gönderir. Sunucu yanıt verdiğinde önce HTML gelir, sonra bu HTML içindeki CSS, JavaScript, görseller ve fontlar gibi diğer kaynaklar yüklenir.
Sayfanın görünmesi için yalnızca dosyaların indirilmesi yetmez. Tarayıcı, aldığı verileri yorumlayıp belge yapısını oluşturmalı, stilleri hesaplamalı, yerleşimi belirlemeli ve sonunda pikselleri ekrana çizmelidir. Kullanıcının gördüğü son ekran, aslında ağ ve işleme katmanlarının ortak sonucudur.
URL Analizi ve İlk Hazırlık: Tarayıcı Adresi Nasıl Yorumlar?
Tarayıcı ilk olarak yazılan metnin bir arama sorgusu mu yoksa gerçek bir URL mi olduğunu anlamaya çalışır. Eğer kullanıcı tam bir web adresi girdiyse, tarayıcı bunu bir kaynak isteği olarak işler. Protokol belirtilmişse doğrudan ona göre hareket eder, belirtilmemişse çoğu modern tarayıcı varsayılan davranışları uygular veya HTTPS denemesi yapar.
Bu aşamada tarayıcı bazı yerel kontroller de yapar. Örneğin tarayıcı önbelleğinde bu alan adı veya ilgili kaynaklara dair taze bilgiler var mı diye bakabilir. Ayrıca HSTS politikası varsa, siteye yalnızca güvenli HTTPS üzerinden gidilmesi gerektiğini önceden bilir ve olası HTTP denemelerini atlayabilir.
İşletim sistemi seviyesinde de hazırlıklar bulunur. Hosts dosyası kontrol edilebilir, daha önce çözülmüş DNS kayıtları yerel önbellekten alınabilir ve daha önce aynı sunucuya kurulmuş bağlantılar yeniden kullanılabilir. Bu nedenle her ziyaret aynı adımları aynı maliyetle yaşamaz, bazı adımlar önbellek sayesinde kısalabilir.
DNS Lookup: Domain Adı IP Adresine Nasıl Çevrilir?
İnternet üzerindeki cihazlar birbirleriyle alan adlarıyla değil, IP adresleriyle haberleşir. Bu yüzden tarayıcının 'www.ornek-site.com' gibi okunabilir bir alan adını önce bir IP adresine çevirmesi gerekir. Bu çeviri sürecine DNS lookup veya DNS çözümleme denir.
Tarayıcı önce kendi DNS önbelleğine bakar. Kayıt burada yoksa işletim sistemi önbelleği kontrol edilir, orada da bulunamazsa configured DNS resolver'a, yani genellikle internet servis sağlayıcısının ya da kullanıcı tarafından seçilmiş bir DNS sunucusuna sorgu gönderilir. Bu sunucu da kayıt elinde yoksa çözümlemeyi hiyerarşik DNS sistemi içinde adım adım yapar.
Bu hiyerarşi kök DNS sunucularıyla başlar. Kök sunucu, istenen domainin hangi uzantı sunucusunda aranacağını söyler; örneğin '.com' için ilgili TLD sunucusunu işaret eder. Ardından TLD sunucusu, 'ornek-site.com' alan adının yetkili nameserver bilgisini döndürür ve son olarak yetkili nameserver ilgili hostun IP adresini verir.
Örneğin bu sorgunun sonunda 'www.ornek-site.com -> 203.0.113.25' gibi bir sonuç alınabilir. DNS yanıtı genellikle TTL adı verilen bir süreyle gelir ve bu süre boyunca aynı bilgi önbellekte tutulabilir. Böylece sonraki ziyaretlerde tekrar tüm DNS zincirinin çalışmasına gerek kalmaz.
DNS sürecinde dikkat edilmesi gereken noktalar
- DNS her zaman tek bir paketlik, tek adımlı bir işlem değildir.
- CNAME kayıtları varsa çözümleme birkaç ek adım içerebilir.
- IPv4 için A kaydı, IPv6 için AAAA kaydı kullanılabilir.
- Geciken DNS yanıtı, sayfanın açılışını daha ilk aşamada yavaşlatabilir.
TCP/IP Bağlantısı: İki Makine Arasında İletişim Nasıl Kurulur?
IP adresi öğrenildikten sonra sıradaki görev, hedef sunucu ile taşıma katmanında bağlantı kurmaktır. Web trafiğinde en yaygın yapı, IP üzerinden TCP bağlantısı kurmaktır. IP, paketlerin ağ üzerinde nereye gideceğini belirler; TCP ise bu paketlerin güvenilir, sıralı ve eksiksiz biçimde iletilmesini sağlar.
Kullanıcı HTTPS kullandığı için genellikle hedef port 443 olur. Tarayıcı, sunucunun IP adresine ve 443 numaralı porta bağlanmak ister. TCP burada iletişimin temelini kurar, çünkü üst katmandaki HTTP verisi çoğunlukla bu bağlantı üzerinden taşınır.
TCP bağlantısı genellikle three-way handshake denen üç aşamalı el sıkışma ile başlar. İstemci önce 'SYN' paketi gönderir, sunucu 'SYN-ACK' ile cevap verir, ardından istemci 'ACK' gönderir. Bu işlem tamamlandığında iki taraf artık veri alışverişi yapabilecek bağlantılı bir oturum kurmuş olur.
Bu adım küçük görünse de gecikme üzerinde doğrudan etkilidir. İstemci ile sunucu arasındaki fiziksel mesafe, ağ cihazları, paket kaybı ve yönlendirme kalitesi bağlantı kurulum süresini etkiler. Bu nedenle performans optimizasyonlarında CDN, edge sunucular ve keep-alive gibi kavramlar önemli hale gelir.
TLS El Sıkışması: HTTPS Güvenliği Nasıl Başlar?
Eğer bağlantı HTTPS ise, TCP bağlantısından hemen sonra TLS el sıkışması başlar. TLS, istemci ile sunucu arasındaki trafiği şifreleyerek üçüncü tarafların veriyi okuyamamasını veya kolayca değiştirememesini sağlar. Adres çubuğundaki kilit simgesi, arka planda bu güvenli katmanın başarıyla kurulduğunu gösterir.
Tarayıcı bu aşamada sunucunun sertifikasını kontrol eder. Sertifikanın güvenilir bir sertifika otoritesi tarafından imzalanıp imzalanmadığına, alan adıyla eşleşip eşleşmediğine ve süresinin geçerli olup olmadığına bakılır. Eğer ciddi bir uyumsuzluk varsa tarayıcı güvenlik uyarısı gösterir ve kullanıcıyı risk konusunda bilgilendirir.
TLS el sıkışması sırasında taraflar hangi şifreleme algoritmalarını kullanacaklarını da belirler. Ayrıca ortak anahtar üretimi yapılarak oturum anahtarları oluşturulur. Sonraki HTTP verileri bu oturum anahtarları kullanılarak şifreli biçimde iletilir.
Modern web'de bu aşama performans açısından da önemlidir. TLS 1.3 gibi güncel sürümler daha hızlı el sıkışma sağlayabilir ve bazı önceki yükleri azaltır. Yine de güvenlik katmanı tamamen ücretsiz değildir; doğrulama ve kriptografik işlem maliyeti vardır, fakat bu maliyet günümüz web'inde standart kabul edilir.
HTTP Request: Tarayıcı Sunucudan Tam Olarak Neyi İster?
Ağ bağlantısı ve güvenlik oturumu hazır olduğunda, tarayıcı artık gerçek kaynak isteğini gönderir. Örneğimizde bu istek, 'GET /blog/web-nasil-calisir HTTP/1.1' veya HTTP/2 kullanılıyorsa protokole uygun çerçeveler halinde iletilir. Buradaki amaç, ilgili yol altındaki HTML dokümanını sunucudan istemektir.
HTTP isteği yalnızca path bilgisinden ibaret değildir. Tarayıcı istekle birlikte 'Host', 'User-Agent', 'Accept', 'Accept-Language', 'Accept-Encoding', 'Cookie', 'Cache-Control' gibi başlıklar da gönderir. Bu başlıklar sunucuya istemcinin kimliği, tercihleri, daha önceki oturumu ve kabul edebileceği veri biçimleri hakkında bilgi verir.
Örneğin aynı sunucu üzerinde birden fazla domain barınabilir. Bu durumda 'Host: www.ornek-site.com' başlığı, sunucunun hangi siteye ait yanıtı döndürmesi gerektiğini anlamasını sağlar. Cookie başlıkları varsa oturum bilgisi, giriş durumu veya kullanıcı tercihleri de istekle birlikte taşınır.
HTTP/2 ve HTTP/3 gibi modern protokoller, aynı bağlantı üzerinden birden fazla isteğin daha verimli taşınmasını sağlar. Bu, özellikle çok sayıda CSS, JS ve görsel dosyası yüklenen sayfalarda performans avantajı sunar. Ancak temel mantık değişmez: istemci bir kaynak ister, sunucu da ona uygun bir yanıt üretir.
Örnek bir HTTP istek mantığı
| Bileşen | Örnek değer | Ne işe yarar? |
|---|---|---|
| Method | GET | Kaynak isteme işlemi yapar |
| Path | /blog/web-nasil-calisir | Sunucudaki hedef kaynağı belirtir |
| Host | www.ornek-site.com | Hangi domain için işlem yapılacağını söyler |
| Accept-Encoding | gzip, br | Sıkıştırılmış yanıt kabul edildiğini belirtir |
| Cookie | session=abc123 | Kullanıcı oturumu gibi bilgileri taşır |
Sunucu Tarafı: İstek Geldiğinde Arkada Neler Olur?
HTTP isteği sunucuya ulaştığında iş artık yalnızca ağ katmanında değildir. Önce web sunucusu veya reverse proxy, örneğin Nginx ya da benzeri bir katman, isteği karşılar. Ardından bu istek statik bir dosyaya mı ait, uygulama katmanına mı yönlendirilmeli, önbellekten mi cevaplanmalı gibi kararlar verilir.
Eğer istenen kaynak statik bir HTML dosyasıysa sunucu bunu doğrudan döndürebilir. Ancak dinamik bir uygulamada çoğu zaman iş uygulama sunucusuna aktarılır. Uygulama tarafında route çözümü yapılır, gerekirse veritabanına sorgu atılır, kullanıcı oturumu kontrol edilir ve sayfa için gerekli içerik bir araya getirilir.
Örneğin blog sayfası istendiyse sistem ilgili yazıyı veritabanından çekebilir. Başlık, açıklama, içerik, yazar bilgisi, kategori, görseller ve benzer yazılar gibi parçalar bir şablon içine yerleştirilir. Bu işlemin sonunda sunucu tarayıcıya geri göndereceği HTML yanıtını üretir.
Sunucu performansı bu aşamada çok kritiktir. Yavaş veritabanı sorguları, kötü yazılmış uygulama mantığı, eksik önbellek kullanımı veya yoğun trafik, Time to First Byte süresini artırabilir. Kullanıcının ekranda hiçbir şey görmeden beklediği ilk bölümün önemli kısmı burada şekillenir.
Server Response: Tarayıcıya Dönen Yanıtta Neler Bulunur?
Sunucu isteği işledikten sonra bir HTTP response döndürür. Bu yanıtın içinde bir durum kodu, response header'ları ve çoğu zaman response body bulunur. Eğer her şey yolundaysa en yaygın durum kodu '200 OK' olur.
Header kısmında içeriğin tipi, sıkıştırma yöntemi, önbellek politikası, cookie ayarları, güvenlik başlıkları ve son değiştirilme zamanı gibi bilgiler olabilir. Örneğin 'Content-Type: text/html; charset=utf-8' tarayıcıya gelen verinin HTML olduğunu söyler. 'Content-Encoding: br' ya da 'gzip' gibi başlıklar ise gövdenin sıkıştırılmış gönderildiğini belirtir.
Response body kısmında çoğu zaman asıl HTML belge bulunur. Tarayıcı bu veriyi parça parça da alabilir, yani tüm dosyanın inmesini beklemeden okumaya başlayabilir. Bu sayede render süreci bazı durumlarda veri akışı devam ederken bile kısmen başlatılabilir.
Durum kodu her zaman 200 olmak zorunda değildir. '301' veya '302' yönlendirme anlamına gelir, '304 Not Modified' önbellekteki sürümün kullanılabileceğini söyler, '404' kaynağın bulunamadığını belirtir, '500' ise sunucu hatasını gösterir. Kullanıcının gördüğü sonuç, çoğu zaman bu kodlara bağlı olarak değişir.
HTML İndirme ve Kaynakların Keşfi: Sayfa Neden Tek Dosya Değildir?
Tarayıcı ilk HTML belgesini almaya başladığında bunu satır satır veya parça parça parse eder. HTML içinde başka dosyalara işaret eden yapılar gördüğünde, örneğin CSS dosyaları, JavaScript dosyaları, görseller, fontlar veya favicon gibi kaynaklar için ek istekler planlar. Yani bir web sayfası çoğu zaman tek bir dosyadan ibaret değildir.
Örneğin HTML içinde '' etiketi varsa tarayıcı ilgili CSS dosyasını ister. '
Burada kritik nokta, bazı kaynakların render'ı engelleyebilmesidir. Özellikle CSS dosyaları, sayfanın doğru stillerle çizilebilmesi için erken yüklenmek istenir. Senkron çalışan bazı JavaScript dosyaları da HTML parse işlemini geçici olarak durdurabilir, çünkü script belge yapısını değiştirebilir.
Modern performans teknikleri tam da bu noktada devreye girer. Dosya küçültme, sıkıştırma, cache kullanımı, lazy loading, preload, preconnect ve CDN gibi yöntemler, bu kaynak zincirini daha verimli hale getirmeyi amaçlar. Kullanıcı deneyimindeki hız algısı çoğu zaman bu katmanda belirginleşir.
Browser Rendering: Tarayıcı Gelen Kodları Görsel Sayfaya Nasıl Dönüştürür?
Tarayıcının en görünür işi, indirilen kaynakları ekranda anlamlı bir arayüz olarak göstermektir. Bunun için önce HTML parse edilerek DOM, yani Document Object Model oluşturulur. DOM, sayfadaki elemanların ağaç yapısındaki temsilidir.
Ardından CSS dosyaları parse edilir ve CSSOM adı verilen stil ağacı oluşturulur. Tarayıcı daha sonra DOM ile CSSOM'u birleştirerek render tree üretir. Bu ağaç, ekranda gerçekten çizilecek öğeleri ve bunların stil bilgilerini içerir.
Bir sonraki aşama layout veya reflow olarak bilinir. Burada her elemanın boyutu, konumu ve birbirine göre yerleşimi hesaplanır. Son aşamada paint ve compositing işlemleri yapılır, yani renkler, yazılar, kenarlıklar, gölgeler ve katmanlar ekrana piksel olarak çizilir.
JavaScript bu akışa önemli ölçüde etki edebilir. Script'ler DOM'u veya CSS'i değiştirirse tarayıcı bazı hesaplamaları yeniden yapmak zorunda kalabilir. Bu nedenle gereksiz DOM manipülasyonu veya ağır script çalışmaları, sayfanın geç görünmesine ya da takılmasına yol açabilir.
Rendering sürecinin temel bileşenleri
- DOM: HTML'in ağaç yapısıdır.
- CSSOM: CSS kurallarının yorumlanmış halidir.
- Render Tree: Görünür öğelerin stil bilgileriyle birleşmiş halidir.
- Layout: Elemanların ekrandaki boyut ve konum hesaplamasıdır.
- Paint: Görsel öğelerin piksellere dönüştürülmesidir.
Baştan Sona Örnek Akış: Tek Bir Sayfa İsteğini İzleyelim
Şimdi tüm süreci kısa ama teknik bir akış halinde birleştirelim. Kullanıcı 'https://www.ornek-site.com/blog/web-nasil-calisir' adresini yazıyor ve Enter'a basıyor. Tarayıcı URL'yi çözümlüyor, HSTS ve önbellek kontrollerini yapıyor, ardından domainin IP adresini bulmak için DNS sorgusu başlatıyor.
DNS sonucu geldikten sonra tarayıcı '203.0.113.25:443' adresine TCP bağlantısı kuruyor. TCP el sıkışması tamamlanınca TLS oturumu başlatılıyor, sertifika doğrulanıyor ve şifreli iletişim için gerekli anahtarlar oluşturuluyor. Artık güvenli kanal hazır hale geliyor.
Bundan sonra tarayıcı sunucuya 'GET /blog/web-nasil-calisir' isteğini gönderiyor. Sunucu isteği karşılıyor, uygulama katmanında ilgili blog içeriğini veritabanından çekiyor, HTML çıktısını hazırlıyor ve '200 OK' ile tarayıcıya dönüyor. HTML sıkıştırılmış olarak geldiyse tarayıcı önce bunu açıyor, sonra parse etmeye başlıyor.
HTML içinde bir ana CSS dosyası, iki JavaScript dosyası, birkaç görsel ve bir web fontu bulunduğunu düşünelim. Tarayıcı bu kaynaklar için ek istekler oluşturuyor, bunları uygun önceliklerle indiriyor ve eş zamanlı olarak DOM ile CSSOM yapılarını hazırlıyor. Gerekli hesaplamalar tamamlandığında sayfanın ilk görünür bölümü ekrana çiziliyor.
Sonraki milisaniyelerde görseller tamamlanıyor, script'ler çalışıyor, etkileşimli öğeler aktif hale geliyor ve sayfa kullanıma hazır oluyor. Kullanıcının gördüğü tek şey bir sayfanın açılmasıdır, fakat arkasında isim çözümleme, ağ iletişimi, güvenlik, uygulama mantığı ve grafik işleme gibi birçok farklı katman birlikte çalışmıştır.
Bu Süreç Neden Yavaşlayabilir ve Nasıl İyileştirilir?
Bir web sayfası yavaş açılıyorsa sorun zincirin herhangi bir halkasında olabilir. DNS çözümleme gecikmeli olabilir, sunucu uzak olabilir, TLS kurulumunda ek yük oluşabilir, uygulama sunucusu geç yanıt veriyor olabilir ya da tarayıcı çok fazla kaynak indiriyor olabilir. Bu yüzden performans analizi yalnızca tek bir noktaya bakılarak yapılmamalıdır.
Örneğin büyük ve optimize edilmemiş görseller, ağır JavaScript paketleri ve gereksiz üçüncü taraf script'ler render süresini uzatabilir. Benzer şekilde zayıf cache politikaları, her ziyarette aynı dosyaların tekrar indirilmesine yol açar. Sunucu tarafında ise yavaş veritabanı sorguları ve eksik CDN kullanımı kullanıcı deneyimini olumsuz etkiler.
İyileştirme için sık kullanılan yöntemler arasında DNS öngetirimi, keep-alive bağlantıları, HTTP/2 veya HTTP/3 kullanımı, Brotli sıkıştırma, güçlü cache başlıkları, kritik CSS yaklaşımı, lazy loading, görsel optimizasyonu ve kod bölme yer alır. Amaç, hem ağ üzerinden daha az veri taşımak hem de tarayıcının daha az iş yapmasını sağlamaktır.
Web sitesi hizmeti sunan yapılarda bu teknik detayların doğru kurgulanması büyük fark yaratır. Özellikle hızlı yayına alınan ama zamanla büyüme potansiyeli taşıyan projelerde altyapının esnek ve optimize edilebilir olması önemlidir. Pratikweb gibi hazır web sitesi ve geliştirilebilir platform çözümleri sunan hizmet modellerinde, kullanıcı deneyimini etkileyen bu temel akışın doğru yönetilmesi sitenin hız, güvenlik ve sürdürülebilirliği açısından doğrudan değer üretir.
Sonuç: Web'de Tek Tık Aslında Birçok Katmanın Ortak Çalışmasıdır
Bir web sitesine girmek, dışarıdan bakıldığında tek adımlı bir işlem gibi görünür. Oysa kullanıcı tarayıcıya adres yazdığı anda DNS, ağ, güvenlik, uygulama ve rendering süreçlerinden oluşan çok katmanlı bir zincir devreye girer. Bu zincirin nasıl çalıştığını anlamak, hem web teknolojilerini öğrenmek isteyenler hem de site performansını iyileştirmek isteyenler için güçlü bir temel sağlar.
Eğer web'in teknik mantığını daha iyi kavramak, sitenizin neden yavaş açıldığını anlamak veya doğru altyapı kararları vermek istiyorsanız bu süreci parçalara ayırarak düşünmek en doğru yaklaşımdır. Çünkü kullanıcı deneyimi, yalnızca tasarımla değil, görünmeyen bu teknik akışın kalitesiyle de şekillenir.
Web Projenizi Daha Sağlam Bir Temelle Kurun
Hazır web sitesi, geliştirilebilir platform yapısı ve yönetimi kolay çözümlerle dijital varlığınızı daha verimli hale getirmek istiyorsanız doğru altyapı seçimiyle başlayın.