Présentation de NGINX 1.18 et 1.19

Aujourd'hui, nous publions NGINX 1.19, la dernière version de NGINX Open Source, le serveur Web le plus populaire sur Internet . Cette version marque le lancement de la branche de développement NGINX 1.19, suite à la sortie de la branche stable NGINX 1.18 le mois dernier.

Dans ce blog, nous discutons du schéma de gestion des versions NGINX, revenons sur ce qui s'est passé pendant le cycle de développement de NGINX 1.17 et attendons avec impatience ce qui nous attend avec NGINX 1.19.

Explication de la gestion des versions NGINX

Chez NGINX, nous maintenons deux branches dans le référentiel de code Open Source NGINX, nommées mainline et stable :

• Mainline est la branche de développement active où les dernières fonctionnalités et corrections de bogues sont ajoutées. Il est indiqué 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 bogues de haute gravité, mais n'est pas mis à jour avec de nouvelles fonctionnalités. Elle est indiqué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 mot « stable » fait référence à la fonctionnalité et à la fréquence de mise à 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 reçoit généralement seulement une ou deux mises à jour, pour les corrections de bogues critiques.

La branche stable a un cycle de vie annuel. Chaque mois d'avril, nous retirons la branche stable actuelle, après quoi aucune autre correction de bug n'est effectuée. Cela déclenche deux événements :

