Détails sur le fonctionnement des serveurs virtuels

Langues Disponibles: en | + fr | + ko | + tr

+ + +

Ce document vise à expliquer dans le détail comment le serveur + HTTP Apache procède lors du choix de l'utilisation + d'un serveur virtuel en fonction d'une requête reçue.

+ +

Il est recommandé de lire la documentation + Serveurs virtuels à base de nom et serveurs virtuels à base + d'adresse IP pour déterminer quel type de serveur virtuel nous + convient le mieux, puis de lire les documentations serveurs virtuels à base de nom ou serveurs virtuels à base d'adresse IP, et enfin + d'étudier quelques exemples.

+ +

Si vous voulez entrer dans les détails, vous pouvez revenir vers + cette page.

+ +

Fichier de configuration
Choix du serveur virtuel
Trucs et astuces

Voir aussi

Fichier de configuration

+ +

Un serveur principal (main_server) contient toutes + les définitions qui apparaissent en dehors des sections + <VirtualHost>.

+ +

Les serveurs virtuels, aussi + appelés vhosts (pour virtual hosts), sont définis par les + sections <VirtualHost>.

+ +

Chaque directive VirtualHost comporte une ou + plusieurs adresses et des ports optionnels.

+ +

Il est possible d'utiliser des noms d'hôtes dans la définition + d'un serveur virtuel, mais ils seront résolus en adresses IP au + démarrage du serveur, et si une résolution de nom échoue, cette + définition de serveur virtuel sera ignorée. Cette méthode est par + conséquent déconseillée.

+ +

L'adresse peut + être spécifiée sous la forme *, ce qui conviendra à la + requête si aucun autre serveur virtuel ne possède l'adresse IP + explicite correspondant à celle de la requête.

+ +

L'adresse qui apparaît dans la directive VirtualHost + peut être associée à un port optionnel. Si aucun port n'est + spécifié, il s'agit d'un port générique qui peut aussi être spécifié + comme *. Le port générique correspond à toutes les + valeurs de port.

+ +

