Web Sunucusu Nedir ve Nasıl Çalışır?

Sesli Dinle — Makale

Web sunucusu yazılımı, web iletişimini sağlayan HTTP isteklerini kabul eder ve bunlara yanıt gönderir. İstenen kaynak hazır bir dosyaysa doğrudan sunabilir; içerik uygulama tarafından oluşturuluyorsa isteği ilgili çalışma ortamına iletip üretilen sonucu istemciye aktarabilir.

HTTPS, HTTP iletişimini TLS ile korur. HTTPS kullanıldığında istemci ile TLS bağlantısını sonlandıran bileşen arasında şifreli bir oturum kurulur. Bu bileşen doğrudan web sunucusu, CDN, yük dengeleyici veya reverse proxy (ters proxy) olabilir. Bu nedenle ziyaretçinin gördüğü sunucu ile uygulamayı çalıştıran sistem her kurulumda aynı değildir.

“Web sunucusu” adı, yazılımın yanında bu yazılımı çalıştıran makine veya bütün hizmet için de kullanılabilir; fiziksel cihazla yazılım aynı şey değildir. Apache HTTP Server ve Nginx, yaygın web sunucusu yazılımlarına örnektir. İkisi de statik içerik sunabilir, sanal host seçebilir, HTTPS bağlantısını karşılayabilir ve dinamik içerik üreten uygulamalarla çalışabilir. Ürün adı tek başına mimariyi, hızı veya güvenliği belirlemez; etkin modüller, yapılandırma ve iş yükü sonucu değiştirir.

HTTP İstekleri ve Yanıtları Neler İçerir?

HTTP, istek ve yanıt mesajlarıyla çalışan durumsuz bir uygulama katmanı protokolüdür. İstek; yöntem, hedef adres, başlıklar ve varsa bir gövde içerir. Bir yanıt yalnız görünen sayfadan oluşmaz. Durum kodu işlemin sonucunu, başlıklar ise içerik türü, önbellek davranışı, boyut, yönlendirme ve güvenlik gibi özellikleri bildirir. Aynı bağlantıda birden fazla istek taşınabilse de sunucu iki isteğin aynı kullanıcıya ait olduğunu yalnız bağlantıya bakarak varsaymamalıdır.

Bir HTTP İsteği Sunucuda Nasıl İşlenir?

Yeni bir bağlantıda tipik işlem sırası aşağıdaki gibidir. Önceden kurulmuş bağlantı yeniden kullanılıyorsa bağlantı kurma ve TLS el sıkışması her istek için tekrarlanmaz.

1. Ad çözülür ve bağlantı kurulur: İstemci, gerekli bilgi önbellekte yoksa DNS üzerinden hedefin IP adresini öğrenir. İstemci hedef porta TCP veya kullanılan HTTP sürümüne uygun başka bir taşıma üzerinden ulaşır.
2. TLS gerekiyorsa el sıkışması tamamlanır: HTTPS bağlantısında sertifika doğrulanır ve şifreli oturum kurulur. TLS öndeki bir bileşende sonlandırılıyorsa bu bileşen web sunucusuna ayrı bir bağlantı kurar veya mevcut arka uç bağlantısını yeniden kullanır.
3. İstek ayrıştırılır: Web sunucusu GET, HEAD veya POST gibi yöntemi, hedefi, başlıkları ve varsa gövdeyi okur. Kabul edilmeyen yöntem, aşırı büyük başlık veya bozuk mesaj uygun bir hata yanıtıyla reddedilebilir.
4. Sanal host ve kural seçilir: Dinlenen IP adresi ve portla birlikte alan adı bilgisi değerlendirilir. Yol; dosyaya, yönlendirmeye, erişim kuralına, dahili işleyiciye veya uygulama uç noktasına eşleştirilir.
5. Yanıt üretilir: Statik dosya okunabilir, uygulamaya istek aktarılabilir ya da 404 Bulunamadı gibi bir yanıt web sunucusunda hazırlanabilir. Uygulama da kendi istemci hatası (4xx) veya sunucu hatası (5xx) yanıtını üretebilir.
6. Yanıt gönderilir: Durum kodu, başlıklar ve gerekiyorsa gövde istemciye iletilir. Bağlantının yeniden kullanımı protokol sürümüne, hata durumuna ve yapılandırmaya bağlıdır.

