Présentation de NGINX 1.18 et 1.19

Nous publions aujourd’hui NGINX 1.19, la dernière version de NGINX Open Source, le serveur web le plus populaire sur Internet. Cette publication marque le lancement de la branche de développement NGINX 1.19, après la publication, le mois dernier, de la branche stable NGINX 1.18.

Dans cet article, nous présentons le système de gestion des versions de NGINX, revenons sur les événements qui ont marqué le cycle de développement de NGINX 1.17 et évoquons ce que nous réserve NGINX 1.19.

Comprendre la gestion des versions de NGINX

Chez NGINX, nous maintenons deux branches dans le dépôt de code de NGINX Open Source, appelées « mainline » et « stable » :

• Mainline est la branche de développement active dans laquelle sont ajoutés les dernières fonctionnalités et les derniers correctifs de bogues. Elle est désignée par un nombre impair dans la deuxième partie du numéro de version, par exemple 1.19.0.
• Stable reçoit des correctifs pour les bugs critiques, mais ne bénéficie pas de nouvelles fonctionnalités. Elle est désignée par un nombre pair dans la deuxième partie du numéro de version, par exemple 1.18.0.

Ce que signifie être « stable »

Pour NGINX Open Source, le terme « stable » fait référence aux fonctionnalités et à la fréquence des mises à jour, et non à la qualité du logiciel. La branche stable ne reçoit jamais de nouvelles fonctionnalités au cours de son cycle de vie et ne bénéficie généralement que d’une ou deux mises à jour visant à corriger des bogues critiques.

La branche stable suit un cycle de vie annuel. Chaque année en avril, nous retirons la branche stable actuelle, après quoi aucun autre correctif de bogue n’est publié. Cela entraîne deux événements :

1. La branche principale actuelle est dérivée afin de créer la prochaine branche stable. La nouvelle branche stable hérite de tous les correctifs de bogues, fonctionnalités et autres changements intégrés à la branche principale au cours de l’année précédente. Le mois dernier, NGINX 1.17.10 a été dérivé pour produire NGINX 1.18.0. Notez que jusqu’à la publication de la nouvelle branche principale, la branche « stable » est identique à la branche principale actuelle et peut inclure de nouvelles fonctionnalités datant de quelques jours seulement (cette situation prend fin aujourd’hui pour la branche NGINX 1.18).
2. La branche principale bénéficie d’une « incrémentation de version » : la deuxième partie du numéro de version passe au nombre impair suivant. Le développement se poursuit sur la branche principale, avec de nouvelles versions créées à partir de celle-ci toutes les quatre à six semaines. Aujourd’hui marque la première publication de la branche principale NGINX 1.19, avec NGINX 1.19.0.

L’édition 2020 de l’augmentation annuelle du numéro de version des branches NGINX Open Source

Quelle branche NGINX Plus utilise-t-il ?

NGINX Plus, la version commerciale de NGINX, est maintenue dans un dépôt de code privé distinct. Elle repose toujours sur la dernière version de la branche principale de NGINX, à laquelle sont intégrées les fonctionnalités propriétaires supplémentaires de NGINX Plus. À l’heure où nous écrivons ces lignes, la dernière version est NGINX Plus R21, basée sur NGINX 1.17.10.

Quelle branche dois-je utiliser ?

Nous recommandons généralement d’utiliser la branche principale. C’est dans cette branche que nous intégrons toutes les nouvelles fonctionnalités, les améliorations de performances et les optimisations. Nous testons activement la branche principale et la soumettons à des contrôles qualité. Comme elle sert de base aux versions de NGINX Plus, elle est parfaitement adaptée à une utilisation en production.

Si vous craignez la charge de travail liée au suivi des nouvelles fonctionnalités et des corrections de bogues dans la branche principale, l’utilisation de la branche stable vous permet de n’examiner les nouvelles fonctionnalités qu’une fois par an, et les corrections de bogues seulement de manière occasionnelle.

Bilan de NGINX 1.17, ou les nouveautés de la branche stable NGINX 1.18

Le cycle de développement de NGINX 1.17 a introduit de nouvelles fonctionnalités et améliorations, notamment l’optimisation de la limitation du débit des requêtes et du nombre de connexions dans ngx_http_limit_req_module et ngx_http_limit_conn_module respectivement, l’ajout d’une directive permettant de retarder l’authentification dans ngx_http_core_module, la prise en charge des variables pour la directive grpc_pass ainsi que l’ajout de variables qui récupèrent l’adresse et le port du serveur avec le protocole PROXY, entre autres. Avant d’examiner plus en détail les améliorations les plus importantes, voici NGINX 1.17 en quelques chiffres :

• 10 versions de la branche principale
• 37 corrections de bugs
• 11 nouvelles fonctionnalités

Améliorations apportées à la limitation du débit des requêtes HTTP et du nombre de connexions

Les directives limit_rate et limit_rate_after contrôlent la bande passante (débit en octets par seconde) à laquelle NGINX répond aux requêtes. À partir de NGINX 1.17.0, le paramètre qui définit le débit peut être une variable, ce qui permet un contrôle dynamique en fonction des attributs de la requête. Pour consulter un exemple, voir Contrôle dynamique de la bande passante.

NGINX 1.17.1 a ajouté un mode de simulation pour la limitation du débit des requêtes, à l’aide de la directive limit_req_dry_run. En mode de simulation, NGINX Plus n’applique pas les limites de débit, mais continue de suivre le débit des requêtes excédentaires dans la zone de mémoire partagée et consigne une entrée dans le journal des erreurs pour chaque requête qui dépasse la limite configurée. Vous pouvez ainsi déterminer plus facilement quelle limite de débit convient aux profils de trafic de votre site. Pour plus de détails, consultez Test des limites de débit en mode de simulation.

Pour rendre le mode de simulation encore plus utile, NGINX 1.17.6 a ajouté la variable $limit_req_status, qui peut être incluse dans les entrées du journal d’accès afin de consigner l’effet de la limitation du débit sur le traitement des requêtes – plus précisément, pour indiquer si une requête :

• Acceptée (transmise sans délai aux serveurs backend) [PASSED]
• A été retardée [DELAYED]
• A été rejeté [REJECTED]
• A été comptabilisé comme retardé en mode de simulation [DELAYED_DRY_RUN]
• A été comptabilisé comme rejeté en mode de simulation [REJECTED_DRY_RUN]

NGINX 1.17.6 a également ajouté un mode de simulation pour la limitation des connexions avec la directive « limit_conn_dry_run », ainsi que la variable « $limit_conn_status » pour indiquer lorsqu’une demande de connexion :

• Acceptée (a été transmise aux serveurs backend) [PASSED]
• A été rejeté [REJECTED]
• A été comptabilisé comme rejeté en mode de simulation [REJECTED_DRY_RUN]

Pour obtenir un exemple de configuration, consultez « Améliorations apportées à la limitation des connexions ».

Nouvelle directive « auth_delay »

La directive auth_delay (ajoutée dans NGINX 1.17.10) permet de retarder le traitement des requêtes non autorisées, le code d’état 401 (Non autorisé) étant renvoyé au client. Cela permet d’éviter les attaques temporelles lors du traitement des requêtes d’accès. Les méthodes d’authentification disponibles sont les suivantes :

• Un mot de passe (lors de l’utilisation de « ngx_http_auth_basic_module »)
• Le résultat d’une sous-requête (disponible dans « ngx_http_auth_request_module »)
• La présence d’un JWT (disponible dans « ngx_http_auth_jwt_module »)

Prise en charge des variables pour la directive « grpc_pass »

La prise en charge native du trafic gRPC a été ajoutée dans NGINX 1.13.10, notamment avec la directive grpc_pass, qui spécifie les serveurs auxquels NGINX transmet les requêtes gRPC. Dans NGINX 1.17.8, nous avons ajouté la possibilité d’inclure des noms de domaine dans l’identifiant du serveur afin de permettre la recherche parmi les groupes de serveurs en amont. Si le nom de domaine est introuvable, NGINX utilise alors un résolveur pour déterminer les adresses des serveurs.

Variables supplémentaires du protocole PROXY

Le protocole PROXY permet à un proxy de couche 4 de transmettre les informations d’origine du client au proxy ou à l’équilibreur de charge suivant qui traite la requête. Cela est important dans les cas d’utilisation où vous devez connaître l’adresse IP du client – par exemple, pour limiter le nombre de connexions par client (à l’aide de la directive least_conn). Ces données sont disponibles dans la variable $proxy_protocol_addr (HTTP | Stream).

Lorsque plusieurs proxys de couche 4 sont déployés, il peut être important que NGINX connaisse l’adresse IP et le port du serveur proxy auquel le client s’est initialement connecté. Les métadonnées du protocole PROXY contiennent ces informations, et NGINX 1.17.6 a ajouté les variables suivantes aux modules HTTP et Stream afin de les récupérer :

• $proxy_protocol_server_addr (HTTP | Stream)
• $proxy_protocol_server_port (HTTP | Flux)

Remarque : Les variables ne sont renseignées que si vous incluez également le paramètre proxy_protocol dans la directive listen afin d’activer la prise en charge du protocole PROXY.

Prise en charge des variables ajoutée aux directives « proxy_upload_rate » et « proxy_download_rate »

Les directives proxy_upload_rate et proxy_download_rate du module Stream contrôlent respectivement le débit auquel NGINX lit les données provenant d’un client ou d’un serveur mandataire. À partir de NGINX 1.17.0, ces directives acceptent une variable comme paramètre, ce qui permet de définir des débits propres à certaines conditions.

Ajout de la prise en charge de l’appel système « ioctl(FIONREAD) »

Sur les systèmes Linux, l’appel système ioctl() indique le nombre d’octets pouvant être lus depuis le périphérique hôte. NGINX 1.17.5 a ajouté ioctl(FIONREAD) afin d’éviter les boucles lorsque les données sont ajoutées au tampon du socket plus rapidement que NGINX ne peut les lire et les traiter. Lorsque le noyau n’indique pas le nombre d’octets disponibles, nous pouvons utiliser ioctl(FIONREAD) pour obtenir cette information à partir d’un tampon contenant des données.

Spécification d’un emplacement nommé dans la fonction Perl « internal_redirect »

Dans NGINX 1.17.2 et les versions ultérieures, le paramètre uri de la fonction internal_redirect du module Perl de NGINX peut être un URI échappé ou un emplacement nommé.

Ce qui vous attend dans NGINX 1.19

La première version de la branche principale NGINX 1.19 sera disponible très prochainement. NGINX 1.19.0 prend en charge QUIC (HTTP/3), la prochaine évolution majeure des protocoles de transport utilisés pour les communications entre les clients et les sites web, les applications et les API.

Si vous souhaitez essayer les fonctionnalités avancées de NGINX Plus, commencez dès aujourd’hui votre essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d’utilisation.

---