NGINX vs. Apache : comparaison des architectures et des possibilités de configuration et d’extension

La première version du serveur HTTP Apache a été publiée en 1995 et même aujourd’hui, plus de 20 ans plus tard, le logiciel est toujours une référence comme structure de serveur Web, mais pas sans concurrence pour autant. C’est principalement le serveur Russe NGINX (prononcé Engine-X), un projet open source également, qui gagne des parts de marché à une vitesse fulgurante. Selon le classement Alexa, la plupart des sites Web qui obtiennent de bons résultats sont livrés via NGINX. Un résultat particulièrement douloureux pour Apache, appuyé par les statistiques régulièrement mises à jour de W3Techs.

Non seulement les géants russes de l’Internet tels que les moteurs de recherche Rambler et Yandex, le service de courrier électronique Mail.RU ou le réseau social VK s'appuient sur ce serveur Web léger, mais les fournisseurs internationaux tels que Dropbox, Netflix, WordPress et FastMail.com utilisent également NGINX pour améliorer les performances de leurs services. Le serveur HTTP Apache sera-t-il bientôt obsolète ?

Note

Le serveur HTTP Apache est un projet logiciel qui dépend de la Fondation Apache. Dans le langage économique de la communauté Internet, le nom du serveur Web est généralement abrégé en "Apache". Lorsque nous faisons référence à "Apache" dans la suite de notre article, nous entendons toujours le logiciel et non le fabricant.

Les défis du Web 2.0

Owen Garrett, Head of Products chez Nginx Inc., décrit le serveur Web Apache dans un article de Blog daté du 9 octobre 2015 comme la colonne vertébrale du Web 1.0, soulignant son importance pour le développement de l’Internet au tournant du millénaire. Le grand succès du serveur Web est principalement dû à l’architecture simple du logiciel. Cependant, ceci était basé sur des décisions de conception qui étaient inspirées d’un World Wide Web différent de celui que l’on connait aujourd’hui. Il y a 20 ans, les sites Web étaient beaucoup plus simples, la bande passante était limitée et coûteuse, tandis que le temps de traitement du CPU (processeur ou unité centrale de traitement, central processing unit en anglais) était relativement avantageux.

Aujourd'hui, nous avons affaire à une deuxième génération du Web, et cela se manifeste bien différemment : le nombre d'utilisateurs et le trafic Web mondial s’est multiplié. Il en va de même pour la taille moyenne des pages Web sur le réseau et le nombre de composants qu'un navigateur web doit interroger et rendre pour les afficher aux utilisateurs. Une partie croissante de la communauté Internet a grandi avec les possibilités du Web 2.0 dès le plus jeune âge. Ce groupe d'utilisateurs n'a pas l'habitude d'attendre plusieurs secondes ou même quelques minutes pour qu'une page Web soit chargée.

Ces évolutions représentaient des défis pour le serveur Apache ces dernières années. Owen Garrett attribue cette situation à l’architecture basée sur les processus d’Apache, qui ne peut pas être mise à l’échelle compte tenu de l’augmentation rapide du trafic de volume de données. Cette faiblesse a été l’une des principales motivations du développement de NGINX en 2002, qui a adopté une approche complètement différente avec une architecture événementielle. NGINX nous vient du développeur de logiciels russe Igor Sysoev, qui a adapté le logiciel, utilisé comme un serveur Web, reverse proxy server ou comme proxy email, en particulier pour les besoins du moteur de recherche Russe Rambler.

Nous comparons les deux serveurs Web et discutons des différences architecturales, de la configuration, des options d’extension, de la comptabilité, de la documentation et de l’assistance.

Conseil

Des introductions générales aux serveurs Web open source Apache et NGINX, sur leur installation et configuration, sont disponibles dans notre guide digital.

Différences architecturales

Les serveurs Web Apache et NGINX reposent sur des architectures logicielles fondamentalement différentes. Il existe différents concepts en ce qui concerne la gestion des connexions, l’interprétation des demandes client, du traitement des contenus Web statiques et dynamiques ainsi que pour la configuration.

Gestion des connexions

Les serveurs Web open source Apache et NGINX diffèrent essentiellement par la façon dont ils traitent les demandes Client entrantes (requêtes). Alors qu’Apache est basé sur une architecture orientée sur les processus, la gestion des connexions NGINX repose sur un algorithme de traitement basé sur les évènements. Ceci permet de traiter les demandes de manière à économiser les ressources, même si elles sont reçues simultanément d’un grand nombre de connexions. Ceci est annoncé, entre autres, par les développeurs de NGINX, comme un avantage majeur par rapport au serveur HTTP Apache. Cependant, à partir de la version 2.4, le programme offre également la possibilité d’implémenter des évènements. Les différences se situent donc dans les détails.

Le serveur Web Apache suit une approche dans laquelle chaque requête client est traitée par un processus ou Thread séparé. Ce single threading, le mode d’exploitation original du serveur HTTP Apache, provoque tôt ou tard des problèmes de blocage I/O (ou I/O Blocking pour blocage Input/Output) : les processus qui nécessitent des opérations de lecture ou d’écriture sont exécutés strictement les uns après les autres. Une demande ultérieure reste dans la boucle d’attente jusqu’à ce que l’on réponde à la précédente. Ceci peut être évité en démarrant plusieurs processus de single threading simultanément : une stratégie associée à une consommation élevée de ressources.

