Publication de nginx 1.20.0

Après un an de développement, une nouvelle branche stable du serveur HTTP haute performance et proxy multi-protocole nginx 1.20.0 a été présentée, incorporant les changements accumulés dans la branche principale 1.19.x. Par la suite, tous les changements dans la branche stable 1.20 seront axés sur la correction de bugs graves et de vulnérabilités. Prochainement, une branche principale nginx 1.21 sera formée, permettant le développement de nouvelles fonctionnalités. 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 la base de laquelle des versions commerciales de Nginx Plus sont générées tous les trois mois.

Selon le rapport de mars de la société Netcraft, nginx est utilisé sur 20,15 % de tous les sites actifs (contre 19,56 % l'année dernière, et 20,73 % il y a deux ans), ce qui le place en deuxième position en termes de popularité dans cette catégorie (la part d'Apache est de 25,38 % (contre 27,64 % l'année dernière), Google — 10,09 %, Cloudflare — 8,51 %. En tenant compte de tous les sites, nginx reste leader avec une part de 35,34 % du marché (contre 36,91 % l'année dernière, et 27,52 % il y a deux ans), tandis que la part d'Apache est de 25,98 %, OpenResty (une plateforme basée sur nginx et LuaJIT) — 6,55 %, et Microsoft IIS — 5,96 %.

Parmi le million de sites les plus visités au monde, la part de nginx est de 25,55 % (contre 25,54 % l'année dernière, et 26,22 % il y a deux ans). Actuellement, environ 419 millions de sites sont gérés par nginx (contre 459 millions l'année dernière). Selon W3Techs, nginx est utilisé sur 33,7 % des sites parmi le million les plus visités ; en avril de l'année dernière, ce chiffre était de 31,9 %, et il y a deux ans — 41,8 % (la baisse est due à la prise en compte distincte du serveur http de Cloudflare). La part d'Apache est passée de 39,5 % à 34 % en un an, et celle de Microsoft IIS de 8,3 % à 7 %. La part de LiteSpeed a augmenté de 6,3 % à 8,4 %, et celle de Node.js de 0,8 % à 1,2 %. En Russie, nginx est utilisé sur 79,1 % des sites les plus visités (contre 78,9 % l'année dernière).

Les améliorations les plus notables ajoutées lors de la formation de la branche principale 1.19.x :

  • Ajout de la possibilité de vérification des certificats clients via des services externes utilisant le protocole OCSP (Online Certificate Status Protocol). Pour activer la vérification, la directive ssl_ocsp est proposée, pour configurer la taille du cache — ssl_ocsp_cache, et pour redéfinir l'URL du gestionnaire OCSP, comme indiqué dans le certificat — ssl_ocsp_responder.
  • Le module ngx_stream_set_module est inclus, permettant d'assigner une valeur à une variable. server { listen 12345; set $true 1; }
  • La directive proxy_cookie_flags a été ajoutée pour spécifier les flags pour les cookies dans les connexions proxy. Par exemple, pour ajouter le flag "httponly" au cookie "one", et pour tous les autres cookies les flags "nosecure" et "samesite=strict", on peut utiliser la construction : proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure samesite=strict;

    Une directive similaire userid_flags pour ajouter des flags aux cookies a également été mise en œuvre pour le module ngx_http_userid.

  • Des directives «ssl_conf_command», «proxy_ssl_conf_command», «grpc_ssl_conf_command» et «uwsgi_ssl_conf_command» ont été ajoutées, permettant de définir des paramètres arbitraires pour la configuration d'OpenSSL. Par exemple, pour prioriser les chiffrages ChaCha et configurer de manière avancée les chiffrages TLSv1.3, on peut indiquer ssl_conf_command Options PrioritizeChaCha; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
  • La directive «ssl_reject_handshake» a été ajoutée, qui exige de rejeter toutes les tentatives de négociation SSL-des connexions (par exemple, cela peut être utilisé pour rejeter toutes les requêtes avec des noms d'hôtes inconnus dans le champ SNI). server { listen 443 ssl; ssl_reject_handshake on; } server { listen 443 ssl; server_name example.com; ssl_certificate example.com.crt; ssl_certificate_key example.com.key; }
  • La directive proxy_smtp_auth a été ajoutée au proxy de messagerie, permettant d'authentifier l'utilisateur sur le backend à l'aide de la commande AUTH et du mécanisme PLAIN SASL.
  • La directive «keepalive_time» a été ajoutée, limitant le temps de vie total de chaque connexion keep-alive, après quoi la connexion sera fermée (ne pas confondre avec keepalive_timeout, qui définit le temps d'inactivité après lequel la connexion keep-alive est fermée).
  • La variable $connection_time a été ajoutée, permettant d'obtenir des informations sur la durée de la connexion en secondes avec une précision milliseconde.
  • Un paramètre «min_free» a été ajouté aux directives «proxy_cache_path», «fastcgi_cache_path», «scgi_cache_path» et «uwsgi_cache_path», régulant la taille du cache sur la base de la définition de la taille minimale de l'espace disque libre.
  • Les directives «lingering_close», «lingering_time» et «lingering_timeout» ont été adaptées pour fonctionner avec HTTP/2.
  • Le code de traitement des connexions dans HTTP/2 est proche de la mise en œuvre de HTTP/1.x. Le support des paramètres individuels «http2_recv_timeout», «http2_idle_timeout» et «http2_max_requests» est abandonné au profit des directives communes «keepalive_timeout» et «keepalive_requests». Les paramètres «http2_max_field_size» et «http2_max_header_size» ont été supprimés, et il convient désormais d'utiliser «large_client_header_buffers».
  • Une nouvelle option de ligne de commande «-e» a été ajoutée, permettant de spécifier un fichier alternatif pour l'enregistrement des erreurs, qui sera utilisé à la place du log défini dans les paramètres. À la place du nom de fichier, une valeur spéciale stderr peut être spécifiée.

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster