Apache ve Nginx Web Sunucularının Karşılaştırılması

İki sunucu, iki tasarım felsefesi

Apache HTTP Server ve Nginx, hosting hesaplarında, VPS’lerde ve bulut imajlarında karşılaşma olasılığınızın en yüksek olduğu iki açık kaynaklı web sunucusudur. İkisi de olgun, aktif olarak geliştirilen, doğru yapılandırıldığında güvenli ve çok yoğun siteleri sunabilecek kapasitededir. Farklar; bağlantıları nasıl işledikleri, nasıl yapılandırıldıkları ve hangi işleri kolaylaştırdıklarında yatar.

Apache 1990’ların ortasında ortaya çıktı ve erken dönem webin varsayılan web sunucusu oldu. Nginx ise 2000’lerin başında, sıklıkla C10k sorunu olarak anılan çok sayıda eşzamanlı bağlantıyı verimli biçimde işleme ihtiyacı için özel olarak geliştirildi. Bu köken, her iki sunucunun bugünkü davranışını hâlâ şekillendiriyor.

Mimari: süreçler, iş parçacıkları ve olaylar

Apache ve çoklu işlem modülleri

Apache bağlantı yönetimini bir çoklu işlem modülüne (MPM) devreder:

• prefork, iş parçacığı kullanmadan her bağlantı için bir süreç çalıştırır. Eski mod_php gibi iş parçacığı güvenli olmayan modüller dahil çok uyumludur, ancak en fazla belleği kullanır.
• worker, süreç başına birden fazla iş parçacığı çalıştırır ve bağlantı başına daha az bellek kullanır.
• event, worker’a benzer, ancak boşta bekleyen keep-alive bağlantılarını bir dinleyici iş parçacığına devrederek işçi iş parçacıklarını serbest bırakır. Birçok güncel dağıtımda varsayılandır.

Nginx ve olay döngüsü

Nginx bir ana süreç ve genellikle CPU çekirdeği başına bir tane olmak üzere az sayıda işçi süreç başlatır. Her işçi engellemeyen bir olay döngüsü çalıştırır ve her biri için ayrı bir iş parçacığı oluşturmadan binlerce bağlantıyı aynı anda idare edebilir. Eşzamanlılık arttıkça bellek kullanımı görece sabit kalır; Nginx’in yüksek trafikli siteler, ters vekiller ve yük dengeleyiciler için popüler olmasının nedeni budur.

Yan yana karşılaştırma

Statik ve dinamik içerik

Görseller, stil dosyaları ve betikler gibi statik dosyalarda Nginx genellikle kaynakları daha verimli kullanan seçenektir ve avantajı eşzamanlı bağlantı sayısı arttıkça büyüme eğilimindedir. Event MPM ile çalışan Apache, eski prefork kurulumlarına kıyasla bu farkı önemli ölçüde kapatır; bu yüzden mütevazı bir sitede fark küçük olabilir.

Dinamik içerikte tablo daha dengelidir. Modern kurulumlarda her iki sunucu da PHP isteklerini genellikle FastCGI üzerinden PHP-FPM’e aktarır. Bu noktada web sunucusu büyük ölçüde bir trafik yönlendiricisidir ve yanıt süresi çoğunlukla PHP sürümüne, OPcache’e, nesne önbelleğine, veritabanı sorgularına ve uygulama koduna bağlıdır. Web sunucusunu değiştirmek, yavaş bir WordPress eklentisini veya indekslenmemiş bir veritabanı tablosunu nadiren düzeltir.

Yapılandırma: .htaccess ve merkezi yapılandırma

Çoğu site sahibinin ilk fark ettiği fark yapılandırmadır. Apache herhangi bir dizindeki .htaccess dosyalarını okuyabilir; bu da paylaşımlı hostingdeki kullanıcıların ana sunucu yapılandırmasına dokunmadan yönlendirmeler, yeniden yazma kuralları ve erişim denetimleri eklemesini sağlar. Bu pratiktir, ancak Apache her istekte dizin yolu boyunca bu dosyaları kontrol etmek zorundadır; bu bir miktar ek yük getirir ve dağınık kuralların denetlenmesi zor olabilir.

