Proxy HTTP, équilibrage de charge, mise en mémoire tampon et mise en cache Nginx : un aperçu

Introduction

Nginx est un serveur web haute performance qui est également utilisé comme proxy inverse, proxy de messagerie, répartiteur de charge et cache HTTP. Nginx est gratuit et open-source, permettant à quiconque de le télécharger et de l'utiliser dans son environnement de serveur.

Vous avez peut-être déjà utilisé Nginx pour héberger des sites web. Dans ce tutoriel, nous aborderons les autres fonctionnalités de Nginx. La fonctionnalité de proxy HTTP de Nginx lui permet de transmettre les requêtes à des serveurs HTTP d'arrière-plan pour traitement. Grâce à cette fonctionnalité, vous pouvez configurer plusieurs serveurs d'arrière-plan. Elle vous permet de faire évoluer votre infrastructure selon vos besoins pour gérer les pics de requêtes des clients.

Au fur et à mesure de la progression de ce tutoriel, vous apprendrez à faire évoluer votre infrastructure en utilisant les propriétés de répartition de charge de Nginx, de mise en mémoire tampon, et de mise en cache des réponses pour améliorer les performances de votre serveur tout en garantissant une meilleure expérience pour les clients. Commençons !

Tout d'abord, pour commencer avec Nginx, jetez un coup d'œil à notre tutoriel sur la façon d'installer Nginx sur votre serveur Ubuntu.

Informations générales sur le proxying

Si vos connaissances sur les serveurs web se limitent au traitement des requêtes de sites web et à la diffusion de pages web, vous vous demandez peut-être pourquoi nous avons besoin de relayer les requêtes par proxy. Ci-dessous, nous en expliquerons les raisons.

L'une des raisons de relayer les requêtes vers d'autres serveurs depuis Nginx est de soutenir l'évolutivité de votre infrastructure. Par défaut, Nginx gère de nombreuses connexions simultanément. Cela en fait le point de contact idéal pour les clients. Il peut ensuite transmettre les requêtes à différents serveurs d'arrière-plan pour gérer le traitement réel des requêtes des clients. C'est ce qui répartit la charge. Par conséquent, cela garantit que vous pouvez faire évoluer votre infrastructure autant que possible. Cela vous permet également de mettre hors service certains serveurs pour maintenance pendant que d'autres continuent de répondre aux requêtes.

La deuxième raison pour laquelle vous pourriez vouloir relayer des requêtes vers d'autres serveurs est lorsque vous utilisez des serveurs d'applications qui ne sont pas adaptés pour gérer directement les requêtes des clients dans des environnements de production réels. Plusieurs frameworks, y compris des serveurs web, ne sont pas adaptés pour des performances élevées comme Nginx. Laisser Nginx être le point d'entrée et relayer les requêtes vers ces serveurs moins performants peut garantir une meilleure expérience à vos utilisateurs. De plus, cela peut garantir une sécurité accrue pour votre application.

Le processus de proxying des requêtes dans Nginx consiste à manipuler une requête provenant du serveur Nginx et à la transmettre à d'autres serveurs d'arrière-plan pour le traitement réel. Une fois que les autres serveurs d'arrière-plan ont traité la requête, ils renvoient le résultat à Nginx. Celui-ci envoie ensuite le résultat sous forme de réponse au client. Le client dans ce cas est un navigateur web ou même une application web mobile. Les autres serveurs d'arrière-plan peuvent être des serveurs locaux qui ne sont pas accessibles publiquement sur Internet, des serveurs distants, ou même d'autres serveurs virtuels au sein des configurations de blocs de serveurs Nginx. Ces autres serveurs vers lesquels Nginx relaye les requêtes sont appelés serveurs amont.

Nginx peut relayer des requêtes vers des serveurs qui communiquent à l'aide de plusieurs protocoles, notamment HTTP(S), Memcached, SCGI, FastCGI, et uWSGI. Pour chaque type de protocole, il existe des ensembles de directives. Ce tutoriel se concentre sur le protocole HTTP. Nginx analyse les requêtes et les composants de message dans un format que le serveur amont peut interpréter et traiter.

