Apache HTTP Server Nedir ve Web Sitesi Geliştirme İçin Ne İşe Yarar?

Apache HTTP Server, istemcilerden (tarayıcılar, API tüketicileri, tarayıcı botları) HTTP/HTTPS istekleri alıp uygun yanıtı döndüren açık kaynaklı web sunucusu yazılımıdır — işlenmiş bir HTML sayfası, ikili dosya, yönlendirme veya hata kodu. 1995’ten bu yana Apache Software Foundation tarafından sürdürülen bu yazılım, tek sayfalık kişisel bloglardan çok katmanlı kurumsal uygulamalara kadar her şeye güç vererek internetteki en yaygın kullanılan web sunucularından biri olmaya devam etmektedir.

Mimari çekirdeğinde Apache, Çok İşlemli Modüller (MPM’ler) tarafından yönetilen süreç/iş parçacığı tabanlı istek işleme modelini izler. Gelen her bağlantı bir çalışan süreç veya iş parçacığı tarafından işlenir; bu, ham eşzamanlılık yerine kararlılık ve izolasyona öncelik veren bilinçli bir tasarım tercihidir — yüksek trafikli iş yükleri için bir web sunucusu seçerken önemli sonuçları olan bir ödünleşim.

Apache’nin Web Yığınına Uyumu

Apache tek başına çalışmaz. Ağ ile uygulama katmanınız arasında yer alarak ham TCP bağlantılarını yapılandırılmış HTTP işlemlerine dönüştürür. Tipik bir üretim dağıtımında şunlarla etkileşime girer:

• Kalıcı veriler için bir veritabanı motoru (MySQL, PostgreSQL, MariaDB)
• Bir sunucu tarafı çalışma zamanı (PHP-FPM, Python WSGI, Ruby Rack, proxy aracılığıyla Node.js)
• Bir TLS sonlandırma katmanı (mod_ssl aracılığıyla yerel olarak işlenir veya ters proxy’ye aktarılır)
• Apache’nin çalışan havuzuna CPU süresi tahsis eden bir işletim sistemi süreç zamanlayıcısı

Bu ilişkileri anlamak, Apache’yi varsayılan kurulumun ötesinde herhangi bir şey için yapılandırmadan önce gereklidir.

Apache’nin Temel Teknik Özellikleri

Çok İşlemli Modüller: Performansı Tanımlayan Mimari

Bu, çoğu giriş düzeyi makalenin tamamen atladığı ayrıntıdır. Apache’nin istek işleme davranışı, hangi MPM‘nin etkin olduğuna göre belirlenir ve yanlış seçim yük altında ciddi performans düşüşüne neden olabilir.

prefork MPM

Her istek ayrı, tek iş parçacıklı bir alt süreç tarafından işlenir. İstekler arasında iş parçacığı paylaşılmaz; bu da onu iş parçacığı güvenli olmayan kütüphaneler için — en kritik olarak eski mod_php (libphp) modülü için — tek güvenli MPM yapar.

• Avantaj: Süreç izolasyonu, bir çalışandaki çökmenin diğerlerini etkilemediği anlamına gelir.
• Dezavantaj: Ölçekte yüksek bellek tüketimi. Her boşta süreç hâlâ RAM kaplar.
• Ne zaman kullanılır: PHP-FPM’ye geçirilmemiş mod_php kullanan eski PHP uygulamaları.

worker MPM

Hibrit bir model: her biri birden fazla iş parçacığı oluşturan birden fazla alt süreç. Tek bir iş parçacığı bir bağlantıyı işler.

• Avantaj: Eşdeğer eşzamanlılıkta prefork‘den önemli ölçüde daha düşük bellek ayak izi.
• Dezavantaj: Sürece yüklenen tüm modüller iş parçacığı güvenli olmalıdır.

event MPM

Apache 2.4’ten bu yana modern varsayılan. Keep-alive bağlantı yönetimini özel bir dinleyici iş parçacığına devrederek worker‘yi genişletir; böylece çalışan iş parçacıkları boşta kalıcı bağlantıları beklemek yerine etkin istekleri işleyebilir.

• Avantaj: Apache’nin MPM’leri arasında en iyi eşzamanlılık-kaynak oranı. Binlerce eşzamanlı keep-alive bağlantısını verimli şekilde işler.
• Dezavantaj: PHP’nin mod_php değil, PHP-FPM (FastCGI) aracılığıyla sunulmasını gerektirir.
• Ne zaman kullanılır: Herhangi bir modern PHP yığını, Python WSGI veya ters proxy yapılandırması.

Çalışan bir sunucuda etkin MPM’yi kontrol etmek için:

apache2ctl -V | grep -i mpm

Debian/Ubuntu’da event MPM’ye geçmek için:

sudo a2dismod php8.2
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.2-fpm
sudo systemctl restart apache2

Apache’nin Web Sitesi Geliştirmeye Katkısı

Statik ve Dinamik İçerik Sunma

Apache’nin en temel rolü içerik dağıtımıdır. Statik varlıklar için — HTML, CSS, JavaScript paketleri, görseller, yazı tipleri — Apache dosyayı diskten okur ve doğrudan istemciye aktarır. Dinamik içerik için yürütmeyi bir arka uç çalışma zamanına devreder ve yanıtı proxy’ler.

Statik içerik yolu:

Browser → TCP connection → Apache → filesystem read → HTTP response

Dinamik içerik yolu (PHP-FPM örneği):

Browser → TCP connection → Apache → FastCGI socket → PHP-FPM worker → HTTP response

Bu ayrım önbellek stratejisi açısından önemlidir. Statik dosyalar, Apache’nin yapılandırmasında ayarlanan Expires ve Cache-Control başlıkları kullanılarak kenarda (CDN, tarayıcı önbelleği) agresif biçimde önbelleğe alınabilir. Dinamik yanıtlar, uygulama düzeyinde önbellek geçersiz kılma mantığı gerektirir.

mod_ssl ile SSL/TLS Sonlandırma

Apache, OpenSSL’i saran mod_ssl aracılığıyla HTTPS’yi yerel olarak işler. Minimal bir TLS sanal ana bilgisayar yapılandırması şöyle görünür:

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example

    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/example.com/privkey.pem

    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    SSLHonorCipherOrder     off
    SSLSessionTickets       off

    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

Sıklıkla gözden kaçırılan kritik güçlendirme noktaları:

• Açıkça TLS 1.0 ve 1.1’i devre dışı bırakın — her ikisi de RFC 8996 tarafından kullanımdan kaldırılmıştır ve PCI-DSS uyumluluk taramalarında başarısız olacaktır.
• TLS 1.2’den farklı şekilde şifre müzakeresini yöneten TLS 1.3 kullanırken SSLHonorCipherOrder off ayarlayın.
• Protokol düşürme saldırılarını önlemek için mod_headers aracılığıyla HSTS başlıkları ekleyin.

Alanınız için düzgün verilmiş bir sertifikaya ihtiyaç duyuyorsanız, SSL Sertifikaları bağımsız bir hizmet olarak sunulmakta ve doğrudan Apache’nin mod_ssl yapılandırmasıyla entegre olmaktadır.

mod_rewrite ile URL Yeniden Yazma ve Yönlendirmeler

mod_rewrite, Apache’nin en güçlü — ve en sık yanlış yapılandırılan — modüllerinden biridir. Apache bunları bir dosyaya veya proxy arka ucuna eşleştirmeden önce gelen istek URI’lerini yeniden yazmak için kural tabanlı bir motor kullanır.

HSTS ön yüklemeli üretim kalitesinde HTTP’den HTTPS’ye yönlendirme:

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

Bir PHP uygulaması için temiz URL yeniden yazma (örneğin, tüm istekleri index.php üzerinden yönlendirme):

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ /index.php [QSA,L]

Yaygın tuzak: Yeniden yazma kurallarını .htaccess dosyalarına yerleştirmek, Apache’nin istek yolundaki her dizinde .htaccess olup olmadığını kontrol etmesi gerektiğinden her istekte dosya sistemi arama yükü oluşturur. Performansın önemli olduğu üretim sunucularında, kuralları ana yapılandırmadaki <VirtualHost> bloğuna taşıyın ve .htaccess işlemini tamamen devre dışı bırakmak için AllowOverride None ayarlayın.

Çok Siteli Barındırma için Sanal Ana Bilgisayarlar

Apache’nin sanal ana bilgisayar sistemi, tek bir sunucu örneğinin rastgele sayıda farklı web sitesine hizmet vermesine olanak tanır. Bu, paylaşımlı barındırmayı mimari olarak mümkün kılan mekanizmadır.

Ad tabanlı sanal barındırma (standart yaklaşım — bir IP’de birden fazla alan adı):

<VirtualHost *:80>
    ServerName site1.com
    ServerAlias www.site1.com
    DocumentRoot /var/www/site1
    ErrorLog ${APACHE_LOG_DIR}/site1_error.log
    CustomLog ${APACHE_LOG_DIR}/site1_access.log combined
</VirtualHost>

<VirtualHost *:80>
    ServerName site2.com
    ServerAlias www.site2.com
    DocumentRoot /var/www/site2
    ErrorLog ${APACHE_LOG_DIR}/site2_error.log
    CustomLog ${APACHE_LOG_DIR}/site2_access.log combined
</VirtualHost>

Apache, HTTP isteğindeki Host: başlığını ServerName ve ServerAlias yönergeleriyle eşleştirerek doğru sanal ana bilgisayarı seçer. Eşleşme bulunamazsa Apache, ilk tanımlanan sanal ana bilgisayara geri döner — varsayılan sanal ana bilgisayarınız açıkça güçlendirilmemişse istenmeyen içeriği açığa çıkarabilecek bir davranış.

IP tabanlı sanal barındırma, TLS SNI’nin mevcut olmadığı ortamlarda (modern dağıtımlarda nadir) veya kiracılar arasında katı ağ düzeyinde izolasyonun gerekli olduğu durumlarda hâlâ kullanılmaktadır.

Tek bir sunucudan birden fazla müşteri sitesi veya proje çalıştırıyorsanız, VPS Barındırma ortamı size Apache’nin sanal ana bilgisayar yapılandırması, MPM seçimi ve modül yükleme üzerinde tam kontrol sağlar — paylaşımlı altyapıda kısıtlanan veya kullanılamayan özellikler.

Günlük Kaydı, İzleme ve Adli Analiz

Apache iki birincil günlük akışı oluşturur:

Erişim günlüğü — tamamlanan her isteği kaydeder:

192.168.1.10 - frank [10/Oct/2024:13:55:36 -0700] "GET /index.html HTTP/1.1" 200 2326

Alanlar varsayılan olarak Birleşik Günlük Formatını izler: istemci IP, kimlik, kimlik doğrulama kullanıcısı, zaman damgası, istek satırı, durum kodu, yanıt boyutu, referrer, kullanıcı aracısı.

Hata günlüğü — sunucu düzeyindeki hataları, modül uyarılarını ve başlangıç tanılamalarını kaydeder. Apache 500 hatası döndürdüğünde veya başlamayı reddettiğinde bakılacak ilk yer burasıdır.

Hata ayıklama sırasında her iki günlüğü aynı anda takip etmek için:

tail -f /var/log/apache2/access.log /var/log/apache2/error.log

Üretim ortamları için, yerel günlük rotasyonuna güvenmek yerine günlükleri merkezi bir toplama sistemine (ELK yığını, Loki, Graylog) yönlendirmeyi düşünün. Apache, kanallı günlük kaydını yerel olarak destekler:

CustomLog "|/usr/bin/logger -t apache -p local6.info" combined

Ters Proxy ve Yük Dengeleme

