Web sunucusu nedir, nasıl çalışır? Görsel rehber

Web sunucusu, bir web sitesinin tarayıcıya sayfa göndermesini sağlayan temel bileşendir. “Sayfam neden açılmıyor?” ya da “Neden yavaş?” sorularının çoğu, web sunucusunun nasıl çalıştığı bilindiğinde netleşir. Bu rehberde web sunucusunun parça parça işleyişini; istek akışını, HTTP mantığını ve sunucu üzerindeki ayar mantığını görsel mantıkla anlatıyorum. Ayrıca statik vs dinamik içerik, yaygın portlar ve performans kaynaklarını kontrol etmen için pratik ölçüm noktaları ekliyorum.

Web sunucusu (web server) nedir?

Web sunucusu; tarayıcıdan gelen HTTP/HTTPS isteklerini karşılayan, doğru kaynağı (dosya veya uygulama çıktısı) hazırlayıp yanıt olarak döndüren sunucu yazılımıdır. Bu yazılım çoğu ortamda Linux’ta çalışır ve genellikle şu bileşenlerle birlikte düşünülür: - HTTP/HTTPS isteği alma: 80 (HTTP) ve 443 (HTTPS) portları üzerinden - URL ve dosya eşleme: İstenen yolun (path) hangi kaynağa gittiğini belirleme - Statik içerik: HTML, CSS, JS, görsel gibi dosyaları doğrudan gönderme - Dinamik içerik: Uygulama çalıştırma (PHP, uygulama backend’i vb.) - Yanıt biçimi: Dosya türüne göre MIME (Multipurpose Internet Mail Extensions) başlıkları

“Web sunucusu” ile “web sitesi” aynı şey mi?

Hayır. Web sitesi, içerik ve uygulamadır. Web sunucusu ise bu içeriği/uygulamayı istemciye servis eden yazılım katmanıdır. Örneğin aynı sunucuda birden fazla domain barınabilir (virtual host mantığı).

Web sunucusu nasıl çalışır? İstek akışını görselleştirelim

Aşağıdaki şema, tarayıcının bir sayfa istemesinden cevabın ekranda görüntülenmesine kadar olan temel akışı özetler.

1) DNS çözümleme (Domain -> IP)

Tarayıcı ornek.com gibi bir domaini açtığında önce DNS, domaini bir IP adresine eşler. Bu adım web sunucusunun kendisi değildir ama “hangi sunucuya gidiyoruz?” bilgisini üretir.

2) TCP bağlantısı ve şifreleme (HTTPS)

HTTP kullanılıyorsa: TCP ile 80 portundan bağlantı
HTTPS kullanılıyorsa: TLS kurulumu (çoğu kurulumda 443 portu)

3) HTTP isteği (request) oluşur

Tarayıcı sunucuya şu bilgileri gönderir: - Metot: GET, POST vb. - Yol: /urun/123 gibi path - Host başlığı: Hangi domain için istek yapıldığını belirtir - Ek başlıklar: User-Agent, Accept-Language, Cookie vb.

4) Web sunucusu route eder (dosya mı, uygulama mı?)