Analyse d'un Proxy Pass HTTP de base

Le type de proxy le plus simple consiste à transmettre une requête à un seul serveur qui communique via HTTP. Ce type de proxy est généralement appelé « proxy pass » et est géré par la directive bien nommée proxy_pass dans les fichiers de configuration Nginx.

La directive proxy_pass apparaît dans les blocs location. Elle se trouve également dans les blocs d'un contexte location et dans les contextes limit_except. Lorsqu'une requête correspond à un emplacement contenant une directive proxy_pass, la requête est envoyée à l'URL spécifiée par la directive. Voici un exemple d'extrait de configuration :

Dans l'exemple ci-dessus, les requêtes vers le port 80 iraient vers localhost:3000 :

La capture d'écran ci-dessus montre la page Nginx par défaut lorsque vous essayez d'accéder à localhost. Après avoir redémarré le serveur Nginx avec la directive proxy pass en vigueur, toutes les requêtes iront vers le port 3000. Une application de démonstration s'exécute sur le port 3000, comme vous pouvez le voir sur l'image ci-dessous, et vous pouvez y accéder directement depuis localhost sans spécifier le port :

Dans l'exemple suivant, aucun URI n'a été spécifié à la fin du serveur dans la définition proxy_pass. Pour les définitions correspondant à ce modèle, l'URI demandé par le client sera transmis au serveur amont tel quel.

Par exemple, lorsque ce bloc gère une requête pour /match/url/here, l'URI de la requête ira vers le serveur example.com sous la forme http://example.com/match/url/here.

Voici ci-dessous un exemple d'extrait de configuration alternative :

Comme vous pouvez le voir dans l'extrait ci-dessus, nous avons défini un segment d'URI à la fin du serveur proxy sous la forme new/url/prefix. Lorsque vous définissez un URI dans la définition proxy_pass, la partie de la requête qui correspond à la définition de l'emplacement (location) est remplacée par cet URI lors de l'envoi au serveur amont pour traitement.

Par exemple, une requête pour /match/url/here sur le serveur Nginx est transmise au serveur amont sous la forme http://example.com/new/url/here. Le /match/url est remplacé par /new/url. Gardez ce point à l'esprit.

Dans certains cas, la transmission des URI comme ci-dessus n'est pas possible. Dans de tels cas, Nginx ignore l'URI à la fin de la définition proxy_pass. En fin de compte, soit l'URI d'origine du client, soit l'URI modifié par d'autres directives est transmis au serveur amont.

Un exemple est lorsque des expressions régulières correspondent à la localisation (location). Nginx peut ne pas être en mesure de déterminer quelle partie de l'URI correspond à l'expression. Par conséquent, il envoie l'URI de la requête client d'origine. Cela entraîne la réécriture et la gestion de l'URI client dans le même bloc. Dans un tel cas, l'URI réécrit est transmis.

Comment Nginx traite-t-il les en-têtes ?

Les en-têtes sont essentiels à la manière dont un serveur traite une requête. Certains en-têtes peuvent inclure des informations d'authentification. Par conséquent, nous devons comprendre comment le proxying Nginx traitera les en-têtes. La requête proxy de Nginx vers le serveur amont sera différente de celle provenant directement du client. Certaines de ces différences résultent des en-têtes qui accompagnent la requête proxy.

Lors du proxying d'une requête, Nginx apportera des ajustements aux en-têtes de requête qu'il reçoit du client. Certains de ces ajustements incluent :

• Supprimer tous les en-têtes vides. Les en-têtes vides ne font que gonfler la requête, il est donc inutile de les transmettre au serveur amont.

