Après 13 mois de développement, une nouvelle branche stable du serveur HTTP haute performance et du proxy multi-protocoles nginx 1.22.0 est présentée, intégrant les modifications accumulées dans la branche principale 1.21.x. À l’avenir, tous les changements dans la branche stable 1.22 seront liés à la correction de bogues critiques et de vulnérabilités. Dans peu de temps, la branche principale nginx 1.23 sera formée, dans laquelle le développement de nouvelles fonctionnalités se poursuivra. Pour les utilisateurs ordinaires 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 d'avril de la société Netcraft, nginx est utilisé sur 20,08 % de tous les sites actifs (20,15 % l'année dernière, 19,56 % il y a deux ans), ce qui en fait la deuxième solution la plus populaire dans cette catégorie (la part d'Apache étant de 22,58 % (25,38 % l'année dernière), Cloudflare – 10,42 % (8,51 %), Google – 8,89 % (10,09 %). En outre, lorsqu'on examine tous les sites, nginx conserve sa position de leader avec 31,13 % du marché (35,34 % l'année dernière, 36,91 % il y a deux ans), tandis que la part d'Apache représente 23,08 % (25,98 %), OpenResty (une plateforme basée sur nginx et LuaJIT) – 8,01 % (6,55 %), Cloudflare – 5,49 %, Microsoft IIS – 4 % (5,96 %).
Parmi le million de sites les plus visités au monde, la part de nginx s'élève à 21,79 % (23,06 % l'année dernière, 25,54 % il y a deux ans). Actuellement, environ 361 millions de sites fonctionnent sous nginx (419 millions l'année dernière). Selon W3Techs, nginx est utilisé sur 33,5 % des sites parmi le million les plus visités, ce chiffre étant de 33,8 % en mai de l'année dernière et de 31,9 % l'année précédente. La part d'Apache a baissé, passant de 33,8 % à 31,5 %, tandis que celle de Microsoft IIS a chuté de 7 % à 6 %. La part de LiteSpeed a augmenté de 8,5 % à 12,1 %, et celle de Node.js de 1,2 % à 1,9 %. En Russie, nginx est utilisé sur 79,8 % des sites les plus visités (79,1 % l'année dernière).
Les améliorations les plus notables ajoutées lors de la formation de la branche principale 1.21.x :
- Les directives «proxy_ssl_certificate», «proxy_ssl_certificate_key», «grpc_ssl_certificate», «grpc_ssl_certificate_key», «uwsgi_ssl_certificate» et «uwsgi_ssl_certificate_key» ont ajouté la prise en charge des variables.
- Le module proxy de messagerie a été amélioré avec le support du mode « pipelining » permettant de transmettre plusieurs requêtes POP3 ou IMAP dans une seule connexion, ainsi qu'une nouvelle directive « max_errors » définissant le nombre maximal d'erreurs de protocole après lequel la connexion sera fermée.
- La transmission des en-têtes « Auth-SSL-Protocol » et « Auth-SSL-Cipher » a été mise en œuvre serveur pour l'authentification du proxy de messagerie.
- Le module stream a ajouté le support de l'extension ALPN pour TLS. Pour déterminer la liste des protocoles pris en charge par ALPN (h2, http/1.1), la directive ssl_alpn a été proposée, et pour obtenir des informations sur le protocole ALPN convenu avec le client, la variable $ssl_alpn_protocol a été introduite.
- Le module de stream a ajouté le paramètre «fastopen», activant le mode «TCP Fast Open» pour les sockets d'écoute.
- L'échappement des caractères « »», « », « \ », « ^ », « ` », « { «, « | » et « } » a été configuré lors du proxy avec modification de l'URI.
- Le module stream a ajouté la directive proxy_half_close, qui permet de configurer le comportement lors de la fermeture d'une connexion TCP proxy d'un côté (« TCP half-close »).
- Le module ngx_http_mp4_module a ajouté une nouvelle directive mp4_start_key_frame pour diffuser un flux vidéo à partir d'une image clé.
- Une variable $ssl_curve a été ajoutée, renvoyant le type de courbe elliptique choisie pour la négociation des clés dans une session TLS.
- Dans la directive «sendfile_max_chunk», la valeur par défaut a été changée à 2 mégaoctets ;
- La compatibilité avec la bibliothèque OpenSSL 3.0 a été assurée. Le soutien de l'appel SSL_sendfile() lors de l'utilisation d'OpenSSL 3.0 a été ajouté.
- La compilation avec la bibliothèque PCRE2, fournissant des fonctions pour le traitement des expressions régulières, est activée par défaut.
- Lors du chargement des certificats de serveurs l'utilisation des niveaux de sécurité pris en charge à partir d'OpenSSL 1.1.0 et définis par le paramètre « @SECLEVEL=N » dans la directive ssl_ciphers a été configurée.
- Le support de l'ensemble de chiffrement à l'export a été arrêté.
- La mise en cache des données traitées a été autorisée dans l'API de filtrage du corps de la requête.
- Sur la plateforme FreeBSD, le support de l'appel système sendfile, destiné à organiser le transfert direct de données entre un descripteur de fichier et un socket, a été amélioré. Le mode sendfile(SF_NODISKIO) est désormais toujours activé et le mode sendfile(SF_NOCACHE) a été ajouté.
- Le support de l'établissement de connexions HTTP/2 utilisant l'extension NPN (Next Protocol Negotiation) au lieu de ALPN a été abandonné.
- Le blocage des requêtes HTTP/1.0 incluant l'en-tête HTTP « Transfer-Encoding » (introduit dans la version du protocole HTTP/1.1) a été assuré.
- La protection contre les attaques de type « HTTP Request Smuggling » sur les systèmes frontend-backend, permettant de s'infiltrer dans le contenu des requêtes d'autres utilisateurs traitées dans le même flux entre le frontend et le backend, a été renforcée. Nginx renvoie désormais toujours une erreur lors de l'utilisation de la méthode CONNECT ; en cas de spécification simultanée des en-têtes « Content-Length » et « Transfer-Encoding » ; en présence d'espaces ou de caractères de contrôle dans la chaîne de requête, le nom de l'en-tête HTTP ou dans la valeur de l'en-tête « Host ».
Source : opennet.ru
