Pourquoi la saisie d'une adresse IP au lieu du nom de domaine correspondant n'affiche-t-elle pas le site Web?
> Host example.com
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
J'écris 93.184.216.34 au lieu de http://example.com dans Chrome. Il ne charge pas le site Web. Pourquoi?
Parce que l'en-tête HTTP Host approprié est souvent requis pour obtenir réellement le site prévu.
Il est très courant d'héberger plusieurs sites Web sur la même adresse IP et de les distinguer en fonction de l'en-tête HTTP Host spécifié par le client (ainsi que de la valeur TLS SNI de nos jours dans le cas de HTTPS).
Autrement dit, lorsque vous avez entré http://example.com dans votre navigateur, l'en-tête Host était example.com, mais ce n'est pas le cas lorsque vous avez entré 93.184.216.34. Vous atteignez le même serveur Web dans les deux cas, mais vous recevez des réponses différentes (dans ce cas particulier 200 contre 404).
Parce que les serveurs Web utilisent généralement la technologie de "serveur virtuel" et sont en mesure de répondre à votre demande HTTP dans le nom de domaine que vous demandez, mais pas l'adresse IP des serveurs Web. Merci de cacher plus d'un nom de domaine sur une seule adresse IP.
Par exemple, le serveur Web Apache peut répondre à votre demande HTTP avec une adresse IP en utilisant la section:
<VirtualHost *:80>
ServerName Default
...
</VirtualHost>
ou si aucun VirtualHost n'est utilisé dans la configuration.
La fonctionnalité VirtualHost dans Apache a été introduite en 1996.
Dans Apache , vous pouvez héberger de nombreux sites Web en utilisant une seule adresse IP. C'est ce qu'on appelle l'hébergement virtuel. C'est ainsi que des sous-domaines peuvent être créés, même des domaines autonomes. Cela se fait en configurant un fichier de configuration Apache contenant des directives VirtualHost pour chaque domaine/sous-domaine.
Un exemple de serveur HTTP qui a deux hôtes virtuels, example1.com et example2.com peut ressembler à ceci (définition d'adresse IP):
<VirtualHost 93.184.216.34:80>
ServerName example1.com
ServerAlias www.example1.com
DocumentRoot /var/www/example1.com
</VirtualHost>
<VirtualHost 93.184.216.34:80>
ServerName example2.com
ServerAlias www.example2.com
DocumentRoot /var/www/example2.com
</VirtualHost>
Il peut également ressembler à ceci (définition basée sur le nom):
<VirtualHost *:80>
ServerName example1.com
ServerAlias www.example1.com
DocumentRoot /var/www/example1.com
</VirtualHost>
<VirtualHost *:80>
ServerName example2.com
ServerAlias www.example2.com
DocumentRoot /var/www/example2.com
</VirtualHost>
Dans les deux cas, deux enregistrements d'hôte virtuel sont créés en interne dans la mémoire et utilisés par Apache pour se comparer à l'arrivée d'une demande d'URI.
Lorsqu'un utilisateur tape l'adresse IP via un agent utilisateur, le premier hôte virtuel répertorié dans le fichier de configuration est utilisé comme domaine principal (c'est-à-dire dans ce cas exemple1.com).
Lorsqu'un utilisateur tape un nom de domaine, la demande est envoyée à un réseau DNS Internet public (ICANN) qui fournit l'adresse IP qui lui est associée. Vous vous êtes inscrit à la fois via un registraire de l'ICANN (comme GoDaddy). Vous devez avoir ces deux correctes et donner un peu de temps avant que la propagation ne s'installe sur tous les serveurs DNS du réseau ICANN. De nos jours, cela peut prendre jusqu'à 24 heures.
Lorsque la demande est acheminée vers votre serveur HTTP Apache, l'adresse IP et le nom de domaine sont mis en correspondance avec la liste des enregistrements VirtualHost internes. Lorsqu'elle est trouvée, la racine du document est utilisée pour former le chemin complet du système de fichiers vers la ressource objet pour revenir à l'agent utilisateur. Sinon, un HTTP 404 est envoyé avec tout document d'erreur qui lui est associé.
J'aime utiliser la terminologie "maison".
Vous pouvez très facilement envoyer une lettre à une maison sans nom et elle arrivera à la maison.
Si vous y mettez le nom de la personne, vous l'envoyez au destinataire prévu.
La destination est la même, mais la façon dont elle est gérée lorsqu'elle atteint la maison est différente.
Lorsque vous spécifiez le site, c'est-à-dire www.example.com, le serveur sait comment gérer la demande et à quel hôte il est destiné et à quel site répondre.
Il y a beaucoup de réponses ici avec des détails techniques, mais je pense que l'explication de haut niveau la plus simple est que même si un serveur Web écoute correctement le trafic http sur son adresse IP, le serveur doit généralement être également configuré pour répondre à un nom de domaine particulier, et ce nom doit figurer dans la demande envoyée par le client (c'est-à-dire le navigateur Web)
Je dis "généralement" parce que c'est presque toujours fait de cette façon, mais il existe en fait des méthodes où vous pouvez configurer le serveur http pour répondre si seule l'adresse IP est utilisée.
Le terme clé à rechercher est "hébergement virtuel basé sur le nom".
Les gens veulent allouer plusieurs noms d'hôte au même serveur Web et diffuser un contenu différent pour chaque nom d'hôte. C'est ce qu'on appelle l'hébergement virtuel (à ne pas confondre avec le concept plus récent de machines virtuelles).
Au départ, l'hébergement virtuel était effectué en allouant plusieurs adresses IP au serveur, le serveur pouvait alors envoyer un contenu différent en fonction de l'adresse IP utilisée, mais cela était considéré comme un gaspillage.
Par conséquent, l'en-tête "Host" a été introduit, initialement comme une extension, mais a ensuite été intégré à la spécification http 1.1 en 1997. Cet en-tête spécifie le nom d'hôte demandé par le client. Le serveur peut ensuite diffuser différents contenus en fonction de la valeur de l'en-tête.
Pour réduire les coûts des serveurs Web, de nombreux serveurs Web hébergent plusieurs sites Web. Ils le font en utilisant des hôtes virtuels, ou Vhosts, dans Apache2/nginx/etc. Donc, si vous allez directement à l'adresse IP du site Web, vous obtiendrez très probablement un écran "Apache fonctionne", ou même vous serez redirigé vers le site Web principal du serveur Web.
Un Vhost regarde l'adresse du site Web entrant et la compare aux noms ServerName ou ServerAlias dans les fichiers Vhosts activés. Si l'un d'eux correspond, ce site Web spécifique est chargé.
À moins que le site Web n'ait une charge massive (nombre élevé de visiteurs uniques/pages vues) ou ne génère des applications à forte charge (pensez youtube.com, facebook, etc.), il est probablement plus rentable d'opérer sur un serveur partagé. Ce serait un gaspillage d'argent pour vous procurer un serveur dédié (à partir de 60 $/mois) juste pour exécuter un site de blog Wordpress. Vous feriez mieux d'avoir une plate-forme partagée sur un serveur avec probablement plus de 200 sites Web sur un seul serveur. Les coûts seront de l'ordre de 5 $/mois.
Une autre raison pour cela est le manque d'adresses IP. Il ne reste tout simplement pas assez d'adresses IPv4. Ce n'est qu'en utilisant NAT pour les réseaux domestiques/professionnels et l'utilisation de Vhosts qu'il nous en reste. Même lorsque IPv6 devient le flux principal, les serveurs resteront probablement sur Vhosts (serveur frais).
Une adresse IP dédiée coûte cher, tandis que la création d'un nouveau site Web sur un serveur est essentiellement gratuite.
Ce qui se passe, c'est que la société d'hébergement loue une seule adresse IP qui pointe vers un serveur physique, puis héberge des milliers de sites Web sur cette adresse IP à l'aide de la fonction "hôte virtuel"
Pensez comme un P.O. Boîte, si vous écrivez simplement l'adresse du bureau de poste mais sans le numéro de boîte, le courrier ne sera pas livré.