NGINX vs. Apache : Comment Choisir le Meilleur Serveur Web

Imagine ça : tu recherches de nouvelles baskets, tu trouves une bonne affaire, et tu décides de vérifier ça sur le site web.

Tu attends 10 secondes… 20 secondes… et le site ne charge toujours pas. Tu en as marre d’attendre, alors tu passes à un autre site. Voici ce qui s’est probablement passé : le site de baskets a probablement dépensé beaucoup de temps et d’argent pour des images élégantes et des designs soignés, mais tout cela ne sert à rien si cela prend une éternité à charger.

Internet est rempli de sites web lents.

La page de destination mobile moyenne prend 22 secondes à charger, et c’est terrible pour les affaires.

Une étude de Portent a révélé qu’un site qui se charge en moins d’une seconde a un taux de conversion trois fois supérieur à celui d’un site qui prend cinq secondes à se charger.

Maintenant, quel est le lien avec notre comparaison NGINX vs. Apache ?

Un facteur majeur affectant la vitesse du site est ton serveur web — le logiciel qui distribue tes pages aux visiteurs.

Apache et NGINX sont deux des serveurs web les plus éminents qui existent.

En juillet 2024, w3techs rapporte que NGINX alimente plus de 34% des sites web, tandis qu’Apache en supporte 29,4%.

Est-ce que cela fait de NGINX le vainqueur incontesté ? Pas encore.

Les serveurs web fonctionnent différemment selon les cas d’utilisation. Dans ce guide, nous examinerons les différences entre Apache et NGINX et expliquerons ce qu’il faut rechercher lors du choix d’un serveur.

Commencez maintenant.

Quels Sont Les Serveurs Web ?

Les serveurs Web sont des applications logicielles qui fonctionnent sur un serveur physique et gèrent les demandes entrantes des utilisateurs.

Quand tu tapes une URL comme “google.com”, ton navigateur envoie une demande au serveur web, qui stocke les fichiers nécessaires pour faire fonctionner le site web.

Le serveur renvoie ensuite le contenu approprié, qu’il s’agisse de HTML, CSS, JavaScript, images ou d’un autre type.

Les serveurs web gèrent de nombreuses tâches importantes en arrière-plan :

• Gestion des connexions et des requêtes HTTP
• Redirection des requêtes vers l’application backend appropriée si nécessaire (comme PHP, Python ou Ruby on Rails)
• Lecture et écriture de fichiers sur disque pour servir des ressources statiques
• Application des politiques de sécurité
• Compression du contenu pour une transmission plus rapide
• Enregistrement des requêtes pour analyse

Maintenant que nous avons expliqué comment fonctionnent les serveurs web, voyons comment NGINX et Apache abordent ces tâches.

Qu’est-ce qu’Apache ?

Apache HTTP Server, couramment appelé Apache, est un logiciel de serveur web open-source populaire créé par Robert McCool et sorti en 1995. Il est basé sur le serveur NCSA HTTPd.

La Fondation Apache Software, une organisation à but non lucratif qui soutient les projets de logiciels open-source, l’a développé et continue de le maintenir.

Pendant de nombreuses années, Apache a été le serveur web le plus utilisé au monde, alimentant de nombreux sites web. En fait, il a joué un rôle significatif dans le développement du World Wide Web à ses débuts.

Certaines des fonctionnalités et avantages clés d’Apache sont :

• Architecture modulaire : Sa fonctionnalité peut être étendue par des modules pour différentes fonctionnalités et langues.
• Fonctionne sur divers systèmes d’exploitation : Apache est conçu pour être multiplateforme afin d’héberger votre serveur web sur n’importe quel système d’exploitation, y compris Linux, Windows et macOS.
• Documentation étendue et une grande communauté : Aide les utilisateurs et les développeurs à résoudre les problèmes et à développer de meilleures solutions en travaillant ensemble.
• Configuration flexible : Les fichiers .htaccess peuvent faciliter les modifications de configuration spécifiques à un répertoire pour les utilisateurs.
• Fonctionnalités de sécurité : Apache bénéficie d’une assez bonne sécurité grâce à sa nature open-source et aux mises à jour régulières pour corriger les vulnérabilités et les bugs.

