Web Sunucusu ile Uygulama Sunucusu Arasındaki Fark

Bir web projesi büyüdükçe "statik içeriği kim servis ediyor, dinamik kodu kim çalıştırıyor" sorusu kaçınılmaz hale gelir. İki kavram pratikte sıkça birbirine karıştırılır çünkü çoğu kurulumda aynı makinede yan yana çalışırlar. Oysa rolleri, sundukları protokoller ve performans karakterleri birbirinden oldukça ayrıdır.

İki Sunucu Tipini Kabaca Tanımlamak

Web sunucusu, istemciden gelen HTTP/HTTPS isteklerini karşılayan, statik dosyaları (HTML, CSS, JS, görseller) diskten okuyup geri gönderen yazılımdır. Apache, Nginx ve LiteSpeed bu kategorinin en bilinen örnekleridir. Uygulama sunucusu ise iş mantığını, yani kodun kendisini çalıştıran katmandır; veritabanıyla konuşur, oturum yönetir, hesaplama yapar ve çoğu zaman çıktıyı bir web sunucusuna devreder. Tomcat, Gunicorn, PHP-FPM, Node.js süreçleri ve uWSGI bu tarafta yer alır.

Görev Dağılımı Neden Önemli?

Bir kullanıcı tarayıcısına adres yazdığında ilk teması web sunucusu yapar. Eğer istenen şey bir .png ya da hazır bir .html ise web sunucusu bunu kendi başına, son derece hızlı biçimde gönderir. Ancak istek bir form gönderimi, bir API çağrısı veya kullanıcıya özel bir sayfa ise işin içine dinamik kod girer ve bu noktada talep uygulama sunucusuna iletilir. Bu ayrım, kaynakların verimli kullanılmasını sağlar: hafif işleri hafif katman, ağır işleri ağır katman yapar.

• Statik servis: Web sunucusu disk veya bellek önbelleğinden doğrudan yanıt verir, neredeyse hiç CPU harcamaz.
• Dinamik işlem: Uygulama sunucusu süreç başlatır, bellek tüketir ve genellikle veritabanı bağlantısı açar.
• Eşzamanlılık: Web sunucuları binlerce eşzamanlı bağlantıyı kolay yönetirken, uygulama sunucularının iş parçacığı sayısı sınırlıdır.

Karşılaştırma Tablosu

Tipik Bir İstek Yolculuğu

Modern bir PHP kurulumunda zincir genellikle şöyle işler: Nginx isteği alır, statikse kendisi yanıtlar, dinamikse FastCGI üzerinden PHP-FPM'e devreder. Aşağıdaki örnek bu devri net biçimde gösterir.

