Web sunucusu
Bu sayfada devam eden bir çalışma vardır. Yardım etmek istiyorsanız ya da çalışma yarım bırakılmışsa, çalışmayı yapan kişilerle iletişime geçebilirsiniz. Bu sayfada son yedi gün içinde değişiklik yapılmadığı takdirde şablon sayfadan kaldırılacaktır. En son değişiklik, 13 saniye önce Netiym (katkılar | kayıtlar) tarafından gerçekleştirildi ( ). |
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ı:[7][8][9]
- 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.[10] 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ı.[11]
Gelişim Süreci (1991–1995)
değiştirAralık 1991'de, Avrupa dışındaki ilk web sunucusu ABD'deki SLAC laboratuvarında kuruldu.[12] 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ı.[13] 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.[14] 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ı.[15][16] 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.[17]
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ı.[18][19]
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.[20][21]
- 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.[22]
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.[23]
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.[24]
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.[25]
Çı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:[26]
- İ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.[27]
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.[28]
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.[29]
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.[30]
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.
Kaynakça
değiştir- ^ "What is a web server? - Learn web development | MDN". developer.mozilla.org (İngilizce). 22 Ekim 2024. 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. 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.
- ^ 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.
- ^ 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 (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 (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 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.
- ^ 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 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.
- ^ "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.
- ^ "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.
- ^ "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.
- ^ "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.
- ^ "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.
- ^ "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.
- ^ "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.
- ^ 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 (2019-05-22). "Directory listings" (İngilizce). Apache foundation: HTTPd server project. 7 June 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 2021-11-16.
- ^ "Apache: directory listing to download files". Apache: HTTPd server. 2 December 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 2021-12-16.