200 Başarılı, 301 Kalıcı Yönlendirme, 404 Bulunamadı ve 500 İç Sunucu Hatası gibi kodlar yanıtın sınıfını ve anlamını bildirir. Ancak kod, hatayı hangi katmanın ürettiğini tek başına kanıtlamaz. Aynı 404 yanıtı web sunucusunun dosya eşlemesinden, uygulama yönlendiricisinden veya öndeki bir proxy kuralından gelebilir.

Alan Adı, IP Adresi, Port ve Sanal Host Seçimi

Aynı web sunucusu birden fazla IP adresinde ve portta dinleyebilir; tek bir IP adresi de birden fazla alan adına hizmet verebilir. Virtual host (sanal host), gelen isteğin hangi site yapılandırmasıyla işleneceğini belirleyen ayrımdır. HTTP/1.1 isteğindeki Host başlığı bu seçimde temel bilgilerden biridir. HTTP/2 ve HTTP/3 ise hedef alan adı ve gerektiğinde port bilgisini taşıyan :authority alanını kullanır; yapılandırma kullanılan protokole göre değerlendirilir.

HTTPS bağlantısında sertifika seçimi, şifreli HTTP isteği okunmadan önce yapılır. SNI (Server Name Indication), istemcinin TLS el sıkışması sırasında bağlanmak istediği alan adını bildirmesine olanak verir. Böylece aynı IP adresinde farklı sertifikalara sahip birden fazla HTTPS sitesi çalışabilir. SNI, HTTP isteğinin Host veya :authority bilgisinin yerine geçmez; TLS sertifikası ile HTTP sanal host seçimi ayrı aşamalardır.

Alan adı yanlış yapılandırmaya düşerse beklenmeyen site, varsayılan sertifika veya 421 Yanlış Yönlendirilmiş İstek gibi bir sonuç görülebilir. Testte doğrudan IP adresine gitmek, normal alan adı isteğiyle aynı sonucu vermeyebilir; alan adı, port, SNI ve HTTP hedef bilgisi birlikte değerlendirilmelidir.

Statik ve Dinamik İçerik Nasıl Ayrılır?

Statik içerik, sunucuda hazır bulunan ve istek geldiğinde çoğunlukla dosyadan okunan kaynaktır. HTML, CSS, JavaScript, yazı tipi, görsel ve indirilebilir belge dosyaları bu gruba girebilir. Web sunucusu dosya yolunu, erişim iznini, içerik türünü ve koşullu istek başlıklarını değerlendirerek yanıtı oluşturur.

Dinamik içerik, oturum, veritabanı sorgusu, form verisi veya iş kuralına göre uygulama tarafından üretilir. Web sunucusu isteği API uç noktasına, uygulama sunucusuna veya uygulama çalışma ortamına aktarabilir. Web sunucusuyla ayrı uygulama süreçleri arasında iletişim kuran FastCGI (Fast Common Gateway Interface), bu aktarım için kullanılabilen yöntemlerden biridir; tek yöntem değildir.

Web sunucusunun isteği uygulamaya iletmesi, uygulama kodunu mutlaka kendi sürecinde çalıştırdığı anlamına gelmez. Uygulama ayrı bir süreçte, konteynerde veya makinede olabilir. Zaman aşımı, istek gövdesi sınırı, yeniden deneme ve istemci bağlantısı kesildiğinde ne yapılacağı iki katman arasında açıkça yapılandırılmalıdır.

Apache HTTP Server Nasıl Çalışır?