Cela dit, Apache présente quelques limitations :

• Utilisation accrue de la mémoire : Il utilise plus de mémoire que NGINX, particulièrement lors de la gestion de plusieurs connexions simultanées.
• Plus lent sous fortes charges : Il peut être plus lent que NGINX pour servir des fichiers statiques, surtout sous de fortes charges.
• Difficile à développer et à maintenir pour les développeurs : Au fil des ans, la complexité croissante de sa base de code l’a rendu plus difficile à construire et à maintenir.

Qu’est-ce Que NGINX ?

NGINX (prononcé « Engine X ») est un logiciel de serveur web gratuit, open-source et haute performance, lancé pour la première fois en 2004. Il a été créé par Igor Sysoev, un ingénieur logiciel russe, pour résoudre le problème de la gestion de nombreux utilisateurs accédant simultanément à un site web, ce qui représentait un défi pour d’autres serveurs web comme Apache.

Le travail de Sysoev sur NGINX a commencé en 2002. Il visait à résoudre le « problème C10k » — gérer 10 000 connexions simultanées.

Sa vision était celle d’un serveur rapide, stable et évolutif. Cet accent mis sur la performance rend NGINX particulièrement efficace pour servir des contenus statiques tels que des pages HTML, des images et des fichiers CSS.

Au-delà de sa vitesse, NGINX excelle en tant que proxy inverse. Il reçoit les demandes des utilisateurs et les achemine intelligemment vers d’autres serveurs, comme Apache ou des applications web, optimisant ainsi l’utilisation des ressources.

Quelques-uns des principaux avantages de NGINX sont :

• Gestion Concurrente : NGINX gère de nombreux utilisateurs simultanément sans exiger une mémoire ou une puissance CPU excessive.
• Facile À Configurer Et À Mettre En Place : NGINX dispose d’un format de fichier de configuration simple et intuitif qui aide les utilisateurs à configurer facilement le serveur web selon leur cas d’utilisation.
• Diverses Fonctionnalités De Performance : NGINX possède de nombreuses fonctionnalités intégrées pour l’équilibrage de charge, la mise en cache et la sécurisation des sites web avec le chiffrement SSL/TLS.
• Supporte IMAP et POP3 : NGINX fonctionne même comme un serveur proxy mail, prenant en charge des protocoles comme IMAP et POP3.

Cependant, il y a quelques inconvénients à utiliser NGINX :

• Les paramètres par défaut ne sont pas optimaux : Les algorithmes par défaut de répartition de charge ne fonctionnent pas toujours de manière optimale dans chaque situation.
• Pas de compilateurs de langage intégrés : Il n’y a pas de support natif pour générer des sites web dynamiques utilisant des langues côté serveur comme PHP ou Python. Néanmoins, tu peux contourner cela avec une extension tierce.

Apache vs. NGINX : Quelles Sont les Différences ?

Apache était autrefois le premier choix en tant que serveur web. Cependant, NGINX a rapidement pris le dessus sur le marché et est maintenant populaire parmi de nombreux sites à fort trafic.

Si tu prévois de travailler avec un Dedicated Hosting, choisir le bon serveur web est une décision importante.

Alors, qu’est-ce qui distingue ces deux-là ?

Regardons de plus près.

