NGINX s’est forgé à juste titre une réputation de serveur web extrêmement performant. Je pense que beaucoup de gens savent que NGINX peut également être utilisé comme proxy inverse, mais ils ne se rendent peut-être pas compte à quel point il est puissant dans ce rôle.
Qu’est-ce qu’un proxy inverse ?
Commençons par prendre un peu de recul et nous demander ce qu’est un serveur proxy. Je trouve que Wikipédia en donne une bonne définition :
« Un serveur proxy est un serveur (un système informatique ou une application) qui sert d’intermédiaire pour les requêtes de clients cherchant à accéder à des ressources provenant d’autres serveurs. »
Ainsi, un serveur proxy se place entre un client et le serveur réel qui héberge les données recherchées par le client. Pour le client, le serveur proxy semble être le véritable serveur backend, tandis que pour le serveur backend, le serveur proxy apparaît comme un client. Pour définir ce qu’est un serveur proxy inverse, revenons à Wikipédia :
« [Un] proxy inverse est un type de serveur proxy qui récupère des ressources pour le compte d’un client auprès d’un ou de plusieurs serveurs. »
La différence réside dans le fait qu’un serveur proxy se situe entre les clients et un seul serveur backend, tandis qu’un serveur proxy inverse se place devant un ou plusieurs serveurs backend et décide lequel utiliser pour chaque requête.
Quels sont les avantages d’utiliser un proxy inverse ?
Pourquoi utiliser un serveur proxy inverse ? Cela présente de nombreux avantages :
- Concurrence – Les applications Internet impliquent souvent un grand nombre de clients ouvrant chacun plusieurs connexions, ce qui génère un très grand nombre de connexions aux serveurs backend. De nombreux serveurs web et serveurs d’applications gèrent mal un nombre élevé de connexions (NGINX, lorsqu’il est utilisé comme serveur web, fait exception). L’ajout d’un proxy inverse capable de mieux gérer les connexions multiples peut donc améliorer considérablement les performances des serveurs backend.
- Résilience – Si les clients se connectent directement à un serveur backend et que celui-ci tombe en panne, les requêtes de tous les clients actuellement connectés (ou qui tentent de se connecter) au serveur échouent. Un serveur proxy inverse peut surveiller l’état des serveurs backend et cesser d’envoyer des requêtes à un serveur défaillant jusqu’à ce qu’il soit de nouveau opérationnel. Les clients ne voient aucune erreur, car le proxy inverse envoie automatiquement leurs requêtes aux serveurs backend qui sont toujours opérationnels.
- Évolutivité – Comme un proxy inverse constitue l’unique « interface publique » du groupe de serveurs backend, vous pouvez ajouter ou supprimer des serveurs en fonction des variations de la charge de trafic.
- Routage de couche 7 – Un proxy inverse voit le trafic destiné à tous les serveurs et peut décider intelligemment vers quel serveur envoyer chaque requête, en modifiant les requêtes et les réponses si nécessaire. Il peut prendre ses décisions de routage en fonction d’un en-tête HTTP particulier de la requête, d’une partie d’une URL, de la localisation géographique du client, etc.
- Mise en cache – Un proxy inverse est idéal pour effectuer la mise en cache : il est généralement bien plus efficace d’y mettre le contenu en cache que d’envoyer toutes les requêtes aux serveurs backend et de laisser chacun d’eux créer son propre cache.
- Autres fonctions – Placé devant les serveurs backend, un proxy inverse peut également assurer d’autres fonctions, telles que la régulation du trafic en fonction de la bande passante ou du taux de requêtes, la limitation des connexions, l’intégration à différents systèmes d’autorisation, la surveillance de l’activité, et bien plus encore.
Utiliser NGINX Plus comme proxy inverse
NGINX Plus enrichit encore les fonctionnalités de serveur web réputées de NGINX Open Source, faisant de NGINX Plus un contrôleur de mise à disposition d’applications (ADC) complet, capable de remplacer les appliances matérielles propriétaires.
Voici quelques-unes des fonctionnalités disponibles dans NGINX Plus.
Répartition de charge
Vous pouvez choisir parmi plusieurs algorithmes d’équilibrage de charge, pondérés ou non. La persistance de session est également prise en charge. NGINX Plus peut équilibrer la charge pour HTTP, HTTPS, WebSocket, FastCGI, memcached, SCGI, SPDY [rendu obsolète par HTTP/2, dont NGINX Plus assure également l’équilibrage de charge] et uwsgi. En savoir plus.
Contrôles d’intégrité
La surveillance passive et active de l’état des serveurs backend est prise en charge. Si NGINX Plus ne parvient pas à se connecter à un nœud, celui-ci est marqué comme indisponible. Des contrôles d’état actifs peuvent également être configurés pour s’exécuter périodiquement sur les nœuds backend. En outre, la fonctionnalité de démarrage progressif permet à NGINX Plus d’augmenter graduellement le trafic vers un nœud qui vient d’être mis en ligne, afin d’éviter de le surcharger par un afflux soudain de trafic important. En savoir plus.
Routage des requêtes
Le trafic peut être acheminé en fonction de n’importe quelle partie d’une requête, telle que l’adresse IP du client, le nom d’hôte, l’URI, la chaîne de requête, les en-têtes, etc.
Réécriture des requêtes et des réponses
Toutes les parties d’une requête ou d’une réponse peuvent être modifiées, notamment les en-têtes, le corps et l’URI. NGINX Plus permet également d’ajouter et de supprimer des en-têtes. En savoir plus.
Mise en cache
Les réponses peuvent être mises en cache, et vous pouvez configurer les types de contenu à mettre en cache ainsi que la durée de leur mise en cache. Vous pouvez également supprimer des éléments du cache. En savoir plus.
Compression
La compression Gzip est prise en charge, avec un contrôle précis du contenu à compresser et des conditions d’utilisation de la compression. En savoir plus.
Traitement SSL/TLS
Le déchiffrement et le chiffrement SSL/TLS sont pris en charge, et le déchiffrement peut être effectué pour de nombreux noms de domaine à l’aide de différents certificats. En savoir plus.
Surveillance et journalisation de l’activité en temps réel
Les statistiques de NGINX Plus encodées au format JSON sont accessibles au moyen d’une simple requête HTTP. Une page Web de tableau de bord permet de les afficher, mais vous pouvez également les transmettre à des outils de surveillance personnalisés ou tiers. Des journaux au format personnalisé peuvent être configurés pour la journalisation locale et l’exportation vers syslog. En savoir plus.
Et bien plus encore
NGINX offre de nombreuses autres fonctionnalités, telles que la prise en charge du streaming vidéo, du proxy de messagerie et de GeoIP, les redémarrages progressifs et les mises à niveau sans interruption de service, la régulation du trafic, la limitation des connexions, et bien plus encore. Pour plus d’informations, consultez nginx.com et nginx.org.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.