Apache, işlevlerini modüllerle genişleten bir web sunucusudur. Ağ portlarını dinleme, bağlantıları kabul etme ve istekleri işleyecek alt süreçleri yönetme modeli, MPM (Multi-Processing Module) tarafından belirlenir. Bir Apache örneğinde aynı anda yalnız bir MPM etkin olur.

event ve worker MPM'leri iş parçacıklı modeller kullanırken prefork iş parçacığı kullanmayan ayrı süreç modelidir. Seçim; işletim sistemi, modül uyumluluğu, bellek sınırı ve trafik biçimiyle birlikte değerlendirilir. MaxRequestWorkers gibi sınırlar kapasiteyi etkiler; çok yüksek değer kaynak tükenmesine, çok düşük değer ise isteklerin kuyrukta beklemesine yol açabilir.

Bir istek Apache içinde hedef kaynağı tanımlayan URI’nin (Uniform Resource Identifier) uygun dosya veya işleyiciyle eşleştirilmesi, erişim denetimi ve yanıt üretimi aşamalarından geçebilir. Statik dosya doğrudan sunulabilir; belirli yollar bir uygulama işleyicisine veya başka bir sunucuya aktarılabilir.

Nginx Nasıl Çalışır?

Nginx, ana sürecin yapılandırmayı okuyup istekleri işleyen worker süreçlerini yönettiği olay tabanlı bir mimari kullanır. İsteklerin gerçek işlenmesini worker süreçleri yürütür. Nginx; statik dosya sunucusu, HTTPS uç noktası, FastCGI istemcisi, ters proxy veya yük dengeleme katmanı olarak yapılandırılabilir.

Yapılandırma yeniden yüklendiğinde yeni ayarlar doğrulanır; başarılıysa yeni worker süreçleri başlatılır ve eski worker süreçleri mevcut isteklerini tamamladıktan sonra kapanabilir. Bu davranış kesintisiz geçişe yardımcı olur, ancak yanlış uygulama hedefi, yanlış zaman aşımı veya yetersiz kaynak sınırı yine sorun oluşturabilir.

Apache ile Nginx arasında evrensel olarak doğru tek seçim yoktur. Mevcut uygulama yığını, gerekli modüller, barındırma paneli, ekip deneyimi, gözlem araçları ve bakım süreci birlikte değerlendirilmelidir. Laboratuvar ölçümü, gerçek yapılandırma ve iş yükü bilinmeden üretim sonucu olarak kabul edilmemelidir.

Web Sunucusu, Ters Proxy ve Uygulama Sunucusu Farkları

Bu roller aynı üründe birleşebilir. Apache ve Nginx hem web sunucusu hem ters proxy olabilir. Bazı uygulama çatıları kendi HTTP sunucusunu içerir. Sunucusuz veya statik barındırma hizmetlerinde web sunucusu yönetimi platform tarafından gizlenebilir; ziyaretçiye yine HTTP yanıtı veren bir altyapı vardır.

Runtime, kodun çalıştığı ortamdır. PHP çalışma ortamı, Java sanal makinesi veya Node.js süreci buna örnektir. Fiziksel makine, sanal makine, konteyner, barındırma hizmeti, web sunucusu ve uygulama çalışma ortamı ayrı katmanlardır; günlük dilde hepsine “sunucu” denmesi sorun giderirken karışıklık yaratabilir.

HTTP/1.1, HTTP/2 ve HTTP/3 Web Sunucusunu Nasıl Etkiler?

HTTP sürümleri aynı temel istek ve yanıt anlamlarını taşır, fakat mesajların bağlantı üzerinde çerçevelenmesi ve eşzamanlı iletimi farklıdır. HTTP/1.1 kalıcı TCP bağlantılarını destekler. HTTP/2, farklı istek ve yanıt çiftlerini taşıyan stream’leri tek TCP bağlantısında eşzamanlı iletebilir. HTTP/3 ise UDP üzerinde çalışan QUIC taşımasını kullanır.