Orijinal makalenin tamamen atladığı bir özellik: Apache, istekleri arka uç uygulama sunucularına ileten bir ters proxy olarak hareket edebilir. Bu, Node.js, Python (Gunicorn/uWSGI) veya Java (Tomcat) uygulamalarını Apache’nin arkasında çalıştırmak için standart mimaridir.

Gerekli modülleri etkinleştirin:

sudo a2enmod proxy proxy_http proxy_balancer lbmethod_byrequests

3000 numaralı bağlantı noktasındaki bir Node.js uygulamasına temel ters proxy:

<VirtualHost *:443>
    ServerName app.example.com

    ProxyPreserveHost On
    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

Birden fazla arka uç örneği arasında yük dengeleme:

<Proxy balancer://appcluster>
    BalancerMember http://127.0.0.1:3001 loadfactor=1
    BalancerMember http://127.0.0.1:3002 loadfactor=1
    ProxySet lbmethod=byrequests
</Proxy>

ProxyPass        / balancer://appcluster/
ProxyPassReverse / balancer://appcluster/

Bu tür bir mimariyi ölçekte gerektiren iş yükleri için — özellikle GPU hızlandırmalı çıkarım arka uçlarına sahip uygulamalar — GPU Barındırma, Apache’nin proxy modülü aracılığıyla ön uç olarak kullanabileceği temel hesaplama altyapısını sağlar.

Apache ile Nginx: Doğrudan Teknik Karşılaştırma

Hiçbir sunucu evrensel olarak üstün değildir. Doğru seçim, iş yükü profilinize, uygulamanızın yapılandırma gereksinimlerine ve ekibinizin operasyonel aşinalığına bağlıdır. Birçok üretim ortamı her ikisini de çalıştırır — TLS sonlandırma ve statik varlıkları işleyen ön uç ters proxy olarak Nginx, dinamik uygulama içeriğini genel olmayan bir bağlantı noktasında sunan Apache ile birlikte.

Temel Apache Modülleri Referansı

Güvenlik Güçlendirme: Çoğu Kılavuzun Atladığı Konular

Varsayılan bir Apache kurulumu, saldırganlara yardımcı olan bilgileri açığa çıkarır. Herhangi bir üretim dağıtımından önce bu güçlendirme adımlarını uygulayın.

/etc/apache2/conf-available/security.conf‘de sürüm ifşasını bastırın:

ServerTokens Prod
ServerSignature Off

Dizin listelemeyi genel olarak devre dışı bırakın:

<Directory /var/www/>
    Options -Indexes
</Directory>

HTTP yöntemlerini yalnızca uygulamanızın kullandıklarıyla sınırlayın:

<LimitExcept GET POST HEAD>
    deny from all
</LimitExcept>

mod_headers kullanarak güvenlik başlıkları ayarlayın:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=()"

.htaccess dosyasının kendisini belge olarak sunulmaktan koruyun:

<FilesMatch "^.ht">
    Require all denied
</FilesMatch>

Bu yapılandırmaları kısıtlama olmaksızın uygulamak için tam kök erişimine ihtiyaç duyduğunuz ortamlarda, Dedicated Sunucular, paylaşımlı veya yönetilen ortamların sunamayacağı izolasyon ve kontrolü sağlar.

Apache Ne Zaman Kullanılır: Karar Matrisi

Pratik Temel Çıkarım Kontrol Listesi

Apache’yi üretimde dağıtmadan önce aşağıdakilerin her birini doğrulayın:

• MPM seçimi: PHP-FPM kullanıyorsanız event MPM’nin etkin olduğunu onaylayın; prefork‘yi yalnızca eski mod_php kurulumları için kullanın.
• TLS yapılandırması: TLS 1.0/1.1’i devre dışı bırakın; güçlü şifre paketleriyle minimum TLS 1.2’yi zorunlu kılın; HSTS başlıkları ekleyin.
• AllowOverride kapsamı: AllowOverride None‘yi genel olarak ayarlayın ve yalnızca gerçekten dizin başına yapılandırma gerektiren dizinler için etkinleştirin.
• Bilgi ifşası: Herhangi bir genel maruziyetten önce ServerTokens Prod ve ServerSignature Off ayarlayın.
• Dizin listeleme: Tüm belge köklerinde Options -Indexes‘nin ayarlandığını onaylayın.
• Günlük yönlendirme: Erişim ve hata günlüklerinin yazıldığından ve döndürüldüğünden emin olun; çok sunuculu kurulumlar için merkezi toplama düşünün.
• Modül denetimi: apache2ctl -M çalıştırın ve uygulamanızın kullanmadığı yüklü modülleri devre dışı bırakın — her yüklü modül saldırı yüzeyini ve bellek ayak izini artırır.
• Güvenlik başlıkları: Dağıtımdan sonra securityheaders.com kullanarak X-Frame-Options, X-Content-Type-Options ve CSP başlıklarını doğrulayın.
• Sanal ana bilgisayar varsayılanı: Tanınmayan Host: başlıklarına sahip istekleri işlemek için 444 veya statik bir sayfa döndüren açık bir varsayılan sanal ana bilgisayar tanımlayın.

Yeni bir proje başlatıyorsanız ve önceden yapılandırılmış bir Apache ortamı istiyorsanız, cPanel ile VPS, Apache, PHP ve SSL’nin bir GUI aracılığıyla yapılandırıldığı ve bakımının yapıldığı yönetilen bir yığın sunar — manuel yapılandırmanın operasyonel yükünü azaltır.

SSS

Apache ile web sunucusu arasındaki fark nedir?

Apache, web sunucusu yazılımının belirli bir uygulamasıdır. “Web sunucusu” genel kavramdır — HTTP isteklerini dinleyen ve yanıt döndüren herhangi bir yazılım. Apache HTTP Server, Nginx, Caddy ve LiteSpeed ile birlikte bu kavramın birkaç uygulamasından biridir.

Apache HTTP/2’yi destekliyor mu?

Evet. HTTP/2 desteği, Apache 2.4.17’den bu yana mevcut olan mod_http2 tarafından sağlanmaktadır. Tüm büyük tarayıcılar HTTP/2’yi yalnızca TLS üzerinden uyguladığından pratikte TLS (HTTPS) gerektirir. SSL sanal ana bilgisayar bloğunuzun içinde Protocols h2 http/1.1 ile etkinleştirin.

Apache neden Nginx’ten daha fazla bellek kullanır?

prefork MPM altında Apache, her biri Apache ikili dosyasının ve yüklü modüllerin tam bellek ayak izini taşıyan bağlantı başına ayrı bir süreç oluşturur. Nginx, tek bir çalışan sürecin binlerce bağlantıyı eşzamanlı olarak işlediği asenkron bir olay döngüsü kullanır. Apache’yi PHP-FPM ile event MPM’ye geçirmek bu farkı önemli ölçüde azaltır.

Apache ve Nginx aynı sunucuda çalışabilir mi?

Evet ve bu yaygın bir üretim modelidir. Nginx 80 ve 443 numaralı bağlantı noktalarını dinler, TLS sonlandırma ve statik varlık dağıtımını işler, ardından dinamik istekleri dahili bir bağlantı noktasında (genellikle 8080) çalışan Apache’ye proxy’ler. Bu, Nginx’in eşzamanlılık verimliliğini Apache’nin mod_rewrite esnekliği ve mod_security entegrasyonuyla birleştirir.

.htaccess Apache’nin çalışması için gerekli mi?

Hayır. .htaccess, isteğe bağlı bir dizin başına yapılandırma geçersiz kılma mekanizmasıdır. Ana sunucu yapılandırmasını değiştiremeyecek kullanıcıların bulunduğu paylaşımlı barındırma ortamları için kullanışlıdır, ancak ölçülebilir bir performans maliyeti taşır. Ana yapılandırma dosyasını kontrol ettiğiniz sunucularda, tüm yönergeleri <VirtualHost> bloklarında birleştirmek ve AllowOverride None ile .htaccess‘yi devre dışı bırakmak doğru yaklaşımdır.