Détails	Serveur HTTP Apache	NGINX
Fondé	1995	2004
Conditions de licence	Licence Apache 2.0	Licence BSD à 2 clauses
Compatibilité du système d’exploitation	Windows, Linux, macOS, systèmes basés sur Unix	Windows, Linux, macOS, systèmes basés sur Unix
Support du protocole WebSocket	Oui	Oui (introduit dans la version 1.3.13)
Support de proxy inversé	Oui	Oui
Configuration de l’hôte virtuel	Pris en charge	Pris en charge
Cache	Disponible via des modules	Intégré au cœur
Consommation de ressources (mémoire)	Élevée	Faible
Format de configuration et d’installation	Basé sur le texte	Basé sur le texte (syntaxe plus simple)
Fonctionnalités de sécurité	Le support de mod_security offre une configuration de règles flexible et un contrôle d’accès	Filtrage avancé, limitation de débit, support intégré pour l’atténuation des DDoS, et performance SSL/TLS
Communication cryptée (SSL/TLS)	Pris en charge	Pris en charge
Gestion des connexions concurrentes	Bonne	Très efficace
Performance d’échelonnement	Bonne	Exceptionnelle
Fonctionnalité de distribution de charge	Accessible avec des modules	Fonctionnalité intégrée
Performance et vitesse globales	Satisfaisante	Deux fois plus rapide qu’Apache

Architecture et Concurrence

L’une des différences les plus significatives entre NGINX et Apache est la manière dont ils gèrent les requêtes entrantes sous le capot.

Cela a un impact substantiel sur leur performance et leur efficacité en termes de ressources.

L’Architecture Basée Sur Les Processus D’Apache

Apache suit un modèle basé sur les processus, lançant un nouveau fil ou processus pour chaque requête entrante.

Ces processus ou threads sont gérés par des Modules Multi-Traitement (MPMs) :

• Prefork MPM : Le modèle original d’Apache. Chaque processus a un seul fil et gère une connexion à la fois. C’est simple mais peut être gourmand en mémoire.
• Worker MPM : Utilise plusieurs fils par processus, chacun gérant une seule connexion. C’est mieux que prefork pour la mémoire, mais le trafic intense et les demandes gourmandes en ressources peuvent encore créer un goulot d’étranglement au niveau du CPU, entraînant des problèmes de performance.
• Event MPM : Similaire au worker MPM mais optimisé pour les connexions keep-alive (appareils qui ne peuvent pas être déconnectés du serveur). Cependant, il n’est toujours pas entièrement asynchrone.

Ce sont tous de bons modules, mais ils ont un inconvénient majeur : Apache doit créer de nouveaux processus ou threads pour chaque connexion entrante et les détruire une fois terminés. Il essaie de gérer cela en pré-forkant certains processus inactifs à l’avance.

Cependant, si plusieurs personnes veulent se connecter au site simultanément, Apache pourrait dépasser son pool existant, et alors il doit rapidement créer plus de processus. Cela prend du temps et consomme de la mémoire.

Ce modèle fonctionne parfaitement bien pour les sites à faible ou moyen trafic. Même ainsi, Apache peut commencer à solliciter les sites avec de nombreuses connexions simultanées.

Tous ces processus séparés ne sont pas très efficaces. Même avec l’événement MPM, Apache ne peut pas complètement échapper au modèle un thread par connexion.

L’architecture événementielle de NGINX

NGINX adopte une approche très différente. Au lieu de processus ou de fils séparés pour chaque connexion, NGINX utilise une architecture asynchrone et pilotée par les événements.

Voici comment ça fonctionne : 

• NGINX utilise un processus principal (généralement un par cœur de CPU) qui gère plusieurs processus travailleurs. Chaque travailleur peut gérer des milliers de connexions simultanées. Il n’est pas nécessaire que les travailleurs génèrent de nouveaux fils ou dirigent chaque requête vers un processus dédié.
• À la place, les travailleurs disposent d’une boucle d’événements où ils surveillent efficacement les nouveaux événements sur les connexions existantes en utilisant les mécanismes du système d’exploitation, comme kqueue ou epoll. Cela leur permet de jongler avec plusieurs connexions dans un seul fil. Lorsqu’un événement se produit, comme une nouvelle requête arrivant ou un serveur backend répondant, NGINX le dispatche rapidement à un emplacement libre dans le travailleur.
• Cette méthode est bien plus efficace que le modèle d’Apache. NGINX peut gérer un nombre massif de requêtes avec une empreinte mémoire très faible. Il s’adapte incroyablement bien, c’est pourquoi il est utilisé pour de nombreux sites très fréquentés sur le web.

