Es ist Teil des HTTP 1.1-Protokolls.
Insbesondere enthält das HTTP 1.1-Protokoll einen Header namens "host:", der angibt, auf welche Website auf einem bestimmten Server der Client zugreifen möchte.
Wenn snoopy.net und woodstock.org 192.0.32.10 gemeinsam nutzen und Ihr Browser versucht, Inhalte von http://snoopy.net/doghouse
der spezifischen http-Anfrage abzurufen, würde dies folgendermaßen aussehen:
GET /doghouse HTTP/1.1
Host: snoopy.net
Wenn die gewünschte URL http://woodstock.org/seeds
die Anfrage ist, würde sie so aussehen
GET /seeds HTTP/1.1
Host: woodstock.org
In beiden Fällen würde sich zwischen Ihrem Computer und Port 80 des Servers ein TCP-Socket befinden. Der Server würde basierend auf dem Host-Header wissen, ob Inhalte von /var/www/snoopy.net oder /var/www/woodstock.org/ abgerufen werden.
Es gäbe andere Header für Cookies und andere Dinge wie Browsertyp und zulässigen Inhalt, aber der "Host" -Header ist speziell das, was dem Webserver ermöglicht, zu wissen, welche virtuelle Website gewünscht wird.
Im RFC2616 steckt noch mehr .
Dies ist auch der Grund, warum https-Sites * eine eigene IP-Adresse haben müssen - der Austausch des SSL-Schlüssels und die Überprüfung des Zertifikats erfolgen vor der http-Transaktion, sodass der http-Server das Zertifikat für "woodstock" nicht herausgeben kann. org "oder" snoopy.net ", wenn eine https-Verbindung auf Port 443 von 192.0.32.10 empfangen wird.
bearbeiten
** in den Kommentaren Grawity weist darauf hin , dass es Erweiterungen SSL in der TLS - Spezifikation sind , dass der Server ermöglichen , die Web - Site der Benutzer als Versuch , den Zugriff, und dass die meisten modernen Web - Browser haben diese Erweiterungen wissen, so muss ein bisschen zu ist stark.