Web sunucusu

Web site içeriklerini kullanıcıya sunan sunucu
(Web server sayfasından yönlendirildi)

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.

Bilgisayar istemcileri yalnıza statik içerik sunan bir web sunucusu aracılığıyla ağ üzerinden iletişim gerçekleştiriyor.
Bir Dell PowerEdge sunucusunun önü ve içi. Bu tarz bilgisayarlar bir rafa monte edilmek için tasarlanmıştır. Buna benzer sunucular genellikle web sunucusu olarak kullanılır.

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.

Çalışma prensibi

değiştir

Bir 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ştir

Bu 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.

REST ve SOAP gibi HTTP'yi bilgisayarlar arası genel iletişim için temel alan teknolojiler ve WebDAV eklentilerine sunulan destekler, web sunucularının uygulama alanını, insan tarafından okunabilir sayfalar sunma gibi asıl amacının çok ötesine genişletmiştir.

WWW projesi (1989–1991)

değiştir

Mart 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ı.[1][2][3]

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ı:[4] [5] [6]

  • 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.[7] 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ı.[8]

Gelişim Süreci (1991–1995)

değiştir

Aralık 1991'de, Avrupa dışındaki ilk web sunucusu ABD'deki SLAC laboratuvarında kuruldu.[9] 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ı.

 
Dünyanın ilk web sunucusu, Ethernet bağlantısına sahip bir NeXT Computer iş istasyonu, 1990. Kasa üzerindeki etiket şöyle yazıyordu: “Bu makine bir sunucudur. KAPATMAYIN!!”

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ştir
 
Sun'ın Cobalt Qube 3'ü – bir bilgisayar sunucu cihazı (1998-2002)

1996 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ı.[14]

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.[15]

2015 ve sonraki yıllar

değiştir

2015 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ı.[16][17]

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.[18][19]

  • 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.[20]

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ştir
 
İnternet üzerinden bir web sunucusuna bağlı istemciler

Aş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ştir

Web 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ştir

Web 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ştir

Web 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.

Web 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ştir

URL 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.[21]

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.[22]

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ştir

Web 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 makinelerinde 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ştir

Aş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ştir

Dinamik 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.[23]

Çı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ştir

Bir 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:[24]

  • İ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ştir

Web 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.[25]

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ştir

Web 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ştir

Web 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.[26]

 
Statik ve dinamik içerik sunan bir web sunucusuyla ağ üzerinden iletişim kuran PC istemcileri

Dinamik içerik sunma

değiştir

Web 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:

Her 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.

Harici 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.

Harici 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ştir
 
Bir web sunucusu tarafından dinamik olarak oluşturulan dizin listesi

Web sunucu, dosyaların ve alt dizinlerin dinamik olarak oluşturulmuş bir dizin indeks listesini yönetme yeteneğine sahip olabilir.[27]

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.[28]

Program veya modül işleme

değiştir

Bir 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ştir

Web 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ştir

Bir 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:

  1. HTTP istemci hataları, talep mesajının türüne veya talep edilen web kaynağının mevcudiyetine bağlı olarak
  2. 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ştir

Bir 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ştir

Bir 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
  1. ^ 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.  Geçersiz |url-erişimi=subscription (yardım)
  2. ^ "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. 
  3. ^ 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. 
  4. ^ 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. 
  5. ^ Web Administrator. "Web History". CERN (World Wide Web project). 2 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2021. 
  6. ^ 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. 
  7. ^ 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. 
  8. ^ 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. 
  9. ^ Web Administrator. "Web History". CERN (World Wide Web project). 2 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2021. 
  10. ^ 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. 
  11. ^ "Netcraft: web server software (1996)". Netcraft (web archive). 30 Aralık 1996 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Aralık 2021. 
  12. ^ "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. 
  13. ^ "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. 
  14. ^ "Maximum concurrent connections to the same domain for browsers". 2017. 21 Aralık 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Aralık 2021. 
  15. ^ "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. 
  16. ^ "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. 
  17. ^ "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. 
  18. ^ "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. 
  19. ^ "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. 
  20. ^ "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. 
  21. ^ 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. 
  22. ^ "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. 
  23. ^ "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. 
  24. ^ "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. 
  25. ^ "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. 
  26. ^ 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. 
  27. ^ 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. 
  28. ^ "Apache: directory listing to download files". Apache: HTTPd server. 2 December 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 2021-12-16.