Nginx vs Apache : La comparaison des serveurs Web

Internet, tel que nous le connaissons aujourd’hui, a commencé sa « conquête » mondiale dans les années 90. L’ensemble du protocole « Web » peut se résumer à la demande d’un document par un visiteur depuis d’une adresse Web donnée, le système DNS et le système IP transmettant cette demande à l’ordinateur approprié. Cet ordinateur, qui héberge la page Web demandée, « servira » la page au visiteur.

Les pages sont essentiellement des documents HTML. Pour pouvoir servir différentes pages aux visiteurs, la machine « serveur » a besoin d’un programme serveur. Des logiciels comme Nginx vs Apache traitent les requêtes, les analysent, puis remettent les documents correspondants pour les visualiser dans le navigateur d’un visiteur.

Apache

Nous allons d’abord nous plonger dans Apache qui est sorti en premier.

Après CERN httpd et NCSA HTTPd de Tim Berners-Lee dans les premières années de l’internet, Apache – sorti pour la première fois en 1995 – a rapidement conquis le marché et est devenu le serveur web le plus populaire du monde. Aujourd’hui, il se trouve toujours dans cette position sur le marché, mais surtout pour des raisons historiques. Apache est développé et maintenu par la Fondation Apache, sous la licence Apache.

Il y a deux histoires différentes sur la façon dont Apache a obtenu son nom. Une version dit que le nom provient du célèbre héritage amérindien, tandis que l’autre dit qu’il s’agit d’un jeu de mots sur un « serveur patchy », qui a suivi une série de patches logiciels.

Linux

L’énorme part de marché d’Apache est due en partie au fait qu’il est pré-installé avec toutes les distributions Linux majeures, comme Red Hat/Centos et Ubuntu.

Un exemple du rôle important d’Apache dans le monde Linux est que son nom de processus serveur est HTTPd, faisant d’Apache un synonyme de logiciel de serveur web.

En plus d’être le premier acteur sérieux sur le marché des serveurs web, une part de la prolifération d’Apache est due à son système de configuration et à son fichier .htaccess.

.htaccess

Apache utilise .htaccess pour sa configuration. Il existe de nombreux tutoriels sur la façon de configurer, de modifier et de travailler avec ce fichier car il offre une grande flexibilité pour configurer la façon dont Apache traite les requêtes entrantes. Voici quelques exemples : règles de redirection différentes, tailles maximales des fichiers téléversés, réécritures d’URL, limites de mémoire, protection de répertoire (htpasswd), expiration d’en-têtes, en-têtes de contrôle de cache, en-têtes d’encodage, cookies, manipulation de chaînes de requête.

D’un autre côté, Kinsta utilise Nginx qui ne prend pas en charge les fichiers .htaccess. Cependant, les paramètres et les règles de vos fichiers .htaccess peuvent être facilement « traduits » dans la syntaxe des règles de réécriture de Nginx.

Un des principaux « avantages » d’Apache est que dans la racine du serveur – le répertoire principal du site web – chaque niveau ou répertoire de l’arborescence peut avoir son propre fichier .htaccess avec sa propre configuration.

Pour les fournisseurs d’hébergement mutualisé, c’est un rêve car ils peuvent fournir à des centaines d’utilisateurs sur la même machine un moyen de configurer la façon dont leurs sites sont servis, sans que cela affecte les autres. Les clients peuvent configurer de nombreux détails dans un environnement d’hébergement mutualisé restreint, sans jamais toucher à la configuration globale du serveur.

Comme le dit la documentation officielle :

« En général, vous ne devriez utiliser les fichiers .htaccess que lorsque vous n’avez pas accès au fichier de configuration du serveur principal ».

Cette flexibilité, cependant, se fait au détriment de la performance « autoriser les fichiers .htaccess provoque une perte de performance, que vous les utilisiez ou non ! »

Chaque fois que les fichiers .htaccess sont activés, Apache doit parcourir l’arborescence complète des répertoires depuis l’URL ou le fichier demandé jusqu’au répertoire racine du serveur, puis les charger, pour chaque requête. Il doit ensuite traiter ces fichiers et se reconfigurer pour chacun des répertoires ainsi configurés.

Avec les sites WordPress, les choses peuvent devenir vraiment complexes. Un site WordPress typique peut contenir des centaines de requêtes provenant de différents répertoires.

Depuis les type de répertoires /wp-content/uploads/aaaa/mm il y aura typiquement plusieurs requêtes sur un seul chargement de page, souvent des répertoires de mois différents. Ensuite, il y aura les ressources statiques /wp-content/themes/theme-enfant, /wp-content/themes/theme-enfant : il s’agira de ressources javascript, css, images.

Ensuite, il y aura aussi /wp-content/plugins avec des fichiers statiques chargés à partir de dizaines de sous-répertoires des extensions. Pour chacune de ces ressources, Apache doit parcourir toute son arborescence pour rechercher la configuration.

Une analyse a montré qu’une configuration WordPress typique, plutôt commune pour les sites sur des hôtes partagés, comprendra 42 exécutions distinctes de .htaccess et 249 recherches distinctes pour le fichier .htaccess.

Ceci est juste au niveau d’un serveur. Le visiteur doit encore attendre que le processus PHP exécute la pile d’appels WordPress complète pour créer la requête de base de données et la donner à MySQL pour assembler la page et l’envoyer au visiteur.

Modules

Une autre chose qui a rendu Apache populaire est son système de modules dynamiques.

Les modules – en tant que fonctionnalité qui permet aux utilisateurs d’étendre les fonctionnalités du serveur – existent à la fois dans Nginx et Apache. Apache permet aux utilisateurs d’installer des modules une fois que le serveur a déjà été installé et déployé, puis les activer ou les désactiver si besoin. Les distributions basées sur Debian ont des commandes qui permettent d’activer et de désactiver ces modules sans avoir à éditer aucun fichier de configuration  : a2enmod et a2dismod.

La liste officielle des modules qui font partie de la distribution standard d’Apache est la suivante : compression, cryptage, journalisation, redirections vers des fonctions plus avancées comme l’édition des requêtes et des réponses avec une syntaxe avancée.

Nginx

Nginx (également écrit sous le nom de nginx ou NGINX), est apparu en 2004, quand il a été publié pour la première fois par le développeur russe Igor Sysoev. Comme l’a dit Owen Garrett, le chef de projet de Nginx :

« Nginx a été écrit spécifiquement pour répondre aux limitations de performance des serveurs web Apache. »

Le serveur a d’abord été créé comme un outil de mise à l’échelle pour le site rambler.ru en 2002. Il existe en deux versions : open source, avec licence de type BSD, et Nginx Plus, avec support et fonctionnalités d’entreprise supplémentaires.

Après sa sortie, Nginx a été utilisé principalement pour servir des fichiers statiques et comme équilibreur de charge ou proxy inversé devant les installations d’Apache. Au fur et à mesure de l’évolution du web, et de la nécessité de comprimer chaque dernière goutte de vitesse et d’efficacité dans l’utilisation du matériel, de plus en plus de sites ont commencé à remplacer complètement Apache par Nginx, grâce aussi à un logiciel plus mature.

En mars 2019, Nginx Inc. a été acquise par F5 Networks pour 670 millions de dollars. A ce moment-là, comme le rapporte Techcrunch, le serveur Nginx alimentait « 375 millions de sites avec environ 1 500 clients payants ».

Selon les données de w3techs, la part de marché de Nginx n’a cessé de croître, poussant Apache dehors et le détrônant de la première place :

Ces données concernent l’ensemble des serveurs dans le monde, mais si nous prenons un échantillon du million de sites les plus importants, Nginx est là depuis un certain temps maintenant :

Google Search Trends semble également refléter ce fait :

L’enquête Netcraft suggère qu’Apache a été dépassé par Nginx en avril 2019.

Configuration Nginx

Nginx n’a pas de système de configuration comme Apache donc, bien qu’il soit beaucoup plus efficace et rapide, il n’est pas largement utilisé chez les hébergeurs de détail. Il ne brille pas dans les environnements partagés comme le fait Apache.

D’autre part, comme nous l’avons dit, en n’autorisant pas les configurations au niveau du répertoire, Nginx gagne un avantage significatif sur Apache. Il y a un article sur le wiki Nginx qui compare l’impact sur la performance :

Modules Nginx

Le système de modules Nginx est une chose de plus qui le positionne comme un choix plus haut de gamme. Les modules Nginx doivent généralement être activés au moment de la compilation, ce qui signifie qu’une prouesse plus technique est nécessaire, et l’ajout de modules après l’installation est un peu plus compliqué.

En 2016, avec la version 1.9.11, les choses ont changé et le dépôt officiel/vérifié des modules dynamiques est réservé aux utilisateurs payants. En mai 2019, ils ont annoncé le début du développement du support pour QUIC et HTTP/3.

La question de la mise en cache : Nginx vs Apache

La mise en cache – si nous voulons la simplifier à l’extrême – peut être présentée comme la préparation du contenu pour les visiteurs du site avant leur visite, de sorte que lorsqu’ils « toquent à la porte », vous n’avez pas besoin d’aller chercher le contenu qu’ils recherchent. Vous l’avez déjà préparé et vous le leur donnez sans attente.

Comme Apache, l’installation typique de Nginx était de se poser entre les serveurs et l’utilisateur final pour soulager la perte de performance sur le reste de l’infrastructure. Dans ces cas, il peut mettre en cache le contenu statique sans avoir besoin de le récupérer à chaque fois sur le serveur d’origine.

Si nous utilisons Nginx comme serveur autonome – comme c’est le cas avec les conteneurs Kinsta LXC – il n’y a pas de besoin. Nginx est très efficace pour servir le contenu statique seul.

Ensuite, il y a la question du cache dynamique ou cache page. Dans le scénario d’un site WordPress, cela signifie stocker toutes les pages WordPress générées pour chaque URL en mémoire ou sur disque.

La mise en cache FastCGI est disponible en natif dans une installation Nginx standard. Elle est simple, très puissante et l’une des fonctionnalités de Nginx les moins utilisées.

Pour comparer ceci aux équivalents d’Apache, vous devez savoir qu’Apache a un module mod_cache qui aurait tendance à être défectueux, en conflit avec d’autres modules. La solution de cache standard déployée avec Apache est donc Varnish HTTP accelerator. Bien que Varnish soit la solution dédiée de l’industrie, certains tests récents donnent à Nginx un avantage certain sur Varnish.

Chez Kinsta, nous utilisons Nginx for dynamic WordPress caching, ainsi qu’une extension de mise en cache propriétaire qui permet un contrôle granulaire sur les pages et les ressources statiques mises en cache par Kinsta CDN.

Traitement des requêtes : Nginx vs Apache

La plus grande différence entre Apache et Nginx réside dans l’architecture sous-jacente de la façon dont ils traitent les requêtes.

Apache traite les requêtes avec MPM-s ou Multi-Processing-Modules, qui est « responsable de la liaison aux ports réseau de la machine, de l’acceptation des requêtes et de l’envoi des enfants pour traiter les requêtes ».

Le MPM plus ancien, qui remonte aux débuts d’Apache, est le module prefork. Ce module seul peut être crédité pour la mauvaise réputation des performances d’Apache. Dans ce mode, Apache génère un nouveau processus avec un thread à chaque requête.

Ce module, utilisé avec mod_php, signifiait que le serveur Apache embarquait un interpréteur PHP dans chaque processus, même s’il devait fournir des fichiers CSS ou des images.

Ceci était inefficace. Le module Prefork est livré avec Apache comme module par défaut. Il limite également les connexions à HTTP/1.

Dans les années suivantes, Apache a développé worker mpm multi-thread et après cela, event mpm. Tous les deux atténuent de nombreux problèmes de performance d’Apache. Le passage à php-fpm permet à Apache d’être toujours une solution concurrente aujourd’hui, tout en éliminant l’utilisation de .htaccess, mais cela va à l’encontre de son objectif.

Nginx utilise une architecture asynchrone, non bloquante et pilotée par des événements.

Pour expliquer la différence : dans le monde Linux/Unix, les processus sont des programmes en cours d’exécution.

Les threads sont un sous-ensemble de processus et il peut y avoir plusieurs threads au sein d’un même processus d’exécution. Considérez cela comme plusieurs onglets dans une fenêtre de navigateur. De cette façon, un programme peut tirer parti de plusieurs processeurs et de processeurs multi-cœurs, multi-threads pour s’exécuter plus rapidement. Vous pouvez lire Linus Torvalds qui explique les différences.

En bref, Apache utilise des processus pour chaque connexion (et avec un worker mpm il utilise des threads). Au fur et à mesure que le trafic augmente, il devient rapidement trop cher.

Nous pouvons imaginer de nouveaux processus ou la création de threads comme le démarrage d’un ordinateur ou le lancement de programmes. Même sur les ordinateurs les plus rapides, cela prend du temps. Avec les sites qui font aujourd’hui des centaines de requêtes sur un seul chargement de page, cela s’additionne rapidement.

Event mpm va un peu plus loin en termes d’optimisation, mais certains tests montrent qu’il ne peut pas dépasser Nginx. Surtout quand on parle de fichiers statiques, où Nginx sert le double des requêtes qu’Apache.

Nginx dispose idéalement d’un worker de processus par CPU/cœur. La différence des processus Nginx pour les workers est que chacun d’eux peut gérer des centaines de milliers de connexions réseau entrantes par worker. Il n’est pas nécessaire de créer de nouveaux threads ou processus pour chaque connexion.

C’est la raison pour laquelle les principaux réseaux de diffusion de contenu, comme Cloudflare, MaxCDN et notre partenaire KeyCDN – ou des sites comme Netflix – trouvent Nginx crucial pour leur diffusion de contenu.

La liste des sociétés qui profitent de Nginx est trop longue pour les énumérer toutes, nous allons donc terminer avec Automattic, la société privée derrière WordPress.com.

Automattic a converti tous ses équilibreurs de charge en Nginx pour WordPress.com en 2008 (vous pouvez lire à ce sujet ici) et a migré sa pile de serveurs complètement vers Nginx.

Vérification dans la vraie vie

Si nous voulons inspecter ce que le site en production utilise, nous pouvons généralement trouver ceci dans les en-têtes de réponse HTTP. Cela signifie que nous devrons faire un clic droit sur un site > Inspecter, dans les outils de développement, nous choisirons le panneau réseau, puis rechargerons le site. Nous verrons toutes les ressources que le site est en train de charger. Si nous choisissons une ressource particulière et son onglet En-têtes, nous verrons généralement les informations du serveur. Si le site utilise un CDN, nous pouvons voir quelque chose comme Cloudflare dans la ligne du serveur ou quelque chose comme Varnish si le site utilise un accélérateur HTTP.

Ceci est un exemple d’un site WordPress qui utilise une configuration d’hébergement mutualisé typique avec cPanel, Apache et PHP :

Ceci est un site sur Nginx :

Sur le côté gauche, si nous le déplions, nous pourrons également analyser le temps de chaque ressource et voir son impact sur le temps de chargement global des pages.

Résumé

Dans cet article, je me suis concentré sur Nginx vs Apache et j’ai expliqué les principales différences architecturales qui ont aidé Nginx à gagner plus d’attraction et d’attention dans l’arène des serveurs. Ce sont ces caractéristiques clés qui lui confèrent l’avantage en matière de performance dans notre industrie avide de ressources.

Bien sûr, tous les cas d’utilisation n’ont pas les mêmes priorités et Apache ou d’autres outils tels que Lighttpd, IIS, LiteSpeed, Caddy pourraient être de bonnes solutions.

Chez Kinsta, nous utilisons Nginx dans le cadre de nos solutions d’hébergement aux performances optimisées pour WordPress et WooCommerce. Chaque site WordPress est hébergé dans son propre conteneur isolé, qui possède toutes les ressources logicielles nécessaires à son fonctionnement (Nginx, Linux, PHP, MySQL). Les ressources sont 100% privées et ne sont partagées avec aucun autre site.

N’oubliez pas de consulter Nginx et tous nos modules premium. Consultez également nos services d’hébergement d’applications et d’hébergement de bases de données pour d’autres possibilités d’hébergement.

Tonino Jankov

Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.

• Twitter