L’inconvénient est que NGINX ne peut pas intégrer des interprètes de code comme le fait Apache.

Alors, quand tu veux exécuter du code PHP ou Python, NGINX envoie les requêtes à un gestionnaire de processus FastCGI séparé comme php-fpm. Ce processus exécute le code et le traduit en quelque chose que le navigateur de l’utilisateur peut comprendre.

D’un autre côté, Apache peut exécuter des langages comme PHP, Perl et Python dans ses processus.

Puisque NGINX ne peut pas, le fichier config peut devenir un peu plus complexe.

Les gains de performance compensent généralement les désagréments.

Performance

NGINX est reconnu pour ses performances élevées lorsqu’il sert des fichiers statiques tels que des pages HTML, des images, des CSS et JavaScript.

L’architecture pilotée par les événements aide, mais NGINX possède également d’autres astuces.

Tout d’abord, contrairement à Apache, NGINX n’a pas besoin de passer par le cache et d’accéder au disque pour chaque requête. Il peut servir les fichiers directement depuis le disque. De plus, NGINX élimine la surcharge associée à la vérification des permissions et au verrouillage des fichiers.

Apache présente ces problèmes car chaque requête est un processus, et si un processus modifie quelque chose, l’autre processus ne peut pas utiliser le même fichier simultanément.

Bien que les petits sites ne remarquent pas ce goulot d’étranglement en raison de la rapidité du traitement en arrière-plan, un grand site avec quelques milliers de requêtes chaque seconde commencera à constater que ces problèmes ralentissent l’expérience utilisateur.

NGINX dispose également d’un cache de fichiers intégré. Lors de la première demande d’un fichier, NGINX le lit depuis le disque et le place dans son cache. Les demandes futures pour ce fichier peuvent être servies extrêmement rapidement directement depuis la mémoire sans toucher au disque. Il invalide également automatiquement les données en cache si le fichier sur le disque change.

Ces optimisations s’accumulent. Dans les benchmarks, NGINX peut souvent servir des fichiers statiques environ trois fois plus rapidement qu’Apache, surtout lorsque les requêtes concurrentes augmentent.

Un bonus : cela peut également t’aider à améliorer tes indicateurs web principaux, te donnant un petit coup de pouce sur Google.

Apache n’est pas lent non plus. Tu dois simplement passer du temps à l’ajuster pour qu’il fonctionne parfaitement. Il est également capable de servir des fichiers statiques très rapidement.

Mais NGINX est la solution à choisir si tu veux un serveur web performant dès le départ.

Configuration et Syntaxe

NGINX et Apache ont des philosophies de configuration différentes.

Apache est célèbre pour ses nombreuses options de configuration. En plus du apache2.conf, tu dois ajouter tes règles et configurations au fichier .htaccess.

Les fichiers de configuration utilisent une syntaxe de type XML et offrent une flexibilité incroyable. Apache possède une liste massive de directives que tu peux utiliser pour ajuster chaque aspect du comportement du serveur.

Tu peux définir des options de configuration globalement ou les remplacer pour des répertoires spécifiques ou des hôtes virtuels.

La véritable puissance d’Apache provient de son vaste écosystème de modules. Un large éventail de modules Apache officiels et tiers te permet de tout faire, du réécriture d’URL au filtrage de sécurité en passant par la mise en cache avancée. Pour utiliser un module, tu le charges dans ta configuration Apache.

L’autre inconvénient est que la configuration d’Apache peut rapidement devenir complexe, surtout pour les configurations sophistiquées. Les directives peuvent se chevaucher dans des chaînes d’héritage complexes. Les options de configuration sont souvent réparties dans plusieurs fichiers de différents sous-dossiers du dossier principal config. C’est extrêmement flexible, mais cela demande du temps pour maîtriser.

La configuration de NGINX, quant à elle, vise la simplicité et la lisibilité. Il n’y a pas de fichier .htaccess ici. Tu configures simplement les sites dans ton NGINX.conf ainsi que le dossier sites-enabled, et c’est tout bon.

