Apache vs Nginx: considérations pratiques

Le serveur HTTP Apache a été créé par Robert McCool en 1995 et a été développé sous la direction de Apache Software Foundation depuis 1999. Étant donné que le serveur Web HTTP est le projet original de la fondation et qu’il est de loin le logiciel le plus populaire, on l’appelle souvent simplement «Apache».

Le serveur Web Apache est le serveur le plus populaire sur Internet depuis 1996. En raison de cette popularité, Apache bénéficie d’une excellente documentation et d’un support intégré provenant d’autres projets logiciels.

Apache est souvent choisi par les administrateurs pour sa flexibilité, sa puissance et son support étendu. Il est extensible via un système de module à chargement dynamique et peut traiter un grand nombre de langages interprétés sans connexion à un logiciel séparé.

En 2002, Igor Sysoev a commencé à travailler sur Nginx en tant que réponse au problème C10K, ce qui constituait un défi pour les serveurs Web: commencer à traiter des milliers de connexions simultanées comme une nécessité pour le Web moderne. La première publication publique a eu lieu en 2004 et répond à cet objectif en s’appuyant sur une architecture asynchrone pilotée par les événements.

Nginx a gagné en popularité depuis sa publication en raison de son utilisation légère des ressources et de sa capacité à évoluer facilement avec un minimum de matériel. Nginx excelle dans la fourniture rapide de contenu statique et est conçu pour transmettre les demandes dynamiques à d’autres logiciels mieux adaptés à ces objectifs.

Nginx est souvent sélectionné par les administrateurs pour l’efficacité de ses ressources et sa réactivité sous charge. Les avocats se félicitent de l’intérêt porté par Nginx aux fonctionnalités principales de serveur Web et de proxy.

Apache fournit une variété de modules multitraitement (ces MPM sont appelés par Apache) qui dictent la manière dont les demandes des clients sont traitées. En gros, cela permet aux administrateurs d’échanger facilement l’architecture de traitement des connexions. Ceux-ci sont:

Comme vous pouvez le constater, Apache fournit une architecture flexible permettant de choisir différents algorithmes de connexion et de traitement des demandes. Les choix proposés sont principalement fonction de l’évolution du serveur et du besoin croissant de simultanéité avec l’évolution du paysage Internet.

Après Apache, Nginx est arrivé sur les lieux avec une prise de conscience accrue des problèmes de simultanéité auxquels les sites seraient confrontés. Tirant parti de ces connaissances, Nginx a été conçu dès le départ pour utiliser un algorithme de traitement de connexion asynchrone, non bloquant et piloté par événement.

Nginx génère des processus de travail, chacun pouvant gérer des milliers de connexions. Les processus de travail y parviennent en mettant en œuvre un mécanisme de bouclage rapide qui vérifie et traite en permanence les événements. Le découplage du travail réel des connexions permet à chaque opérateur de se préoccuper d’une connexion uniquement lorsqu’un nouvel événement a été déclenché.

Chacune des connexions gérées par le travailleur est placée dans la boucle d’événements là où elles existent avec d’autres connexions. Au sein de la boucle, les événements sont traités de manière asynchrone, ce qui permet de gérer le travail de manière non bloquante. Lorsque la connexion se ferme, elle est supprimée de la boucle.

Ce style de traitement de la connexion permet à Nginx d’évoluer incroyablement avec des ressources limitées. Étant donné que le serveur est mono-thread et que les processus ne sont pas générés pour gérer chaque nouvelle connexion, l’utilisation de la mémoire et du processeur a tendance à rester relativement cohérente, même en période de forte charge.

Les serveurs Apache peuvent gérer le contenu statique à l’aide de ses méthodes classiques basées sur des fichiers. La performance de ces opérations est principalement fonction des méthodes MPM décrites ci-dessus.

Apache peut également traiter du contenu dynamique en incorporant un processeur du langage en question dans chacune de ses instances de travail. Cela lui permet d’exécuter du contenu dynamique au sein du serveur Web lui-même sans avoir à recourir à des composants externes. Ces processeurs dynamiques peuvent être activés à l’aide de modules chargeables dynamiquement.

La capacité d’Apache à gérer le contenu dynamique en interne signifie que la configuration du traitement dynamique a tendance à être plus simple. La communication n’a pas besoin d’être coordonnée avec un logiciel supplémentaire et les modules peuvent facilement être remplacés si les exigences en matière de contenu changent.

Nginx n’a aucune possibilité de traiter le contenu dynamique de manière native. Pour gérer PHP et d’autres requêtes de contenu dynamique, Nginx doit passer à un processeur externe pour exécution et attendre que le contenu rendu soit renvoyé. Les résultats peuvent ensuite être relayés au client.

Pour les administrateurs, cela signifie que la communication doit être configurée entre Nginx et le processeur via l’un des protocoles que Nginx sait parler (http, FastCGI, SCGI, uWSGI, memcache). Cela peut légèrement compliquer les choses, en particulier lorsque vous essayez d’anticiper le nombre de connexions à autoriser, car une connexion supplémentaire sera utilisée pour chaque appel au processeur.

Cependant, cette méthode présente également certains avantages. Étant donné que l’interpréteur dynamique n’est pas intégré au processus de travail, sa surcharge ne concerne que le contenu dynamique. Le contenu statique peut être servi de manière simple et l’interprète ne sera contacté qu’en cas de besoin. Apache peut également fonctionner de cette manière, mais cela supprime les avantages de la section précédente.

Apache comprend une option permettant d’autoriser une configuration supplémentaire par répertoire en inspectant et en interprétant les directives contenues dans des fichiers cachés dans les répertoires de contenu eux-mêmes. Ces fichiers sont appelés fichiers "+ .htaccess +".

Étant donné que ces fichiers se trouvent dans les répertoires de contenu eux-mêmes, lors du traitement d’une demande, Apache vérifie chaque composant du chemin d’accès au fichier demandé pour un fichier + .htaccess + et applique les directives qu’il contient. Cela permet effectivement une configuration décentralisée du serveur Web, qui est souvent utilisée pour la mise en œuvre de la réécriture d’URL, des restrictions d’accès, de l’autorisation et de l’authentification, voire des stratégies de mise en cache.

Bien que les exemples ci-dessus puissent tous être configurés dans le fichier de configuration principal Apache, les fichiers + .htaccess + présentent des avantages importants. Premièrement, étant donné qu’ils sont interprétés chaque fois qu’ils se trouvent le long d’un chemin de requête, ils sont immédiatement implémentés sans recharger le serveur. Deuxièmement, il permet aux utilisateurs non privilégiés de contrôler certains aspects de leur propre contenu Web sans leur donner le contrôle de l’ensemble du fichier de configuration.

Cela permet à certains logiciels Web, tels que les systèmes de gestion de contenu, de configurer leur environnement sans donner accès au fichier de configuration central. Ceci est également utilisé par les fournisseurs d’hébergement partagé pour garder le contrôle de la configuration principale tout en donnant aux clients le contrôle de leurs répertoires spécifiques.

Nginx n’interprète ni les fichiers + .htaccess +, ni ne fournit de mécanisme d’évaluation de la configuration par répertoire en dehors du fichier de configuration principal. Cela peut sembler moins flexible que le modèle Apache, mais cela a ses propres avantages.

L’amélioration la plus notable par rapport au système + .htaccess + de la configuration au niveau du répertoire est l’amélioration des performances. Pour une configuration Apache typique pouvant autoriser + .htaccess + dans n’importe quel répertoire, le serveur recherchera ces fichiers dans each des répertoires parents menant au fichier demandé, pour chaque demande. Si un ou plusieurs fichiers + .htaccess + sont trouvés au cours de cette recherche, ils doivent être lus et interprétés. En n’autorisant pas les remplacements de répertoire, Nginx peut répondre aux demandes plus rapidement en + effectuant une seule recherche dans le répertoire et en lisant le fichier pour chaque demande (en supposant que le fichier se trouve dans la structure de répertoire conventionnelle).

Un autre avantage est lié à la sécurité. La distribution de l’accès à la configuration au niveau de l’annuaire répartit également la responsabilité de la sécurité sur des utilisateurs individuels, qui peuvent ne pas être fiables pour gérer correctement cette tâche. S’assurer que l’administrateur garde le contrôle de l’intégralité du serveur Web peut éviter certaines erreurs de sécurité pouvant survenir lors de l’accès à d’autres parties.

N’oubliez pas qu’il est possible de désactiver l’interprétation + .htaccess + dans Apache si ces préoccupations vous intéressent.

Apache permet d’interpréter une requête en tant que ressource physique sur le système de fichiers ou en tant qu’emplacement URI pouvant nécessiter une évaluation plus abstraite. En général, Apache utilise en général les blocs + <Directory> + ou + <Files> +, alors qu’il utilise les blocs + <Location> + pour des ressources plus abstraites.

Apache ayant été conçu dès le départ en tant que serveur Web, il est généralement utilisé par défaut pour interpréter les demandes en tant que ressources de système de fichiers. Pour commencer, prenez la racine du document et ajoutez la partie de la requête qui suit l’hôte et le numéro de port pour essayer de trouver un fichier réel. Fondamentalement, la hiérarchie du système de fichiers est représentée sur le Web sous forme d’arborescence de documents disponible.

Apache fournit un certain nombre d’alternatives lorsque la demande ne correspond pas au système de fichiers sous-jacent. Par exemple, une directive + Alias ​​+ peut être utilisée pour mapper vers un autre emplacement. Utiliser des blocs + <Location> + est une méthode de travail avec l’URI lui-même au lieu du système de fichiers. Il existe également des variantes d’expressions régulières qui peuvent être utilisées pour appliquer la configuration de manière plus flexible dans le système de fichiers.

Bien qu’Apache puisse fonctionner à la fois sur le système de fichiers sous-jacent et sur l’espace Web, il s’appuie fortement sur les méthodes du système de fichiers. Cela se voit dans certaines des décisions de conception, y compris l’utilisation de fichiers + .htaccess + pour la configuration par répertoire. Les http://httpd.apache.org/docs/2.4/sections.html#whichennen AWPache docs] eux-mêmes mettent en garde contre l’utilisation de blocs basés sur l’URI pour restreindre l’accès lorsque la demande reflète le système de fichiers sous-jacent.

Nginx a été créé pour être à la fois un serveur Web et un serveur proxy. En raison de l’architecture requise pour ces deux rôles, il fonctionne principalement avec les URI, en effectuant une traduction vers le système de fichiers lorsque cela est nécessaire.

Cela se voit de différentes manières dans la construction et l’interprétation des fichiers de configuration de Nginx. Nginx ne fournit pas de mécanisme permettant de spécifier la configuration d’un répertoire de système de fichiers et analyse à la place l’URI lui-même.

Par exemple, les principaux blocs de configuration pour Nginx sont les blocs + serveur + et + emplacement +. Le bloc + serveur + interprète l’hôte demandé, tandis que les blocs + emplacement + sont responsables de la correspondance des parties de l’URI situées après l’hôte et le port. À ce stade, la demande est interprétée comme un URI et non comme un emplacement sur le système de fichiers.

Pour les fichiers statiques, toutes les demandes doivent éventuellement être mappées vers un emplacement du système de fichiers. Tout d’abord, Nginx sélectionne les blocs serveur et emplacement qui gèrent la demande, puis combine la racine du document avec l’URI, en adaptant tout ce qui est nécessaire en fonction de la configuration spécifiée.

Cela peut sembler similaire, mais l’analyse des demandes principalement sous forme d’URI plutôt que d’emplacement de système de fichiers permet à Nginx de fonctionner plus facilement dans les rôles Web, de messagerie et de serveur proxy. Nginx est configuré simplement en indiquant comment répondre à différents types de demandes. Nginx ne vérifie pas le système de fichiers jusqu’à ce qu’il soit prêt à répondre à la demande, ce qui explique pourquoi il n’implémente pas de formulaire + .htaccess +.

Le système de modules d’Apache vous permet de charger ou de décharger dynamiquement des modules afin de répondre à vos besoins lors de l’exécution du serveur. Le noyau Apache est toujours présent, tandis que les modules peuvent être activés ou désactivés, en ajoutant ou en supprimant des fonctionnalités supplémentaires et en se connectant au serveur principal.

Apache utilise cette fonctionnalité pour une grande variété de tâches. En raison de la maturité de la plate-forme, une vaste bibliothèque de modules est disponible. Ceux-ci peuvent être utilisés pour modifier certaines des fonctionnalités principales du serveur, telles que + mod_php +, qui incorpore un interpréteur PHP dans chaque utilisateur en cours d’exécution.

Les modules ne se limitent toutefois pas au traitement du contenu dynamique. Entre autres fonctions, elles peuvent être utilisées pour réécrire les URL, authentifier les clients, renforcer le serveur, journaliser, mettre en cache, compresser, utiliser un proxy, limiter le débit et chiffrer. Les modules dynamiques peuvent étendre considérablement les fonctionnalités de base sans trop de travail supplémentaire.

Nginx implémente également un système de modules, mais il est assez différent du système Apache. Dans Nginx, les modules ne peuvent pas être chargés dynamiquement. Ils doivent donc être sélectionnés et compilés dans le logiciel principal.

Pour de nombreux utilisateurs, cela rendra Nginx beaucoup moins flexible. Ceci est particulièrement vrai pour les utilisateurs qui ne sont pas à l’aise avec la maintenance de leur propre logiciel compilé en dehors du système de conditionnement classique de leur distribution. Alors que les paquetages des distributions ont tendance à inclure les modules les plus couramment utilisés, si vous avez besoin d’un module non standard, vous devrez créer le serveur vous-même à partir du code source.

Les modules Nginx sont toujours très utiles et vous permettent de dicter ce que vous voulez sur votre serveur en n’incluant que les fonctionnalités que vous souhaitez utiliser. Certains utilisateurs peuvent également considérer cela comme plus sécurisé, car des composants arbitraires ne peuvent pas être connectés au serveur. Cependant, si votre serveur se trouve dans une position où cela est possible, il est probablement déjà compromis.

Les modules Nginx offrent de nombreuses fonctionnalités identiques à celles des modules Apache. Par exemple, les modules Nginx peuvent prendre en charge les fonctions de proxy, de compression, de limitation de débit, de journalisation, de réécriture, de géolocalisation, d’authentification, de cryptage, de diffusion en continu et de messagerie.

Comme Apache est populaire depuis si longtemps, la prise en charge du serveur est relativement omniprésente. Une vaste bibliothèque de documentation de première et de tierce partie est disponible pour le serveur principal et pour les scénarios basés sur des tâches impliquant le raccordement d’Apache à un autre logiciel.

Outre la documentation, de nombreux outils et projets Web incluent des outils pour s’amorcer dans un environnement Apache. Cela peut être inclus dans les projets eux-mêmes ou dans les packages gérés par l’équipe d’emballage de votre distribution.

Apache, en général, bénéficiera d’un soutien accru de projets tiers simplement en raison de sa part de marché et de la durée de disponibilité de celui-ci. Les administrateurs sont également un peu plus susceptibles d’avoir une expérience de travail avec Apache, non seulement en raison de sa prévalence, mais aussi parce que de nombreuses personnes démarrent dans des scénarios d’hébergement partagé qui reposent presque exclusivement sur Apache en raison des capacités de gestion distribuées + .htaccess +.

Nginx bénéficie d’une assistance accrue à mesure que de plus en plus d’utilisateurs l’adoptent pour son profil de performances, mais il lui reste encore du chemin à parcourir dans certains domaines clés.

Dans le passé, il était difficile de trouver une documentation complète en langue anglaise concernant Nginx en raison du fait que la plupart des premiers développements et la documentation étaient en russe. À mesure que l’intérêt pour le projet s’intensifiait, la documentation a été complétée et de nombreuses ressources administratives sont désormais disponibles sur le site de Nginx et par des tiers.

En ce qui concerne les applications tierces, l’assistance et la documentation deviennent de plus en plus disponibles, et les responsables de paquets commencent, dans certains cas, à donner le choix entre la configuration automatique pour Apache et Nginx. Même sans assistance, la configuration de Nginx pour fonctionner avec un logiciel alternatif est généralement simple tant que le projet lui-même documente ses exigences (autorisations, en-têtes, etc.).