• Tous les en-têtes contenant des traits de soulignement (underscores) sont considérés comme invalides par défaut, et donc supprimés de la requête. Si vous souhaitez modifier ce comportement et autoriser Nginx à interpréter les en-têtes avec des traits de soulignement comme valides, vous pouvez définir la directive underscores_in_headers sur « on ». Si vous ne le faites pas, ces en-têtes du client n'atteindront jamais le serveur amont.

• L'en-tête « Host » est réécrit avec la valeur spécifiée par la variable $proxy_host. Il s'agit de l'adresse IP ou du nom et du numéro de port du serveur amont, comme spécifié par la directive proxy_pass.

• La valeur de l'en-tête « Connection » passe à « close ». L'en-tête de connexion contient des informations sur une connexion particulière établie entre deux parties. Lorsque Nginx définit sa valeur sur close, cela indique au serveur amont que la connexion se fermera une fois qu'il aura été répondu à la requête d'origine, et qu'il ne doit donc pas s'attendre à ce qu'il s'agisse d'une connexion persistante.

Voici quelques points que nous pouvons noter à partir des ajustements des en-têtes de requête proxy décrits ci-dessus :

• Si vous ne souhaitez pas qu'un en-tête soit transmis au serveur amont, le définir sur une chaîne vide le supprimera complètement de la requête.

• Si l'application de votre serveur amont doit traiter des en-têtes non standard, assurez-vous que ces en-têtes ne contiennent pas de trait de soulignement (underscore). En option, vous pouvez définir la directive underscores_in_headers sur « on » dans votre configuration (valable soit dans le contexte de la déclaration du serveur par défaut pour la combinaison adresse IP/port, soit dans le contexte HTTP). Cela garantira que les en-têtes ne seront pas signalés comme invalides et seront donc effectivement transmis au serveur amont.

• L'en-tête « Host » est très important dans la plupart des situations de proxy. Par défaut, il est défini sur la valeur de $proxy_host, une variable contenant le nom de domaine ou l'adresse IP et le port récupérés à partir de la spécification proxy_pass. Cette adresse est sélectionnée par défaut et extraite directement des informations de connexion. C'est la seule adresse pour laquelle Nginx a la garantie que le serveur amont répondra.

Voici ci-dessous les valeurs les plus courantes pour l'en-tête « Host » :

• $host – une variable définie par ordre de préférence sur le nom d'hôte de la ligne de requête elle-même, l'en-tête « Host » de la requête client, ou le nom du serveur correspondant à la requête.

• $http_host – une variable qui définit l'en-tête « Host » sur l'en-tête « Host » de la requête client. Les en-têtes de la requête du client sont toujours disponibles pour Nginx sous forme de variables. Ces variables commencent par un préfixe $http_, suivi du nom de l'en-tête en minuscules. Bien que la variable $http_host fonctionne généralement bien, lorsque la requête du client ne contient pas d'en-tête « Host » valide, cela peut entraîner l'échec de la transmission.

• $proxy_host – une variable qui définit l'en-tête « Host » sur la combinaison de nom de domaine ou d'adresse IP et de port récupérée à partir de la spécification de proxy_pass. Il s'agit du comportement par défaut du point de vue de Nginx, et il est donc considéré comme sûr. Cependant, cela peut ne pas correspondre à ce dont le serveur a besoin pour traiter correctement la requête.

La plupart des configurations impliquent de définir l'en-tête « Host » sur la variable $host. Elle est extrêmement flexible et fournira des en-têtes correctement renseignés au serveur amont.

Définition et modification des en-têtes

La directive proxy_set_header nous permet de définir ou de modifier les en-têtes pour les connexions proxy. Pour l'en-tête « Host » mentionné précédemment, nous pouvons procéder comme suit pour modifier et ajouter des en-têtes supplémentaires couramment utilisés avec les requêtes mandatées :

Dans l'extrait de configuration ci-dessus, nous définissons l'en-tête « Host » sur la variable $host qui contient des informations sur l'hôte d'origine demandé. Nous définissons l'en-tête X-Forwarded-Proto avec des informations sur le schéma de la requête d'origine du client (il peut s'agir d'une requête HTTP ou HTTPS).

