Temel olarak: tarayıcı HTTP isteğinde alan adını içerir, böylece web sunucusu hangi alanın talep edildiğini bilir ve buna göre yanıt verebilir.
HTTP istekleri
Tipik HTTP isteğiniz şöyle:
Kullanıcı, formda bir URL sağlar http://host:port/path
.
Tarayıcı, URL'nin ana bilgisayar (etki alanı) bölümünü ayıklar ve ad çözümlemesi olarak bilinen bir işlemde gerekirse IP adresini dönüştürür . Bu çeviri DNS üzerinden gerçekleşebilir, ancak zorunlu değildir (örneğin, hosts
yaygın işletim sistemindeki yerel dosya DNS'yi atlar).
Tarayıcı, belirtilen bağlantı noktasına bir TCP bağlantısı açar veya bu IP adresinde varsayılan olarak bağlantı noktası 80'e ayarlar.
Tarayıcı bir HTTP isteği gönderir. HTTP / 1.1 için şöyle görünür:
GET /path HTTP/1.1
Host: example.com
( Host
Başlık HTTP / 1.1'de standart ve zorunludur. HTTP / 1.0 belirtiminde belirtilmemiş, ancak bazı sunucular yine de desteklemektedir.)
Buradan, web sunucusu cevabın ne olması gerektiğine karar vermek için kullanabileceği çeşitli bilgiler içerir. Tek bir web sunucusunun birden fazla IP adresine bağlanmasının mümkün olduğunu unutmayın.
- TCP soketinden istenen IP adresi
- İstemcinin IP adresi de mevcuttur, ancak bu nadiren kullanılır - bazen engelleme / filtreleme için
- TCP soketinden istenen port
- İstenen ana bilgisayar adı,
Host
HTTP isteğindeki tarayıcı tarafından başlıkta belirtildiği şekilde .
- İstenen yol
- Diğer başlıklar (çerezler vb.)
Farkında göründüğünüz gibi, bugünlerde en yaygın paylaşılan barındırma kurulumu, birden fazla web sitesini tek bir IP adresine yerleştirir: bağlantı noktası birleşimi, yalnızca Host
web siteleri arasındaki farkı ayırt eder.
Bu, Apache ülkesinde Ad Tabanlı Sanal Konak olarak bilinirken, Nginx bunları Sunucu Bloklarında Sunucu Adları olarak adlandırır ve IIS, Sanal Sunucu'yu tercih eder .
HTTPS'den ne haber?
HTTPS biraz farklı. Her şey TCP bağlantısının kurulmasıyla aynıdır, ancak bundan sonra şifreli bir TLS tüneli kurulmalıdır. Amaç, istekle ilgili hiçbir bilgiyi sızdırmamak.
Sunucunun gerçekte bu etki alanına sahip olduğunu doğrulamak için, sunucunun güvenilir bir üçüncü tarafça imzalanmış bir sertifika göndermesi gerekir. Tarayıcı daha sonra bu sertifikayı istediği alanla karşılaştıracak.
Bu bir sorun sunuyor. Sunucu, HTTP isteği alınmadan önce bunu yapması gerekiyorsa hangi ana bilgisayarın (web sitesinin) sertifikasının gönderileceğini nasıl biliyor?
Geleneksel olarak bu, HTTPS gerektiren her web sitesi için özel bir IP adresine (veya bağlantı noktasına) sahip olarak çözülmüştür. Açıkçası, IPv4 adresleri tükendiğinde bu sorunlu hale geliyor.
SNI (Sunucu Adı Gösterimi) girin . Tarayıcı şimdi TLS görüşmeleri sırasında ana bilgisayar adını geçirir, bu nedenle sunucu bu bilgiyi doğru sertifikayı gönderecek kadar erken alır. Sunucu tarafında, yapılandırma, HTTP sanal ana makinelerinin nasıl yapılandırıldığına çok benzer.
Dezavantajı, ana bilgisayar adının şimdi şifrelemeden önce düz metin olarak geçirilmesidir ve esasen sızdırılmış bilgidir. Bu, genellikle ana bilgisayar adının normal olarak bir DNS sorgusuna zaten maruz kaldığı düşünülürse, kabul edilebilir bir tradeoff olarak kabul edilir.
Bir siteyi yalnızca IP adresine göre talep ederseniz?
Sunucunun, hangi belirli ana bilgisayarı istediğinizi bilmediği durumda ne yapacağı, sunucu uygulamasına ve yapılandırmasına bağlıdır. Genellikle, bir ana bilgisayarı açıkça belirtmeyen tüm isteklere yanıtlar verecek bir "varsayılan", "catchall" veya "geri dönüş" sitesi vardır.
Bu varsayılan site kendi bağımsız sitesi olabilir (genellikle bir hata mesajı gösterir) veya sunucu yöneticisinin tercihine bağlı olarak sunucudaki diğer sitelerden biri olabilir.
Host:
başlık içinde bir etki alanı olmaz . Paylaşılan barındırma durumunda, web sunucusu sağlayıcı tarafından bunu farklı şekillerde ele alması için yapılandırılabilir (örn. Varsayılan bir, sağlayıcıya yönlendirme vb.).