server {
    listen 443 ssl http2;
    server_name ornek.com;
    root /var/www/ornek/public;

    # Statik dosyalar: web sunucusu doğrudan servis eder
    location ~* \.(jpg|css|js|woff2)$ {
        expires 30d;
        access_log off;
    }

    # Dinamik istekler: uygulama sunucusuna (PHP-FPM) devredilir
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Burada fastcgi_pass satırı, web sunucusunun nerede bittiğini ve uygulama sunucusunun nerede başladığını gösteren sınır çizgisidir. Python tarafında benzer mantık, Nginx'in proxy_pass ile Gunicorn'a yönlendirmesiyle kurulur.

Python ve Java Dünyasında Durum

WSGI tabanlı bir Django ya da Flask uygulamasında uygulama sunucusu çoğunlukla Gunicorn veya uWSGI olur. Nginx isteği bir Unix soketi üzerinden bu sürece taşır:

gunicorn --workers 3 --bind unix:/run/app.sock proje.wsgi:application

Java ekosisteminde ise Tomcat hem servlet motoru hem de uygulama sunucusu rolünü üstlenir; önüne çoğu zaman bir Nginx veya Apache konularak TLS sonlandırma ve statik dağıtım o katmana bırakılır. WildFly gibi tam donanımlı sunucular ise EJB, mesajlaşma ve işlem yönetimi gibi kurumsal yetenekleri tek çatı altında toplar.

Burada sık karşılaşılan bir kafa karışıklığı şudur: Node.js ya da Tomcat aslında gömülü bir HTTP dinleyicisine sahip olduğu için "web sunucusu" gibi de davranabilir. Yani teknik olarak bir Node uygulamasını 3000 portunda tek başına yayına alabilirsiniz. Ne var ki üretim ortamında önüne yine de bir ters vekil (reverse proxy) konulması neredeyse standart bir tercihtir; çünkü TLS yönetimi, sıkıştırma ve statik varlık servisi gibi işleri olgun bir web sunucusu çok daha verimli yapar.

Reverse Proxy Mantığı Neyi Çözer?

Ters vekil, web sunucusunu uygulama sunucusunun önüne yerleştiren mimarinin adıdır. Bu yapı sayesinde tek bir 443 portu üzerinden gelen trafik, arkadaki birden çok uygulama sürecine dağıtılabilir. Aşağıdaki Nginx bloğu, gelen istekleri bir Node sürecine taşıyan tipik bir yapılandırmadır:

upstream nodeapp {
    server 127.0.0.1:3000;
    keepalive 16;
}

server {
    listen 443 ssl http2;
    server_name uygulama.ornek.com;

    location / {
        proxy_pass http://nodeapp;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

X-Forwarded-For başlığı, gerçek istemci IP'sinin uygulama katmanına aktarılmasını sağlar; bu başlık atlanırsa uygulama tüm istekleri tek bir IP'den geliyormuş gibi görür. Bu küçük ayrıntı, oran sınırlama ve loglama açısından kritik öneme sahiptir.

Aynı Makine mi, Ayrı Sunucu mu?

Küçük ve orta ölçekli sitelerde her iki katman aynı sunucuda yaşar ve bu gayet sağlıklıdır. Trafik arttığında ya da uygulama CPU yoğun hale geldiğinde katmanları ayırmak mantıklı olur: statik trafiği web hosting paketleri üzerinde barındırılan bir web sunucusuna bırakıp, dinamik yükü ölçeklenebilir bir kaynağa taşımak yaygın bir yaklaşımdır. İş mantığı için izole, kaynakları garantili bir ortam isteyenler genellikle yönetimi kendinize ait bir sanal sunucu üzerinde uygulama sunucusunu yapılandırmayı tercih eder.

• Birlikte barındırma: Düşük gecikme, basit yönetim, sınırlı ölçeklenme.
• Ayrı barındırma: Bağımsız ölçeklendirme, daha iyi izolasyon, ek ağ gecikmesi.

Bogahost Önerisi: PHP-FPM veya Gunicorn worker sayısını rastgele büyütmeyin. Genel bir başlangıç noktası olarak çekirdek sayısının 2-4 katı kadar worker ile başlayıp, htop ve yanıt sürelerini izleyerek kademeli artırın; aşırı worker, çoğu durumda belleği tüketip swap'a düşürerek performansı tersine çevirir.

Performans ve Güvenlik Açısından İnce Ayrım

Web sunucusunu önde tutmanın güvenlik tarafında da getirileri vardır. TLS sonlandırma, rate limiting, statik önbellek ve temel WAF kuralları bu katmanda uygulanır; uygulama sunucusu doğrudan internete açılmaz, yalnızca yerel soket üzerinden erişilir. Bu yüzden üretim kurulumlarında Gunicorn ya da PHP-FPM'i 0.0.0.0 yerine 127.0.0.1 veya bir Unix soketine bağlamak iyi bir alışkanlıktır. Böylece saldırı yüzeyi daralır ve dinamik katman dış dünyadan soyutlanmış olur.

Özetle Ayrımı Akılda Tutmak

Web sunucusunu kapıdaki görevli, uygulama sunucusunu ise arka ofisteki uzman gibi düşünebilirsiniz: biri herkesi hızlıca karşılar ve basit talepleri yerinde çözer, diğeri ise asıl işi yapan, hesap kitap gerektiren süreçleri yürütür. Projenizin trafik deseni ve kod yapısı, bu iki katmanı nasıl konumlandıracağınızı belirler; doğru görev dağılımı hem hızı hem de istikrarı doğrudan etkiler.