Grundsätzlich gilt: Der Browser bezieht den Domainnamen in die HTTP-Anfrage ein, sodass der Webserver weiß, welche Domain angefordert wurde und entsprechend reagieren kann.
HTTP-Anfragen
So passiert Ihre typische HTTP-Anfrage:
Der Benutzer gibt im Formular eine URL an http://host:port/path
.
Der Browser extrahiert den Host- (Domain-) Teil der URL und übersetzt ihn bei Bedarf in eine IP-Adresse. Dies wird als Namensauflösung bezeichnet . Diese Übersetzung kann über DNS erfolgen, muss jedoch nicht (z. B. hosts
umgeht die lokale Datei auf gängigen Betriebssystemen DNS).
Der Browser öffnet eine TCP-Verbindung zu dem angegebenen Port oder verwendet standardmäßig Port 80 für diese IP-Adresse.
Der Browser sendet eine HTTP-Anfrage. Für HTTP / 1.1 sieht das so aus:
GET /path HTTP/1.1
Host: example.com
(Der Host
Header ist Standard und in HTTP / 1.1 erforderlich. Er wurde in der HTTP / 1.0-Spezifikation nicht angegeben, wird jedoch von einigen Servern trotzdem unterstützt.)
Von hier aus kann der Webserver anhand mehrerer Informationen entscheiden, wie die Antwort lauten soll. Beachten Sie, dass ein einzelner Webserver an mehrere IP-Adressen gebunden sein kann.
- Die angeforderte IP-Adresse aus dem TCP-Socket
- Die IP-Adresse des Clients ist ebenfalls verfügbar, wird jedoch selten verwendet - manchmal zum Blockieren / Filtern
- Der angeforderte Port vom TCP-Socket
- Der angeforderte Hostname, wie im
Host
Header des Browsers in der HTTP-Anforderung angegeben.
- Der angeforderte Pfad
- Alle anderen Header (Cookies usw.)
Wie Sie anscheinend bemerkt haben, werden beim derzeit am häufigsten verwendeten Shared-Hosting-Setup mehrere Websites auf eine einzige Kombination aus IP-Adresse und Port gelegt, sodass nur Host
zwischen Websites unterschieden werden muss.
Dies wird in Apache-land als namensbasierter virtueller Host bezeichnet , während Nginx sie Servernamen in Serverblöcken nennt und IIS den virtuellen Server bevorzugt .
Was ist mit HTTPS?
HTTPS ist ein bisschen anders. Bis zum Aufbau der TCP-Verbindung ist alles identisch, danach muss jedoch ein verschlüsselter TLS-Tunnel aufgebaut werden. Ziel ist es, keine Informationen über die Anfrage zu verlieren.
Um zu überprüfen, ob der Server tatsächlich Eigentümer dieser Domäne ist, muss der Server ein von einem vertrauenswürdigen Dritten signiertes Zertifikat senden. Der Browser vergleicht dieses Zertifikat dann mit der von ihm angeforderten Domain.
Dies ist ein Problem. Woher weiß der Server, welches Zertifikat des Hosts (der Website) gesendet werden soll, wenn dies erforderlich ist, bevor die HTTP-Anforderung empfangen wird?
Traditionell wurde dies dadurch gelöst, dass für jede Website, die HTTPS benötigt, eine eigene IP-Adresse (oder ein eigener Port) eingerichtet wurde. Offensichtlich wird dies problematisch, wenn uns die IPv4-Adressen ausgehen.
Geben Sie SNI (Server Name Indication) ein. Der Browser übergibt jetzt den Hostnamen während der TLS-Verhandlungen, sodass der Server diese Informationen früh genug hat, um das richtige Zertifikat zu senden. Auf der Serverseite ist die Konfiguration der Konfiguration der virtuellen HTTP-Hosts sehr ähnlich.
Der Nachteil ist, dass der Hostname jetzt vor der Verschlüsselung als Klartext übergeben wird und im Wesentlichen Informationen verloren gehen. Dies wird normalerweise als akzeptabler Kompromiss angesehen, da der Hostname normalerweise ohnehin in einer DNS-Abfrage offengelegt wird.
Was ist, wenn Sie eine Site nur über die IP-Adresse anfordern?
Was der Server tut, wenn er nicht weiß, welchen bestimmten Host Sie angefordert haben, hängt von der Serverimplementierung und -konfiguration ab. In der Regel ist eine "Standard" -, "Catchall" - oder "Fallback" -Site angegeben, die Antworten auf alle Anforderungen liefert, die keinen Host explizit angeben.
Bei dieser Standardwebsite kann es sich um eine eigene unabhängige Site handeln (die häufig eine Fehlermeldung anzeigt), oder es kann sich um eine beliebige andere Site auf dem Server handeln, je nach den Vorlieben des Serveradministrators.
Host:
Header. Im Falle von Shared Hosting kann der Webserver vom Anbieter so konfiguriert werden, dass dies auf unterschiedliche Weise behandelt wird (z. B. Standard, Weiterleitung an den Anbieter usw.).