Alternativement, on peut utiliser des mécanismes multi-threading. Contrairement au single-threading, où un seul thread est disponible dans chaque processus pour répondre aux demandes Client, le multi-threading permet à plusieurs threads de s’exécuter au sein du même processus. Puisque les threads sous Linux nécessitent moins de ressources en tant que processus, le multi-threading permet de compenser les besoins importants en ressources de l’architecture du serveur HTTP Apache supportée par les processus.

Les mécanismes de traitement parallèle des requêtes Client chez Apache peuvent être intégrés par l’un des trois modules Multi-Processus (MPMs) : mpm_prefork, mpm_worker, mpm_event.

  • mpm_prefork : le module Apache « Prefork » offre une gestion multi-processus sur un mécanisme de Single Threading. Le module crée un processus parent qui fournit un pool de processus enfants. Un thread s’exécute dans chaque processus enfant, ce qui permet de répondre à une demande client à la fois. Tant qu’il y a plus de processus Single Thread (un seul fil de discussion) que de demandes client, les demandes sont traitées simultanément.

    Le nombre de processus single-threading disponibles est défini à l’aide des options de configuration de serveur « MiniSpareServers » et « MaxSpareServers ». Prefork présente les inconvénients de performance du Single Threading mentionnés ci-dessus. Cependant, la grande indépendance de processus distincts est un avantage : si une connexion est perdue en raison d’un processus défectueux, cela n’affecte généralement pas les connexions qui sont traitées dans d’autres processus.
  • mpm_worker: avec le module « Worker », Apache met à disposition des utilisateurs un mécanisme multi-threading pour le traitement parallèle des requêtes Client. Il définit combien de Threads peuvent être lancés par processus, avec l’option de configuration de serveur « ThreadsPerChild ». Le module fournit un thread par connexion TCP. Tant qu’il y a plus de threads disponibles que de demandes Client, les demandes sont traitées en parallèle. Le processus parent (HTTPd) surveille les Threads inactifs.

    Les utilisateurs peuvent utiliser les commandes « MiniSpareThreads » et « MaxSpareThreads » pour définir le nombre de Threads inactifs à partir desquels de nouveaux Threads sont créés ou des Threads en cours d’exécution retirés de la mémoire. Le module Worker nécessite beaucoup moins de ressources que le module Prefork. Cependant, comme les connexions ne sont pas traitées dans des processus séparés, un Thread incorrect peut affecter l’ensemble du processus multi-threading et donc toutes les connexions qui y sont traitées. De plus, Worker et Prefork sont sensibles aux surcharges causées par ce qu’on appelle les connexions keep-alive (voir plus bas).
  • mpm_event : depuis la version 2.4, le serveur HTTP Apache avec Event dispose d’un troisième module multipropcesseur pour la production. Il s’agit d’une variante du module de travail qui répartit la charge entre les Threads démarrés. Pour chaque processus multi-threading, un thread d’écoute est utilisé, qui reçoit les demandes Client entrantes et distribue les tâches connexes aux Threads de travail.

    Le module évènement a été développé pour optimiser le traitement des connexions dites keep-alive, c’est-à-dire des connexions TCP qui sont maintenues pour permettre la transmission d’autres requêtes Client ou de réponses de serveurs. Si le module de travail classique est utilisé, les Threads de travail déjà établis une fois sont bloqués, même si aucune demande autre demande n’est reçue.

    Ceci peut conduire à une surcharge du serveur avec un nombre élevé de connexions keep-alive. Le module évènement, d’autre part, sous-traite la maintenance des connexions keep-alive au fil de discussion de l’auditeur indépendant. Les Threads de travail ne sont donc pas bloqués et sont disponibles pour le traitement des demandes ultérieures.

Le graphique suivant montre une représentation schématique de l'architecture basée sur les processus du serveur Web Apache à l'aide du module Worker :

représentation schématique de l’architecture Apache avec mpm Worker
le module mpm_worker fournit à Apache un mécanisme de multithreading qui permet de traiter en parallèle plusieurs requêtes Client.

Selon le module utilisé, Apache résout le problème de concomitance (concurrency, réponse simultanée à de multiples demandes Client) soit par des processus ou des threads supplémentaires. Les deux stratégies s’accompagnent de Threads supplémentaires. Ceci devient un facteur limitant lors de la mise à l’échelle d’un serveur Apache.

L’énorme manque de ressources de l’approche uni-processus par connexion résulte du fait qu’un environnement d’exécution distinct doit être fourni pour chaque processus supplémentaire. Cela nécessite une allocation du temps CPU et une mémoire séparée. De plus, chaque module Apache qui doit être disponible dans un processus Worker doit être chargé séparément pour chaque processus. Les threads, en revanche, partagent un environnement d’exécution (le programme) et l’espace d’adressage sur la mémoire. La surcharge des Threads supplémentaires est donc considérablement plus faible que celle des processus. Cependant, le multi-threading est également intensif en calcul lorsque des changements de contexte (Context Switches) se produisent.

Un changement de contexte est le processus dans lequel un système passe d'un processus ou d'un thread à un autre. Pour ce faire, le contexte du processus ou du thread fini doit être sauvegardé et le contexte du nouveau processus ou thread doit être créé ou restauré. C’est un processus administratif long et fastidieux, dans lequel les registres CPU et les différents tableaux et listes doivent être chargés et sauvegardés.

Le module mpm_event fournit un mécanisme d’évènement pour le serveur HTTP Apache qui sous-traite le traitement des connexions entrantes à un fil d’écoute, ou Listener-Thread. Ceci permet de mettre fin aux connexions non nécessaires (les connexions Keep-Alive également) et de réduire ainsi la consommation de ressources. Le problème des changements de contexte à forte intensité CPU, se produisant lorsque le Thread de l’auditeur transmet séparément des requêtes à des Threads de travail (Worker Threads), n’est toutefois pas résolu.

L’architecture événementielle de NGINX, d’autre part, permet d’obtenir la simultanéité sans avoir besoin d’un processus ou d’un Thread supplémentaire pour chaque nouvelle connexion. Un seul processus NGINX peut gérer simultanément des milliers de connexions HTTP. Ceci est réalisé par un mécanisme de boucle, appelé Event-loop (boucle d‘événement). Ceci permet aux demandes Client d’être traitées de manière asynchrone au sein d’un même thread.

Conseil

en théorie, NGINX n’a besoin que d’un seul processus de Single-Threading pour traiter les connexions. Pour une utilisation optimale du matériel, toutefois, le serveur Web est en général démarré avec un processus de travail par processeur (CPU) de la machine sous-jacente.

Contrairement au serveur Web Apache, où le nombre de processus actifs ou de Threads ne peut être limité que par des valeurs minimales et maximales, NGINX offre un modèle de processus prévisible qui est parfaitement adapté au matériel. Ceci inclut un processus maître, l’assistant traite le Cache-loader, le gestionnaire de cache, ainsi qu’un certain nombre de processus Worker qui sont définis précisément via la configuration, et ajustés au nombre de cœurs de processeur.

  • Processus maître : le processus maître est un processus de niveau supérieur qui exécute toutes les opérations de base. Il s’agit notamment de la lecture dans la configuration du serveur, de la liaison de port et de la création de tous les types de processus suivants.
     
  • Processus d’aide : NGINX utilise deux processus d’aide à la gestion des Cache : le Cache-loader et le gestionnaire de Cache (Cache-Manager).
    • Cache-Loader: le chargeur de Cache est responsable du chargement du Cache sur disque dur dans la mémoire de travail.
    • Cache-Manager : la tâche du gestionnaire de cache est de s’assurer que les entrées du cache du disque dur ont la taille précédemment configurée, et de les découper si nécessaire. Ce processus est adressé périodiquement.
       
  • Worker-Prozess : les processus de travail sont responsables du traitement des connexions, de l’accès à la lecture sur le disque dur et de la communication avec les serveurs en amont (serveurs qui fournissent des services à d’autres serveurs). Ce sont donc les seuls processus du modèle de processus NGINX qui sont actifs en permanence.

Le graphique suivant montre une représentation schématique du modèle de processus NGINX :

représentation schématique de l’architecture NGINX
L’architecture des processus de NGINX est basée sur les types de processus Master, Worker, Cache Loader et Cache manager

Tous les processus Worker démarrés via le processus maître NGINX dans le cadre de la configuration partagent un ensemble de Listener Sockets (terminaux de communication). Au lieu de démarrer un processus ou un Thread séparé pour chaque connexion entrante, chaque processus Worker exécute une boucle d’évènements qui permet à plusieurs milliers de connexions au sein d’un Thread d’être traitées de manière asynchrone sans bloquer le processus. Pour ce faire, les processus Worker traitent les Listener-sockets en permanence à la recherche d’événements déclenchés par des connexions entrantes, les accepte et exécute les processus de lecture et d’écriture sur Socket lors du traitement HTTP.

NGINX ne fournit pas ses propres mécanismes pour la distribution des connexions aux processus Worker. Au lieu de cela, les fonctions du noyau du système d’exploitation sont utilisées. Les schémas de traitement des requêtes entrantes sont fournis par des automates finis (State Machine) séparées pour HTTP, raw TCP ainsi que SMTP, IMAP et POP3.

Plus généralement, NGINX peut être décrit comme un gestionnaire d’événements qui reçoit des informations sur les événements du noyau et indique au système d’exploitation comment gérer les tâches associées. Le traitement asynchrone des tâches dans la boucle d’événements est basé sur des notifications d’événements, des fonctions de rappel (Callbacks) et des temporisateurs (Timers). Ces mécanismes permettent à un processus Worker de déléguer une opération après l’autre au système d’exploitation sans attendre le résultat d’une opération ou la réponse des programmes Client. NGINX fonctionne comme un orchestrateur pour le système d’exploitation, qui lit et écrit des octets.

Ce type de gestion des connexions ne génère qu’une surcharge minimale pour les connexions supplémentaires. Tout ce dont vous avez besoin est un descripteur de fichier (FD pour File Descriptor) supplémentaire et un minimum de mémoire supplémentaire dans le processus Worker. Toutefois, les modifications de contexte à forte intensité de calcul n’interviennent que si aucun autre événement ne se produit dans une boucle d’événements. Cette efficacité dans le traitement des demandes à travers une variété de connexions prédestine NGINX comme un outil équilibré pour les sites Web très fréquentés tels que WordPRess.com par exemple.

En résumé

avec son architecture événementielle, NGINC offre une alternative à la gestion des connexions par processus du serveur HTTP Apache. Cependant, cette seule caractéristique n’est pas suffisante pour expliquer pourquoi NGINX est si performant dans les différents tests. Depuis la version 2.4, Apache supporte également un mécanisme de traitement basé sur les événements pour les requêtes Client. Lorsque vous comparez des serveurs Web tels qu’Apache et NGINX, faites toujours attention aux modules utilisés dans le test, à la configuration des serveurs Web et aux tâches à maîtriser.

Traitement des contenus Web statiques et dynamiques

NGINX suit également une stratégie différente de celle du serveur HTTP Apache lorsqu’il s’agit de contenu Web dynamique.