La syntaxe emprunte son style à des langages de programmation courants. Elle reste puissante mais pas aussi étendue qu’Apache.

Au lieu de modules, NGINX dispose d’un ensemble plus restreint de directives principales et de fonctionnalités qui sont intégrées. Toutes tes options pour une fonctionnalité donnée sont généralement regroupées dans un bloc (entourées d’accolades { }).

Des fonctionnalités avancées comme l’équilibrage de charge et la mise en cache sont configurées dans le fichier principal NGINX.conf, et non réparties dans des fichiers annexes.

Le résultat est que les fichiers de configuration NGINX ont tendance à être plus épurés et plus accessibles à lire et à configurer que les lourds fichiers Apache, mais tu peux quand même faire beaucoup avec eux.

Sécurité

NGINX et Apache sont des projets open-source avec de grandes communautés actives de développeurs travaillant constamment à identifier et corriger les vulnérabilités. Ils bénéficient tous deux de mises à jour de sécurité régulières et ont un bon historique en matière de résolution rapide des problèmes.

Cela dit, il existe certaines différences dans leur approche de la sécurité.

Voici quelques points clés à considérer :

• Modularité : L’architecture modulaire d’Apache signifie que tu n’as besoin d’activer que les fonctionnalités que tu utilises, minimisant ainsi la surface d’attaque. Avec NGINX, de nombreuses fonctionnalités standard sont directement intégrées dans le noyau, ce qui, selon certains, le rend moins flexible du point de vue de la sécurité.
• Filtrage des requêtes : NGINX dispose d’un moteur de filtrage de requêtes intégré puissant qui peut aider à bloquer les attaques web courantes telles que l’injection SQL et les scripts intersites (XSS). Apache possède des capacités similaires grâce à des modules comme mod_security.
• Configuration SSL/TLS : Les deux serveurs prennent en charge SSL/TLS pour les connexions cryptées, mais NGINX est souvent considéré comme plus facile à configurer. Il dispose d’une documentation plus claire et de paramètres par défaut plus sécurisés dès le départ.
• Isolation des processus : L’utilisation par NGINX d’un processus principal unique avec plusieurs processus de travail peut aider à isoler les zones problématiques. Les MPM prefork et worker d’Apache peuvent fournir une isolation similaire au niveau du processus mais au prix d’une utilisation accrue des ressources.
• Atténuation des DDoS : L’architecture orientée événements de NGINX et son traitement efficace des connexions concurrentes en font un choix populaire pour atténuer les attaques DDoS de petite à moyenne taille. Quelques modules supplémentaires et des ajustements peuvent également rendre Apache résistant aux attaques DDoS.

Contenu Dynamique, Modules et Écosystème

Apache est depuis longtemps la référence pour servir du contenu dynamique car il intègre facilement les langages côté serveur. Avec les MPM prefork et worker, tu peux compiler le support pour des langages comme PHP, Python et Perl directement dans le binaire Apache.

Apache exécutera alors un interprète à l’intérieur de chacun de ses processus de travail. C’est simple et pratique — Apache peut transférer les demandes pour les fichiers .php à son interprète PHP intégré et obtenir en retour une sortie rendue.

NGINX n’a pas de support intégré pour les langages côté serveur. Tu as besoin d’un service séparé tel que php-fpm qui exécute l’interpréteur de langage pour utiliser PHP, Python ou Ruby on Rails avec NGINX. NGINX reçoit les requêtes et les transfère au backend, qui traite le code et renvoie une réponse.

Cela demande un peu plus de travail à configurer que l’approche tout-en-un d’Apache. Cela dit, cela correspond bien à la philosophie de NGINX de faire une chose (servir les requêtes) — et de le faire bien.

En ce qui concerne d’autres fonctionnalités, NGINX est livré avec un noyau serré de fonctionnalités bénéfiques telles que l’équilibrage de charge, la mise en proxy, le cache, la limitation du taux, la compression, et la terminaison SSL. Mais il n’égale pas l’incroyable étendue de l’écosystème de modules d’Apache. Avec Apache, tu as des modules pour les schémas d’authentification, le filtrage de contenu, les langages de script intégrés, et au-delà.