1. La branche principale actuelle est bifurquée pour créer la prochaine branche stable. La nouvelle branche stable hérite de toutes les corrections de bugs, fonctionnalités et autres modifications apportées à la branche principale au cours de l'année précédente. Le mois dernier, NGINX 1.17.10 a été forké pour produire NGINX 1.18.0. Notez que jusqu'à la sortie de la nouvelle branche principale, « stable » est identique à la branche principale actuelle et peut inclure de nouvelles fonctionnalités qui datent de quelques jours seulement (cet état se termine aujourd'hui pour la branche NGINX 1.18).
2. La branche principale bénéficie d'une « augmentation de version » ; c'est-à-dire que la deuxième partie du numéro de version est incrémentée jusqu'au numéro impair suivant. Le développement continu se poursuit dans la branche principale, avec de nouvelles versions construites à partir de la branche principale toutes les quatre à six semaines. Aujourd'hui marque la première version de la ligne principale NGINX 1.19 avec NGINX 1.19.0.

Quelle branche NGINX Plus utilise-t-il ?

NGINX Plus , la version commerciale de NGINX, est conservée dans un référentiel de code privé distinct. Il est toujours basé sur la dernière version de la ligne principale NGINX, fusionnée avec les fonctionnalités et capacités propriétaires supplémentaires de NGINX Plus. Au moment de la rédaction de cet article, 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 ici que nous intégrons toutes les nouvelles fonctionnalités, améliorations des performances et perfectionnements. Nous testons et contrôlons activement la qualité de la branche principale et, en tant que source des builds NGINX Plus, elle est parfaitement adaptée à une utilisation en production.

Si vous êtes préoccupé par les frais généraux liés à la surveillance de la branche principale pour les nouvelles fonctionnalités et les corrections de bogues, alors l'utilisation de la branche stable signifie que vous n'avez besoin d'examiner les nouvelles fonctionnalités qu'une fois par an et les corrections de bogues de manière peu fréquente.

NGINX 1.17 en revue, ou quoi de neuf dans la branche stable de NGINX 1.18

Le cycle de développement de NGINX 1.17 a introduit de nouvelles fonctionnalités et améliorations, notamment des améliorations du taux de requête et de la limitation de connexion dans ngx_http_limit_req_module et ngx_http_limit_conn_module respectivement, l'ajout d'une directive de retard d'authentification à ngx_http_core_module , l'introduction de la prise en charge des variables pour la directive grpc_pass et des variables qui capturent l' adresse et le port du serveur avec le protocole PROXY, et bien plus encore. Avant d'examiner plus en détail les améliorations les plus importantes, voici NGINX 1.17, en chiffres :

• 10 versions principales
• 37 corrections de bugs
• 11 nouvelles fonctionnalités

Améliorations apportées au taux de requêtes HTTP et à la limitation des 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. Dans NGINX 1.17.0 et versions ultérieures, le paramètre qui définit le débit peut être une variable, ce qui permet un contrôle dynamique basé sur les attributs de la demande. Pour un exemple, voir Contrôle dynamique de la bande passante .

NGINX 1.17.1 a ajouté un mode d'exécution à sec pour la limitation du taux de requêtes, avec la directive limit_req_dry_run . En mode d'exécution à sec, NGINX Plus n'applique pas de limites de débit, mais suit toujours le taux de demandes excessives dans la zone de mémoire partagée et écrit une entrée dans le journal des erreurs pour chaque demande qui dépasse la limite configurée. Cela vous permet de déterminer plus facilement quelle limite de débit est appropriée aux modèles de trafic sur votre site. Pour plus de détails, voir Test des limites de débit en mode d'exécution à sec .

Pour rendre le mode d'exécution à sec 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 pour capturer l'effet de la limitation du débit sur le traitement des requêtes, en particulier si une requête :

• Passé (a été transmis aux serveurs backend sans délai) [ PASSED ]
• A été retardé [ RETARDÉ ]
• A été rejeté [ REJETÉ ]
• A été compté comme retardé en mode d'exécution à sec [ DELAYED_DRY_RUN ]
• A été compté comme rejeté en mode d'exécution à sec [ REJECTED_DRY_RUN ]

NGINX 1.17.6 a également ajouté un mode d'exécution à sec pour la limitation de connexion avec la directive limit_conn_dry_run et la variable $limit_conn_status pour capturer lorsqu'une demande de connexion :

• Passé (a été transmis aux serveurs backend) [ PASSED ]
• A été rejeté [ REJETÉ ]
• A été compté comme rejeté en mode d'exécution à sec [ REJECTED_DRY_RUN ]

Pour un exemple de configuration, voir Améliorations apportées à la limitation de connexion .

Nouvelle directive auth_delay

La directive auth_delay (ajoutée dans NGINX 1.17.10) permet le traitement différé des requêtes non autorisées, avec un code d'état 401(Non autorisé) retourné au client. Cela empêche les attaques temporelles lors du traitement des demandes d'accès. Les méthodes d’authentification disponibles incluent :

• 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, y compris 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, pour prendre en charge la recherche parmi les groupes de serveurs en amont . Si le nom de domaine n'est pas trouvé, NGINX utilise un résolveur pour identifier les adresses de serveur.

Variables supplémentaires du protocole PROXY

Le protocole PROXY permet à un proxy de couche 4 de fournir des informations client d'origine au prochain proxy ou équilibreur de charge gérant la demande. Ceci est important pour les cas d'utilisation où vous devez connaître l'adresse IP du client, par exemple pour limiter le nombre de connexions pour chaque 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 pour NGINX de connaître l'adresse IP et le port du serveur proxy auquel le client s'est initialement connecté. Les métadonnées du protocole PROXY incluent ces informations et NGINX 1.17.6 a ajouté les variables suivantes aux modules HTTP et Stream pour les capturer :

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

Note: Les variables ne sont renseignées que si vous incluez également le paramètre proxy_protocol à la directive listen pour activer la gestion 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 la vitesse à laquelle NGINX lit les données d'un client ou d'un serveur proxy, respectivement. Dans NGINX 1.17.0 et versions ultérieures, les directives acceptent un paramètre variable, vous permettant de définir des taux spécifiques aux conditions.

Ajout de la prise en charge de l'appel système ioctl(FIONREAD)

Dans les systèmes Linux, l'appel système ioctl() fournit le nombre d'octets lisibles à partir du périphérique hôte. NGINX 1.17.5 a ajouté ioctl(FIONREAD) pour empêcher la boucle lorsque les données sont ajoutées au tampon de socket plus rapidement que NGINX ne peut les lire et les traiter. Lorsque le noyau ne fournit pas le nombre d'octets disponibles, nous pouvons utiliser ioctl(FIONREAD) pour obtenir ces informations à partir d'un tampon rempli.

Spécification d'un emplacement nommé dans la fonction internal_redirect de Perl

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

Nouveautés de NGINX 1.19

La première version de la ligne principale NGINX 1.19 arrive très bientôt. NGINX 1.19.0 inclut la prise en charge de QUIC (HTTP/3), la prochaine mise à jour importante des protocoles de transport pour la communication entre les clients et les sites Web, les applications et les API.

Si vous souhaitez tester les fonctionnalités améliorées de NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .