Moi qui aime toujours savoir pourquoi… et c’est quoi le mieux… entre 2 trucs j’arrive a fair un choix mais la ufffffffffff
Fonctionnement de plusieurs serveurs virtuels par nom sur une seule adresse IP.
Serveurs virtuels par nom sur plus d’une seule adresse IP.
Servir le même contenu sur des adresses IP différentes (telle qu’une adresse interne et une externe).
Servir différents sites sur différents ports.
Hébergement virtuel basé sur IP
Hébergements virtuels mixtes basés sur les ports et sur les IP
Hébergements virtuels mixtes basé sur les noms et sur IP
Utilisation simultanée de Virtual_host et de mod_proxy
Utilisation de serveurs virtuels _default_
Migration d’un serveur virtuel par nom en un serveur virtuel par IP
Utilisation de la directive ServerPath
Si vous avez un conseil pour une solution la plus courante et efficace…
Sauf si tu trouves un moyen d’avoir d’autres adresses IP publiques (VPN, IPv6…)
C’est les deux. Tu pourrais servir des sites différents ayant le même nom sur des ports différents.
Utiliser plusieurs ports si ce n’est pas nécessaire, c’est chercher les ennuis : un seul sera le port standard (80 en HTTP, 443 en HTTPS) or certains proxys filtrants et pare-feu n’autorisent les connexions que sur les ports standard.
D’un autre côté, il y a des raisons historiques à l’utilisation de plusieurs ports quand on doit servir plusieurs sites avec une seule adresse IP.
En HTTP/1.0, le client ne transmet pas l’en-tête « Host » qui contient le nom du site demandé (correspondant au ServerName d’Apache). Ce n’est apparu qu’en HTTP/1.1. Les clients et serveurs HTTP/1.0 ne doivent plus courir les rues, mais qui sait…
En HTTPS, le serveur doit présenter un certificat pour s’authentifier avant l’envoi de la requête HTTP contenant le nom du site. Or ce certificat doit mentionner le nom du site. Pour servir plusieurs sites, il fallait donc utiliser soit :
une adresse IP par site
un port par site
un certificat contenant les noms de tous les sites (compliqué si ces noms sont gérés par des autorités distinctes).
Pour éviter ces contraintes, une extension ultérieure du protocole HTTPS appelée SNI (Server Name Indication), a permis au client de transmettre au serveur le nom du site avant la négociation TLS, à condition que le client et le serveur le supportent,. C’est le cas des versions récentes d’Apache et des gros navigateurs comme Firefox ou Chrome.