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

İnternette bir web sayfasını açtığınızda “tıklama” ile bitmiyor; arka planda birden fazla sistem aynı anda çalışıyor. Bu yolculuğu net şekilde bilirseniz; erişim gecikmesi, yanlış yönlendirme, sertifika hatası gibi problemlerin nerede ortaya çıktığını çok daha hızlı ayırırsınız. Bu rehberde domain kaydından başlayıp tarayıcıda sayfanın görünmesine kadar olan süreci adım adım açıklıyoruz; ayrıca her aşamada hangi metriklerin ve kontrollerin işe yaradığını göreceksiniz.

1) Domain ne işe yarar: IP yerine isim

Bir web sitesine tarayıcıdan "ornek.com" yazdığınız anda bilgisayarınızın ilk ihtiyacı isim çözümlemektir. Çünkü sunucular genellikle IP adresi üzerinden erişilir. Domain ise insanın hatırlaması için kullanılan bir etiket; gerçek erişim IP ile yapılır.

Domain kaydı (registry/registrar katmanı) şunları belirler: - Domain’in kime ait olduğu (whois) - Hangi DNS sunucularının domain’e ait kayıtları yöneteceği - Domain’in hangi sunuculara (A/AAAA/CNAME kayıtları) yönlendirileceği - E-posta tarafında MX, gönderim/doğrulama için SPF/DKIM/DMARC (web trafiğiyle karışmaz)

DNS kaydı mantığı (A/AAAA/CNAME)

A kaydı (IPv4): "ornek.com" → 203.0.113.10
AAAA kaydı (IPv6): "ornek.com" → 2001:db8::10
CNAME kaydı: "www.ornek.com" → "ornek.com" gibi başka bir isme eşleştirme

Bu kayıtlar doğru değilse tarayıcı sayfaya ulaşamaz. Yanlış DNS sonucu görülen tipik belirtiler: - Tarayıcıda “sunucu bulunamadı” / “DNS probe” benzeri hatalar - DNS güncellemesinin yayılmasından (propagation) sonra bile farklı kullanıcıların farklı sonuç görmesi

2) Tarayıcı DNS sorgusunu nasıl yapar?

İsim çözümleme tek bir sorgu değildir; hiyerarşi vardır.

Tipik sorgu akışı

Tarayıcı önbellek: Daha önce aynı domain açıldıysa sonuçlar tarayıcıda olabilir.
İşletim sistemi önbelleği: Önce OS resolver’ına bakılır.
Yerel DNS resolver (ISP ya da kurumsal DNS): Burada kayıt yoksa sorgu yukarı taşınır.
Yetkili DNS (authoritative): Domain için kayıtların gerçek kaynağıdır.

Burada kritik nokta şudur: DNS çözümlemesi sırasında gecikme yaşanırsa, sayfa daha yüklenmeden “bekleme” başlar. Bu bekleme, hosting kalitesiyle değil çoğu zaman DNS katmanıyla ilgilidir.

Net kontrol: DNS ne kadar hızlı cevap veriyor?

Hedef metrikler: - DNS sorgu süresi (ms) - UDP/TCP fallback olup olmadığı - Rekorların doğru döndüğü (A/AAAA/CNAME)

Kullanılabilecek pratik araçlar: - dig ornek.com A - dig www.ornek.com CNAME - nslookup -type=A ornek.com

Örnek yorumlama: - dig doğru IP’yi dönüyorsa, problem DNS değildir; bir sonraki aşamaya geçilir. - Yanlış veya hiç kayıt dönmüyorsa hosting değil DNS yönlendirmesi sorumludur.

3) IP bulundu: Tarayıcı bağlantıyı kurar (TCP) ve güvenliği açar (TLS)

DNS sonucunda tarayıcı artık “hangi sunucuya gideceğini” biliyordur. Ardından bağlantı kurulması gerekir.

TCP üçlü el sıkışma (handshake)

Tarayıcı sunucuya bağlanırken TCP üzerinden bağlantı kurar. Bu adımda gecikme; özellikle uzak coğrafyalarda görülebilir.

TLS ile sertifika doğrulaması (HTTPS)

HTTPS kullanıyorsanız tarayıcı şu kontrolleri yapar: - Sertifika alan adı (SAN/Subject) domain ile eşleşiyor mu? - Sertifika zinciri güvenilir CA ile doğrulanıyor mu? - Sertifika süresi dolmuş mu? - Anahtar doğrulaması başarılı mı?

TLS hataları genellikle şu şekilde görünür: - “Sertifika güvenilmiyor” - “Domain adı sertifika ile eşleşmiyor”

Bu hatalar DNS’den sonra gelir; çünkü TLS için önce doğru IP ve doğru host bilgisi gerekir.

4) HTTP isteği: Sayfa gerçekten nasıl istenir?

TLS tamamlandıktan sonra tarayıcı HTTP üzerinden istek yollar. Günümüzde en sık senaryolar: - HTTP/1.1 - HTTP/2 - Bazı kurulumlarda HTTP/3 (QUIC)

HTTP yöntemleri ve içerik akışı

Web sayfası çoğunlukla şunları ister: - HTML - CSS - JavaScript - Görseller - API çağrıları (ör. GraphQL/REST)

Burada iki kavram önemlidir: - Ana belge (document): Genellikle HTML - Alt kaynaklar (subresources): CSS/JS/img ve benzeri