Nous transmettons l'adresse IP réelle du client à X-Real-IP. Cela permet au serveur amont de prendre des décisions appropriées ou de stocker des journaux basés sur l'origine IP du client. L'en-tête X-Forwarded-For contient une liste de toutes les adresses IP appartenant aux serveurs par lesquels le client a été relayé avant d'atteindre ce point. Dans l'extrait de code ci-dessus, nous le définissons sur la variable $proxy_add_x_forwarded_for. Cette variable prendra la valeur de l'en-tête X-Forwarded-For d'origine récupéré auprès du client et ajoutera l'adresse IP du serveur proxy Nginx à la fin.

Si vous souhaitez que les directives proxy_set_header soient référencées dans plusieurs blocs location, vous pouvez les déplacer vers le contexte server ou http. Considérez l'extrait de configuration ci-dessous :

Définir un contexte upstream pour l'équilibrage de charge des connexions proxy

Jusqu'à présent, vous comprenez comment effectuer un proxy HTTP simple vers un seul serveur amont en arrière-plan. Heureusement, avec Nginx, vous pouvez faire évoluer une telle configuration en définissant des pools de serveurs d'arrière-plan auxquels transmettre les requêtes pour traitement.

Nginx fournit une directive appelée upstream qui est utilisée pour définir un pool de serveurs. Dans la configuration de la directive, vous ne devez spécifier que des serveurs capables de gérer la requête d'un client. Nginx en tant que serveur proxy permet de faire évoluer l'infrastructure avec un minimum d'effort. La directive upstream doit être spécifiée dans le contexte http de votre configuration Nginx.

Voici un exemple montrant la directive upstream :

Dans l'extrait de code de configuration ci-dessus, nous avons défini un contexte upstream appelé several_backend_hosts. Le nom du contexte défini est désormais disponible dans les passes de proxy (proxy passes). Il peut être utilisé comme s'il s'agissait d'un domaine normal, comme le montre l'exemple. Dans le bloc server, nous transmettons toutes les requêtes adressées à example.com/proxy-me/… au pool que nous avons défini à l'aide de la directive upstream, dans ce cas, several_backend_hosts. Un hôte est sélectionné au sein du pool pour gérer les requêtes entrantes en appliquant un algorithme configurable. Par défaut, la sélection suit un round-robin (circulaire) – chaque requête est acheminée vers un hôte différent à son tour.

Comment modifier l'algorithme d'équilibrage de l'upstream

Comme souligné ci-dessus, le processus de sélection suit un processus round-robin. Dans cette section, nous verrons comment modifier l'algorithme d'équilibrage utilisé par le pool upstream. Pour modifier l'algorithme, vous incluez d'autres directives ou drapeaux (flags) dans le contexte upstream comme défini ci-dessous :

• (round-robin) – si aucune autre directive d'équilibrage upstream n'est spécifiée, alors par défaut, chaque serveur défini dans le contexte upstream reçoit les requêtes séquentiellement à son tour.

• least_conn – cette directive indique à l'upstream de sélectionner le serveur d'arrière-plan ayant le moins de connexions actives. Cela s'applique dans les situations où les connexions à un serveur d'arrière-plan peuvent persister pendant un certain temps.

• hash – cette directive est courante pour le proxying memcached. Les connexions sont transmises aux serveurs d'arrière-plan en fonction de la valeur d'une clé de hachage fournie de manière aléatoire. La valeur de la clé de hachage peut être des variables, du texte ou une combinaison des deux. hash se trouve être la seule méthode d'équilibrage nécessitant une saisie de la part des utilisateurs pour servir de clé à utiliser pour le hachage.

• ip_hash – cette directive indique à l'upstream de distribuer les requêtes à différents serveurs en fonction de l'adresse IP du client. Les trois premiers octets de l'adresse IP constituent la clé permettant de déterminer quel serveur doit traiter une requête. Un avantage de cette directive est que les clients ont tendance à recevoir le même serveur à chaque fois, assurant ainsi la cohérence de la session.

