Web sunucusu
Web sunucusu, HTTP (Hypertext Transfer Protocol) veya uzantısı olan HTTPS (HTTP Secure) üzerinden gelen istemcilerin (web tarayıcıları veya arama robotları) taleplerini kabul eden bir bilgisayar yazılımı ve altyapı donanımını ifade eder. Web sunucularının temel işlevi, istemcilerden gelen istekleri istenen web sayfalarının veya diğer kaynakların içeriğini sunmak veya hata mesajlarıyla yanıt vermektir.
Web sunucusundan gönderilen kaynak, var olan bir dosya (statik içerik) olabilir, ya da isteğin gönderildiği an sunucu yazılımıyla iletişime geçen başka bir program tarafından oluşturulabilir (dinamik içerik). Statik içerik tekrarlayan istekler için daha hızlı servis edilebilir ve önbelleğe alması daha kolaydır. Dinamik içerik daha geniş bir yelpazede servis sunulabilmesini sağlar.[1]
Çalışma prensibi
değiştirBir web sunucusu çalıştırmak için gereken donanım, gelen isteklerin hacmine göre değişiklik gösterebilir. Donanım aralığının alt ucunda, bir yönlendiricinin yapılandırma arayüzü olarak küçük bir web sunucusu çalıştırması gibi gömülü sistemler bulunur. Yoğun trafikli bir internet sitesi ise istekleri yüksek hızlı bilgisayarlardan oluşan raflarda çalışan yüzlerce sunucuyla işleyebilir.
İletişim Süreci
değiştirBu iletişim süreci, istemcinin belirli bir URL (Uniform Resource Locator) ile kaynak talep etmesiyle başlar. Bu istek, sunucuya HTTP protokolü kullanılarak iletilir. Web sunucusu, talep edilen içeriği bulur ve bunu istemciye geri gönderir. Bu süreçte yanıt, istemcinin talebine göre değişiklik gösterebilir. Örneğin, istenen kaynak başarıyla bulunduğunda "200 OK" durumu ile yanıt verilirken kaynak bulunamazsa 404, yetkisiz erişim durumunda 403, fiziksel sunucu kaynaklı bir hata durumda 503 vb. hata kodları ile geri dönüş yapılır.[2][3]
REST ve SOAP, HTTP'yi bilgisayarlar arası genel iletişim için bir temel olarak kullanan teknolojilerdir. Ayrıca, WebDAV gibi eklentilere sağlanan destekler, web sunucularının işlevselliğini insan tarafından okunabilir sayfalar sunmanın daha ilerisine taşıyarak gelişmesini sağlamıştır. Bu gelişmeler, web sunucularını sadece içerik sunan sistemler olmaktan çıkarıp, karmaşık veri alışverişlerini yönetebilen, API erişimi sağlayabilen ve modern web uygulamaları için çeşitli fonksiyonları destekleyen çok yönlü platformlar haline getirmiştir.
WWW projesi (1989–1991)
değiştirMart 1989 tarihinde, Sir Tim Berners-Lee, CERN bilim insanları arasındaki bilgi alışverişini kolaylaştırmak amacıyla bir hiper metin sistemi kullanarak yeni bir proje önerdi. "HyperText (HTTP) ve CERN" başlıklı bu öneri, görüş almak üzere sunuldu. Ekim 1990'da öneri yeniden düzenlenip (Robert Cailliau eş-yazar olarak yer aldı) ve onaylandı.[4][5][6]
1990 sonları ile 1991 başları arasında, proje Berners-Lee ve geliştiricilerinin birkaç yazılım kütüphanesinin yanı sıra, ilk olarak NeXT iş istasyonlarına kurulu NeXTSTEP işletim sistemi üzerinde çalışan üç program yazmaları ve test etmeleriyle sonuçlandı:[6][7][8]
- WorldWideWeb (WWW) adında grafiksel bir web tarayıcısı;
- Modlu web tarayıcısı;
- CERN httpd olarak bir web sunucusu.
Bu ilk tarayıcılar, basit bir HTML formunda yazılmış web sayfalarını, HTTP 0.9 olarak adlandırılan yeni bir temel iletişim protokolünü kullanarak web sunucularından alıyordu.
Ağustos 1991’de Tim Berners-Lee, WWW teknolojisinin doğuşunu duyurdu ve bilim insanlarını bu teknolojiyi benimsemeye ve geliştirmeye teşvik etti.[9] Kısa bir süre sonra, bu programlar ve kaynak kodları, ilgilenenlerin kullanımına sunuldu. Her ne kadar kaynak kodu resmi olarak lisanslanmamış veya kamuya mal edilmemiş olsa da, CERN, kullanıcıların ve geliştiricilerin bu kodlar üzerinde deney yapmasına ve onları daha da geliştirmesine gayri resmi olarak izin verdi. Berners-Lee, bu programların benimsenmesini, kullanılmasını ve diğer işletim sistemlerine uyarlanmasını teşvik etmeye başladı.[6]
Gelişim Süreci (1991–1995)
değiştirAralık 1991'de, Avrupa dışındaki ilk web sunucusu ABD'deki SLAC laboratuvarında kuruldu.[8] Bu, web tarayıcıları ve web sunucuları arasında kıtalar arası iletişimin başlaması açısından önemli bir olaydı.1991–1993 yılları arasında, CERN web sunucusu programı www grubu tarafından aktif olarak geliştirilmeye devam etti. Aynı zamanda, kaynak kodunun ve HTTP protokolünün kamuya açık spesifikasyonlarının bulunması sayesinde, başka birçok web sunucusu uygulaması geliştirilmeye başlandı.
Nisan 1993’te CERN, Web yazılımının üç bileşeninin (temel satır istemci, web sunucusu ve ortak kod kitaplığı) kaynak kodlarıyla birlikte kamuya mal edildiğini belirten resmi bir bildiri yayınladı.[10] Bu açıklama, web sunucusu geliştiricilerini, bu kaynak koda dayalı türev işler geliştirme konusunda olası yasal sorunlardan muaf tuttu.
1994 yılının başında, yeni web sunucuları arasında öne çıkanlardan biri, çeşitli Unix tabanlı işletim sistemlerinde çalışabilen ve POST HTTP yöntemini ve CGI’yi dış programlarla iletişim kurmak için uygulayarak dinamik içerik sunabilen NCSA httpd idi. Bu özellikler, HTML FORM alanlarını yönetebilen ve web sunucusuna veri gönderebilen NCSA'nın Mosaic tarayıcısının multimedya özellikleri ile birlikte, web teknolojisinin yayıncılık ve bilişim uygulamaları için potansiyelini ortaya koydu.
1994'ün ikinci yarısında, NCSA httpd'nin gelişimi durma noktasına geldi. Bu durum, NCSA httpd kaynak kodunun kamuya açık olmasından yararlanan bir grup yazılım geliştiricinin, web yöneticilerinin ve diğer profesyonellerin yamalar yazıp bir araya getirmesine yol açtı. 1995’in başında bu yamalar NCSA kaynak kodunun son sürümüne uygulandı ve çeşitli testlerden sonra Apache HTTP sunucu projesi başlatıldı.
1994 yılının sonunda, Netscape tarafından geliştirilen ve özel özelliklere sahip ilk ticari web sunucusu olan Netsite piyasaya sürüldü. Bu ürün, Netscape'in ardından Sun Microsystems ve en sonunda Oracle Corporation tarafından geliştirilen benzer ürünlerin ilk örneğiydi.
1995’in ortasında, Microsoft tarafından Windows NT işletim sistemi için geliştirilen IIS’in ilk sürümü yayınlandı. Bu, web teknolojileri alanına hem istemci hem de sunucu tarafında önemli bir rol oynayan büyük bir ticari geliştirici ve satıcının girmesini simgeliyordu.
1995'in ikinci yarısında CERN ve NCSA web sunucularının (küresel kullanım oranı olarak) düşüşe geçmesi, daha hızlı geliştirme döngüsüne, daha fazla özelliğe, daha çok hata düzeltmesine ve daha yüksek performansa sahip yeni web sunucularının yaygın olarak benimsenmesi nedeniyle gerçekleşti.
Büyüme Süreci (1996–2014)
değiştir1996 yılının sonunda, internet alan adı sahibi olmak veya web siteleri barındırmak isteyen herkesin erişimine açık olan elliden fazla farklı web sunucu yazılımı zaten mevcuttu.[11] Bu yazılımların birçoğu kısa ömürlüydü ve yerini başka web sunucularına bırakıyordu.
HTTP/1.0 (1996) ve HTTP/1.1 (1997, 1999) hakkında yayınlanan RFC'ler, çoğu web sunucusunu bu standartlara uymaya zorladı. TCP/IP sürekli bağlantı kullanımını (HTTP/1.1) gerektirdiğinden, web sunucularının hem izin verilen eşzamanlı bağlantı sayısını artırması hem de ölçeklenebilirlik seviyelerini geliştirmesi gerekiyordu.
1996 ile 1999 arasında Netscape Enterprise Server ve Microsoft IIS, önde gelen ticari seçenekler arasında ortaya çıkarken, serbest ve açık kaynak programlar arasında Apache HTTP Server, güvenilirliği ve sunduğu birçok özellik nedeniyle tercih edilen sunucu olarak liderliğini sürdürdü.
Bu yıllarda, pazarda mevcut olan en hızlı ve ölçeklenebilir web sunucularından biri olarak bilinen ve düşük kullanım yüzdesine sahip olan başka bir ticari ve yenilikçi web sunucusu olan Zeus'da dikkat çekiyordu.
Apache, 1996 ortalarından 2015 sonuna kadar en çok kullanılan web sunucusu olmuştur; 2015'ten sonra birkaç yıl süren bir düşüşün ardından, öncelikle IIS tarafından daha sonra da Nginx tarafından geride bırakıldı. Daha sonra IIS, Apache'nin çok daha düşük kullanım yüzdelerine düştü.
2005-2006 yıllarında Apache, yeni performans özellikleri (Event MPM ve yeni içerik önbelleği) tanıtarak hızını ve ölçeklenebilirlik seviyesini geliştirmeye başladı.[12][13] Bu yeni performans iyileştirmeleri başlangıçta deneysel olarak işaretlendiği için kullanıcıları tarafından uzun süre etkinleştirilmedi ve bu nedenle Apache, ticari sunucuların ve özellikle gelişimlerinin başlangıcında çok daha yüksek performanslar sunan diğer açık kaynak sunucuların rekabetine daha fazla maruz kaldı.
2000'li yıllardan sonra, yalnızca diğer ticari ve yüksek rekabetçi web sunucuları (örneğin, LiteSpeed) değil, aynı zamanda yüksek performans ve kalite sunan birçok açık kaynaklı web sunucusu da geliştirilmiştir.
Bunlar arasında;
- Hiawatha,
- Cherokee HTTP sunucusu,
- Lighttpd,
- Nginx
gibi web sunucuları ticari destek sağlasa da, mevcut olan diğer türev ve ilişkili ürünler de dikkate alınmalıdır.
2007-2008 civarında, en popüler web tarayıcıları önceki önerilen RFC-2616'daki her bir ana bilgisayar alanı için 2 sürekli bağlantı limitini 4, 6 veya 8'e çıkardılar. Bu değişiklik, birçok görüntü içeren ağır web sayfalarının geri alımını hızlandırmak ve dinamik nesneler için ayrılmış sürekli bağlantı eksikliği sorununu hafifletmek amacıyla yapıldı.
Bir yıl içinde, bu değişiklikler, ortalama olarak, web sunucularının yönetmesi gereken sürekli bağlantıların sayısını neredeyse üç kat artırdı. Bu trend, daha yavaş web sunucularının önünde ters proxy'lerin benimsenmesine güçlü bir teşvik sağladı ve çok sayıda eşzamanlı bağlantıyı yönetebilen yeni web sunucularının hızını ve yeteneklerini göstermesi için bir fırsat daha sundu.[14]
2015 ve sonraki yıllar
değiştir2015 yılında RFC'ler (Uzaktan Fonksiyon Çağrısı), yeni protokol sürümü olan [HTTP/2]'yi yayınladı. Yeni yöntemlerin uygulanması basit olmamasından dolayı, (kullanım oranı %1 .. %2’den düşük) olan daha az popüler web sunucularının geliştiricileri arasında bu yeni protokol sürümüne destek ekleyip eklememe konusunda bir ikilem ortaya çıktı.[15][16]
HTTP/2 desteği sağlamak çoğu zaman sistem yapılarında radikal değişiklikler gerektiriyordu. Bunun nedenleri arasında neredeyse her zaman şifreli bağlantılar gerektirmesi, aynı TCP portunda HTTP/1.x ve HTTP/2 bağlantılarını ayırt edebilme yeteneği, HTTP mesajlarının ikili sayı sistemi (binary) ve mesaj önceliği HTTP başlıklarının sıkıştırılması, TCP/IP alt bağlantıları olarak da bilinen akışların kullanımı ve bunlara bağlı akış kontrolü gibi unsurlar bulunuyordu. Bu sebeplerden ötürü, bazı web sunucularının geliştiricileri yeni HTTP/2 sürümünü desteklememeye karar verdiler.[15][16]
- HTTP/1.x protokolleri tarayıcılar tarafından çok uzun bir süre destekleneceğinden, gelecekte istemci ve sunucular arasında herhangi bir uyumsuzluk oluşmayacaktı;
- HTTP/2'yi uygulamak, 2015 yılına kadar var olmayan yepyeni bir hata sınıfının ortaya çıkmasına neden olabilecek ve bu yüzden yeni protokolün uygulanması için ciddi yatırımlar gerektiren karmaşık bir görev olarak görülüyordu;
- HTTP/2 desteği, ileride çabaların haklı bulunması durumunda her zaman eklenecekti.
En popüler web sunucularının geliştiricileri, yalnızca yeterli iş gücü ve zamana sahip oldukları için değil, aynı zamanda genellikle SPDY protokolünün daha önceki uygulamalarını bir başlangıç noktası olarak yeniden kullanabildikleri için yeni protokolün kullanılabilirliğini sunmak için acele ettiler. Ayrıca, en çok kullanılan web tarayıcıları da aynı nedenle HTTP/2’yi çok hızlı bir şekilde uyguladı. Bu geliştiricileri hızlı davranmaya iten bir diğer neden de, web trafiğinin giderek artması karşısında web yöneticilerinin baskı hissetmesi ve barındırdıkları sitelere erişimleri hızlandıracak, TCP/IP bağlantı sayısını önemli ölçüde azaltabilecek bir çözümü mümkün olan en kısa sürede kurup denemek istemeleriydi.[17]
2020-2021 yıllarında, HTTP/3 protokolüne dair ileri düzey taslakların yayınlanmasının ardından, HTTP/2'nin uygulanmasına dair yaşanan dinamiklerin bir kısmı tekrarlandı.
Teknik genel bakış
değiştirAşağıdaki teknik genel bakış, bir web sunucusunda uygulanan bazı özellikler ve gerçekleştirilen görevler hakkında sınırlı örnekler sunmayı amaçlamaktadır. Bir web sunucu programı, HTTP protokolünün bir veya daha fazla sürümünü uygulayarak istemci-sunucu modelinde sunucu rolünü üstlenir. Ayrıca, HTTPS protokolü ile birlikte, belirli kullanım senaryoları için faydalı görülen diğer özellikler ve uzantılar da içermektedir.
Bir web sunucu programının karmaşıklığı ve verimliliği:
- Uygulanan yaygın özellikler,
- Gerçekleştirilen yaygın görevler,
- Hedeflenen performans ve ölçeklenebilirlik seviyesi,
- İstenen performans ve ölçeklenebilirlik seviyesine ulaşmak için benimsenen yazılım modeli ve teknikleri,
- Hedef donanım ve kullanım
gibi faktörlere bağlı olarak önemli ölçüde değişiklik gösterebilir.
Yaygın Özellikler
değiştirWeb sunucu programları uygulanma şekilleri bakımından farklılık gösterse de, çoğu aşağıdaki yaygın özellikleri sunar.
Çoğu web sunucusunda genellikle bulunan temel özelliklerdir.
- Statik içerik sunma: HTTP protokolü aracılığıyla istemcilere statik içerik sunma.
- HTTP: HTTP istekleri ile uyumlu HTTP yanıtları gönderebilmek için bir veya daha fazla HTTP protokolü sürümünü desteklemek (HTTP/1.0, HTTP/1.1, HTTPS, HTTP/2, HTTP/3).
- Loglama: Web sunucularının, güvenlik ve istatistiksel amaçlar için istemci istekleri ve sunucu yanıtları hakkında bazı bilgileri günlük dosyalarına kaydetme yeteneği vardır.
Daha ileri düzeydeki ve popüler birkaç başka özellik şunlardır:
- Dinamik içerik sunma: HTTP protokolü aracılığıyla istemcilere dinamik içerik sunabilme.
- Sanal barındırma: Tek bir IP adresi kullanarak birçok web sitesini sunabilme.
- Yetkilendirme: Web sitesi yollarının belirli bölümlerine erişimi sağlama, yasaklama veya yetkilendirme yeteneği.
- İçerik önbelleği: Sunucu yanıtlarını hızlandırmak amacıyla statik ve/veya dinamik içeriği önbelleğe alabilme.
- Büyük dosya desteği: 32 bit işletim sistemlerinde 2 GB'tan büyük dosyaları sunabilme.
- Bant genişliği sınırlama: Ağı aşırı yüklememek ve daha fazla istemciye hizmet verebilmek için içerik yanıtlarının hızını sınırlama.
- Yeniden yazma motoru: Temiz URL adreslerin belirli bölümlerini gerçek adlarına eşleyebilme.
- Özel hata sayfaları: Özelleştirilmiş HTTP hata mesajlarını destekleme.
Yaygın Görevler
değiştirWeb sunucusu çalışırken birkaç genel görevi yerine getirir:
- İsteğe bağlı olarak yapılandırma dosyalarında veya başka yerlerde bulunan ayarları okur ve uygular.
- İsteğe bağlı olarak genel davranışını ayarlarına ve mevcut çalışma koşullarına göre uyarlamaya çalışır.
- İstemci bağlantılarını yönetir.
- İstemci isteklerini alır (HTTP):
- Her HTTP istek mesajını okur ve doğrular,
- URL işlemini gerçekleştirir,
- URL eşlemesi yapar,
- URL yol çevirisi yapar ve çeşitli güvenlik kontrolleri gerçekleştirir.
- İstenilen HTTP yöntemini uygular veya reddeder:
- İsteğe bağlı olarak URL yetkilendirmelerini yönetir,
- İsteğe bağlı olarak URL yönlendirmelerini yönetir,
- İsteğe bağlı olarak statik kaynaklar için istekleri yönetir:
- İsteğe bağlı olarak dizin indeks dosyalarını yönetir,
- İsteğe bağlı olarak düzenli dosyaları yönetir,
- İsteğe bağlı olarak dinamik kaynaklar için istekleri yönetir:
- İsteğe bağlı olarak dizin listelerini yönetir,
- İsteğe bağlı olarak program veya modül işleme, kontrol etme, başlatma ve gerekirse durdurma işlemlerini yönetir,
- İsteğe bağlı olarak dinamik içerik üretmek için kullanılan dış programlar / iç modüllerle iletişimleri yönetir.
- İstemci isteklerine uygun HTTP yanıtları göndererek yanıt verir.
- İsteğe bağlı olarak, istemci isteklerini ve/veya yanıtlarını dış bir kullanıcı günlük dosyasına veya sistem günlük dosyasına kayıt eder.
- İsteğe bağlı olarak, tespit edilen anormallikler veya diğer dikkate değer olaylarla ilgili süreç mesajlarını veya başka sistem olanakları kullanarak kaydeder.
- İsteğe bağlı olarak, yönetilen web trafiği ve/veya performansları hakkında istatistikler oluşturur.
İstek Mesajını Okuma
değiştirWeb sunucusu şunları yapabilir:
- HTTP istek mesajını okumak;
- Yorumlamak;
- Sözdizimini doğrulamak;
- Bilinen HTTP başlıklarını tanımlamak ve bunlardan değerlerini çıkarmak.
Bir HTTP istek mesajı çözümlenip doğrulandığında, değerleri o isteğin karşılanıp karşılanamayacağını belirlemek için kullanılabilir. Bu, güvenlik kontrolleri de dahil olmak üzere birçok başka adımı gerektirir.
URL
değiştirWeb sunucusu bazı tür URL isteklerini (HTTP) gerçekleştirir.
Bunun amacı:
- Kaynak yolunu her zaman web sitesinin kök dizininden temiz bir yol haline getirmek;
- Güvenlik risklerini azaltmak;
- Web kaynaklarını günlük analiz programlarının daha tanınabilir hale getirmek.
URL istekleri terimi, URL'yi tutarlı bir şekilde değiştirme ve standart hale getirme sürecini ifade eder.
En önemli isteklerden bazıları, "." ve ".." yol yöntemlerinin kaldırılması ve boş olmayan bir yol bileşenine sonlandırıcı eğik çizgiler eklenmesidir.
URL Eşleşmesi
değiştirURL eşlemesi, bir URL'nin analiz edilerek hangi kaynağı ifade ettiğini belirleme sürecidir. Kaynak istek yapan istemciye döndürülebilir. Bu süreç, bir web sunucusuna yapılan her istekte gerçekleştirilir; bazı istekler bir dosyayla karşılanırken, diğerleri bir CGI programının çalıştırılmasıyla elde edilen sonuçlarla veya başka bir süreçle (örneğin, yerleşik bir modül işleyicisi, bir PHP belgesi veya bir Java dosyası) karşılanır.[18]
Pratikte, basit statik içerik sunumunun ötesinde gelişmiş özellikler uygulayan web sunucusu, URL'nin nasıl işleneceğini belirlemek zorundadır.
Şu şekillerde olabilir:
- URL yönlendirmesi,
- Dosya içeriğinin statik isteği,
- Dinamik istek:
- Dizindeki dosyaların veya diğer alt dizinlerin dizin listesi,
- URL parçalarını iletmek amacıyla diğer dinamik istek türleri
Web sunucusu, URL yolunun parçalarının belirli bir URL işleyicisine nasıl eşleneceğini belirten bir veya daha fazla yapılandırma dosyası kullanabilir.[19]
Web sunucusu, yukarıda bahsedilen bir veya daha fazla gelişmiş özelliği uyguladığında, geçerli bir URL'nin yol parçası her zaman web sitesi dizin ağacında mevcut bir dosya sistemi yolu ile eşleşmeyebilir. Bunun nedeni, bu yol parçasının dinamik istekler için iç veya dış modül işleyicisinin sanal bir adını ifade edebilmesidir.
URL Yol Çevirisi
değiştirWeb sunucusu, fiziksel bir dosya sistemi yoluna atıfta bulunan bir URL yolunu hedef web sitesinin kök dizini altında bir mutlak yola çevirebilir.
Web sitesinin kök dizini, bir yapılandırma dosyası veya web sunucusunun iç kurallarından biri kullanılarak, HTTP istemci isteğindeki URL'nin ana bilgisayar kısmı olan web sitesinin adıyla belirtilebilir.
Dosya sistemine URL yol çevirisi, aşağıdaki türdeki web kaynakları için gerçekleştirilir:
- Yerel, çalıştırılabilir olmayan bir dosya;
- Yerel bir dizin;
- CGI veya SCGI ara yüzü kullanılarak yürütülen ve çıktısı web sunucusu tarafından okunup HTTP isteğinde bulunan istemciye yeniden gönderilen dinamik istekler.
Web sunucusu, istenen URL (HTTP istek mesajında) bulunan yolu alır ve bunu (Host) web sitesinin kök dizininin yoluna ekler. Apache sunucusunda, bu genellikle /home/www/website
şeklindedir (Unix sunucularda ise genellikle /var/www/website
olarak kullanılır).
Aşağıda, bu işlemin nasıl sonuçlanabileceğine dair örnekler verilmiştir.
Mevcut bir dosyanın belirtilen URL ile yapılan statik bir dosya isteği örneği:
http://www.example.com/path/file.html
İstemci kullanıcı aracı, www.example.com'a bağlanır ve ardından aşağıdaki HTTP/1.1 isteğini gönderir:
GET /path/file.html HTTP/1.1 Host: www.example.com Connection: keep-alive
Sonuç, yerel dosya sistemi kaynağıdır:
/home/www/www.example.com/path/file.html
Web sunucusu daha sonra dosyayı okur, eğer mevcutsa ve istemcinin web tarayıcısına bir yanıt gönderir. Yanıt; dosyanın içeriğini tanımlayacak ve dosyayı içerecek veya dosyanın mevcut olmadığını ya da erişiminin yasaklandığını belirten bir hata mesajı döndürecektir.
Dizin İsteği URL Yolu Çevirisi
değiştirAşağıdaki URL ile belirtilen mevcut bir dizine yapılan dinamik istek örneği:
http://www.example.com/directory1/directory2/
İstemci kullanıcı aracı, www.example.com'a bağlanır ve ardından aşağıdaki HTTP/1.1 isteğini gönderir:
GET /directory1/directory2 HTTP/1.1 Host: www.example.com Connection: keep-alive
Sonuç, yerel dizin yoludur:
/home/www/www.example.com/directory1/directory2/
Web sunucusu daha sonra dizinin varlığını doğrular ve mevcutsa erişilebiliyorsa, bir indeks dosyası bulmaya çalışır. Böylece isteği dizin listelemeleri için ayrılmış bir iç modül veya programa yönlendirir. Sonunda, veri çıktısını okur ve istemcinin web tarayıcısına bir yanıt gönderir. Yanıt, dizinin içeriğini tanımlayacak veya dizinin mevcut olmadığını ya da erişiminin yasaklandığını belirten bir hata mesajı döndürecektir.
Dinamik İstek URL Yolu Çevirisi
değiştirDinamik bir istek için, istemci tarafından belirtilen URL yolu, web sunucusunun dinamik içerik oluşturmak için kullandığı mevcut bir dosyayı ifade etmelidir.[20]
Çıktı üretmek için bir program dosyası kullanan dinamik bir isteğin örneği:
http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15
İstemci kullanıcı aracı, www.example.com'a bağlanır ve ardından aşağıdaki HTTP/1.1 isteğini gönderir:
GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1 Host: www.example.com Connection: keep-alive
The result is the local file path of the program (in this example, a PHP program):
/home/www/www.example.com/cgi-bin/forum.php
Sonuç, programın yerel dosya yoludur.
Web sunucusu, programın çalışması için gereken bilgileri sağlamak amacıyla path-info ve query string olan action=view&orderby=thread&date=2021-10-15
değerlerini geçirir. (Bu durumda, 15 Ekim 2021 tarihli forum girişlerini başlığa göre sıralanmış bir şekilde içeren bir HTML belgesi dönecektir.) Bunun yanı sıra, web sunucusu dışarıdan gelen verileri okur ve bu verileri istekte bulunan istemciye iletir.
İstek mesajını yönetme
değiştirBir istek okunduktan yorumlandıktan ve doğrulandıktan sonra yöntemi URL ve HTTP başlıklarının değerlerini içerebilecek parametrelerine bağlı olarak yönetilmelidir.
Web sunucusu isteği aşağıdaki yanıt yollarından biriyle işlemelidir:[19]
- İstek kabul edilemez bir durumdaysa, web sunucusu zaten bir hata yanıtı gönderir.
- İstek, web sunucusunun genel koduyla karşılanabilecek bir yöntem içeriyorsa, başarılı bir yanıt gönderilir.
- URL yetkilendirme gerektiriyorsa, yetkilendirme hatası mesajı gönderilir.
- URL bir yönlendirmeye karşılık geliyorsa, yönlendirme mesajı gönderilir.
- URL dinamik bir kaynağa karşılık geliyorsa, ilgili işlemci çağrılır ve istek parametreleri ona iletilir, böylece isteğe yanıt verebilir.
- URL, statik bir kaynağa karşılık geliyorsa, dahili statik işlemci dosyayı göndermek üzere çağrılır.
- İstek yöntemi bilinmiyorsa veya başka bir kabul edilemez durum oluşursa bir hata yanıtı gönderilir.
Statik içerik sunma
değiştirWeb sunucusu statik içerik sunabiliyor ve buna göre yapılandırılmışsa, geçerli bir URL yolu mevcut bir dosya ile eşleştiğinde ve dosyanın, web sunucusu programının iç kurallarına uygun niteliklere sahip olduğu durumlarda dosya içeriğini gönderebilir.[19]
Bu tür içerikler statik olarak adlandırılır. Çünkü istemcilere gönderilirken web sunucusu tarafından değiştirilmez ve yalnızca bir program tarafından dosya değiştirilene kadar aynı kalır.
Yalnızca statik içerik sunarken, web sunucusu programı genellikle sunulan web sitelerinin dosya içeriklerini değiştirmez ve bu nedenle yalnızca şu HTTP yöntemlerini desteklemesi yeterlidir.
OPTIONS
HEAD
GET
Statik dosya içeriği yanıtı bir dosya önbelleği ile hızlandırılabilir.
Dizin dosyaları
değiştirWeb sunucusu, yolu mevcut bir dizinle eşleşen bir URL içeren bir istemci isteği alırsa ve bu dizine erişilebiliyorsa ve dizin indeks dosyalarının sunulması etkinleştirilmişse, web sunucusu programı o dizinde bulunan bilinen statik indeks dosyası adlarından ilkini sunmayı dener. Eğer bir indeks dosyası bulunamazsa veya diğer koşullar sağlanmazsa, bir hata mesajı döndürülür.
En çok kullanılan statik indeks dosyası adları şunlardır: index.html
, index.htm
ve Default.htm
.
Düzenli dosyalar
değiştirWeb sunucusu yolu mevcut bir dosyanın dosya adıyla eşleşen bir URL içeren bir istemci isteği alırsa ve bu dosyaya web sunucusu programı tarafından erişilebiliyorsa ve dosyanın özellikleri web sunucusu programının iç kurallarına uyuyorsa, web sunucusu programı bu dosyayı istemciye gönderebilir.
Güvenlik nedenleriyle, çoğu web sunucusu programı yalnızca normal dosyaları sunacak şekilde önceden yapılandırılmıştır. Aygıt dosyaları gibi özel dosya türlerini kullanmaktan, ayrıca bunlara yönelik sembolik veya sabit bağlantılardan kaçınacak şekilde ayarlanmıştır. Bu düzenleme, statik web kaynakları sunulurken istenmeyen yan etkilerden kaçınmayı amaçlamaktadır.[21]
Dinamik içerik sunma
değiştirWeb sunucusu dinamik içerik sunacak şekilde yapılandırılmışsa, istemci isteğine ait parametreleri iletebilmek için ilgili dahili modül veya harici programla iletişim kurabilir. Bunun ardından, web sunucusu bu modülden veya programdan üretilen veri yanıtını okur ve istemciye iletir.
Statik ve dinamik içerik sunarken, bir web sunucusu genellikle aşağıdaki HTTP yöntemini de desteklemesi gerekir. Böylece, istemcilerden güvenli bir şekilde veri alabilir ve büyük veri kümeleri gönderebilen interaktif form içeren web sitelerine de ev sahipliği yapabilir.
POST
Web sunucusunun dahili modüller veya harici programlarla iletişim kurabilmesi için mevcut birçok geçit ara yüzünden bir veya birkaçının uygulanmış olması gerekir.
Üç standart geçit arayüzü şunlardır:
CGI
değiştirHer dinamik istek için, web sunucusu tarafından bir harici CGI programı çalıştırılır; ardından web sunucusu bu programın ürettiği veri yanıtını okuyarak istemciye iletir.
SCGI
değiştirHarici bir SCGI programı web sunucusu veya başka bir işlem tarafından bir kez başlatılır ve ardından ağ bağlantılarını bekler. Her yeni istek geldiğinde, web sunucusu bu programa yeni bir ağ bağlantısı kurarak istek parametrelerini gönderir, veri yanıtını okur ve kapatır.
FastCGI
değiştirHarici bir FastCGI web sunucusu veya başka bir işlem tarafından bir kez başlatılır ve ardından web sunucusu tarafından kalıcı olarak kurulan bir ağ bağlantısını bekler. Bu bağlantı üzerinden istek parametreleri gönderilir ve veri yanıtları okunur.
Dizin Listeleri
değiştirWeb sunucu, dosyaların ve alt dizinlerin dinamik olarak oluşturulmuş bir dizin indeks listesini yönetme yeteneğine sahip olabilir.[22]
Eğer bir web sunucu bu şekilde yapılandırılmışsa ve istenen URL yolu mevcut bir dizin ile eşleşiyorsa, erişimine izin veriliyorsa ve o dizin altında statik bir indeks dosyası bulunmuyorsa, belirtilen dizindeki dosyaların veya alt dizinlerin listesini içeren bir web sayfası ( HTML formatında) dinamik olarak oluşturulur. Eğer bu sayfa oluşturulamazsa, bir hata döndürülür.
Bazı web sunucuları, dizin listelemelerinin özelleştirilmesine izin verir; Dizin altında bulunan her dosya girişi için web sunucusu tarafından bulunan alan değerleriyle değiştirilmiş yer tutucular (örneğin, $(FILE_NAME), $(FILE_SIZE)
vb.) içeren bir HTML belgesi olan bir web sayfası şablonunun kullanımını veya dinamik olarak yorumlanıp çalıştırılan HTML ve gömülü kaynak kodlarının kullanımını destekler. Ayrıca, dinamik indeks programlarının (örneğin, CGIs, SCGIs, FCGIs) kullanılmasını da destekleyebilir; Örneğin, index.cgi
, index.php
, index.fcgi
gibi.
Dinamik olarak oluşturulmuş dizin listelemelerinin kullanımı genellikle, bu tür bir oluşturmanın, statik bir indeks sayfası göndermeye göre çok daha fazla işletim sistemi kaynağı tüketmesi nedeniyle, bir web sitesinin yalnızca birkaç seçilmiş diziniyle sınırlıdır.
Dizin listelemelerinin ana kullanım amacı, dosyaların kullanıcıya ek bilgi sağlama gerekliliği olmaksızın, olduğu gibi indirilmesine olanak tanımaktır.[23]
Program veya modül işleme
değiştirBir dış program veya bir iç modül, bir veya daha fazla veri deposundan veri almak veya bu verilere veri kaydetmek için kullanılabilecek bir uygulama işlevini yerine getirebilir;
Örneğin:
- Dosyalar,
- Veri tabanları,
- Diğer kaynaklar.
Bir işlem birimi, veri deposundan alınan verileri de kullanarak her türlü web içeriğini döndürebilir;
Örneğin:
- Belge (örneğin, HTML, XML vb.),
- Resim,
- Video,
- Yapılandırılmış veriler
Pratikte, içeriğin bir veya daha fazla istemci talebinde veya yapılandırma ayarlarında bulunan parametreye bağlı olarak değişebileceği durumlarda, genellikle bu içerik dinamik olarak oluşturulur.
Cevap mesajı gönderme
değiştirWeb sunucusu, istemci talep mesajlarına yanıt olarak yanıt mesajları gönderebilir. Bir hata yanıt mesajı, bir talep mesajının başarılı bir şekilde okunamaması, çözümlenememesi veya yürütülememesi nedeniyle gönderilebilir.
Aşağıdaki bölümler, bir web sunucusunun ne yaptığını anlamanıza yardımcı olmak için yalnızca örnekler olarak verilmiştir; bu bölümler kesinlikle kapsamlı veya tam değildir.
Hata Mesajı
değiştirBir web sunucusu, istemci talep mesajına birçok farklı hata mesajıyla yanıt verebilir;
Ancak bu hatalar esasen iki ana kategoriye ayrılır:
- HTTP istemci hataları, talep mesajının türüne veya talep edilen web kaynağının mevcudiyetine bağlı olarak
- HTTP sunucu hataları, sunucudaki iç hatalardan kaynaklanan
Bir hata yanıt istemci tarayıcısı tarafından alındığında, eğer bu hata ana kullanıcı talebiyle ilgiliyse, bu hata mesajı bir tarayıcı penceresinde veya mesajında gösterilir.
URL Yetkilendirmesi
değiştirBir web sunucu programı, talep edilen URL yolunun:
- Herkes tarafından serbestçe erişilebilir olup olmadığını,
- Bir kullanıcı kimlik doğrulaması gerektirip gerektirmediğini,
- Belirli veya tüm kullanıcılar için erişimin yasak olup olmadığını doğrulayabilir.
Eğer yetkilendirme/erişim hakları özelliği uygulanmış ve etkinleştirilmişse ve web kaynağına erişim verilmemişse, gerekli erişim haklarına bağlı olarak bir web sunucusu:
- Erişimi reddedebilir ve belirli bir hata mesajı gönderebilir;
- Erişimi reddedebilir ve genellikle istemci tarayıcının insan kullanıcıdan gerekli kullanıcı kimlik bilgilerini sağlamasını talep etmesini zorlayan belirli bir hata mesajı gönderebilir.
Eğer kimlik doğrulama bilgileri sağlanırsa, web sunucu programı bu bilgileri doğrular ve kabul eder veya reddeder.
URL Yönlendirmesi
değiştirBir web sunucusu, istemci talep mesajına geçerli veya mevcut bir web kaynağına erişmek için uygun yeni bir URL içeren bir yanıt mesajı ile yanıt vererek URL yönlendirmeleri yapma yeteneğine sahip olabilir.
URL yönlendirmesi şu durumlarda kullanılır:
- Bir dizin adını düzeltmek için sonuna bir eğik çizgi '/' eklemek,
- Artık mevcut olmayan bir URL yolu için yeni bir URL vererek, o türdeki web kaynağının bulunabileceği yeni bir yola yönlendirmek,
- Mevcut alan adı aşırı yüke sahipse başka bir alan adına yeni bir URL vermek.
Örnek: Bir URL yolu bir dizin adını gösteriyor ancak sonunda bir eğik çizgi '/' yoksa, web sunucusu istemciye düzeltme yapması için yönlendirme gönderir, böylece istemci düzeltilmiş yol adıyla isteği yeniden yapabilir.
Eski URL:
/directory1/directory2
Yeni URL:
/directory1/directory2/
Örnek : Tüm belgeler, dosya sistemi yollarını yeniden düzenlemek amacıyla web sitesinin içinde taşınmıştır.
Eski URL:
/directory1/directory2/2021-10-08/
Yeni URL:
/directory1/directory2/2021/10/08/
Örnek: Tüm belgeler yeni bir web sitesine taşınmış ve artık onlara erişim sağlamak için güvenli HTTPS bağlantıları kullanmak zorunlu hale gelmiştir.
Eski URL:
http://www.example.com/directory1/directory2/2021-10-08/
Yeni URL:
https://docs.example.com/directory1/2021-10-08/
Yukarıdaki örnekler, olası yönlendirmelerin yalnızca birkaç tanesidir.
Başarılı mesaj uyarısı
değiştirWeb sunucusu, geçerli bir istemci istek mesajına başarılı bir yanıt verebilir; bu yanıt, isteğe bağlı olarak istenen web kaynağı verilerini içerebilir. Eğer web kaynağı verileri istemciye gönderiliyorsa, bu veriler dosyadan veya bir program/modülün çıktısından elde edilip edilmeye bağlı olarak statik içerik veya dinamik içerik olabilir.
Önbellek
değiştirWeb sunucusu yanıtlarını hızlandırmak, ortalama HTTP yanıt sürelerini ve kullanılan donanım kaynaklarını azaltmak amacıyla, web sunucusu bir veya birden fazla içerik önbelleği uygular; her biri belirli bir içerik kategorisine özelleştirilmiştir.
İçerik genellikle kaynağına göre önbelleğe alınır,
Örneğin:
- Statik içerik: Dosya önbelleği
- Dinamik içerik: Dinamik önbellek
Dosya Önbelleği
değiştirTarihsel olarak, rastgele ve hızlı bir şekilde erişilmesi gereken dosyalardaki statik içerikler, 1960'ların ortalarından 1970'lere kadar çoğunlukla elektro-mekanik disklerde depolanmıştır. Bu tür cihazlardan okuma ve yazma işlemleri, RAM hızına kıyasla her zaman çok yavaş işlemler olarak kabul edilmiştir. Bu nedenle, erken işletim sistemleri ile birlikte önce disk önbellekleri ve ardından da işletim sistemi dosya önbellek alt sistemleri, sık erişilen veri/dosya girdi/çıktı (I/O) işlemlerini hızlandırmak için geliştirilmiştir.
Bir işletim sistemi dosya önbelleğinin yardımıyla bile, disklerde depolanan dizinler ve dosyalarla ilgili I/O işlemlerinin göreli / ara sıra yavaşlığı, özellikle 1990'ların ortalarından itibaren, yüksek performanslı web sunucularından beklenen performans artışının önünde bir engel haline gelmiştir.
Statik dosyaların hizmet verme sürecini daha verimli bir şekilde hızlandırma, dolayısıyla saniye başına maksimum istek/yanıt sayısını (RPS) artırma sorunu, 1990'ların ortalarından itibaren, web sunucu programlarında uygulanabilir faydalı önbellek modelleri önermeyi amaçlayarak araştırılmaya başlanmıştır.[24]
Günümüzde birçok yüksek performanslı web sunucusu, kullanımına özel ve kendi spesifik uygulamaları ve parametreleri ile uyumlu kullanıcı alanı dosya önbelleklerine sahiptir.
RAID veya yüksek I/O hızına sahip hızlı katı hal sürücülerinin (SSD) yaygın olarak benimsenmesi, dosya önbelleği kullanmanın avantajını biraz azaltmış olsa da, tamamen ortadan kaldırmamıştır.
Dinamik Önbellek
İç modül veya harici bir program tarafından üretilen dinamik içerik, her zaman çok sık değişmeyebilir ve bu nedenle bir süre RAM'de veya hatta hızlı bir disk üzerinde önbelleğe alınabilir.[25]
Dinamik önbelleğin tipik kullanımı, haberler, hava durumu, görseller, haritalar vb. hakkında dinamik web sayfalarına sahip olan bir web sitesinin, sık değişmeyen ve dakika/saat çok sayıda istemci tarafından erişilen sayfalara sahip olduğu durumlardır. İstemcilerin genellikle tarayıcı önbelleklerinde istenen içeriğin güncellenmiş bir kopyasına sahip olmadıklarından, önbelleğe alınmış içeriğin de döndürülmesi yararlı olabilir.[26]
Bu tür önbellekler, donanım kaynakları (CPU, RAM, diskler) ile web sunucusu ile rekabet etmemek için harici sunucular veya dinamik veri çıktısını ayrı bilgisayarlarda belirli uygulamalar tarafından yönetilerek uygulanmaktadır.[27]
Kernel ve Kullanıcı modunda çalışan web sunucuları
değiştirWeb sunucusu, işletim sistemine entegre edilerek çekirdek alanında çalıştırılabileceği gibi, diğer sıradan uygulamalar gibi kullanıcı alanında da çalıştırılabilir.
Kernel modunda çalışan web sunucuları, çekirdek kaynaklarına doğrudan erişim sağlayabilir ve bu sayede teorik olarak kullanıcı modunda çalışanlara göre daha hızlı olabilir. Kernel modunda çalışan bir web sunucusunun bazı dezavantajları vardır;
Örneğin; Yazılım geliştirme zor olabilir ve çalışma sırasında meydana gelen kritik hatalar, işletim sisteminin çekirdeğinde ciddi sorunlara yol açabilir.
Kullanıcı modunda çalışan web sunucuları ise, daha fazla bellek veya CPU kaynağı kullanmak istediklerinde sistemden izin almak zorundadırlar. Çekirdeğe yapılan bu tür istekler zaman alır ve her zaman karşılanmayabilir. Sistem kendi kullanımı için kaynak ayırmakta ve diğer tüm çalışan uygulamalarla donanım kaynaklarını paylaşma sorumluluğuna sahiptir. Kullanıcı modunda çalışmak, ayrıca kullanıcı alanı ile çekirdek alanı arasında daha fazla bilgi kopyası yapılması anlamına gelebilir ki bu da kullanıcı modunda çalışan bir web sunucusunun performansını düşürebilir.
Tüm web sunucusu yazılımları kullanıcı modunda çalıştırılmaktadır. Yukarıda bahsedilen küçük dezavantajların çoğu, daha hızlı donanımlar, yeni işletim sistemi sürümleri, çok daha hızlı işletim sistemi çağrıları ve optimize edilmiş web sunucusu yazılımları sayesinde aşılmıştır.
Performans
değiştirKullanıcı deneyimini geliştirmek için, bir web sunucusu istemci isteklerine mümkün olduğunca hızlı yanıt vermelidir; bazı dosya türleri için içerik yanıtı sınırlandırılmadığı sürece, geri dönen veri içeriği de mümkün olan en yüksek hızda iletilmelidir.
Başka bir deyişle, web sunucusu her zaman ve yoğun web trafiği altında bile çok duyarlı olmalı ve kullanıcının toplam bekleme süresini mümkün olan en düşük seviyede tutmalıdır.
Performans Ölçütleri
değiştirWeb sunucusu için temel performans şu ölçütleri içerir:[28]
- Saniye başına istek sayısı,
- Saniye başına bağlantı sayısı, web sunucusu tarafından kabul edilen saniye başına bağlantı sayısıdır,
- Her yeni istemci isteği için ağ gecikmesi
- Yanıt süresi; (belirli bir süre ölçeği içinde kaç isteğin karşılandığını gösterir veya en kısa, ortalama ve en uzun yanıt süresini verir),
- Saniye başına bayt olarak yanıtların aktarım hızı.
Çalışma koşulları arasında, test sırasında kullanılan eşzamanlı istemci bağlantı sayısı, web sunucusunun desteklediği eşzamanlılık düzeyini test edilen performans ölçütlerinin sonuçlarıyla ilişkilendirmek için önemli bir parametredir.
Yazılım Performansı
değiştirWeb sunucusu yazılımının tasarımı ve kullanılan model:
- Tek işlem veya çoklu işlem;
- Her işlem için tek iş parçacığı veya çoklu iş parçacığı;
- Eşzamanlı işlemler kullanımı veya kullanılmaması;
- Diğer programlama teknikleri,
Örneğin:
- Olası CPU önbellek hatalarının en aza indirilmesi;
- Hız için kritik yollardaki CPU yanlış tahminlerinin en aza indirilmesi;
- Belirli bir işlevi / görevi gerçekleştirmek için kullanılan sistem çağrılarının sayısının en aza indirilmesi;
Web sunucusu kullanıldığında, performansı ve özellikle ağır yük altında veya yüksek performanslı donanım kullanıldığında elde edilebilecek ölçeklenebilirlik düzeyini önemli ölçüde etkileyebilir.
Bazı web sunucusu yazılım modelleri hedef performanslara ulaşabilmek için diğerlerinden daha fazla işletim sistemi kaynağına ihtiyaç duyabilir.
Çalışma Koşulları
değiştirBir web sunucusunun performansını etkileyen birçok çalışma koşulu vardır;
- Web sunucusu ayarları,
- İstemci isteklerinde kullanılan HTTP sürümü;
- Ortalama HTTP istek türü,
- İstenen içeriğin statik mi yoksa dinamik mi olduğu,
- İçeriğin önbelleğe alınıp alınmadığı,
- İçeriğin iletim sırasında dinamik olarak sıkıştırılıp sıkıştırılmadığı,
- Bağlantıların şifreli olup olmadığı,
- Web sunucusu ile istemcileri arasındaki ortalama ağ hızı,
- Aktif TCP bağlantı sayısı,
- Web sunucusu tarafından yönetilen aktif işlem sayısı,
- Donanım ve yazılım sınırlamaları veya ayarları,
- Diğer küçük koşullar.
Karşılaştırma
değiştirWeb sunucusunun performansı genellikle bir veya daha fazla mevcut otomatik yük test araçları kullanılarak karşılaştırılır.
Yük Sınırları
değiştirBir web sunucusu, genellikle işletim koşullarının her kombinasyonu için önceden tanımlanmış yük sınırlamalarına sahiptir. Aynı zamanda işletim sistemi kaynakları tarafından sınırlı olmasından ve yalnızca sınırlı sayıda eşzamanlı istemci bağlantısını işleyebilmesinden kaynaklanmaktadır.
Bir web sunucusu yük sınırlarına yakın olduğunda veya bu sınırları aştığında, aşırı yüklenir ve bu nedenle yanıt vermez hale gelebilir.
Aşırı Yüklenme Nedenleri
değiştirHerhangi bir zamanda web sunucuları, aşağıdaki nedenlerden biri veya daha fazlası nedeniyle aşırı yüklenebilir:
- Aşırı web trafiği: Kısa bir süre içinde binlerce hatta milyonlarca istemcinin bir web sitesine bağlanması,
- Hizmet saldırıları: Bir hizmet saldırısı (DoS saldırısı) veya hizmet reddi saldırısı (DDoS saldırısı), bir bilgisayar veya ağ kaynağının hedeflenen kullanıcılarına ulaşılamaz hale getirilmesi için yapılan bir girişimdir.
- Bilgisayar solucanları: Bazen milyonlarca enfekte bilgisayar nedeniyle anormal trafik yaratan bu solucanlar, ağda koordinasyon olmaksızın yayılabilir.
- XSS solucanları: Milyonlarca enfekte tarayıcı veya web sunucusu nedeniyle yüksek trafik oluşturabilir.
- İnternet botları: Büyük web sitelerinde filtrelenmemiş veya sınırlanmamış trafik, sınırlı ağ kaynakları olduğunda sorun yaratabilir.
- İnternet (ağ) yavaşlamaları: Paket kayıpları nedeniyle istemci talepleri daha yavaş sunulabilir ve bağlantı sayısı o kadar artar ki sunucu sınırları aşılır.
- Web sunucularının kısmi erişilmezlik: Gerekli veya acil bakım veya yükseltme, donanım veya yazılım arızaları gibi durumlar nedeniyle gerçekleşebilir. Bu tür durumlarda kalan web sunucuları çok fazla trafik alabilir ve aşırı yüklenebilir.
Aşırı Yüklenme Belirtileri
değiştirAşırı yüklenmiş bir web sunucusunun belirtileri genellikle şunlardır:
- Taleplerin gecikmeli karşılanması: Yanıtlar, 1 saniyeden birkaç yüz saniyeye kadar değişen uzun gecikmelerle sunulur.
- HTTP hata kodları döndürme: Web sunucusu, 500, 502[29][30], 503[31], 504[32], 408 veya hatta geçici olarak 404 gibi HTTP hata kodları döndürebilir.
- TCP bağlantılarını reddetme veya sıfırlama: Web sunucusu, herhangi bir içerik döndürmeden önce TCP bağlantılarını reddedebilir veya sıfırlayabilir.
- İstenilen içeriğin sadece bir kısmını döndürme: Çok nadir durumlarda, web sunucusu yalnızca istenilen içeriğin bir kısmını döndürebilir. Bu davranış bir hata olarak kabul edilebilir, ancak genellikle aşırı yüklenmenin bir belirtisi olarak ortaya çıkar.
Aşırı Yüklenmeyi Önleme Teknikleri
değiştirYukarıdaki ortalama yük limitlerini kısmen aşmak ve aşırı yüklenmeyi önlemek için, web siteleri genellikle aşağıdaki gibi yaygın teknikler kullanır:
- Donanım yeteneklerine ve kullanımına göre işletim sistemi parametrelerini ayarlama.
- Web sunucusu parametrelerini ayarlayarak güvenlik ve performansı artırma.
- Web önbellek tekniklerini uygulama (Önbellek Sistemi) bakınız.
- Ağ trafiğini yönetme
- İstenmeyen trafiği kötü IP kaynaklarından veya kötü desenlere sahip olanlardan engellemek için güvenlik duvarı kullanma,
- Kötü HTTP desenlerine sahip talepleri düşürmek, yönlendirmek veya yeniden yazmak için HTTP trafik yöneticileri kullanma,
- Bant genişliği yönetimi
- Farklı alan adları, IP adresleri ve bilgisayarlar kullanarak farklı içerik türlerini (statik ve dinamik) sunma
Büyük veya devasa dosyaları küçük ve orta boy dosyalardan (örneğin,
static.*
) ve ana dinamik siteden ayırmaktır. Farklı ayarlarla her web sunucu bilgisayarı için etkin bir şekilde büyük dosyaları sunmak ve dinamik sitenin ağır yük altında performansını etkilemeden küçük ve orta boy dosyaları tamamen önbelleğe almak.https://download.example.com
https://static.example.com
https://www.example.com
- Yük dengeleyici arkasında bir araya getirilen birçok web sunucusu kullanma,
- Her bilgisayara daha fazla donanım kaynağı ekleme,
- Web sunucuları için daha verimli bilgisayar programları kullanma,
- En son verimli HTTP sürümlerini kullanma
HTTP/2 ve HTTP/3 protokollerini kullanmayla ilgili uyarılar
değiştirHTTP (2 ve 3) protokolleri genellikle her istek/yanıt verisi için daha az ağ trafiği oluşturmasına rağmen, web sunucusu tarafından kullanılan daha fazla işletim sistemi kaynağı gerektirebilir. Bunun nedeni, şifreli veriler ve diğer uygulama detaylarıdır. Ayrıca, HTTP/2 ve belki de HTTP/3, web sunucusunun ve istemci programının ayarlarına bağlı olarak, çok büyük dosyaların çok yüksek hızda yüklenmesi için en iyi seçenekler olmayabilir. Çünkü bu protokollerin veri akışları, isteklerin eşzamanlılığı için optimize edilmiştir; bu nedenle, birçok durumda HTTP/1.1 TCP/IP bağlantılarını kullanmak daha iyi sonuçlar veya daha yüksek yükleme hızları sağlayabilir.[33][34]
Pazar Payı
değiştirAşağıda, Netcraft tarafından sağlanan, İnternet'teki en popüler web sunucularının tüm sitelerinin pazar payına dair en güncel istatistikler yer almaktadır.
Tarih | nginx | Apache (ASF) | OpenResty | (Cloudflare, Inc.) | IIS (Microsoft) | GWS (Google) | Diğerleri |
---|---|---|---|---|---|---|---|
Ekim 2021[35] | 34.95% | 24.63% | 6.45% | 4.87% | 4.00% (*) | 4.00% (*) | %22'den az |
Şubat 2021[36] | 34.54% | 26.32% | 6.36% | 5.0% | 6.5% | 3.90% | %18'den az |
Şubat 2020[37] | 36.48% | 24.5% | 4.00% | 3.0% | 14.21% | 3.18% | %15'den az |
Şubat 2019[38] | 25.34% | 26.16% | N/A | N/A | 28.42% | 1.66% | %19'dan az |
Şubat 2018[39] | 24.32% | 27.45% | N/A | N/A | 34.50% | 1.20% | %13'den az |
Şubat 2017[40] | 19.42% | 20.89% | N/A | N/A | 43.16% | 1.03% | %15'den az |
Şubat 2016[41] | 16.61% | 32.80% | N/A | N/A | 29.83% | 2.21% | %19'dan az |
NOT: (*) Yüzde, kaynak sayfasında yalnızca yuvarlanmış değerin raporlandığı için tam sayı olarak yuvarlanmıştır; ondalık değerler kamuya açık olarak rapor edilmemektedir.
Kaynakça
değiştir- ^ "What is a web server? - Learn web development | MDN". developer.mozilla.org (İngilizce). 22 Ekim 2024. 1 Ekim 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 3 Kasım 2024.
- ^ "What are Web Servers and How do They Work?". Nywhash Research (İngilizce). 7 Ekim 2024. Erişim tarihi: 3 Kasım 2024.
- ^ "HTTP response status codes - HTTP | MDN". developer.mozilla.org (İngilizce). 18 Ekim 2024. 4 Kasım 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 3 Kasım 2024.
- ^ Zolfagharifard, Ellie (24 Kasım 2018). "'Father of the web' Sir Tim Berners-Lee on his plan to fight fake news". The Telegraph (İngilizce). Londra. ISSN 0307-1235. 11 Ocak 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019.
- ^ "History of Computers and Computing, Internet, Birth, The World Wide Web of Tim Berners-Lee". history-computer.com. 4 Ocak 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019.
- ^ a b c Tim Berner-Lee (1992). "WWW Project History (original)". CERN (World Wide Web project). 8 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 20 Aralık 2021.
- ^ Tim Berner-Lee (20 Ağustos 1991). "WorldWideWeb wide-area hypertext app available (announcement)". CERN (World Wide Web project). 2 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2021.
- ^ a b Web Administrator. "Web History". CERN (World Wide Web project). 2 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2021.
- ^ Tim Berner-Lee (2 Ağustos 1991). "Qualifiers on hypertext links ..." CERN (World Wide Web project). 7 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2021.
- ^ Tim Smith; François Flückiger. "Licensing the Web". CERN (World Wide Web project). 6 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2021.
- ^ "Netcraft: web server software (1996)". Netcraft (web archive). 30 Aralık 1996 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Aralık 2021.
- ^ "Overview of new features in Apache 2.2" (İngilizce). Apache: HTTPd server project. 2005. 27 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Aralık 2021.
- ^ "Overview of new features in Apache 2.4" (İngilizce). Apache: HTTPd server project. 2012. 26 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Aralık 2021.
- ^ "Linux Web Server Performance Benchmark - 2016 results". RootUsers. 8 Mart 2016. 23 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Aralık 2021.
- ^ a b "Will HTTP/2 replace HTTP/1.x?". IETF HTTP Working Group. 27 Eylül 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Aralık 2021.
- ^ a b "Implementations of HTTP/2 in client and server software". IETF HTTP Working Group. 23 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Aralık 2021.
- ^ "Why just one TCP connection?". IETF HTTP Working Group. 27 Eylül 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Aralık 2021.
- ^ R. Bowen (29 Eylül 2002). "URL Mapping" (PDF) (İngilizce). Apache software foundation. 15 Kasım 2021 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 15 Kasım 2021.
- ^ a b c "Mapping URLs to Filesystem Locations" (İngilizce). Apache: HTTPd server project. 2021. 20 Ekim 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Ekim 2021.
- ^ "Dynamic Content with CGI" (İngilizce). Apache: HTTPd server project. 2021. 15 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Ekim 2021.
- ^ Chris Shiflett (2003). HTTP developer's handbook (İngilizce). Sams's publishing. ISBN 0-672-32454-7. 20 Ocak 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Aralık 2021.
- ^ ASF Infrabot (22 Mayıs 2019). "Directory listings" (İngilizce). Apache foundation: HTTPd server project. 7 Haziran 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Kasım 2021.
- ^ "Apache: directory listing to download files". Apache: HTTPd server. 2 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Aralık 2021.
- ^ Evangelos P. Markatos (1996). "Main Memory Caching of Web Documents" (İngilizce). Computer networks and ISDN Systems. 20 Ocak 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Aralık 2021.
- ^ "Apache Module mod_cache_disk" (İngilizce). Apache: HTTPd server project. 2021. 9 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Aralık 2021.
- ^ "What is dynamic cache?" (İngilizce). Educative. 2021. 9 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Aralık 2021.
- ^ "Dynamic Cache Option Tutorial" (İngilizce). Siteground. 2021. 20 Ocak 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Aralık 2021.
- ^ Jussara M. Almeida; Virgilio Almeida; David J. Yates (7 Temmuz 1997). "WebMonitor: a tool for measuring World Wide Web server performance". First Monday (İngilizce). doi:10.5210/fm.v2i7.539. 4 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Kasım 2021. Geçersiz
|doi-access=free
(yardım) - ^ Fisher, Tim; Lifewire. "Getting a 502 Bad Gateway Error? Here's What to Do". Lifewire (İngilizce). 23 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019.
- ^ "What is a 502 bad gateway and how do you fix it?". IT PRO (İngilizce). 20 Ocak 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019.
- ^ Fisher, Tim; Lifewire. "Getting a 503 Service Unavailable Error? Here's What to Do". Lifewire (İngilizce). 20 Ocak 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019.
- ^ Fisher, Tim; Lifewire. "Getting a 504 Gateway Timeout Error? Here's What to Do". Lifewire (İngilizce). 23 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019.
- ^ many (24 Ocak 2021). "Slow uploads with HTTP/2" (İngilizce). github. 16 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 15 Kasım 2021.
- ^ Junho Choi (24 Ağustos 2020). "Delivering HTTP/2 upload speed improvements" (İngilizce). Cloudflare. 16 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 15 Kasım 2021.
- ^ "October 2021 Web Server Survey". Netcraft. 15 Ekim 2021. 15 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 15 Kasım 2021.
- ^ "February 2021 Web Server Survey". Netcraft. 26 Şubat 2021. 15 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2021.
- ^ "February 2020 Web Server Survey". Netcraft. 20 Şubat 2020. 17 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2021.
- ^ "February 2019 Web Server Survey". Netcraft. 28 Şubat 2019. 15 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2021.
- ^ "February 2018 Web Server Survey". Netcraft. 13 Şubat 2018. 17 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2021.
- ^ "February 2017 Web Server Survey". Netcraft. 27 Şubat 2017. 14 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 13 Mart 2017.
- ^ "February 2016 Web Server Survey". Netcraft. 22 Şubat 2016. 27 Ocak 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Ocak 2022.