Nginx’in bir karşılığı yoktur. Tüm kurallar sunucu yapılandırmasında bulunur; bu daha hızlıdır ve anlaşılması daha kolaydır, ancak o yapılandırmaya erişim ve değişikliklerden sonra yeniden yükleme gerektirir.

Örnek: HTTP’yi HTTPS’e yönlendirmek

Apache, bir sanal sunucu (virtual host) veya .htaccess içinde:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx, server bloğu içinde:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Örnek: bir PHP uygulaması için kalıcı bağlantılar

PHP-FPM ile Nginx:

location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~ [.]php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Soket yolu dağıtıma ve PHP sürümüne göre değişir; kopyalamadan önce kendi sisteminizdekini kontrol edin.

.htaccess kurallarını taşırken dikkat edilecekler

Bir siteyi Apache’den Nginx’e geçirirken önce tüm dizinlerdeki .htaccess dosyalarını bulun; uygulamalar bazen alt klasörlere de kural ekler. Her kuralın ne işe yaradığını not edin, Nginx karşılığını yazın ve önemli URL’leri yönlendirme ve durum kodları açısından tek tek test edin. Özellikle erişim kısıtlamalarının, örneğin yükleme klasörlerinde PHP çalıştırmayı engelleyen kuralların, eksiksiz taşındığından emin olun. Nginx, .htaccess dosyalarını yok saydığı için unutulan bir kural sessizce devre dışı kalır ve bu bir güvenlik açığına dönüşebilir.

Modüller, ekosistem ve uyumluluk

Apache’nin modül sistemi en güçlü yanlarından biridir. mod_rewrite, mod_security, mod_headers ve birçok kimlik doğrulama modülü tek bir komutla etkinleştirilebilir ve yeniden derlemeye gerek kalmadan yüklenebilir. cPanel dahil birçok hosting kontrol paneli Apache veya Apache uyumlu sunucular etrafında kuruludur ve sayısız uygulama Apache’yi varsayan .htaccess kurallarıyla gelir.

Nginx tarihsel olarak modüllerin derlemeye dahil edilmesini gerektiriyordu, ancak dinamik modüller yıllardır destekleniyor ve dağıtım paketleri yaygın olanları içeriyor. Ekosistemi en çok vekil kullanımı, önbellekleme, hız sınırlama ve TLS sonlandırma etrafında güçlüdür. Artık birçok uygulama Apache kurallarının yanında resmî Nginx yapılandırma örnekleri de yayımlıyor.

cPanel sunucuları çalıştırıyorsanız, cPanel hosting otomasyon ipuçları rehberimiz ilgili bakım işlerini ele alır.

Nginx ve Apache’yi birlikte kullanmak

Yalnızca birini seçmek zorunda değilsiniz. Yaygın kullanılan bir düzen, Nginx’i önde ters vekil olarak konumlandırır:

• Nginx tüm istemci bağlantılarını kabul eder, TLS’i sonlandırır ve statik dosyaları doğrudan sunar.
• Yanıtları önbelleğe alabilir ve hız sınırları uygulayabilir.
• Dinamik sayfa istekleri yerel bir porttaki Apache’ye aktarılır; mevcut .htaccess kuralları orada çalışmaya devam eder.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Arka uç sunucusunun iletilen istemci IP’sini kaydettiğinden ve ona güvendiğinden emin olun (örneğin Apache’nin mod_remoteip modülüyle); aksi halde her ziyaretçi 127.0.0.1’den geliyormuş gibi görünür. Bunun bedeli, yapılandırılması, izlenmesi ve güncellenmesi gereken ek bir katmandır.

Ayar, güvenlik ve bakım

Seçimden daha önemli olan ayar ipuçları

Hangi sunucuyu çalıştırırsanız çalıştırın, birkaç ayar gerçek dünyadaki hız üzerinde genellikle yazılım değiştirmekten daha büyük etki yaratır:

• HTTP/2’yi etkinleştirin (sürümünüz ve kurulumunuz destekliyorsa HTTP/3’ü de); böylece tarayıcılar tek bir bağlantı üzerinden çok sayıda dosya alabilir.
• Metin yanıtlarını sıkıştırın; gzip veya Brotli ile. Apache mod_deflate veya mod_brotli kullanır; Nginx gzip yönergelerini ve kuruluysa bir Brotli modülünü kullanır.
• Statik dosyalar için önbellek başlıkları ayarlayın; böylece geri dönen ziyaretçiler ve CDN’ler bunları gereksiz yere yeniden istemez.
• PHP-FPM’i doğru boyutlandırın. Çok az işçi istekleri sıraya sokar; çok fazlası belleği tüketir. Sınırı mevcut RAM’e ve süreç başına ortalama belleğe göre belirleyin.
• Keep-alive’ı makul tutun. Çok uzun zaman aşımları, özellikle prefork kullanan Apache’de kaynakları meşgul eder.
• Doğru Apache MPM’ini kullanın. Hâlâ mod_php ile prefork çalıştırıyorsanız, event artı PHP-FPM’e geçmek çoğu zaman Apache’de yapılabilecek en büyük iyileştirmedir.

Örneğin Nginx’te sıkıştırmayı etkinleştirmek yalnızca birkaç satır sürer:

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;

Her değişiklikten önce ve sonra ölçüm yapın. İlk bayt süresini ve toplam yükleme süresini birkaç farklı konumdan raporlayan araçlar, bir ayarın gerçekten işe yarayıp yaramadığını gösterir.

Her iki sunucu için güvenlik temelleri

İki sunucu da özünde güvensiz değildir ve her iki proje de düzenli olarak güvenlik bildirimleri ve düzeltmeler yayımlar. Gerçek dünyadaki sorunların çoğu güncel olmayan paketlerden, açıkta kalan yönetim yollarından, zayıf TLS ayarlarından veya fazla serbest dosya izinlerinden kaynaklanır. Her ikisi için iyi uygulamalar:

• Dağıtımınızdan veya resmî depolardan kurun ve güvenlik güncellemelerini hemen uygulayın.
• Sürüm bilgilerini gizleyin (Apache’de ServerTokens Prod, Nginx’te server_tokens off;).
• Modern TLS ayarları kullanın ve sertifika yenilemeyi otomatikleştirin.
• Yeniden yüklemeden önce yapılandırmayı test edin: apachectl configtest veya nginx -t.
• Olağandışı trafik, tekrarlanan başarısız istekler ve tarama kalıpları için erişim ve hata günlüklerini izleyin.

Otomatik yenileme de, örneğin bir DNS değişikliğinden sonra, sessizce başarısız olabilir. Sertifika ve hosting bitiş tarihlerini TLDix hosting panelinde takip etmek, ziyaretçiler bir tarayıcı uyarısı görmeden önce size haber verir.

Hangisini seçmelisiniz?

.htaccess’e dayanıyorsanız, paylaşımlı hosting veya onun etrafında kurulu bir kontrol paneli kullanıyorsanız ya da Apache modüllerini varsayan uygulamalar çalıştırıyorsanız Apache’yi seçin. Kendi VPS’inizi veya bulut sunucunuzu yönetiyorsanız, çok fazla statik içerik ya da eşzamanlı bağlantı sunuyorsanız veya bir ters vekile, yük dengeleyiciye ya da önbelleğe ihtiyacınız varsa Nginx’i seçin. Mevcut bir uygulama için Apache uyumluluğunu korurken Nginx’in ön uç verimliliğinden yararlanmak istiyorsanız ikisini birden kullanın.

Belirli bir sitenin ne çalıştırdığını mı merak ediyorsunuz? Yanıt başlıkları çoğu zaman sunucu yazılımını ele verir ve TLDix hosting sorgusu bir alan adının arkasındaki sağlayıcıyı gösterir. Hostingin kendisiyle ilgili rehberlik için VPS hosting nedir ve kimin ihtiyacı vardır yazısına bakın.