Après un an de développement, une nouvelle branche stable du serveur HTTP haute performance et du proxy multi-protocole nginx 1.28.0 a été publiée, intégrant les modifications accumulées dans la branche principale 1.27.x. À l'avenir, toutes les modifications de la branche stable 1.28 seront liées à la correction de bogues graves et de vulnérabilités. Une nouvelle branche principale nginx 1.29 sera bientôt formée, où le développement de nouvelles fonctionnalités se poursuivra. Pour les utilisateurs réguliers qui n'ont pas besoin d'assurer la compatibilité avec des modules tiers, il est recommandé d'utiliser la branche principale, sur laquelle des versions du produit commercial Nginx Plus sont publiées tous les trois mois.
Selon le rapport de mars de la société Netcraft, environ 245 millions de sites sont gérés par nginx (243 millions l'année dernière, 289 millions il y a deux ans). Nginx est utilisé sur 17,89 % de tous les sites actifs (18,15 % l'année dernière, 18,94 % il y a deux ans), ce qui lui confère la première place en popularité dans cette catégorie (la part d'Apache est de 16,03 % (20,09 % l'année dernière, 20,52 % il y a deux ans), Cloudflare — 17,81 % (14,12 %, 11,32 %), Google — 9,89 % (10,41 %, 9,89 %).
En prenant en compte tous les sites, nginx conserve sa position de leader avec une part de marché de 20,48 % (22,31 % l'année dernière, 25,94 % il y a deux ans), tandis que la part d'Apache est de 16,03 % (20,17 %, 20,58 %), Cloudflare — 12,87 % (11,24 %, 10,17 %), OpenResty (plateforme basée sur nginx et LuaJIT) — 9,36 % (7,93 %, 7,94 %).
Parmi le million de sites les plus visités au monde, nginx occupe la deuxième place avec une part de 20,37 % (20,63 % l'année dernière, 21,37 % il y a deux ans). La première place est détenue par Cloudflare — 22,32 % (22,59 % l'année dernière, 21,62 % il y a deux ans). La part d'Apache httpd est de 17,95 % (20,09 %, 21,18 %).
Selon W3Techs, nginx est utilisé sur 33,8 % des sites parmi le million les plus visités (en avril de l'année dernière, ce chiffre était de 34,3 %, et l'année précédente, de 34,5 %). La part d'Apache a diminué d'une année sur l'autre, passant de 30,1 % à 26,3 %, tandis que la part de Microsoft IIS a baissé de 5 % à 4 %. La part de Node.js a augmenté de 3,2 % à 4,4 %, et celle de LiteSpeed est passée de 12,9 % à 14,6%.
Les améliorations les plus notables ajoutées lors de la formation de la branche principale 1.27.x :
- Pour les connexions utilisant le protocole QUIC, le support de l'algorithme de contrôle de la congestion CUBIC (RFC 9438) a été ajouté. Son fonctionnement consiste à augmenter progressivement la taille de la fenêtre de congestion jusqu'à ce qu'une perte de paquets survienne, après quoi la taille de la fenêtre revient à sa valeur avant la perte. Dans les tests réalisés, l'utilisation de CUBIC a permis de réduire le temps de transmission d'un fichier de 500 Mo de 24 % avec des latences de 40 ms et un BDP de 750 K (Bandwidth Delay Product), et de 73 % avec des latences de 100 ms et un BDP de 9 M.
- Le module stream a ajouté la prise en charge de la vérification de la révocation des certificats clients, en utilisant le protocole OCSP (Protocole de Statut de Certificat en Ligne).
- Dans le module stream, le support de la technique de vérification des certificats OCSP Stapling a été implémenté. Cette technique consiste à transmettre la réponse OCSP signée par une autorité de certification par le serveur hôte du site lors de l'établissement de la connexion TLS, sans avoir besoin de contacter directement l'autorité de certification.
- Un caching a été implémenté lors du démarrage et de la mise à jour de la configuration. de certificats SSL, des clés et des CRL (Listes de Révocation de Certificats).
- Des problèmes liés au long chargement des fichiers de configuration à cause du réexamen de la même série de clés et de listes d'autorités de certification ont été résolus. Le redémarrage de la configuration a été accéléré grâce à la réutilisation des objets TLS non modifiés, tels que les certificats, les clés et les CRL. Pour désactiver l'héritage des objets lors de la mise à jour de la configuration, une nouvelle directive « ssl_object_cache_inheritable » a été ajoutée.
- La directive « ssl_client_certificate » supporte désormais les certificats avec des informations supplémentaires.
- Pour la vérification des certificats SSL clients, la directive « ssl_client_certificate » n'est plus obligatoire.
- Le module ngx_mail_proxy_module a ajouté le support d'un mode IMAP LOGIN spécifique à SmarterMail avec une réponse CAPABILITY non étiquetée.
- Le module ngx_http_proxy_module a ajouté la directive « proxy_pass_trailers », permettant le passage des champs d'en-tête à la fin de la réponse du serveur proxy au client.
- La directive «server» utilisée dans le bloc «upstream» a été étendue avec le paramètre «resolve» permettant de suivre les modifications du nom de domaine utilisé et de mettre à jour automatiquement la configuration du bloc «upstream» sans nécessiter un redémarrage de nginx en cas de changement d'adresse. adresses IP pour le nom de domaine utilisé, et met à jour automatiquement la configuration du bloc «upstream» sans avoir besoin de redémarrer nginx en cas de changement d'adresse.
- Il est désormais possible d'utiliser des variables dans les directives «proxy_limit_rate», «fastcgi_limit_rate», «scgi_limit_rate» et «uwsgi_limit_rate».
- Dans les directives «proxy_bind», «fastcgi_bind», «grpc_bind», «memcached_bind», «scgi_bind» et «uwsgi_bind», ainsi que dans l'adresse client du module ngx_http_realip_module, les adresses IPv6 peuvent être spécifiées entre crochets sans numéro de port.
- La directive «keepalive_min_timeout» a été ajoutée, définissant le délai d'attente pendant lequel nginx ne fermera pas la connexion keep-alive avec le client.
- Les protocoles TLSv1 et TLSv1.1 sont désactivés par défaut.
- Les problèmes de chargement lent des fichiers de configuration dus au parsing répété du même ensemble de certificats TLS, de clés et de listes d'autorités de certification ont été résolus. Le redémarrage de la configuration a été accéléré grâce à la réutilisation des objets TLS inchangés tels que les certificats, les clés et les CRL. Pour désactiver l'héritage des objets lors de la mise à jour de la configuration, une directive «ssl_object_cache_inheritable» a été ajoutée.
- Un cache a été ajouté pour les certificats et clés chargés à l'aide de variables dans les directives (par exemple, «ssl_certificate /etc/ssl/$ssl_server_name.crt»). Des directives telles que «ssl_certificate_cache», «proxy_ssl_certificate_cache», «grpc_ssl_certificate_cache» et «uwsgi_ssl_certificate_cache» ont été ajoutées pour gérer le cache. Ces directives permettent de configurer la taille maximale du cache, la durée de vie des entrées et le temps de nettoyage des entrées inutilisées. Par exemple : «ssl_certificate_cache max=1000 inactive=20s valid=1m;».
- La consommation de mémoire lors du traitement de requêtes de longue durée dans les configurations utilisant les directives «gzip», «gunzip», «ssi», «sub_filter» ou «grpc_pass» a été réduite.
- La taille maximale des sessions SSL pouvant être mises en cache en mémoire partagée a été augmentée à 8192.
- Le montage avec la bibliothèque C Musl a été corrigé.
- Des travaux ont été effectués pour optimiser les performances et corriger les erreurs dans l'implémentation de HTTP/3.
On peut également souligner la publication de la version du projet FreeNginx 1.28.0, qui développe un fork de Nginx. Le développement du fork est dirigé par Maxim Dunin, l'un des développeurs clés de Nginx. FreeNginx se positionne comme un projet non commercial, assurant le développement de la base de code de Nginx sans intervention corporative. Parmi les modifications spécifiques de la branche FreeNginx 1.28 :
- Le paramètre « off » dans la directive « pid », qui désactive la création du fichier PID.
- Restriction de l'intensité d'écriture des messages dans le journal des erreurs pour éviter le remplissage du journal par des messages typiques.
- Mise en œuvre du paramètre multipath dans la directive listen pour supporter le Multipath TCP.
- Prise en charge de l'en-tête HTTP « Age » pour déterminer la durée de vie des cache.
- Ajout des méthodes d'authentification XOAUTH2 et OAUTHBEARER dans le module mail_proxy.
Source : opennet.ru