Voici un exemple de la façon dont nous pouvons ajouter la directive d'algorithme d'équilibrage au contexte upstream :

Dans l'extrait ci-dessus, Nginx sélectionnera l'un des serveurs ayant le moins de connexions pour traiter une requête entrante. La directive ip_hash suit la même syntaxe. Pour la directive hash, vous devez fournir une clé de votre choix pour effectuer le hachage, voici un exemple :

Le hachage utilisé ici sera le résultat de l’adresse IP et du port du client. Le paramètre optionnel consistent implémente l’algorithme de hachage cohérent ketama. Cela garantit un impact minimal sur votre cache si vous deviez modifier vos serveurs amont.

Comment spécifier le poids des serveurs pour l'équilibrage

Par défaut, lorsque vous déclarez des serveurs d'arrière-plan, chaque serveur a le même poids. On suppose que chaque serveur dispose des ressources et des capacités nécessaires pour gérer la même quantité de charge, bien sûr, cela prend en compte l'algorithme d'équilibrage que vous spécifiez dans le contexte amont. Pour modifier ce comportement par défaut, vous pouvez définir un poids alternatif pour chaque serveur lors de la déclaration. Prenons un exemple :

Dans cet exemple, host1.example.com recevra deux fois plus de trafic que les deux autres serveurs. Le poids de chaque serveur est de un par défaut.

Libérer les serveurs d'arrière-plan grâce aux tampons

Lors de la configuration du proxy dans la configuration de votre serveur, vous pouvez vous inquiéter de l'impact sur les performances de l'ajout de serveurs supplémentaires au processus. Heureusement, Nginx est doté de fonctionnalités de mise en tampon et de mise en cache qui peuvent aider à atténuer ces problèmes de performances.

La vitesse de deux connexions différentes va certainement affecter l'expérience d'un client lors du passage par un proxy vers un autre serveur :

• La première connexion va du client au proxy Nginx.

• La deuxième connexion va du proxy Nginx au serveur amont d'arrière-plan.

Nginx peut ajuster son comportement pour aider à optimiser l'une ou l'autre des connexions selon les besoins.

Si nous supprimons les tampons, la transmission des données depuis le serveur amont vers le client commence immédiatement au niveau du proxy Nginx. Si vous savez que vos clients sont rapides, vous pouvez désactiver complètement la mise en tampon pour vous assurer que les données parviennent assez rapidement au client. Lorsque la mise en tampon est activée, le proxy Nginx stocke temporairement les données de réponse reçues du serveur amont d'arrière-plan. Ensuite, il envoie les données au client en fonction de sa vitesse. Une fois que Nginx a la réponse dans ses tampons, il peut fermer la connexion avec le serveur d'arrière-plan. Il distribuera ensuite les données au client à une vitesse que ce dernier prend en charge. En même temps, cela permet au serveur d'arrière-plan de continuer à traiter d'autres requêtes entrantes.

Par défaut, Nginx aura la mise en tampon activée. En effet, nous ne pouvons pas connaître la vitesse de connexion des clients. Les clients ont tendance à avoir des connexions différentes qui peuvent être plus lentes. Ci-dessous, nous définirons les différentes directives que nous pouvons spécifier pour ajuster le comportement de mise en tampon de Nginx. Les directives peuvent être définies dans les contextes http, server ou location, cependant, vous devez noter que les directives de dimensionnement sont configurées par requête. Par conséquent, les augmenter au-delà de ce qui est absolument nécessaire peut affecter les performances de votre serveur lorsqu'il y a trop de requêtes clients entrantes. Voici les directives :

• proxy_buffering – la directive qui contrôle si la mise en mémoire tampon est active pour un contexte particulier et ses contextes enfants. La configuration par défaut pour proxy_buffering est « on ».

• proxy_buffer_size – la directive qui spécifie la taille du tampon pour stocker les en-têtes trouvés dans une réponse d'un serveur d'arrière-plan. Les en-têtes constituent la première partie de la réponse d'un serveur d'arrière-plan. La mise en mémoire tampon de ces en-têtes est distincte du reste de la réponse. Par défaut, la taille définie de ce tampon est la même que celle de proxy_buffers. Cependant, si les informations d'en-tête sont de petite taille, vous pouvez définir la taille sur une valeur inférieure.

• proxy_buffers – la directive contrôlant le nombre (premier argument) et la taille (second argument) des tampons pour les réponses mandatées. La configuration par défaut spécifie 8 tampons d'une taille égale à une page mémoire (soit 4k, soit 8k). Vous pouvez autoriser la mise en mémoire tampon de plus d'informations en augmentant le nombre de tampons.

• proxy_max_temp_file_size – la directive spécifiant la taille maximale, par requête, d'un fichier temporaire sur le disque. Les fichiers temporaires sont créés lorsque la réponse en amont est trop grande pour tenir dans un tampon.

• proxy_busy_buffers_size – la directive spécifiant la taille maximale des tampons qui peuvent être considérés comme « prêts pour le client » et donc occupés. Un client ne peut lire les données que d'un seul tampon à la fois. Cependant, les tampons sont dans une file d'attente pour être envoyés au client par lots. Vous pouvez spécifier la taille de l'espace tampon autorisé à être dans cet état en modifiant cette directive.

• proxy_temp_file_write_size – la directive spécifiant la quantité de données que Nginx écrira dans le fichier temporaire en une seule fois lorsque la réponse du serveur d'arrière-plan en amont est trop grande pour tenir dans les tampons configurés.

• proxy_temp_path – la directive spécifiant le chemin d'accès à l'emplacement sur le disque où Nginx doit stocker les fichiers temporaires lorsque la réponse du serveur d'arrière-plan en amont est trop grande pour tenir dans les tampons configurés.

Nginx est hautement personnalisable, vous fournissant plusieurs directives pour ajuster le comportement de mise en mémoire tampon. Dans la plupart des cas, les valeurs par défaut fonctionneront très bien. En même temps, il est bon de savoir que vous pouvez ajuster certaines de ces valeurs pour votre implémentation personnalisée. Vous souhaiterez principalement ajuster les directives proxy_buffers et proxy_buffer_size.

Ci-dessous se trouve un exemple qui augmente le nombre de tampons proxy disponibles pour chaque requête en amont. Il le fait tout en réduisant la taille du tampon qui stocke les en-têtes :

Voyons comment vous pouvez servir les données plus rapidement aux clients rapides en désactivant complètement la mise en mémoire tampon. S'il s'avère que votre client n'est pas assez rapide, Nginx utilisera automatiquement des tampons. Cependant, il videra d'abord les données vers le client au lieu d'attendre les pools de tampons. Cette configuration présente un inconvénient. Elle maintient la connexion au serveur en amont ouverte pour les clients lents jusqu'à ce que le client ait reçu toutes les données de réponse. Si la mise en mémoire tampon est définie sur « off », seul le tampon défini par la directive proxy_buffer_size sera utilisé. Voici un extrait montrant comment spécifier la désactivation de la mise en mémoire tampon :

• Configuring a Highly Available(HA) Infrastructure (Optional setup)

Vous pouvez ajouter un ensemble redondant de répartiteurs de charge à la configuration du proxy Nginx pour la rendre plus robuste et, par conséquent, hautement disponible. Une configuration de haute disponibilité (HA) est une infrastructure sans point de défaillance unique. Les répartiteurs de charge font partie de cette configuration. Avec plus d'un répartiteur de charge, vous pouvez éviter les temps d'arrêt potentiels si un répartiteur de charge tombe en panne ou est mis hors ligne pour maintenance.

Comment implémenter la mise en cache du proxy Nginx pour réduire les temps de réponse

Dans la section précédente, nous avons vu comment utiliser la mise en mémoire tampon pour libérer les serveurs backend afin qu'ils puissent traiter plus de requêtes. Nginx propose une autre fonctionnalité qui nous permet de mettre en cache les données de réponse du backend. Elle élimine complètement le besoin de se connecter au serveur amont pour toutes les requêtes entrantes.

Implémentation d'un cache proxy

La directive proxy_cache_path nous permet de configurer un cache en spécifiant une zone sur le disque à utiliser pour stocker le contenu proxifié. La directive proxy_cache_path est définie dans le contexte http.

L'extrait de code de configuration ci-dessous est un exemple de la façon dont vous pouvez implémenter un système de mise en cache :

Dans cet extrait de code, nous avons utilisé la directive proxy_cache_path pour définir un répertoire sur le système de fichiers qui contiendra notre cache. Le répertoire /var/lib/nginx/cache est celui que nous avons défini dans ce cas. Vous êtes libre de définir le chemin de répertoire de votre choix. Utilisez les commandes suivantes pour créer les répertoires de votre choix, avec les autorisations et la propriété appropriées :

Dans l'extrait de code, le paramètre levels= spécifie l'organisation du cache. Nginx va créer une clé de cache en hachant la valeur d'une clé (spécifiée à l'aide de la directive proxy_cache_key). Les niveaux que nous avons spécifiés (1:2) indiquent qu'un répertoire à un seul caractère (c'est-à-dire le dernier caractère de la valeur hachée) avec un sous-répertoire à deux caractères (pris à partir des deux caractères suivants depuis la fin de la valeur hachée) sera créé. Dans la plupart des cas, cela ne vous concernera pas. Cependant, il est bon de savoir comment cela aide Nginx à trouver rapidement les valeurs pertinentes.

Le paramètre keys_zone= définit le nom d'une zone de cache, dans notre cas nous l'avons nommée backendcache. Ici, nous définissons également la quantité de métadonnées que nous voulons stocker. Dans cet exemple, nous stockons 8 Mo de clés. Nginx peut stocker environ 8000 entrées pour chaque mégaoctet. Le paramètre max_size spécifie la taille maximale des données réellement mises en cache, soit 50 Mo pour notre exemple.

Vous devriez également remarquer la directive proxy_cache_key utilisée. Cette directive spécifie la clé que nous utiliserons pour stocker les valeurs mises en cache. Nous utiliserons la même clé pour vérifier si la requête existe dans le cache. Nous avons spécifié que cette clé soit une combinaison du schéma (http ou https), de la méthode de requête HTTP, ainsi que de l'hôte et de l'URI demandés.

De plus, nous avons utilisé la directive proxy_cache_valid. Cette directive peut être spécifiée plusieurs fois pour différents codes d'état. Elle nous permet de spécifier combien de temps stocker les valeurs en fonction du code d'état. Dans l'extrait de code, nous avons spécifié 10 minutes pour les codes de succès et 1 minute pour les réponses 404.

Puisque nous avons configuré la zone de cache, l'étape suivante consiste à appliquer la configuration en indiquant à Nginx quand utiliser le cache. Ci-dessous se trouve un extrait de configuration montrant comment nous pouvons implémenter l'utilisation de ce cache :

Dans la directive proxy_cache, nous avons spécifié que la zone de cache backendcache doit être utilisée pour ce contexte. Si vous avez choisi un nom différent dans la configuration du cache, c’est ici que vous le remplacerez. Pour chaque entrée valide, Nginx vérifiera le cache avant de transmettre une requête au serveur amont (backend).

Nous définissons la directive proxy_cache_bypass pour utiliser la variable $http_cache_control. Cette variable indique au serveur s’il doit répondre avec une réponse mise en cache ou une version fraîche et non mise en cache de la ressource. Définir correctement cette directive permet à Nginx de gérer correctement différents types de requêtes entrantes provenant des clients.

Un en-tête supplémentaire appelé X-Proxy-Cache est également spécifié. Cet en-tête a pour valeur la variable $upstream_cache_status. Il nous donne des informations sur le fait que la requête a donné lieu à un succès de cache (cache hit), un échec de cache (cache miss) ou si le cache a été explicitement contourné. De telles informations peuvent être utiles pour le client et cruciales lors du débogage des applications.

Points importants concernant la mise en cache des résultats

Bien que la mise en cache améliore considérablement les performances de votre serveur proxy, vous devez prendre note de ce qui suit lors de la mise en œuvre de la mise en cache :

Toutes les données relatives aux informations personnelles d’un utilisateur ne doivent pas être mises en cache, afin d’éviter les scénarios où les données d’un utilisateur sont visibles par un autre utilisateur.

Vos serveurs d’arrière-plan doivent prendre en compte tous les éléments dynamiques de votre site Web. Nous avons plusieurs en-têtes Cache-Control que nous pouvons spécifier dans notre réponse pour répondre à différents objectifs. Discutons-en :

• no-cache – spécifie que le proxy doit vérifier si les données ont changé sur le backend avant de renvoyer une réponse. Cela s’applique aux données dynamiques et importantes. Un en-tête de métadonnées hachées ETag est vérifié à chaque requête et si le backend renvoie la même valeur de hachage, la valeur précédente est alors servie.

• no-store – spécifie qu’aucune mise en cache ne doit être effectuée pour les données reçues, par conséquent, chaque requête ira vers le serveur pour obtenir des données fraîches. C’est l’option la plus sûre pour les données sensibles.

• private – spécifie qu’aucun espace de cache partagé ne doit mettre les données en cache. Vous pouvez utiliser cet en-tête pour spécifier la mise en cache dans le navigateur de l’utilisateur, mais aussi pour informer le serveur proxy de considérer les données comme invalides pour les requêtes ultérieures.

• public – spécifie une réponse publique et permet la mise en cache à n’importe quel point de la connexion.

Vous pouvez spécifier la durée de validité du cache en secondes à l’aide de l’en-tête max-age. Les différents en-têtes définis ci-dessus peuvent vous aider à implémenter la mise en cache tout en protégeant les données sensibles, en gardant les données dynamiques fraîches et, surtout, en améliorant les performances de votre serveur.

Si vos serveurs d’arrière-plan exécutent des serveurs Nginx, vous pouvez spécifier dans les blocs server la durée de validité d’un cache. Vous pouvez le faire en ajoutant la directive expires à la configuration comme indiqué ci-dessous :

Le premier bloc permet la mise en cache du contenu pendant 59 minutes, tandis que le second bloc indique qu’il n’y a pas de mise en cache. Ces paramètres s’appliquent aux options des en-têtes Cache-Control, par exemple, « no-cache » pour le second bloc.

Vous pouvez utiliser la directive add-header pour définir des valeurs supplémentaires :

Conclusion

Dans ce tutoriel, nous avons découvert les fonctionnalités puissantes de Nginx. Nginx est à la fois un serveur Web et, surtout, un proxy inverse. La conception de Nginx lui permet de gérer des milliers de connexions simultanées. Cela le rend parfait pour la répartition de charge. Grâce à cette conception, la transmission de requêtes vers d’autres serveurs d’arrière-plan pour traitement est assez simple.

Avec les connaissances acquises dans ce tutoriel, vous devriez être en mesure d'implémenter des proxys et des équilibreurs de charge complexes, grâce à la flexibilité de Nginx.

Voici quelques ressources que vous pouvez trouver sur notre blog qui peuvent vous aider à vous familiariser davantage avec Nginx :

• Comment sécuriser Nginx avec Let’s Encrypt sur Ubuntu 20.04

• Comment installer la pile LEMP (Linux, Nginx, MySQL PHP) sur Ubuntu 20.04

• Le monde des serveurs web : Apache vs Nginx

• Déployer Laravel, Nginx et MySQL avec Docker Compose

Bonne informatique !