İnternet nasıl çalışır? Domain’den sayfaya teknik yolculuk

İnternetin temelinde “bir siteyi açtım ve sayfa geldi” gibi görünen süreç, saniyenin çok küçük dilimlerinde sayısız teknik adımın tamamlanmasıyla oluşur. Bu yazıda, bir tarayıcının domain adını alıp en sonunda sayfa içeriğini ekrana getirmesine kadar geçen yolu parçalarına ayırıyoruz. DNS (Domain Name System) sorgusundan HTTP isteklerine, TLS şifrelemeden CDN/cache katmanlarına kadar her adımın ne yaptığını ve hangi noktada yavaşlama veya hata görebileceğinizi net şekilde öğreneceksiniz.

1) Domain (alan adı) neden tek başına yeterli değil?

Domain adı, insanlar için okunabilir bir isimdir (ör. "example.com"). İnternet ise erişim için isim değil, konum bilgisi ister. Bu konum bilgisi çoğunlukla IP adresidir (IPv4 veya IPv6).

Tarayıcı, siz tarayıcıya "example.com" yazdığınız anda doğrudan web sunucusuna gitmez. Önce şu soruyu çözer: - "Bu domain hangi IP adresine karşılık geliyor?"

Bunun cevabını DNS sağlar. DNS, ad-çözümleme (name resolution) katmanıdır.

DNS nasıl düşünülmeli?

DNS’yi bir telefon rehberi gibi düşünün: - Domain adı -> ilgili IP adresi - Gerekirse başka kayıtlar (MX, TXT, A/AAAA gibi) -> e-posta ve doğrulama süreçleri

Web tarama senaryosunda kritik kayıtlar genellikle: - A: IPv4 adresine karşılık - AAAA: IPv6 adresine karşılık

2) DNS sorgu zinciri: Propagation kadar cache de önemli

DNS tarafında tek bir sorgu yoktur; zincir halinde ilerler. Tarayıcı genellikle işletim sistemi üzerindeki DNS cache’ten sonuç arar. Yoksa sırayla DNS sunucularına gider.

Tipik akış: 1. Tarayıcı/OS DNS cache kontrolü 2. Yerel DNS resolver (ISP veya kurumsal ağ) sorgusu 3. Root DNS (kök) yönlendirmeleri 4. TLD (ör. .com) katmanı 5. Authoritative DNS (domain’in yetkili DNS’i) sonucu

Güncelleme yapınca “hemen” görünmeme nedenleri

NetKıyas’ta DNS değişikliği ile ilgili en sık karşılaşılan sorun “Propagation (yayılma) tamam olmadı” beklentisidir. Propagation tek neden değildir: - Cache süreleri: TTL (Time To Live) değeri - Taraf bazlı farklı cache: işletim sistemi, tarayıcı, ISP resolver - DNSSEC doğrulama varsa ek doğrulama adımı

DNS kaydı güncellendiğinde, doğru IP’ye çözümleme en hızlı şekilde farklı ağlarda aynı anda olmaz. Bu yüzden DNS değişikliği yaptığınızda test etmeniz gereken yaklaşım “tek bir noktadan kontrol” değil, farklı resolver’larla doğrulamadır.

3) IP adresi gelince: Bağlantı kurma (TCP) ve çok kritik bir eşik

DNS çözümü başarıyla sonuçlanınca tarayıcı artık bağlantı kurmaya geçer. Bu aşama genellikle TCP üzerinden başlar (çoğu web trafiği başlangıçta TCP/QUIC benzeri mekanizmalarla ilerler; burada mantığı TCP olarak anlatıyoruz).

Tarayıcı şu kararı verir: - IP adresi doğru mu? - Hangi port üzerinden bağlanmalı? (HTTP genelde 80, HTTPS genelde 443)

Sunucu tarafında portlar kapalıysa veya yönlendirme (routing/NAT) yanlışsa DNS çalışsa bile sayfa gelmez.

Bağlantı kurarken süreyi etkileyen faktörler