(Il ne faut pas confondre les numéros de port sur lesquels Apache + est en écoute avec les numéros de port spécifiés dans la directive + VirtualHost ; ces derniers ne servent qu'à définir le + serveur virtuel qui sera sélectionné pour traiter la + requête. Pour définir les ports sur lesquels Apache est en écoute, + utilisez la directive Listen). +

+ +

L'ensemble des adresses (y compris les résultats multiples + A issus des requêtes DNS) est appelé jeu + d'adresses du serveur virtuel.

+ +

Apache fait automatiquement sa sélection à partir de l'en-tête + HTTP Host fourni par le client, lorsque la + correspondance la plus exacte du point de vue adresse IP/port a lieu + pour plusieurs serveurs virtuels.

+ +

La directive ServerName peut + apparaître en quelque endroit de la définition d'un serveur. + Cependant, chaque occurrence écrase la précédente (pour ce serveur). + Si aucune directive ServerName n'est spécifiée, le + serveur tente de déterminer le nom du serveur à partir de l'adresse + IP.

+ +

Le premier serveur virtuel à base de nom apparaissant dans le + fichier de configuration pour une paire IP:port donnée est + significatif car c'est lui qui sera utilisé pour toutes les requêtes + reçues sur cette adresse IP/port et pour laquelle aucun autre + serveur virtuel ne possède un ServerName ou un ServerAlias + correspondant. Il sera aussi utilisé pour toutes les connexions SSL + si le serveur ne supporte pas l'Indication du nom du serveur.

+ +

Tous les noms spécifiés au sein d'une section + VirtualHost sont traités comme un + ServerAlias (sans caractères génériques), mais ne sont + écrasés par aucune directive ServerAlias.

+ +

Pour chaque serveur virtuel, diverses valeurs sont initialisées + par défaut. En particulier :

+ +

Dans le cas où un serveur virtuel ne contient pas de directives + ServerAdmin, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + ReceiveBufferSize, + ou SendBufferSize, + alors la valeur de chacun de ces paramètres est héritée de celle du + serveur principal. (C'est à dire, héritée de la valeur finale après + lecture de la configuration du serveur principal.)
Les permissions par défaut sur les répertoires de chaque + serveur virtuel sont assemblées avec celles du serveur principal. + Elles concernent également toutes les informations de configuration + par répertoire pour tous les modules.
Les configurations par serveur pour chaque module sont assemblées + à partir de celles du serveur principal.

+ +

L'essentiel des valeurs de configuration des serveurs virtuels + provient de valeurs par défaut issues du serveur principal. + Mais la position dans le fichier de configuration des directives + du serveur principal n'a pas d'importance -- l'ensemble de la + configuration du serveur principal est lu avant que ces valeurs par + défaut soient appliquées aux serveur virtuels. Ainsi, même si la + définition d'une valeur apparaît après celle d'un serveur virtuel, + cette valeur peut affecter la definition du serveur virtuel.

+ +

Dans le cas où le serveur principal n'a pas de ServerName + à ce stade, le nom de la machine sur laquelle tourne le programme + httpd est utilisé à sa place. Nous appellerons + jeu d'adresses du serveur principal les adresses IP + renvoyées par une résolution DNS sur le ServerName + du serveur principal.

+ +

Pour tous les champs ServerName non définis, dans + le cas d'une configuration en serveur virtuel par nom, la valeur + adoptée par défaut est la première adresse donnée dans la section + VirtualHost qui définit le serveur virtuel.

+ +

Si un serveur virtuel contient la valeur magique + _default_, il fonctionne sur le même ServerName + que le serveur principal.

+ +

Choix du serveur virtuel

+ +

À la réception d'une requête, le serveur procède comme suit pour + déterminer quel serveur virtuel utiliser :

+ +

Recherche de l'adresse IP

+ +

Lors d'une première connexion sur une adresse/port, le serveur + recherche toutes les directives VirtualHost qui + possèdent la même adresse IP/port.

+ +

S'il n'y a aucune correspondance exacte pour cette adresse/port, + la recherche s'effectue sur la valeur générique (*).

+ +

Si aucune correspondance n'est enfin trouvée, la requête sera + servie par le serveur principal.

+ +

S'il existe des définitions VirtualHost pour + l'adresse IP, l'étape suivante consiste à déterminer si nous avons à + faire à un serveur virtuel à base de nom ou d'adresse IP.

+ + + +

Serveur virtuel par IP

+ +

Si une seule section VirtualHost présente la + meilleure correspondance avec la paire adresse IP/port, aucune + action n'est entreprise et la requête est + traitée par le serveur virtuel qui correspond.

+ + + +

Serveur virtuel par nom

+ +

Si plusieurs sections VirtualHost présentent la + meilleure correspondance avec la paire adresse IP/port, le terme + "liste" dans les étapes suivantes fait référence à la liste des + serveurs virtuels qui correspondent, selon l'ordre dans lequel ils + apparaissent dans le fichier de configuration.

+ +

Si la connexion utilise SSL, si le serveur supporte l'Indication de nom de serveur, + et si la négociation du client SSL inclut l'extension TLS dans le + nom d'hôte requis, alors ce nom d'hôte sera utilisé par la suite, tout + comme un en-tête Host: aurait été utilisé dans le cas + d'une connexion non-SSL. Si ces conditions ne sont pas réunies, le + premier serveur virtuel à base de nom dont l'adresse correspond sera + utilisé pour les connexions SSL. Ceci est important car c'est le + serveur virtuel qui détermine quel certificat le serveur va utiliser + pour la connexion.

+ +

Si la requête contient un en-tête Host:, on + recherche dans la liste le premier serveur virtuel dont le + ServerName ou le ServerAlias correspond, + et c'est celui-ci qui va traiter la requête. Un en-tête + Host: peut comporter un numéro de port mais Apache + l'ignore systématiquement et utilise toujours le + port sur lequel il a effectivement reçu la requête.

+ +

Le premier serveur virtuel du fichier de configuration qui + possède l'adresse spécifiée est prioritaire et intercepte toutes les + requêtes à destination d'un nom de serveur inconnu, ou toute requête + sans en-tête Host: (comme les requêtes HTTP/1.0).

+ + + +

Connexions persistantes

+ +

La recherche par adresse IP décrite ci-avant n'est faite + qu'une fois pour chaque session TCP/IP, alors que la + recherche par nom est réalisée pour chaque requête au + cours d'une connexion persistante (KeepAlive). En d'autres termes, + il est possible pour un client de faire des requêtes sur + différents serveurs virtuels par nom, au cours d'une unique + connexion persistante.

+ + + +

URI absolu

+ +

Au cas où l'URI de la requête est absolu, et que son nom de + serveur et son port correspondent au serveur principal (ou l'un + des serveurs virtuels configurés), et qu'ils correspondent + à l'adresse et au port de la requête, alors l'URI est amputé + de son préfixe protocole/nom de serveur/port et traité par le + serveur correspondant (principal ou virtuel). Si cette correspondance + n'existe pas, l'URI reste inchangé et la requête est considérée + comme une requête d'un serveur mandataire (proxy).

+ + +

Observations

+ +

La sélection d'un serveur virtuel en fonction de son nom est + un processus qui intervient après la sélection par le serveur du + serveur virtuel qui correspond le mieux du point de vue adresse + IP/port.
Si vous ne tenez pas compte de l'adresse IP à laquelle le + client s'est connecté, indiquez un caractère "*" comme adresse + pour tous les serveurs virtuels, et la sélection du serveur + virtuel en fonction du nom s'appliquera alors à tous les serveurs + virtuels définis.
Les vérifications sur ServerName et + ServerAlias ne sont jamais + réalisées pour les serveurs virtuels par IP.
Seul l'ordre des serveurs virtuels par nom + pour une adresse donnée a une importance. Le serveur virtuel + par nom qui est présent en premier dans la configuration se + voit attribué la priorité la plus haute pour les requêtes + arrivant sur son jeu d'adresses IP.
Le numéro de port contenu dans l'en-tête Host: n'est jamais utilisé + pour les tests de correspondances. Apache ne prend en compte + que le numéro de port sur lequel le client a envoyé la requête.
Si deux serveurs virtuels partagent la même adresse, la + sélection se fera implicitement sur le nom. Il s'agit d'une + nouvelle fonctionnalité de la version 2.3.11.
Le serveur principal ne sert les requêtes que + lorsque l'adresse IP et le port demandés par le client ne + correspondent à aucun serveur virtuel (y compris un serveur + virtuel *). En d'autres termes, le serveur + principal n'est utile que pour les combinaisons adresse/port + non spécifiées (sauf quand un serveur virtuel _default_ + correspond au port).
Il ne faut jamais employer de noms DNS dans des directives + VirtualHost, car cela oblige le serveur a s'appuyer + sur le DNS au moment du démarrage. De plus, vous vous exposez + à des problèmes de sécurité si vous n'avez pas la maîtrise du + DNS pour la totalité de vos domaines. Voir la documentation + disponible ici, ainsi que + les deux points précisés ci-après.
Un nom de serveur ServerName devrait toujours + être indiqué pour chaque serveur virtuel. Sans cela, une + résolution DNS est nécessaire pour chaque serveur virtuel.

+ + +

Trucs et astuces

+ +

En plus des points évoqués sur la page des + problèmes liés au DNS, + voici quelques points intéressants :

+ +

Toujours positionner les définitions relatives au serveur + principal avant toute définition VirtualHost. + (Ceci améliore grandement la lisibilité de la configuration + -- la manière dont la configuration est interprétée après la + lecture des fichiers ne met pas en évidence le fait que les + définitions positionnées avant et surtout après les serveurs + virtuels peuvent impacter le fonctionnement de tous les + serveurs virtuels.)

+ +