Cela fait partie du protocole HTTP 1.1.
Plus précisément, le protocole HTTP 1.1 comprend un en-tête appelé «hôte:» qui spécifie à quel site Web sur un serveur particulier le client tente d'accéder.
Donc, si snoopy.net et woodstock.org partagent tous les deux 192.0.32.10 et que votre navigateur essaie d'obtenir le contenu de http://snoopy.net/doghouse
la requête http spécifique, cela ressemblerait à:
GET /doghouse HTTP/1.1
Host: snoopy.net
Si l'URL souhaitée est http://woodstock.org/seeds
la demande ressemblerait à
GET /seeds HTTP/1.1
Host: woodstock.org
Dans les deux cas, il y aurait un socket TCP entre votre ordinateur et le port 80 du serveur. Le serveur saurait obtenir le contenu de /var/www/snoopy.net ou /var/www/woodstock.org/ en fonction de l'en-tête Host.
Il y aurait d'autres en-têtes pour les cookies et d'autres choses comme le type de navigateur et le contenu autorisé, mais l'en-tête "Host" est précisément ce qui permet au serveur Web de savoir quel site Web virtuel est souhaité.
Il y a plus dans le RFC2616 .
C'est aussi pourquoi les sites https * doivent *** avoir leur propre adresse IP - l'échange de clés ssl et la vérification des certificats ont lieu avant la transaction http, donc le serveur http ne saura pas donner le certificat pour "woodstock". org "ou" snoopy.net "lorsqu'il reçoit une connexion https sur le port 443 de 192.0.32.10.
modifier
** dans les commentaires, Grawity souligne qu'il existe des extensions SSL dans la spécification TLS qui permettent au serveur de savoir à quel site Web l'utilisateur tente d'accéder, et que la plupart des navigateurs Web modernes ont ces extensions, il en va de même un peu trop fort.