Ziyaretçi HTTP/3 kullanırken kaynak sunucuya giden bağlantının HTTP/1.1 veya HTTP/2 olması mümkündür; CDN ya da ters proxy iki tarafta farklı protokoller sonlandırabilir. Bu nedenle tarayıcıdaki protokol bilgisi, uygulama sunucusuna kadar aynı protokolün kullanıldığını kanıtlamaz.

Birden fazla HTTP ayrıştırıcısı aynı isteği işliyorsa mesaj sınırlarını tutarlı yorumlamaları gerekir. Özellikle HTTP/1.1'de çelişkili Content-Length ve Transfer-Encoding alanlarını farklı yorumlayan katmanlar request smuggling’e (istek kaçakçılığına) yol açabilir. Güncel bileşen kullanmak, belirsiz istekleri reddetmek ve ön uç ile arka uç protokol davranışını birlikte sınamak gerekir.

Web Sunucusu Yanıtı ve Günlükleri Nasıl Kontrol Edilir?

Bir sitenin tarayıcıda açılması tüm ayrıntıların doğru olduğunu göstermez. Tarayıcının geliştirici araçlarındaki Network (Ağ) bölümünde durum kodunu, yönlendirme isteklerini, Content-Type (içerik türü), Cache-Control (önbellek denetimi) ve güvenlik başlıklarını inceleyin. Yönlendirme zincirini izlemek için gezinme sırasında ağ kaydını koruma seçeneğini açın.

Server başlığı bir ürün adı gösterebilir, ancak gizlenebilir veya öndeki proxy tarafından değiştirilebilir; tek başına gerçek yazılımı kanıtlamaz. Benzer biçimde yanıt süresi de yalnız web sunucusunu ölçmez; DNS, bağlantı, TLS, proxy, uygulama ve veritabanı sürelerinin toplamını içerebilir.

• Erişim günlüğünde zaman, yöntem, hedef, durum kodu, gönderilen bayt ve işlem süresi gibi alanları kaydedin.
• Hata günlüğünü uygulama günlüğüyle aynı zaman aralığında karşılaştırın.
• Ters proxy arkasında istemci IP adresini yalnız güvenilir bağlantılardan gelen ve proxy'nin belgelediği başlık işleme kuralına göre belirlenen değerden alın; adres listesinin ilk öğesine koşulsuz güvenmeyin.
• 404 ve 5xx artışını yol, sanal host, uygulama ve arka uç durumuna göre ayırın.
• Yapılandırma değişikliğinden önce sözdizimi denetimi yapın; yeniden yükleme sonrası aktif ayarı ve gerçek ziyaretçi yanıtını doğrulayın.

Web Sunucusunda Güncelleme ve Erişim Yetkileri

İnternete açık web sunucusu düzenli bakım gerektirir. Yazılım ve modüller güncel tutulmalı, gereksiz özellikler kapatılmalı, süreçler en az ayrıcalıkla çalışmalı, dosya erişimleri sınırlandırılmalı ve yapılandırma değişiklikleri kayıt altına alınmalıdır. İstek yöntemi, gövde ve başlık boyutu, bağlantı ve uygulama zaman aşımı için iş yüküne uygun sınırlar belirlenmelidir.

Yedekleme, erişim ve hata günlüklerinin merkezi saklanması, sağlık denetimi, kapasite alarmı ve belgelenmiş geri dönüş adımı işletimin parçasıdır.

HTTPS Uygulama Açıklarını Giderir mi?

HTTPS aktarım sırasında gizlilik ve bütünlük sağlar; uygulama açığını, hatalı yetkilendirmeyi, zayıf parola politikasını veya yanlış dosya iznini gidermez. TLS öndeki proxy'de sonlandırılıyorsa proxy ile web sunucusu arasındaki bağlantının güveni de ayrıca planlanmalıdır. Kaynak sunucuyu herkese açık bırakmak, öndeki güvenlik katmanının atlanmasına yol açabilir.