Jest to część protokołu HTTP 1.1.
W szczególności protokół HTTP 1.1 zawiera nagłówek o nazwie „host:”, który określa, do której strony internetowej na określonym serwerze próbuje uzyskać dostęp klient.
Więc jeśli snoopy.net i woodstock.org oba współużytkują 192.0.32.10, a twoja przeglądarka próbuje uzyskać zawartość z http://snoopy.net/doghouse
określonego żądania http wyglądałby tak:
GET /doghouse HTTP/1.1
Host: snoopy.net
Jeśli pożądany adres URL http://woodstock.org/seeds
będzie wyglądał, żądanie będzie wyglądać
GET /seeds HTTP/1.1
Host: woodstock.org
W obu przypadkach między komputerem a portem 80 serwera znajdowałoby się gniazdo tcp. Serwer wiedziałby, aby uzyskać zawartość z /var/www/snoopy.net lub /var/www/woodstock.org/ na podstawie nagłówka Host.
Istnieją inne nagłówki plików cookie i inne rzeczy, takie jak typ przeglądarki i dozwolona zawartość, ale nagłówek „Host” jest tym, co pozwala serwerowi internetowemu wiedzieć, która wirtualna strona internetowa jest pożądana.
W RFC2616 jest więcej .
Dlatego też strony https * muszą *** mieć swój własny adres IP - wymiana transakcji ssl i weryfikacja certyfikatu odbywają się przed transakcją http, więc serwer http nie będzie wiedział o wydaniu certyfikatu dla woodstock. org ”lub„ snoopy.net ”, gdy odbierze połączenie https na porcie 443 192.0.32.10.
edytować
** w komentarzach Grawity wskazuje, że w specyfikacji TLS istnieją rozszerzenia protokołu SSL, które pozwalają serwerowi dowiedzieć się, do której strony użytkownik próbuje uzyskać dostęp, i że większość współczesnych przeglądarek internetowych ma te rozszerzenia, więc to też musi być trochę zbyt silny.