Sayfa “açılıyor ama geç geliyor” şikayetinde, çoğu zaman DNS veya TLS değil; HTML’den sonra gelen kaynakların (asset) gecikmesi veya istemci tarafı önbellekleme devreye girer.

5) Hosting ve CDN: Trafik nereden geliyor, nerede bitiyor?

DNS doğru olsa bile sayfanın hızını belirleyen iki katman vardır: - Sunucunun kendisi (web server + uygulama) - Ön planda çalışabilen dağıtım katmanı (CDN)

CDN ne yapar?

CDN, içeriğin bazı kopyalarını kullanıcıya daha yakın sunucularda tutar. - Kullanıcı ornek.com isteğinde bulunur - DNS bazen CDN’e yönlendirir (CNAME/alias ile) - CDN, kullanıcıya en yakın noktadan yanıt verir

Bu sayede özellikle görsel/JS/CSS gibi statik içerikte gecikme azalır.

CDN ile hosting arasındaki sınır

CDN kullanımında şu ayrım net olmalıdır: - Dinamik içerik (kullanıcıya göre değişen sayfalar) çoğu zaman asıl uygulamaya gider. - Statik içerik (filtrelenmiş ve önbelleğe alınabilen varlıklar) CDN’de daha hızlı döner.

6) Bir sorun yaşandığında yolculuk hangi noktada kesilir?

Bu kısım, “neden açılmıyor?” sorusuna sistematik cevap verir.

Sorun türlerine göre olası aşama eşlemesi

DNS hatası: Domain IP’ye çözülemiyor
Bağlantı kurulamadı: TCP kurulamıyor (firewall, port erişimi, routing)
Sertifika/HTTPS hatası: TLS doğrulaması başarısız
404/500: Uygulama ya da web sunucusu katmanı hatalı yönlendirme/konfigürasyon
Uzun yüklenme: HTTP kaynakları yavaş (cache yok, veritabanı gecikmesi, büyük JS)

Net teşhis için pratik test listesi

dig ile DNS kayıtlarının doğru IP’yi döndürdüğünü kontrol edin.
Tarayıcıda hatanın “DNS mi TLS mi HTTP mi” tarafında göründüğünü ayırın.
Geliştirici araçlarında Network (Ağ) sekmesinden: - Ana HTML ne kadar sürede geliyor? - İlk bayt (TTFB) ne durumda? - CSS/JS/img istekleri kaç ms?
HTTP status kodlarını inceleyin (200, 301, 404, 500).
Eğer CDN kullanıyorsanız, CDN’de cache hit/miss oranını kontrol edin (servis panelinden).

7) Domain’den sayfaya giden yolda “net” kontrol edilecek ayarlar

Bir web projesinde yönetici olarak hangi ayarlar yolculuğu doğrudan etkiler?

Domain/DNS tarafı

A/AAAA kayıtları doğru mu?
CNAME zinciri doğru mu? (sonsuz/yanlış yönlendirme olmamalı)
TTL (Time To Live) mantıklı mı? TTL çok düşükse gereksiz DNS trafiği artabilir; çok yüksekse değişiklik yayılımı yavaşlar.

Web sunucusu tarafı

80/443 portları erişilebilir mi?
Virtual host / site tanımı doğru host adını görüyor mu?
Sertifika (TLS) doğru domain için mi?

Uygulama tarafı (hosting performansını etkiler)

Veritabanı bağlantı süresi
Sunucunun CPU/RAM doygunluğu
Uygulamanın cache kullanımı
En önemlisi: log’ların mevcut ve izlenebilir olması

8) DNS ve HTTP hızını sayılarla değerlendirme: hedef yaklaşım

“Yavaş” şikayeti yerine ölçümle karar vermek gerekir. Aşağıdaki hedefler bir başlangıç çerçevesi sağlar.

Ölçüm için pratik hedefler

DNS yanıt süresi: tipik kullanıcıda tek haneli ms-ortalama onlar aralığında hedeflenir (bölge ve ISP’ye göre değişir)
TLS kurulumu: ilk bağlantıda birkaç yüz ms bandı görülebilir; sonraki bağlantılarda oturum tekrar kullanım (session resumption) varsa düşer
HTML yüklenme: TTFB (time to first byte) ve toplam indirme süresi birlikte yorumlanır

Karar verme mantığı (örnek)

DNS süreleri yüksek: Öncelik DNS resolver/rekor ve TTL optimizasyonu.
TLS hatalı: Sertifika/host eşleşmesi.
HTTP durum kodları 301/302 aşırıysa: Yönlendirme zinciri var.
Aynı sayfanın Network’te bazı dosyaları “(from disk cache)” ya da yüksek gecikmeli geliyorsa: cache policy veya CDN ayarı gerekir.

9) Sonuç: Domain’den sayfaya yolculuğu parçalara ayırın

İnternet, tek bir “hosting” ürünü değildir; domain/DNS çözümleme, bağlantı kurma (TCP), güvenlik (TLS), HTTP istek/yanıt ve gerekirse CDN dağıtımı birlikte çalışır. Sayfa açılmıyorsa önce DNS katmanını, HTTPS hatası varsa TLS katmanını, 404/500 görüyorsanız HTTP uygulama katmanını net şekilde ayırın. En hızlı aksiyon: Elinizdeki domain için dig ile rekorları doğrulayın; sonra tarayıcı Network akışında sorunun hangi aşamada başladığını bulun. Bu şekilde hem doğru bileşeni düzeltirsiniz hem de hosting değiştirmenize gerek kalmadan performans/erişim kazanımı elde edersiniz.