Şu durumlar, “DNS doğru ama yine de yavaş” hissini doğurur: - Sunucunun bulunduğu coğrafi uzaklık - Ağ gecikmesi (latency) - İlk bağlantı maliyeti: SYN/SYN-ACK süreçleri - Sunucunun iş yükü (yüksek CPU, thread starvation)

4) HTTPS için TLS: Sayfanın “güvenli” gelmesini sağlayan katman

Web sitesi HTTPS kullanıyorsa tarayıcı bağlantıyı şifreler. Bu noktada TLS (Transport Layer Security) devreye girer.

TLS’in iki temel hedefi vardır: - Verinin gizliliği: içerik şifrelenir - Kimlik doğrulama: sertifika (certificate) sayesinde doğru alan adına ait sunucuya bağlandığınız doğrulanır

Sertifika doğrulaması neden sayfa açılışını etkiler?

TLS sırasında tarayıcı şunları kontrol eder: - Sertifikanın geçerliliği (validity) - Sertifikanın alan adına (domain) uyumu - Sertifika zinciri (CA chain) ve gerekirse ara sertifikalar

Sertifika yanlış veya eksikse tarayıcı uyarı verir, kullanıcı güvenliğe tıklamazsa sayfa yüklenmez.

5) HTTP isteği: Sayfa “iste”r, sunucu “yanıt”lar

TLS tamamlandıktan sonra tarayıcı HTTP üzerinden isteği gönderir. Bu noktada artık “domain” değil, hedef URL (path dahil) önemlidir: - Örn: https://example.com/blog/xyz

HTTP tarafında tarayıcı genellikle: - Ana dokümanı ister (HTML) - HTML içindeki kaynakları ister (CSS, JS, görseller, fontlar)

HTTP akışını hızlandıran pratik mekanizmalar

Keep-Alive: aynı bağlantı üzerinden birden çok isteğin yapılması
HTTP/2 veya HTTP/3: multiplexing ile paralel isteklerin daha verimli taşınması
Cache-Control ve ETag: tekrar yüklemeyi azaltma

Buradaki kritik nokta şudur: Sayfa açılışında tek bir “HTML isteği” değil, onlarca küçük istek toplam süreyi belirler.

6) CDN ve cache: İstek sunucuya gitmeden de karşılanabilir

Birçok hosting senaryosunda domain, doğrudan origin sunucuya değil önce CDN’e bağlanır. CDN (Content Delivery Network), içeriği kullanıcıya yakın edge konumlarda tutar.

Bu durumda yol şu hale dönüşür: 1. Tarayıcı -> CDN edge IP 2. CDN -> isteği cache’ten karşılarsa origin’e gitmez 3. Cache yoksa veya süresi dolduysa origin’e gidilir 4. Yanıt edge’e döner ve sonraki kullanıcılar hız kazanır

CDN ne zaman fark yaratır?

Kullanıcı tabanı farklı ülkelerdeyse
Görsel, statik dosya (CSS/JS) yoğun içerik varsa
İlk istek (cache miss) pahalı ama sonrakiler ucuzsa

Cache yanlış ayarlanırsa ne olur?

Eski içerik görünür
Dinamik sayfalar uygunsuz şekilde cache’lenir
Güncelleme “geç” yansır (CDN cache purge yapılmadan)

7) Origin (asıl hosting/sunucu) tarafında neler olur?

CDN veya doğrudan tarayıcı origin’e ulaştığında web sunucusu devreye girer. Bu katmanda tipik bileşenler: - Web server: Nginx/Apache - Uygulama: PHP-FPM, Node.js, Java, Python vb. - Veritabanı: MySQL/MariaDB veya PostgreSQL - Cache katmanı: Redis/Memcached

Bir sayfa açıldığında zamanın çoğu şu yerlere gidebilir: - Uygulama kodunun çalışması - Veritabanı sorguları - Dosya sisteminden okuma (yüksek I/O) - Harici API çağrıları

Hosting seçiminde “sayfa yolculuğu” perspektifi

