NGINX vs. Apache : com­pa­rai­son des ar­chi­tec­tures et des pos­si­bi­li­tés de con­fi­gu­ra­tion 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 con­cur­rence pour autant. C’est prin­ci­pa­le­ment le serveur Russe NGINX (prononcé Engine-X), un projet open source également, qui gagne des parts de marché à une vitesse ful­gu­rante. Selon le clas­se­ment Alexa, la plupart des sites Web qui ob­tien­nent de bons résultats sont livrés via NGINX. Un résultat par­ti­cu­liè­re­ment dou­lou­reux pour Apache, appuyé par les sta­tis­tiques ré­gu­liè­re­ment 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 élec­tro­nique Mail.RU ou le réseau social VK s'ap­puient sur ce serveur Web léger, mais les four­nis­seurs in­ter­na­tio­naux tels que Dropbox, Netflix, WordPress et FastMail.com utilisent également NGINX pour améliorer les per­for­mances de leurs services. Le serveur HTTP Apache sera-t-il bientôt obsolète ?

Les serveurs Web Apache et NGINX reposent sur des ar­chi­tec­tures lo­gi­cielles fon­da­men­ta­le­ment dif­fé­rentes. Il existe dif­fé­rents concepts en ce qui concerne la gestion des con­nexions, l’in­ter­pré­ta­tion des demandes client, du trai­te­ment des contenus Web statiques et dy­na­miques ainsi que pour la con­fi­gu­ra­tion.

Selon le module utilisé, Apache résout le problème de con­co­mi­tance (con­cur­rency, réponse si­mul­ta­née à de multiples demandes Client) soit par des processus ou des threads sup­plé­men­taires. Les deux stra­té­gies s’ac­com­pag­nent de Threads sup­plé­men­taires. Ceci devient un facteur limitant lors de la mise à l’échelle d’un serveur Apache.

L’énorme manque de res­sources de l’approche uni-processus par connexion résulte du fait qu’un en­vi­ron­ne­ment d’exécution distinct doit être fourni pour chaque processus sup­plé­men­taire. Cela nécessite une al­lo­ca­tion du temps CPU et une mémoire séparée. De plus, chaque module Apache qui doit être dis­po­nible dans un processus Worker doit être chargé sé­pa­ré­ment pour chaque processus. Les threads, en revanche, partagent un en­vi­ron­ne­ment d’exécution (le programme) et l’espace d’adressage sur la mémoire. La surcharge des Threads sup­plé­men­taires est donc con­si­dé­ra­ble­ment plus faible que celle des processus. Cependant, le multi-threading est également intensif en calcul lorsque des chan­ge­ments de contexte (Context Switches) se pro­dui­sent.

Un chan­ge­ment 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 sau­ve­gardé et le contexte du nouveau processus ou thread doit être créé ou restauré. C’est un processus ad­mi­nis­tra­tif long et fas­ti­dieux, dans lequel les registres CPU et les dif­fé­rents tableaux et listes doivent être chargés et sau­ve­gar­dés.

Le module mpm_event fournit un mécanisme d’évènement pour le serveur HTTP Apache qui sous-traite le trai­te­ment des con­nexions entrantes à un fil d’écoute, ou Listener-Thread. Ceci permet de mettre fin aux con­nexions non né­ces­saires (les con­nexions Keep-Alive également) et de réduire ainsi la con­som­ma­tion de res­sources. Le problème des chan­ge­ments de contexte à forte intensité CPU, se pro­dui­sant lorsque le Thread de l’auditeur transmet sé­pa­ré­ment des requêtes à des Threads de travail (Worker Threads), n’est toutefois pas résolu.

L’ar­chi­tec­ture évé­ne­men­tielle de NGINX, d’autre part, permet d’obtenir la si­mul­ta­néité sans avoir besoin d’un processus ou d’un Thread sup­plé­men­taire pour chaque nouvelle connexion. Un seul processus NGINX peut gérer si­mul­ta­né­ment des milliers de con­nexions 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 asyn­chrone au sein d’un même thread.

Tous les processus Worker démarrés via le processus maître NGINX dans le cadre de la con­fi­gu­ra­tion partagent un ensemble de Listener Sockets (terminaux de com­mu­ni­ca­tion). 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è­ne­ments qui permet à plusieurs milliers de con­nexions au sein d’un Thread d’être traitées de manière asyn­chrone sans bloquer le processus. Pour ce faire, les processus Worker traitent les Listener-sockets en per­ma­nence à la recherche d’évé­ne­ments dé­clen­chés par des con­nexions entrantes, les accepte et exécute les processus de lecture et d’écriture sur Socket lors du trai­te­ment HTTP.

NGINX ne fournit pas ses propres mé­ca­nismes pour la dis­tri­bu­tion des con­nexions aux processus Worker. Au lieu de cela, les fonctions du noyau du système d’ex­ploi­ta­tion sont utilisées. Les schémas de trai­te­ment 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é­ra­le­ment, NGINX peut être décrit comme un ges­tion­naire d’évé­ne­ments qui reçoit des in­for­ma­tions sur les évé­ne­ments du noyau et indique au système d’ex­ploi­ta­tion comment gérer les tâches associées. Le trai­te­ment asyn­chrone des tâches dans la boucle d’évé­ne­ments est basé sur des no­ti­fi­ca­tions d’évé­ne­ments, des fonctions de rappel (Callbacks) et des tem­po­ri­sa­teurs (Timers). Ces mé­ca­nismes per­met­tent à un processus Worker de déléguer une opération après l’autre au système d’ex­ploi­ta­tion sans attendre le résultat d’une opération ou la réponse des pro­grammes Client. NGINX fonc­tionne comme un or­ches­tra­teur pour le système d’ex­ploi­ta­tion, qui lit et écrit des octets.

Ce type de gestion des con­nexions ne génère qu’une surcharge minimale pour les con­nexions sup­plé­men­taires. Tout ce dont vous avez besoin est un des­crip­teur de fichier (FD pour File Des­crip­tor) sup­plé­men­taire et un minimum de mémoire sup­plé­men­taire dans le processus Worker. Toutefois, les mo­di­fi­ca­tions de contexte à forte intensité de calcul n’in­ter­vien­nent que si aucun autre événement ne se produit dans une boucle d’évé­ne­ments. Cette ef­fi­ca­cité dans le trai­te­ment des demandes à travers une variété de con­nexions pré­des­tine NGINX comme un outil équilibré pour les sites Web très fré­quen­tés tels que WordPRess.com par exemple.

NGINX suit également une stratégie dif­fé­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 in­ter­pré­teur capable de traiter un langage de pro­gram­ma­tion tel que PHP, Perl, Python ou Ruby. Apache fournit plusieurs modules comme mod_php, mod_perl, mod_python ou mod_ruby, qui per­met­tent de charger l‘in­ter­pré­teur di­rec­te­ment dans le serveur Web. Ainsi, Apache lui-même est équipé de la capacité à traiter du contenu Web dynamique créé avec le langage de pro­gram­ma­tion approprié. Les fonctions de mise à dis­po­si­tion de contenu statique sont déjà im­plé­men­tées par les modules MPM men­tion­nés ci-dessus.

NGINX, par contre, ne fournit que des mé­ca­nismes de diffusion de contenu Web statique. La mise à dis­po­si­tion de contenu dynamique est confiée à des serveurs d'ap­pli­ca­tion spé­cia­li­sés. Dans ce cas, NGINX fonc­tionne sim­ple­ment comme un proxy entre le programme client et le serveur Upsteam. La com­mu­ni­ca­tion s'ef­fec­tue via des pro­to­coles tels que HTTP, FastCGI, SCGI, SCGI, uWSGI et Memcached. WebSphere, JBoss ou Tomcat sont des serveurs d'ap­pli­ca­tion possibles pour la livraison de contenu dynamique. Cependant, le serveur HTTP Apache peut également être utilisé à cette fin.

Les deux stra­té­gies pour traiter le contenu statique et dynamique ont des avantages et des in­con­vé­nients. Un module comme mod_php permet au serveur Web d’exécuter le code PHP lui-même. Un serveur d’ap­pli­ca­tion séparé n’est pas né­ces­saire. Cela rend l’ad­mi­nis­tra­tion de sites Web dy­na­miques très pratique. Cependant, les modules d’in­ter­pré­ta­tion pour les langages de pro­gram­ma­tion dynamique doivent être chargés sé­pa­ré­ment dans chaque processus de travail qui est res­pon­sable de la livraison du contenu. Dans le cas d’un grand nombre de processus de travail, ceci s’ac­com­pagne de frais généraux im­por­tants. NGINX réduit ces frais généraux, car l’in­ter­prète ex­ter­na­lisé n’est chargé qu’en cas de besoin.

Alors que NGINX est limité à l'in­te­rac­tion avec un in­ter­pré­teur externe, les deux stra­té­gies sont ouvertes aux uti­li­sa­teurs d'Apache. Apache peut aussi être placé devant un serveur d'ap­pli­ca­tion qui in­ter­prète le contenu Web dynamique. En règle générale, le protocole FastCGI est utilisé à cette fin. Une interface cor­res­pon­dante peut être chargée avec le module mod_proxy_proxy_fcgi.

Pour être en mesure de répondre de façon sa­tis­fai­sante aux demandes des pro­grammes Client (comme les na­vi­ga­teurs Web ou les pro­grammes de courrier élec­tro­nique), un serveur doit dé­ter­mi­ner 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 dif­fé­rence d'orien­ta­tion se reflète dans la façon dont le logiciel respectif in­ter­prète les demandes Client et alloue les res­sources sur le serveur.

Le serveur HTTP Apache et NGINX ont tous deux des mé­ca­nismes qui per­met­tent aux requêtes entrantes d’être in­ter­pré­tées soit comme des res­sources physiques dans le système de fichiers, soit comme des URI (Uniform Resource Iden­ti­fiers). Cependant, alors qu’Apache est basé sur les fichiers par défaut, NGINX se concentre sur le trai­te­ment URI des requêtes.

Si le serveur HTTP Apache reçoit une requête Client, par défaut, il suppose qu'une ressource spé­ci­fique doit être récupérée à partir du système de fichiers du serveur. Comme Apache utilise Vir­tual­Hosts pour fournir dif­fé­rents contenus Web sur le même serveur sous dif­fé­rents noms d’hôtes, adresses IP ou numéros de port, il doit d'abord dé­ter­mi­ner à quel Vir­tual­Host 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 Vir­tual­Hosts définis dans le fichier de con­fi­gu­ra­tion principal HTTPd.conf.

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

L’as­té­risque (*) sert de caractère de rem­pla­ce­ment pour toute adresse IP. Apache décide via un alig­ne­ment du nom d’hôte contenu dans la requête avec la directive Ser­ver­Name de quel Do­cu­men­tRoot (le ré­per­toire de démarrage d'un projet Web) la ressource demandée est re­cher­ché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é­ci­fi­ca­tion de chemin continue dans l’URL. En com­bi­nai­son avec Do­cu­men­tRoot, 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 af­fi­che­rait (sur la base de l’exemple ci-dessus) la ressource désirée en utilisant le chemin de fichier suivant :

Apache compare également l’URL de la requête avec des blocs de fichiers et de ré­per­toires op­tion­nels dans la con­fi­gu­ra­tion. Ceux-ci vous per­met­tent de définir des ins­truc­tions spéciales pour les requêtes qui se réfèrent aux fichiers ou ré­per­toires sé­lec­tion­nés (y compris les sous-ré­per­toires).

L’exemple suivant définit des ins­truc­tions spéciales pour le ré­per­toire public_html/images et le fichier private.html :

En plus de cette procédure standard pour in­ter­pré­ter les requêtes des clients, la directive Alias d'Apache vous permet de spécifier un autre ré­per­toire pour re­cher­cher la ressource demandée au lieu de Do­cu­men­tRoot. De plus, le serveur HTTP Apache fournit un module appelé mod_rewrite qui permet aux uti­li­sa­teurs de réécrire ou de rediriger des URL.

L’URL de requête n’est pas comparée avec les blocs de lo­ca­li­sa­tion dans un bloc serveur jusqu'à ce que le serveur demandé soit trouvé. NGINX lit les blocs d'em­pla­ce­ment listés et recherche l'em­pla­ce­ment qui cor­res­pond le mieux à la requête URI. Chaque bloc d'em­pla­ce­ment contient des ins­truc­tions spé­ci­fiques qui montrent à NGINX comment traiter la requête cor­res­pon­dante.

Les em­pla­ce­ments peuvent être définis comme des préfixes pour un chemin, des cor­res­pon­dances exactes ou des ex­pres­sions ré­gu­lières (RegEx). Les mo­di­fi­ca­teurs suivants sont utilisés dans la syntaxe de la con­fi­gu­ra­tion de serveur :

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

Sur la base d'une demande du client avec la demande URL, HTTP://www.example.org:80/logo.gif, NGINX pro­cé­de­rait comme suit pour in­ter­pré­ter les demandes sub­sé­quentes et livrer la ressource désirée :

Tout d’abord, NGINX détermine l’em­pla­ce­ment du préfixe le plus spé­ci­fique. Pour ce faire, le serveur Web lit tous les em­pla­ce­ments en séquence sans mo­di­fi­ca­teur et s’arrête au premier em­pla­ce­ment qui cor­res­pond à la requête. Tous les em­pla­ce­ments marqués avec le mo­di­fi­ca­teur RegEx (~) sont ensuite importés. Ici aussi, le premier coup est appliqué. Si aucun em­pla­ce­ment RegEx approprié n'est trouvé, le serveur Web accède à l'em­pla­ce­ment de préfixe pré­cé­dem­ment déterminé comme solution de secours.

Par exemple, la requête URI HTTP://www.example.org:80/logo.gif cor­res­pond à la fois au préfixe location / et à l'ex­pres­sion régulière \.(gif|jpg|png)$. NGINX mapperait donc la requête en com­bi­nai­son avec la racine vers le chemin du fichier /data/www/logo.gif et livrerait la ressource cor­res­pon­dante au Client. L'en-tête Expires spécifie quand une réponse est con­si­dé­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 cor­res­pond également à l’em­pla­ce­ment du préfixe / et à l’em­pla­ce­ment RegEx ~ \.php$, qui bénéficie d’un trai­te­ment pré­fé­ren­tiel. NGINX transmet donc la requête à un serveur FastCGI qui écoute sur localhost:9000 et est res­pon­sable du trai­te­ment 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 cor­res­pond à 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 com­pli­quée, pour l’in­ter­pré­ta­tion des demandes des clients est due aux dif­fé­rents domaines d'ap­pli­ca­tion dans lesquels le NGINX est utilisé. Par rapport à l’approche prin­ci­pa­le­ment basée sur les fichiers du serveur HTTP Apache, l’in­ter­pré­ta­tion des requêtes basée sur l'URL permet une plus grande flexi­bi­lité lors du trai­te­ment de dif­fé­rents modèles de requêtes. Ceci est né­ces­saire, par exemple, si NGINX fonc­tionne comme un serveur proxy ou proxy de mes­sa­ge­rie plutôt qu'un serveur web.

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 dif­fé­rences de con­fi­gu­ra­tion.

En plus du fichier de con­fi­gu­ra­tion principal HTTPd.conf, le serveur Web Apache offre aux ad­mi­nis­tra­teurs l’option d’ad­mi­nis­tra­tion au niveau du ré­per­toire. Les fichiers .htaccess sont utilisés à cette fin. En principe, ces fichiers de con­fi­gu­ra­tion dé­cen­tra­li­sés peuvent être im­plé­men­tés dans n’importe quel ré­per­toire serveur. Les ins­truc­tions définies dans un .htaccess se réfèrent à la fois au ré­per­toire contenant le fichier de con­fi­gu­ra­tion et à ses sous-ré­per­toires. En pratique, les fichiers .htaccess sont utilisés pour res­treindre l’accès aux ré­per­toires à certains groupes d’uti­li­sa­teurs, con­fi­gu­rer la pro­tec­tion par mot de passe et définir des règles pour la na­vi­ga­tion dans les ré­per­toires, les messages d'erreur, les re­di­rec­tions ou le contenu al­ter­na­tif.

Notez que tout cela peut également être configuré de manière cen­tra­li­sée dans le fichier HTTPd.conf. Cependant,.htaccess devient pertinent pour les modèles d'hé­ber­ge­ment Web tels que l'hé­ber­ge­ment mutualisé, où l'accès au fichier de con­fi­gu­ra­tion principal est réservé au four­nis­seur de services d'hé­ber­ge­ment. La con­fi­gu­ra­tion dé­cen­tra­li­sée via.htaccess permet aux uti­li­sa­teurs d'au­to­ri­ser l'ad­mi­nis­tra­tion de certaines zones du système de fichiers du serveur, par exemple pour des ré­per­toires de projets sé­lec­tion­nés, sans leur donner accès à la con­fi­gu­ra­tion prin­ci­pale. De plus, les mo­di­fi­ca­tions prennent effet im­mé­dia­te­ment et sans re­dé­mar­rage.

NGINX, par contre, n’offre que des options de con­fi­gu­ra­tion centrale. Toutes les ins­truc­tions sont définies dans le fichier nginx.conf. L’accès à ce fichier permet à l’uti­li­sa­teur de contrôler l'en­semble du serveur. Con­trai­re­ment à Apache, l’accès ad­mi­nis­tra­tif ne peut pas être limité à des ré­per­toires sé­lec­tion­nés. Ceci présente à la fois des avantages et des in­con­vé­nients. La con­fi­gu­ra­tion centrale de NGINX est moins flexible que le concept du serveur HTTP Apache, mais offre un net avantage en termes de sécurité : les chan­ge­ments de con­fi­gu­ra­tion du serveur web ne peuvent être effectués que par des uti­li­sa­teurs ayant des droits root.

Plus important que l'ar­gu­ment de sécurité : l'in­con­vé­nient de per­for­mance d'une con­fi­gu­ra­tion dé­cen­tra­li­sée via .htaccess. Déjà dans la do­cu­men­ta­tion du serveur HTTP Apache, les dé­ve­lop­peurs re­com­man­dent 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 in­ter­prète les fichiers de con­fi­gu­ra­tion.

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’ar­chi­tec­ture Apache permet une con­fi­gu­ra­tion dé­cen­tra­li­sée, le serveur Web recherche un fichier .htaccess dans chaque ré­per­toire le long du chemin d’accès au fichier .htaccess sur son chemin vers la ressource demandée. Tous les fichiers de con­fi­gu­ra­tion qu'il passe sont lus et in­ter­pré­tés, un schéma qui ralentit con­si­dé­ra­ble­ment le serveur web.

Les uti­li­sa­teurs qui veulent dé­sac­ti­ver ou res­treindre la con­fi­gu­ra­tion dé­cen­tra­li­sée sous Apache utilisent la directive Al­lo­wO­ver­ride dans les blocs de ré­per­toire du fichier de con­fi­gu­ra­tion principal HTTPd.conf et la mettent à None. Ceci demande au serveur web d'ignorer tous les fichiers .htaccess dans les ré­per­toires cor­rec­te­ment con­fi­gu­rés.

L‘exemple de con­fi­gu­ra­tion demande au serveur Web d’ignorer tous les fichiers .htaccess pour l’hôte example.com.

Dans notre com­pa­rai­son, les deux serveurs Web reposent sur un système modulaire dans lequel le logiciel de base peut être complété par des com­po­sants sup­plé­men­taires si né­ces­saire. Cependant, jusqu’à la version 1.9.10, NGINX pour­sui­vait une stratégie fon­da­men­ta­le­ment dif­fé­rente de celle de ses con­cur­rents 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é­ve­lop­pe­ment ou chargés dy­na­mi­que­ment et donc au moment de l'exé­cu­tion.

ON distingue trois ca­té­go­ries de modules Apache :

• Modules de base : les modules de base d’Apache com­pren­nent tous les com­po­sants qui four­nis­sent une fonc­tion­na­lité de base du serveur Web.
• Modules d’ex­ten­sions : ces ex­ten­sions sont des modules de la Fondation Apache, qui sont inclus dans la dis­tri­bu­tion Apache. Pour un aperçu de tous les modules inclus dans l’ins­tal­la­tion standard d’Apache 2.4, voir la do­cu­men­ta­tion d'Apache.
• Module de four­nis­seur tiers : ces modules ne sont pas fournis par la Fondation Apache, mais par des four­nis­seurs de services externes ou des pro­gram­meurs in­dé­pen­dants.

Avec NGINX, cependant, la mo­du­la­rité a longtemps été limitée aux com­po­sants d’extension statiques qui devaient être compilés dans le fichier binaire du noyau logiciel. Surtout pour les uti­li­sa­teurs qui n'étaient pas habitués à gérer leurs propres com­po­sants logiciels sans le ges­tion­naire de paquets de la dis­tri­bu­tion res­pec­tive, ce type d'ex­ten­sion lo­gi­cielle limitait clai­re­ment la flexi­bi­lité du serveur web. L’équipe de dé­ve­lop­pe­ment a amélioré ce point : depuis la version 1.9.11 supporte des mé­ca­nismes qui per­met­tent aux modules statiques d'être convertis en modules dy­na­miques afin qu'ils puissent être chargés via des fichiers de con­fi­gu­ra­tion pendant l'exé­cu­tion. 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 dy­na­miques. Les modules qui patchent le code source du logiciel serveur ne doivent pas être chargés dy­na­mi­que­ment. De plus, NGINX limite, dans les pa­ra­mètres standards, le nombre de modules dy­na­miques pouvant être chargés si­mul­ta­né­ment à 128. Pour augmenter cette limite, dé­fi­nis­sez la constante pour NGX_MAX_DYNAMIC_MODULES dans le code source NGINX à la valeur souhaitée.

En plus des modules officiels de la do­cu­men­ta­tion du NGINX, les uti­li­sa­teurs ont accès à divers modules tiers.

• NGINX-Er­wei­te­rung­smo­dule
• Modules de four­nis­seurs tiers pour NGINX

Les deux projets logiciels sont bien do­cu­men­tés et four­nis­sent aux uti­li­sa­teurs des in­for­ma­tions de première main via des wikis et des blogs.

• Serveur HTTP Apache : Wiki
• NGINX: Wiki

Alors que la do­cu­men­ta­tion du NGINX n’est ac­ces­sible qu’en anglais et en russe, le projet Apache se ca­rac­té­rise par des documents d’in­for­ma­tion dans de nom­breuses versions lin­guis­tiques. Cependant, certaines d'entre elles sont dépassées, il est donc in­dis­pen­sable de jeter un coup d'œil à la do­cu­men­ta­tion en anglais.

Les uti­li­sa­teurs peuvent obtenir de l'aide pour résoudre des problèmes dans les deux projets open source par l'in­ter­mé­diaire de la com­mu­nauté. Les listes de mailing servent de forum de dis­cus­sion.

• Apache HTTP Server: listes mailing
• NGINX: listes mailing

Des plans de pu­bli­ca­tion et des feuilles de route trans­pa­rents donnent aux uti­li­sa­teurs la pos­si­bi­lité de s’adapter aux dé­ve­lop­pe­ments futurs. Les bugs logiciels et les failles de sécurité dans les deux projets sont en­re­gis­trés et corrigés dans un rapport public des bugs.

• Serveur HTTP Apache : Bug-Report
• NGINX: Bug-Report

En plus du projet open source NGINX, Nginx, Inc. offre le produit com­mer­cial NGINX Plus. Moyennant des frais d'uti­li­sa­tion annuels, les uti­li­sa­teurs peuvent obtenir des fonctions sup­plé­men­taires et un soutien pro­fes­sion­nel du fabricant. Une matrice de com­pa­rai­son des deux produits se trouve sur le site Web de NGINX.

Il n’existe pas d’édition com­mer­ciale du serveur HTTP Apache. Toutefois, des services d’as­sis­tance payants sont offerts par divers four­nis­seurs tiers.

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 ca­rac­té­ri­sés par une large prise en charge des pla­te­formes. Bien qu’Apache soit re­com­mandé pour tous les systèmes d’ex­ploi­ta­tion unixoid et Windows, la do­cu­men­ta­tion 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 com­pa­tible avec des projets tiers. Tous les standards web per­ti­nents 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 ad­mi­nis­tra­teurs et les dé­ve­lop­peurs Web mettent gé­né­ra­le­ment en œuvre leurs premiers projets sur des plates-formes d'hé­ber­ge­ment mutualisé à faible coût. La plupart d'entre eux sont basés sur Apache et la pos­si­bi­lité de con­fi­gu­ra­tion dé­cen­tra­li­sée via .htaccess. De plus, le serveur HTTP Apache fait partie de plusieurs pro­gi­ciels de dé­ve­lop­pe­ment et de test de logiciels open source tels que XAMPP ou AMPPS.

NGINX offre également aux uti­li­sa­teurs un large éco­sys­tème de modules. De plus, l’équipe de dé­ve­lop­pe­ment en­tre­tient des par­te­na­riats avec divers projets de logiciels libres et pro­prié­taires ainsi qu’avec des four­nis­seurs de services d’in­fras­truc­ture tels qu’Amazon Web Services, Windows Azure et HP.

Malgré des dif­fé­rences dans l'ar­chi­tec­ture lo­gi­cielle, les deux serveurs Web offrent des fonctions si­mi­laires. Apache et NGINX sont utilisés dans des scénarii si­mi­laires, mais chacun utilise ses propres stra­té­gies et concepts pour répondre aux exigences spé­ci­fiques. Le tableau suivant compare les deux projets logiciels en utilisant des fonctions centrales.

Avec Apache et NGINX, les uti­li­sa­teurs 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 com­pa­rai­son. Les deux projets sont basés sur des décisions de con­cep­tion fon­da­men­ta­le­ment dif­fé­rentes, qui apportent des avantages ou des in­con­vé­nients en fonction de l'uti­li­sa­tion du logiciel.

Le serveur HTTP Apache offre un immense ré­per­toire de modules qui, avec les options de con­fi­gu­ra­tion flexibles, ouvre de nombreux champs d’ap­pli­ca­tion pour le logiciel. Le serveur Web est considéré comme un logiciel standard pour les scénarii d’hé­ber­ge­ment mutualisé et con­ti­nuera à se défendre contre les serveurs Web légers tels que NGINX dans ce segment d'ac­ti­vité. La pos­si­bi­lité d'in­té­grer des in­ter­prètes pour des langages de pro­gram­ma­tion tels que PHP, Perl, Python ou Ruby di­rec­te­ment dans le serveur Web via des modules permet de livrer du contenu web dynamique sans serveur d’ap­pli­ca­tion 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é dy­na­mi­que­ment pendant la ré­cu­pé­ra­tion.

NGINX, en revanche, n’offre aucune pos­si­bi­lité de traiter du contenu Web dynamique en natif ou d'in­té­grer les in­ter­prètes cor­res­pon­dants par modules. Un serveur d'ap­pli­ca­tion séparé est donc toujours né­ces­saire. Ceci peut sembler être un effort sup­plé­men­taire inutile pour les sites Web de petite à moyenne taille. Cependant, une telle structure montre ses forces dans les grands projets Web et l'aug­men­ta­tion des volumes de trafic.

NGINX est gé­né­ra­le­ment utilisé en tant qu'équi­li­breur de charge face à un groupe de serveurs d'ap­pli­ca­tions. L’équi­li­breur de charge reçoit les demandes entrantes et, selon le type de demande, décide si elle doit être transmise à un serveur spé­cia­lisé en arrière-plan. Le contenu Web statique est livré di­rec­te­ment par NGINX. Cependant, si un client demande du contenu dynamique, l’équi­li­breur de charge transmet la demande à un serveur d’ap­pli­ca­tion dédié. Celui-ci in­ter­prète le langage de pro­gram­ma­tion, assemble le contenu demandé dans une page Web et le renvoie à l’équi­li­breur de charge qui, à son tour, le livre au client. De cette façon, les volumes de trafic élevés peuvent être gérés ef­fi­ca­ce­ment.

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é di­rec­te­ment à partir de l'équi­li­breur de charge sans que NGINX ait à accéder à nouveau à un serveur d'ap­pli­ca­tion.

L’avantage de l’ex­ter­na­li­sa­tion de l’in­ter­pré­teur à un ou plusieurs serveurs backend séparés est que le réseau de serveurs peut fa­ci­le­ment être mis à l'échelle en ajoutant des serveurs backend sup­plé­men­taires ou en dé­sac­ti­vant des systèmes qui ne sont pas né­ces­saires. Dans la pratique, de nombreux uti­li­sa­teurs s'ap­puient sur la com­bi­nai­son de NGINX et d'Apache pour une telle con­fi­gu­ra­tion et utilisent donc les points forts des deux serveurs Web.