En principe, pour délivrer un contenu Web dynamique, un serveur Web doit utiliser un interpréteur capable de traiter un langage de programmation tel que PHP, Perl, Python ou Ruby. Apache fournit plusieurs modules comme mod_php, mod_perl, mod_python ou mod_ruby, qui permettent de charger l‘interpréteur directement dans le serveur Web. Ainsi, Apache lui-même est équipé de la capacité à traiter du contenu Web dynamique créé avec le langage de programmation approprié. Les fonctions de mise à disposition de contenu statique sont déjà implémentées par les modules MPM mentionnés ci-dessus.

NGINX, par contre, ne fournit que des mécanismes de diffusion de contenu Web statique. La mise à disposition de contenu dynamique est confiée à des serveurs d'application spécialisés. Dans ce cas, NGINX fonctionne simplement comme un proxy entre le programme client et le serveur Upsteam. La communication s'effectue via des protocoles tels que HTTP, FastCGI, SCGI, SCGI, uWSGI et Memcached. WebSphere, JBoss ou Tomcat sont des serveurs d'application possibles pour la livraison de contenu dynamique. Cependant, le serveur HTTP Apache peut également être utilisé à cette fin.

Les deux stratégies pour traiter le contenu statique et dynamique ont des avantages et des inconvénients. Un module comme mod_php permet au serveur Web d’exécuter le code PHP lui-même. Un serveur d’application séparé n’est pas nécessaire. Cela rend l’administration de sites Web dynamiques très pratique. Cependant, les modules d’interprétation pour les langages de programmation dynamique doivent être chargés séparément dans chaque processus de travail qui est responsable de la livraison du contenu. Dans le cas d’un grand nombre de processus de travail, ceci s’accompagne de frais généraux importants. NGINX réduit ces frais généraux, car l’interprète externalisé n’est chargé qu’en cas de besoin.

Alors que NGINX est limité à l'interaction avec un interpréteur externe, les deux stratégies sont ouvertes aux utilisateurs d'Apache. Apache peut aussi être placé devant un serveur d'application qui interprète le contenu Web dynamique. En règle générale, le protocole FastCGI est utilisé à cette fin. Une interface correspondante peut être chargée avec le module mod_proxy_proxy_fcgi.

En résumé

Dans notre comparaison, ces deux serveurs Web permettent de livrer des pages Web dynamiques. Mais tandis qu’Apache utilise des modules pour interpréter et exécuter le code lui-même, NGINX sous-traite cette étape à un serveur d’application externe.

Interprétation des requêtes Client

Pour être en mesure de répondre de façon satisfaisante aux demandes des programmes Client (comme les navigateurs Web ou les programmes de courrier électronique), un serveur doit déterminer quelle ressource est demandée et où elle se trouve en fonction de la demande.

Le serveur HTTP Apache a été conçu comme un serveur Web. NGINX, d'autre part, offre à la fois des fonctions de serveur Web et de serveur proxy. Cette différence d'orientation se reflète dans la façon dont le logiciel respectif interprète les demandes Client et alloue les ressources sur le serveur.

Note

le serveur HTTP Apache peut aussi être utilisé comme un serveur proxy en utilisant le module mod_proxy.

Le serveur HTTP Apache et NGINX ont tous deux des mécanismes qui permettent aux requêtes entrantes d’être interprétées soit comme des ressources physiques dans le système de fichiers, soit comme des URI (Uniform Resource Identifiers). Cependant, alors qu’Apache est basé sur les fichiers par défaut, NGINX se concentre sur le traitement URI des requêtes.

Si le serveur HTTP Apache reçoit une requête Client, par défaut, il suppose qu'une ressource spécifique doit être récupérée à partir du système de fichiers du serveur. Comme Apache utilise VirtualHosts pour fournir différents contenus Web sur le même serveur sous différents noms d’hôtes, adresses IP ou numéros de port, il doit d'abord déterminer à quel VirtualHost la requête se réfère. Pour ce faire, le serveur Web compare le nom d’hôte, l’adresse IP et le numéro de port au début de la requête URI avec les VirtualHosts définis dans le fichier de configuration principal HTTPd.conf.

L’exemple de code suivant montre une configuration Apache dans laquelle les deux domaines www.exemple.com et www.autre-exemple.com sont exploités sous la même adresse IP :

NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.exemple.com
ServerAlias exemple.com *.exemple.com
DocumentRoot /data/www/exemple
</VirtualHost>
<VirtualHost *:80>
ServerName www.autre-exemple.com
DocumentRoot /data/www/autre-exemple
</VirtualHost>

L’astérisque (*) sert de caractère de remplacement pour toute adresse IP. Apache décide via un alignement du nom d’hôte contenu dans la requête avec la directive ServerName de quel DocumentRoot (le répertoire de démarrage d'un projet Web) la ressource demandée est recherchée.

Une fois qu’Apache a trouvé le serveur souhaité, l’URL de la requête est mappée au système de fichiers du serveur par défaut. Apache utilise la spécification de chemin continue dans l’URL. En combinaison avec DocumentRoot, il en résulte le chemin d’accès à la ressource

Pour une demande avec requête URL HTTP://www.exemple.org:80/public_html/images/logo.gif, Apache afficherait (sur la base de l’exemple ci-dessus) la ressource désirée en utilisant le chemin de fichier suivant :

/data/www/exemple/public_html/images/logo.gif
Note

Puisque le port standard pour HTTP est le 80, cette spécification est généralement omise dans la pratique.

Apache compare également l’URL de la requête avec des blocs de fichiers et de répertoires optionnels dans la configuration. Ceux-ci vous permettent de définir des instructions spéciales pour les requêtes qui se réfèrent aux fichiers ou répertoires sélectionnés (y compris les sous-répertoires).

L’exemple suivant définit des instructions spéciales pour le répertoire public_html/images et le fichier private.html :

<VirtualHost *:80>
    ServerName www.exemple.com
    ServerAlias exemple.com *.exemple.com
    DocumentRoot /data/www/exemple
      <Directory var/www/exemple.com/public_html/images>
          Order Allow,Deny
          Allow from all
     </Directory> 
      <Files public.html>
          Order Allow,Deny
          Deny from all
      </Files>
</VirtualHost>

En plus de cette procédure standard pour interpréter les requêtes des clients, la directive Alias d'Apache vous permet de spécifier un autre répertoire pour rechercher la ressource demandée au lieu de DocumentRoot. De plus, le serveur HTTP Apache fournit un module appelé mod_rewrite qui permet aux utilisateurs de réécrire ou de rediriger des URL.

Conseil

plus d’informations sur le module mod_rewrite sont disponibles sur l’article de mbase sur Rewrite-Engine

Si vous voulez qu’Apache récupère les ressources qui sont stockées en dehors du système de fichiers du serveur, utilisez la directive Location. Ceci vous permet de définir des instructions pour des URL spécifiques.

Ce qui fait figure d’exception avec Apache est un cas standard avec NGINX. NGINX analyse d’abord l’URL de la requête et l’associe aux blocs de server et location dans la configuration du serveur Web. Ce n’est qu’ensuite qu’une mise en correspondance avec le système de fichiers et la combinaison avec la racine (qui correspond à la racine du document du serveur Apache) est effectuée (si nécessaire).

En utilisant la directive Server, NGINX détermine quel hôte est responsable de répondre à la requête du Client. Le bloc serveur correspond donc à un VirtualHost dans la configuration d'Apache. Pour ce faire, le nom d’hôte, l’adresse IP et le numéro de port de l’URL de la requête sont comparés à tous les blocs de serveur définis dans la configuration de serveur Web. L’exemple de code suivant montre trois blocs serveur dans le fichier de configuration NGINX nginx.conf :

server {
    listen 80;
    server_name example.org www.example.org;
    ...
}
server {
    listen 80;
    server_name example.net www.example.net;
    ...
}
server {
    listen 80;
    server_name example.com www.example.com;
    ...
}
Note

chaque bloc serveur contient généralement une série de blocs de localisation. Dans l’exemple actuel, ceux-ci ont été remplacés par des espaces réservés (…).

L’URL de requête n’est pas comparée avec les blocs de localisation dans un bloc serveur jusqu'à ce que le serveur demandé soit trouvé. NGINX lit les blocs d'emplacement listés et recherche l'emplacement qui correspond le mieux à la requête URI. Chaque bloc d'emplacement contient des instructions spécifiques qui montrent à NGINX comment traiter la requête correspondante.

Les emplacements peuvent être définis comme des préfixes pour un chemin, des correspondances exactes ou des expressions régulières (RegEx). Les modificateurs suivants sont utilisés dans la syntaxe de la configuration de serveur :

Pas de modificateur L'emplacement est interprété comme un préfixe. Toutes les requêtes dont les URL ont le préfixe défini dans la directive location sont considérées comme correspondant à l'emplacement. Si aucun autre emplacement spécifique n'est trouvé, la demande est traitée en fonction des informations contenues dans ce bloc d'emplacement
= L’emplacement est interprété comme une correspondance exacte. Toutes les requêtes dont l'URL correspond exactement à la chaîne de caractères listée dans la directive location sont traitées conformément aux spécifications de ce bloc de localisation.
~ Le lieu est interprété comme une expression régulière. Toutes les requêtes dont l'URL correspond à l'expression régulière sont traitées conformément aux spécifications de ce bloc de localisation. Les majuscules et minuscules sont évaluées pendant le réglage (sensible à la casse).
~* Le lieu est interprété comme une expression régulière. Toutes les requêtes dont l'URL correspond à l'expression régulière sont traitées conformément aux spécifications de ce bloc de localisation. Les majuscules et minuscules ne sont pas évaluées pendant l'ajustement (insensible à la casse).

L'exemple suivant montre trois blocs d'emplacement qui montrent comment traiter les demandes entrantes pour les domaines example.org et www.example.orgserver {

listen 80;
    server_name example.org www.example.org;
    root /data/www;
    location / {
        index index.html index.php;
    }
    location ~* \.(gif|jpg|png)$ {
        expires 30d;
    }
location ~ \.php$ {
        fastcgi_pass localhost:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

Sur la base d'une demande du client avec la demande URL, HTTP://www.example.org:80/logo.gif, NGINX procéderait comme suit pour interpréter les demandes subséquentes et livrer la ressource désirée :

HTTP://www.example.org:80/logo.gif
HTTP://www.example.org:80/index.php

Tout d’abord, NGINX détermine l’emplacement du préfixe le plus spécifique. Pour ce faire, le serveur Web lit tous les emplacements en séquence sans modificateur et s’arrête au premier emplacement qui correspond à la requête. Tous les emplacements marqués avec le modificateur RegEx (~) sont ensuite importés. Ici aussi, le premier coup est appliqué. Si aucun emplacement RegEx approprié n'est trouvé, le serveur Web accède à l'emplacement de préfixe précédemment déterminé comme solution de secours.

Par exemple, la requête URI HTTP://www.example.org:80/logo.gif correspond à la fois au préfixe location / et à l'expression régulière \.(gif|jpg|png)$. NGINX mapperait donc la requête en combinaison avec la racine vers le chemin du fichier /data/www/logo.gif et livrerait la ressource correspondante au Client. L'en-tête Expires spécifie quand une réponse est considérée comme obsolète, dans l'exemple actuel après 30 jours : expire 30d.

La demande de la page PHP avec l'URI HTTP://www.example.org:80/index.php correspond également à l’emplacement du préfixe / et à l’emplacement RegEx ~ \.php$, qui bénéficie d’un traitement préférentiel. NGINX transmet donc la requête à un serveur FastCGI qui écoute sur localhost:9000 et est responsable du traitement du contenu Web dynamique. La directive fastcgi_param définit le paramètre FastCGI SCRIPT_FILENAME à /data/www/index.php. Le fichier s’exécute ensuite sur le serveur uptream. La variable $document_root correspond à la directive root, la variable $fastcgi_script_name à la partie de l’URI qui suit le nom d’hôte et le numéro de port : /index.php.

Cette procédure, à première vue quelque peu compliquée, pour l’interprétation des demandes des clients est due aux différents domaines d'application dans lesquels le NGINX est utilisé. Par rapport à l’approche principalement basée sur les fichiers du serveur HTTP Apache, l’interprétation des requêtes basée sur l'URL permet une plus grande flexibilité lors du traitement de différents modèles de requêtes. Ceci est nécessaire, par exemple, si NGINX fonctionne comme un serveur proxy ou proxy de messagerie plutôt qu'un serveur web.

En résumé

Apache est principalement utilisé comme serveur Web et interprète les requêtes Client principalement basées sur des fichiers. NGINX, d'autre part, fonctionne avec les URIs de manière standard et répond donc aussi à d'autres modèles de demandes.

Configuration

On dit que NGINX offre un énorme avantage de vitesse par rapport au serveur HTTP Apache lors de la livraison de contenu web statique. Ceci s’explique en partie par des différences de configuration.

En plus du fichier de configuration principal HTTPd.conf, le serveur Web Apache offre aux administrateurs l’option d’administration au niveau du répertoire. Les fichiers .htaccess sont utilisés à cette fin. En principe, ces fichiers de configuration décentralisés peuvent être implémentés dans n’importe quel répertoire serveur. Les instructions définies dans un .htaccess se réfèrent à la fois au répertoire contenant le fichier de configuration et à ses sous-répertoires. En pratique, les fichiers .htaccess sont utilisés pour restreindre l’accès aux répertoires à certains groupes d’utilisateurs, configurer la protection par mot de passe et définir des règles pour la navigation dans les répertoires, les messages d'erreur, les redirections ou le contenu alternatif.

Notez que tout cela peut également être configuré de manière centralisée dans le fichier HTTPd.conf. Cependant,.htaccess devient pertinent pour les modèles d'hébergement Web tels que l'hébergement mutualisé, où l'accès au fichier de configuration principal est réservé au fournisseur de services d'hébergement. La configuration décentralisée via.htaccess permet aux utilisateurs d'autoriser l'administration de certaines zones du système de fichiers du serveur, par exemple pour des répertoires de projets sélectionnés, sans leur donner accès à la configuration principale. De plus, les modifications prennent effet immédiatement et sans redémarrage.

NGINX, par contre, n’offre que des options de configuration centrale. Toutes les instructions sont définies dans le fichier nginx.conf. L’accès à ce fichier permet à l’utilisateur de contrôler l'ensemble du serveur. Contrairement à Apache, l’accès administratif ne peut pas être limité à des répertoires sélectionnés. Ceci présente à la fois des avantages et des inconvénients. La configuration centrale de NGINX est moins flexible que le concept du serveur HTTP Apache, mais offre un net avantage en termes de sécurité : les changements de configuration du serveur web ne peuvent être effectués que par des utilisateurs ayant des droits root.

Plus important que l'argument de sécurité : l'inconvénient de performance d'une configuration décentralisée via .htaccess. Déjà dans la documentation du serveur HTTP Apache, les développeurs recommandent de ne pas utiliser .htaccess si l'accès est possible avec HTTPd.conf. La raison à cela est la procédure dans laquelle Apache lit et interprète les fichiers de configuration.

Comme nous l'avons déjà mentionné, Apache suit par défaut un schéma basé sur les fichiers pour répondre aux demandes Client. Puisque l’architecture Apache permet une configuration décentralisée, le serveur Web recherche un fichier .htaccess dans chaque répertoire le long du chemin d’accès au fichier .htaccess sur son chemin vers la ressource demandée. Tous les fichiers de configuration qu'il passe sont lus et interprétés, un schéma qui ralentit considérablement le serveur web.

Note

En principe, les administrateurs d’Apache sont libres de décider s'ils veulent utiliser les options de configuration décentralisée du serveur web et accepter les avantages et inconvénients associés. Dans la documentation, les développeurs soulignent que toutes les configurations .htaccess peuvent également être faites en utilisant des blocs de répertoire dans la configuration principale HTTPd.conf.

Les utilisateurs qui veulent désactiver ou restreindre la configuration décentralisée sous Apache utilisent la directive AllowOverride dans les blocs de répertoire du fichier de configuration principal HTTPd.conf et la mettent à None. Ceci demande au serveur web d'ignorer tous les fichiers .htaccess dans les répertoires correctement configurés.

<VirtualHost *:80>
    ServerName example.com;
    ...
    DocumentRoot /data/www/example
      <Directory /data/www/example>
        AllowOverride None
        ...
      </Directory>
    ...
</VirtualHost>

L‘exemple de configuration demande au serveur Web d’ignorer tous les fichiers .htaccess pour l’hôte example.com.

En résumé

Contrairement à NGINX, qui n'est configuré que de manière centralisée, Apache, avec .htaccess, offre la possibilité d'une configuration décentralisée, basée sur des répertoires. Si des fichiers .htaccess sont utilisés, le serveur Web perd de la vitesse.

Possibilités d‘extensions

Dans notre comparaison, les deux serveurs Web reposent sur un système modulaire dans lequel le logiciel de base peut être complété par des composants supplémentaires si nécessaire. Cependant, jusqu’à la version 1.9.10, NGINX poursuivait une stratégie fondamentalement différente de celle de ses concurrents en ce qui concerne les modules.

Le serveur HTTP Apache offre deux façons d’étendre le logiciel de base. Les modules peuvent être compilés dans les fichiers binaires Apache pendant le développement ou chargés dynamiquement et donc au moment de l'exécution.

ON distingue trois catégories de modules Apache :

  • Modules de base : les modules de base d’Apache comprennent tous les composants qui fournissent une fonctionnalité de base du serveur Web.
  • Modules d’extensions : ces extensions sont des modules de la Fondation Apache, qui sont inclus dans la distribution Apache. Pour un aperçu de tous les modules inclus dans l’installation standard d’Apache 2.4, voir la documentation d'Apache.
  • Module de fournisseur tiers : ces modules ne sont pas fournis par la Fondation Apache, mais par des fournisseurs de services externes ou des programmeurs indépendants.

Avec NGINX, cependant, la modularité a longtemps été limitée aux composants d’extension statiques qui devaient être compilés dans le fichier binaire du noyau logiciel. Surtout pour les utilisateurs qui n'étaient pas habitués à gérer leurs propres composants logiciels sans le gestionnaire de paquets de la distribution respective, ce type d'extension logicielle limitait clairement la flexibilité du serveur web. L’équipe de développement a amélioré ce point : depuis la version 1.9.11 supporte des mécanismes qui permettent aux modules statiques d'être convertis en modules dynamiques afin qu'ils puissent être chargés via des fichiers de configuration pendant l'exécution. Dans les deux cas, l'API du module du serveur est utilisée.

Veuillez noter que tous les modules NGINX ne peuvent pas être convertis en modules dynamiques. Les modules qui patchent le code source du logiciel serveur ne doivent pas être chargés dynamiquement. De plus, NGINX limite, dans les paramètres standards, le nombre de modules dynamiques pouvant être chargés simultanément à 128. Pour augmenter cette limite, définissez la constante pour NGX_MAX_DYNAMIC_MODULES dans le code source NGINX à la valeur souhaitée.

En plus des modules officiels de la documentation du NGINX, les utilisateurs ont accès à divers modules tiers.

En résumé

les deux serveurs Web peuvent être étendus de manière modulaire. En plus des modules statiques, des modules dynamiques sont disponibles, qui peuvent être chargés dans le programme en cours d'exécution si nécessaire.

Documentation et assistance

Les deux projets logiciels sont bien documentés et fournissent aux utilisateurs des informations de première main via des wikis et des blogs.

Alors que la documentation du NGINX n’est accessible qu’en anglais et en russe, le projet Apache se caractérise par des documents d’information dans de nombreuses versions linguistiques. Cependant, certaines d'entre elles sont dépassées, il est donc indispensable de jeter un coup d'œil à la documentation en anglais.

Les utilisateurs peuvent obtenir de l'aide pour résoudre des problèmes dans les deux projets open source par l'intermédiaire de la communauté. Les listes de mailing servent de forum de discussion.

Des plans de publication et des feuilles de route transparents donnent aux utilisateurs la possibilité de s’adapter aux développements futurs. Les bugs logiciels et les failles de sécurité dans les deux projets sont enregistrés et corrigés dans un rapport public des bugs.

En plus du projet open source NGINX, Nginx, Inc. offre le produit commercial NGINX Plus. Moyennant des frais d'utilisation annuels, les utilisateurs peuvent obtenir des fonctions supplémentaires et un soutien professionnel du fabricant. Une matrice de comparaison des deux produits se trouve sur le site Web de NGINX.

Il n’existe pas d’édition commerciale du serveur HTTP Apache. Toutefois, des services d’assistance payants sont offerts par divers fournisseurs tiers.

En résumé

les serveurs HTTP Apache et NGINX sont tous deux suffisamment documentés pour une utilisation professionnelle.

Compatibilité et écosystème

Le serveur HTTP Apache façonne le World Wide Web depuis plus de deux décennies et demeure la norme de facto pour la diffusion de contenu Web en raison de sa part de marché. NGINX peut également jeter un regard en arrière sur une histoire à succès longue de 15 ans. Les deux serveurs Web sont caractérisés par une large prise en charge des plateformes. Bien qu’Apache soit recommandé pour tous les systèmes d’exploitation unixoid et Windows, la documentation NGINX énumère les systèmes suivants comme étant testés : FreeBSD, Linux, Solaris, IBM AIX, HP-UX, macOS et Windows.

En tant que serveur standard, Apache est largement compatible avec des projets tiers. Tous les standards web pertinents peuvent être intégrés par le biais de modules. En outre, un grand nombre de joueurs en ligne sont familiers avec les concepts d'Apache. Les administrateurs et les développeurs Web mettent généralement en œuvre leurs premiers projets sur des plates-formes d'hébergement mutualisé à faible coût. La plupart d'entre eux sont basés sur Apache et la possibilité de configuration décentralisée via .htaccess. De plus, le serveur HTTP Apache fait partie de plusieurs progiciels de développement et de test de logiciels open source tels que XAMPP ou AMPPS.

NGINX offre également aux utilisateurs un large écosystème de modules. De plus, l’équipe de développement entretient des partenariats avec divers projets de logiciels libres et propriétaires ainsi qu’avec des fournisseurs de services d’infrastructure tels qu’Amazon Web Services, Windows Azure et HP.

En résumé

les deux serveurs Web sont bien établis et proposent un vaste écosystème à leurs utilisateurs. Comparé à NGINX, Apache présente l’avantage de disposer d’une grande communauté d'utilisateurs, formée au fil des années, qui s'est familiarisée avec les bases du serveur Web. Le fait que des milliers d'administrateurs ont vérifié et amélioré le code source du logiciel ne joue pas seulement en faveur de la sécurité du serveur Web, mais a également pour conséquence que les nouveaux utilisateurs bénéficient de l’aide des nombreux administrateurs Apache expérimentés en cas de problème, dans les forums ou via des listes de diffusion.

NGINX vs. Apache : aperçu des différences

Malgré des différences dans l'architecture logicielle, les deux serveurs Web offrent des fonctions similaires. Apache et NGINX sont utilisés dans des scénarii similaires, mais chacun utilise ses propres stratégies et concepts pour répondre aux exigences spécifiques. Le tableau suivant compare les deux projets logiciels en utilisant des fonctions centrales.

Caractéristiques Apache NGINX
Fonction Serveur Web Serveur Proxy Serveur Web Serveur Proxy Email-Proxy Load-Balancer (répartiteur de charge)
Langue de programmation C C
Système d‘exploitation Toutes les plateformes Unixoid Windows FreeBSD Linux Solaris IBM AIX HP-UX macOS Windows
Publication 1995 2002
Licence Apache License v2.0 BSD-License (Berkeley Software Distribution)
Développeur Apache Software Foundation Nginx, Inc.
Architecture logicielle Basé sur processus/thread Basé sur des événements
Simultanéité Multi-Processing Multi-Threading Event-Loop (boucle d’événements)
Contenus Web statiques Oui Oui
Contenus Web dynamiques Oui Non
Interpretation de requêtes Client Basé sur un fichier primaire Basé sur URI
Konfiguration Configuration centrale via HTTPd.conf Configuration décentralisée via via .htaccess   Configuration centrale via nginx.conf
Erweiterungsmöglichkeiten Modules statiques Modules dynamiques Modules statiques Modules dynamiques
Dokumentation Allemand Anglais Danois Espagnol Français Japonais Coréen Portuguais Turc Mandarin Anglais
Assistance développeurs Non Oui (payant via Nginx, Inc.)
Community-Support Listes Mailing Wiki Listes Mailing Wiki

Bilan

Avec Apache et NGINX, les utilisateurs disposent de deux projets open source stables et sécurisés. Cependant, ni l’un ni l’autre des deux serveurs Web ne sort vainqueur de cette comparaison. Les deux projets sont basés sur des décisions de conception fondamentalement différentes, qui apportent des avantages ou des inconvénients en fonction de l'utilisation du logiciel.

Le serveur HTTP Apache offre un immense répertoire de modules qui, avec les options de configuration flexibles, ouvre de nombreux champs d’application pour le logiciel. Le serveur Web est considéré comme un logiciel standard pour les scénarii d’hébergement mutualisé et continuera à se défendre contre les serveurs Web légers tels que NGINX dans ce segment d'activité. La possibilité d'intégrer des interprètes pour des langages de programmation tels que PHP, Perl, Python ou Ruby directement dans le serveur Web via des modules permet de livrer du contenu web dynamique sans serveur d’application séparé. Cela fait du serveur HTTP Apache une solution pratique pour les sites Web de petite et moyenne taille où le contenu est généré dynamiquement pendant la récupération.

NGINX, en revanche, n’offre aucune possibilité de traiter du contenu Web dynamique en natif ou d'intégrer les interprètes correspondants par modules. Un serveur d'application séparé est donc toujours nécessaire. Ceci peut sembler être un effort supplémentaire inutile pour les sites Web de petite à moyenne taille. Cependant, une telle structure montre ses forces dans les grands projets Web et l'augmentation des volumes de trafic.

NGINX est généralement utilisé en tant qu'équilibreur de charge face à un groupe de serveurs d'applications. L’équilibreur de charge reçoit les demandes entrantes et, selon le type de demande, décide si elle doit être transmise à un serveur spécialisé en arrière-plan. Le contenu Web statique est livré directement par NGINX. Cependant, si un client demande du contenu dynamique, l’équilibreur de charge transmet la demande à un serveur d’application dédié. Celui-ci interprète le langage de programmation, assemble le contenu demandé dans une page Web et le renvoie à l’équilibreur de charge qui, à son tour, le livre au client. De cette façon, les volumes de trafic élevés peuvent être gérés efficacement.

De plus, NGINX met en cache le contenu déjà livré pendant une certaine période de temps, de sorte que le contenu dynamique demandé à nouveau peut être livré directement à partir de l'équilibreur de charge sans que NGINX ait à accéder à nouveau à un serveur d'application.

L’avantage de l’externalisation de l’interpréteur à un ou plusieurs serveurs backend séparés est que le réseau de serveurs peut facilement être mis à l'échelle en ajoutant des serveurs backend supplémentaires ou en désactivant des systèmes qui ne sont pas nécessaires. Dans la pratique, de nombreux utilisateurs s'appuient sur la combinaison de NGINX et d'Apache pour une telle configuration et utilisent donc les points forts des deux serveurs Web.

Cet article vous a-t-il été utile ?