Web sunucusu gelen isteği alır ve şu karar adımlarını uygular: - İstenen kaynak statik dosya mı? (ör. /assets/app.js) - İstenen yol dinamik mi? (ör. /index.php, /api/*) - Gerekli yetkilendirme/kuralları uygulayacak mı? (redirect, rewrite, auth)

5) Yanıt üretimi (response)

Web sunucusu yanıtı hazırlar: - Durum kodu: 200, 301, 404, 500 gibi - MIME başlığı: Örneğin CSS için text/css - Gövde (body): Dosya içeriği veya uygulama çıktısı

6) Tarayıcı render eder

Tarayıcı HTML’i alır, CSS/JS ve görselleri istek olarak toplar; böylece sayfa ekranda tamamlanır.

Statik ve dinamik içerik farkı: Performansın anahtarı

Web sunucusunun çalışma biçimi, içeriğin statik mi dinamik mi olduğuna göre hız ve kaynak tüketimini ciddi etkiler.

Statik içerik akışı

Statik içerikte çoğu senaryoda web sunucusu dosyayı okur ve doğrudan gönderir. - Üst katman (uygulama) çalışmaz - CPU tüketimi daha düşüktür - Cache (önbellek) ile hız ciddi artar

Dinamik içerik akışı

Dinamik içerikte web sunucusu uygulamayı çalıştırır veya arka uçla konuşur. - PHP-FPM / FastCGI / uygulama motoru gibi katmanlar devreye girer - Her istek için ek hesaplama ve olası veritabanı sorguları oluşur - Uygulama hataları 500 dönebilir

Hız ve yük açısından pratik sonuç

Aynı sayfada statik varlıklar (JS/CSS/görseller) ne kadar iyi cache’lenirse, dinamik kısım için yük o kadar azalır.
Dinamik endpoint’lerde yavaşlığın kaynağı genellikle uygulama kodu veya veritabanı sorgusu olur; web sunucusu tek başına suçlanmaz.

Web sunucusu hangi teknolojileri kullanır? (Ana kavramlar)

Aşağıdaki bileşenleri bilmek, panelde karşılaştığın terimleri doğru yorumlamanı sağlar.

HTTP yöntemleri ve durum kodları

GET: Sayfa/dosya isteme
POST: Form veya API verisi gönderme
301/302: Yönlendirme
404: Kaynak bulunamadı
500: Sunucu tarafı hata

Bu kodlar, “sorun nerede?” sorusunu daraltır. Örneğin 404 genelde yanlış path/konfigürasyon; 500 ise uygulama/çalıştırma tarafında hata işaret eder.

MIME (Content-Type) başlığı

Web sunucusu yanıt verirken tarayıcıya dosyanın türünü Content-Type olarak bildirir. Yanlış MIME, dosyanın indirilmeye zorlanması veya tarayıcıda hatalı yorumlanması gibi sonuçlar doğurabilir.

Portlar: 80 ve 443

80/tcp: HTTP
443/tcp: HTTPS

CDN veya ters proxy (reverse proxy) varsa, istemci tarafındaki portlar CDN’e gider; asıl uygulama sunucusu iç ağdan farklı portlarda konuşabilir.

Yaygın web sunucusu yazılımları ve kullanım mantığı

NetKıyas’ta VDS/VPS/dedicated gibi seçeneklere bakarken “web sunucusu” ifadesi bazen sadece yazılımı, bazen de tüm LAMP/LEMP paketini (stack) çağrıştırır. En yaygın örnekler: - Nginx: Yüksek eşzamanlılık, event tabanlı mimari - Apache: Modüler yapı, .htaccess gibi yaklaşımlar - LiteSpeed: Apache uyumlu modüllerle performans odaklı

Hangi durumda hangisi daha mantıklı?

Tek bir doğru yoktur; karar çoğu zaman uygulama mimarisine ve yönetim tercihlerine göre verilir. Ancak pratik bir ayrım şöyle yapılır: - Nginx tabanlı kurulumlar, cache ve reverse proxy senaryolarında sık görülür. - Apache tabanlı kurulumlar, belirli modül/konfigürasyon alışkanlıklarında tercih edilebilir.

Görsel rehber: Dosya, uygulama ve cache birlikte nasıl çalışır?

Aşağıdaki “katman” şeması tipik bir web akışını anlatır.

Katman 1: İstemci (tarayıcı)
HTML/CSS/JS istekleri
Katman 2: Web sunucusu
URL eşleme, statik dosya teslim
Dinamik istekleri uygulama katmanına yönlendirme
Katman 3: Uygulama (PHP-FPM, Node, Python backend, vb.)
İstek işleme, iş kuralı
Cache veya veritabanı sorguları
Katman 4: Veritabanı (DB)
Ürün/yorum/abonelik gibi veriler
Katman 5: Depolama ve dosya sistemi
Görseller, loglar, geçici dosyalar

Bu şema, bir sorun yaşandığında “hangi katmanda tıkanma var?” sorusunu sistematikleştirir.

Web sunucusunda performans nerede bozulur? (Kontrol noktaları)

Aşağıdaki başlıklar, web sunucusu anlatımının “karar verdiren” kısmıdır. Çünkü çoğu kullanıcı için asıl konu: açılış süresi ve kaynak tüketimi.

1) Üç temel ölçüm: TTFB, istek süresi, hata oranı

TTFB (Time To First Byte): Sunucunun ilk yanıtı ne kadar sürede verdiği
İstek sayısı ve toplam yanıt süresi
4xx/5xx hata oranı

TTFB yüksekse genelde web sunucusu veya uygulama katmanı gecikiyor.

2) Statik dosyalar cache’leniyor mu?

Cache kontrol edilmezse, her istek aynı dosyayı yeniden üretir/okur. - Doğru Cache-Control ayarı - CDN kullanımı (varsa) - Tarayıcı cache stratejisi

3) Dinamik içerikte veritabanı yavaş mı?

Dinamik sayfalarda yavaşlığın önemli bir bölümü SQL sorguları kaynaklıdır. - yavaş sorgu tespiti - index eksikliği - yanlış sorgu planları

4) Sunucu kaynakları: CPU, RAM, disk I/O

VDS/VPS üzerinde web sunucusu süreçleri: - CPU: uygulama ve şifreleme (HTTPS/TLS) yükü - RAM: süreç başına çalışma, cache - Disk I/O: log yazma, statik dosya okuma, swap riskleri

Web sunucusu ayarları: Ne işe yarar, nasıl etkiler?

Aşağıdaki ayarlar, kullanıcı panelinde “aynı görünen” ama sonuca doğrudan etki eden parametrelerdir.

(Örnek) Redirect ve rewrite

301 kalıcı yönlendirmeyi doğru kullan
rewrite kuralları, yanlış eşleşirse 404 veya döngü oluşturur

(Örnek) Gzip/Brotli sıkıştırma

HTML/CSS/JS için sıkıştırma, bant genişliği kullanımını düşürür. - CPU maliyeti vardır - Doğru ayar ile toplam süre genelde azalır

(Örnek) TLS ayarları (HTTPS)

Sertifika doğru kurulu değilse tarayıcı uyarı verir
Eski protokol/şifre takımları performansı etkileyebilir

Kendi sunucun için “web sunucusu doğru çalışıyor mu?” hızlı test listesi

Aşağıdaki kontrol listesi, sorun giderme süresini ciddi kısaltır.

Tarayıcıdan başlayarak

Sayfa açılıyor mu? (ana HTML)
CSS/JS görünüyor mu? (Console/Network hataları)
HTTPS uyarısı var mı?

Sunucu tarafı (Linux) temel kontrol mantığı

Web sunucusu servisi çalışıyor mu? (ör. Nginx/Apache)
Portlar dinleniyor mu? (80/443)
Loglarda hata var mı? (özellikle 4xx/5xx)

Görsel teşhis: 3 senaryo

Her şey 404: Yanlış doküman kökü (document root) veya yanlış virtual host
Ana sayfa 200 ama JS/CSS 404: Static path/alias hatası
500 hatası: Uygulama çalıştırma katmanı veya izin sorunları

Sonuç: Kararı kolaylaştıran aksiyon planı

Web sunucusu; DNS çözümlemeden başlayıp HTTP yanıtını üretmeye kadar birçok adımın merkezinde yer alır. Doğru yaklaşım, “web sunucusu iyi mi kötü mü?” sorusunu TTFB, cache durumu, 4xx/5xx hata oranı ve dinamik içerikte uygulama/DB kaynaklı gecikmelerle netleştirmektir. İlk aksiyon olarak: statik dosyaların cache politikasını kontrol et, ardından dinamik sayfalarda TTFB ve hata oranlarını ölç; sorun neredeyse oraya odaklan. Eğer istersen, NetKıyas üzerinden hedef uygulamanın türünü (WordPress/WooCommerce/custom) yaz; ben de web sunucusu + barındırma (VDS/VPS) tarafında hangi testlerin öncelikli olacağını net bir kontrol akışıyla sıralayayım.