Tous ces éléments ne sont pas uniques. NGINX peut effectuer beaucoup des mêmes tâches, mais de manière différente. Cependant, la bibliothèque de modules d’Apache est assez étendue.

Si tu as besoin d’une fonctionnalité très spécifique, Apache pourrait avoir l’avantage ici.

Toutefois, l’ensemble de fonctionnalités de NGINX est robuste pour la plupart des besoins courants en matière de service web.

Utilisation Réelle, Performance, et Communauté

La popularité de NGINX a augmenté au cours de la dernière décennie.

En 2022, il alimente plus de 34% de tous les sites web mondiaux, contre environ 29% pour Apache.

Une chose à garder en tête : tu ne remarqueras pas la différence entre ces serveurs web à moins que tu n’aies un grand site web ou un très petit serveur.

Suppose que tu aimes les options de configuration étendues d’Apache et son approche tout-en-un pour le contenu dynamique. Les documents Apache sont parmi les meilleurs, et la communauté est immense si tu as besoin d’aide un jour.

NGINX pourrait être meilleur si tu cherches une concurrence maximale ou si tu construis un site immense. Son architecture est un peu plus tournée vers l’avenir et conçue pour l’évolutivité. Et la communauté NGINX s’est rapidement développée. Les documents sont également solides ; tu peux trouver de nombreux guides et supports.

Apache vs. NGINX : Lequel est fait pour toi ?

Il n’y a pas de réponse universelle au débat NGINX vs. Apache. Toutefois, voici quelques bonnes règles générales pour t’aider à prendre la décision.

NGINX est meilleur si :

• Tu as un site à très forte fréquentation.
• Tu as besoin de servir rapidement une grande quantité d’actifs statiques.
• Tu construis une architecture de microservices.
• Tu préfères un style de configuration plus épuré.
• Tu utilises des containers ou du Cloud Hosting où chaque once de mémoire compte.

Apache est meilleur si :

• Tu as besoin d’une compatibilité approfondie avec des fonctionnalités exclusives à Apache comme .htaccess.
• Tu souhaites des modules pour des fonctionnalités super spécifiques.
• Tu as besoin d’exécuter des applications web anciennes conçues pour Apache et mod_php.
• Tu es simplement attaché au système de configuration d’Apache.
• Ton serveur est principalement une boîte de développement, et la performance est moins critique.

Il n’y a aucune règle qui t’oblige à en choisir un.

Utiliser NGINX devant Apache comme proxy inverse est très courant. Cela te permet de combiner le service inégalé de fichiers statiques et le traitement simultané de NGINX avec le riche support de langage dynamique d’Apache sur le backend — le meilleur des deux mondes.

Conclusion

Apache et NGINX sont tous les deux excellents, donc choisir l’un ou l’autre dépend surtout de ce qui correspond le mieux à tes besoins.

Rappelle-toi, même le serveur web le plus puissant n’est qu’un engrenage dans la machine. Ainsi, si le site semble lent, le logiciel ou le matériel du serveur web ne devrait pas nécessairement être la première chose à optimiser.

Un cache plus intelligent, l’optimisation de la base de données, l’optimisation du code et un matériel sous-jacent solide peuvent tous contribuer à accélérer votre pile plus que de passer des heures à bidouiller NGINX ou Apache.

Si tu as besoin d’un serveur pour expérimenter, essaie le VPS géré de DreamHost. Avec un VPS, tu peux choisir quels logiciels installer, comment le serveur doit répondre aux requêtes, et plus encore. De plus, avec la flexibilité d’un VPS, tu peux héberger plusieurs sites web sur un seul serveur et répartir les ressources entre eux comme il convient.

De plus, tous les plans DreamPress incluent désormais NGINX.

Le seul moyen de trouver une configuration idéale est d’expérimenter. Lance un VPS, installe NGINX et Apache, et vois ce qui fonctionne le mieux pour toi !