Bu noktada VDS/VPS değil sadece disk/CPU değil, darboğazın nerede olacağını anlamak önemlidir. Örneğin: - Dinamik sayfalarda gecikme veritabanından geliyorsa, CPU’dan önce sorgu optimizasyonu ve DB performansı belirleyicidir. - Statik dosyalarda gecikme geliyorsa CDN/cache ve web server ayarları belirleyicidir. - TLS süresi ve ilk bağlantı maliyeti hissediliyorsa, sertifika zinciri ve sunucu ağ davranışı etkili olur.

8) Başarı veya hata: Hangi adımda bozulursa hangi belirti gelir?

Aşağıdaki tablo, kullanıcı deneyimini teknik adımla eşleştirmeye yardımcı olur.

Hata/Belirti	Muhtemel adım	Ne kontrol edilir?
“ERR_NAME_NOT_RESOLVED” / domain bulunamadı	DNS çözümleme	A/AAAA kaydı, DNSSEC, TTL, resolver testi
Tarayıcı sertifika uyarısı veriyor	TLS doğrulama	Sertifika geçerliliği, domain eşleşmesi, CA zinciri
Bağlantı zaman aşımı	TCP/TLS veya ağ	Port erişimi (80/443), firewall, routing, sunucu yükü
404 (Not Found)	HTTP yönlendirme/routing	Web server config, uygulama route, yanlış URL path
502/503	Origin uygulama veya web server	PHP-FPM/Node servis durumu, worker sayısı, kaynak limitleri
Çok yavaş ilk yükleme, sonraki hızlı	CDN cache miss	Cache ayarı, CDN origin cache süresi
Eski içerik görünmesi	Cache/CDN	Cache-Control, CDN purge, uygulama cache invalidation

9) “İnternet nasıl çalışır” bilgisi nasıl işe dönüşür?

Bu yolculuğu bilmek, bir sorunu “hostingim kötü” demeden önce doğru noktaya yöneltir. Aşağıdaki kontrol listesi, domain’den sayfaya giden süreçte sırayla teşhis yapmanıza yardım eder.

Tanılama için net kontrol sırası

Domain çözülüyor mu? - Farklı cihaz/hat ile A/AAAA doğrulayın. - DNS değişikliği yaptıysanız TTL süresini ve resolver cache’leri hesaba katın.
Portlar ulaşıyor mu? - 80/443 erişimi engellenmiş mi (firewall/security group)?
HTTPS çalışıyor mu? - Sertifika domain ile uyumlu mu, zincir hatası var mı?
CDN var mı? - Cache miss’te mi yavaş, yoksa her zaman mı yavaş?
Origin tarafı yanıt süresi nasıl? - Web server logları ve uygulama loglarıyla 5xx/4xx dağılımını inceleyin.
Dinamik sayfada DB mi yavaş? - İlgili endpoint’te en çok zaman alan sorgu/işlem hangisi?
Statik dosyalarda boyut ve gzip/brotli var mı? - Büyük dosyalar ve sıkıştırma eksikliği ilk yüklemeyi belirgin etkiler.

10) Bu mimariyi bir cümleyle özetleyelim

Domain adı önce DNS ile IP’ye dönüşür. IP’ye göre tarayıcı bağlantı kurar; HTTPS kullanılıyorsa TLS ile güvenlik doğrulanır. Sonra HTTP istekleri sırayla HTML ve kaynak dosyalarını getirir. CDN/cache varsa yanıtın bir kısmı origin’e gitmeden edge’den karşılanır; bu da hız farkını yaratır. En sonda origin’deki web server + uygulama + veritabanı, yanıtın toplam süresini belirler.

Sonuç: Bir sonraki adımınız “doğru noktayı” ölçmek olsun

İnternet yolculuğunu adım adım bilmek, sorun yaşadığınızda tahmin yürütmek yerine doğru katmanı test etmenizi sağlar. Bugün için en pratik aksiyon: domain çözümlemesini (A/AAAA), HTTPS sertifikasını ve varsa CDN davranışını ayrı ayrı kontrol edip, yavaşlığın nerede üretildiğini netleştirmektir. Sorunun kaynağını bulduğunuzda hosting tarafında atacağınız adımlar (CDN ayarı, cache politikası, sunucu kaynakları veya uygulama/veritabanı optimizasyonu) doğrudan hedefli hale gelir.