{"id":115269,"date":"2024-04-24T02:30:06","date_gmt":"2024-04-24T00:30:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-nginx-1-26-0-s-podderzhkoj-http-3"},"modified":"2024-04-24T02:30:06","modified_gmt":"2024-04-24T00:30:06","slug":"vypusk-nginx-1-26-0-s-podderzhkoj-http-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-nginx-1-26-0-s-podderzhkoj-http-3","title":{"rendered":"Sortie de nginx 1.26.0 avec support HTTP\/3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Apr\u00e8s un an de d\u00e9veloppement, une nouvelle version stable du serveur HTTP haute performance et du proxy multi-protocole nginx 1.26.0 est publi\u00e9e, int\u00e9grant les modifications accumul\u00e9es dans la branche principale 1.25.x. \u00c0 l'avenir, tous les changements dans la branche stable 1.26 seront ax\u00e9s sur la correction des bogues et des vuln\u00e9rabilit\u00e9s s\u00e9rieuses. Dans un proche avenir, la branche principale nginx 1.27 sera form\u00e9e, poursuivant le d\u00e9veloppement de nouvelles fonctionnalit\u00e9s. Pour les utilisateurs ordinaires sans besoin d'assurer la compatibilit\u00e9 avec des modules tiers, il est recommand\u00e9 d'utiliser la branche principale, sur laquelle des versions commerciales de Nginx Plus sont publi\u00e9es tous les trois mois. <\/p>\n
Selon le rapport de mars de Netcraft, environ 243 millions de sites sont g\u00e9r\u00e9s par nginx (contre 289 millions l'ann\u00e9e derni\u00e8re). Nginx est utilis\u00e9 sur 18,15 % de tous les sites actifs (contre 18,94 % l'ann\u00e9e derni\u00e8re, et 20,08 % il y a deux ans), ce qui le place au deuxi\u00e8me rang en termes de popularit\u00e9 dans cette cat\u00e9gorie (la part d'Apache est de 20,09 % (contre 20,52 % l'ann\u00e9e derni\u00e8re, et 22,58 % il y a deux ans), Cloudflare \u2014 14,12 % (11,32 %, 10,42 %), Google \u2014 10,41 % (9,89 %, 8,89 %). En outre, en consid\u00e9rant tous les sites, nginx conserve la premi\u00e8re place avec une part de march\u00e9 de 22,31 % (contre 25,94 % l'ann\u00e9e derni\u00e8re, et 31,13 % il y a deux ans), tandis que la part d'Apache est de 20,17 % (20,58 %, 23,08 %), Cloudflare \u2014 11,24 % (10,17 %, 5,49 %), OpenResty (plateforme bas\u00e9e sur nginx et LuaJIT) \u2014 7,93 % (7,94 %, 8,01 %). <\/p>\n
Parmi un million des sites les plus visit\u00e9s au monde, la part de nginx s'\u00e9l\u00e8ve \u00e0 20,63 % (il y a un an, c'\u00e9tait 21,37 %, il y a deux ans, 21,79 %), Cloudflare \u2014 22,59 % (il y a un an, 21,62 %), Apache httpd \u2014 20,09 % (21,18 %). Selon W3Techs, nginx est utilis\u00e9 sur 34,3 % des sites des mille plus visit\u00e9s ; en avril dernier, ce chiffre \u00e9tait de 34,5 %, et l'ann\u00e9e pr\u00e9c\u00e9dente \u2014 33,1 %. La part d'Apache a diminu\u00e9 au cours de l'ann\u00e9e, passant de 32,2 % \u00e0 30,1 %, tandis que celle de Microsoft IIS a chut\u00e9 de 5,6 % \u00e0 4,8 %. La part de Node.js a augment\u00e9 de 2,4 % \u00e0 3,2 %, et celle de LiteSpeed est pass\u00e9e de 11,8 % \u00e0 12,9 %. <\/p>\n
Les am\u00e9liorations les plus remarquables ajout\u00e9es lors de la formation de la branche principale 1.25.x : <\/p>\n
\n
Le module ngx_http_v3 a \u00e9t\u00e9 ajout\u00e9 avec un support exp\u00e9rimental pour le protocole HTTP\/3. Une option «\u2014with-http_v3_module» est pr\u00e9vue pour compiler le module. HTTP\/3 d\u00e9finit l'utilisation du protocole QUIC (Quick UDP Internet Connections) comme transport pour HTTP\/2. QUIC est une superposition du protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des m\u00e9thodes de cryptage \u00e9quivalentes \u00e0 celles de TLS\/SSL. Ce protocole a \u00e9t\u00e9 cr\u00e9\u00e9 en 2013 par Google comme alternative \u00e0 la combinaison TCP+TLS pour le Web, r\u00e9solvant des probl\u00e8mes de temps de connexion et d'\u00e9tablissement de connexions dans TCP, tout en \u00e9liminant les retards caus\u00e9s par la perte de paquets pendant le transfert de donn\u00e9es.\n
Une directive distincte \u00ab http2 \u00bb a \u00e9t\u00e9 ajout\u00e9e pour activer s\u00e9lectivement le protocole HTTP\/2 li\u00e9 aux serveurs (peut \u00eatre utilis\u00e9e dans des blocs \u00ab server \u00bb individuels). Le param\u00e8tre \u00ab http2 \u00bb dans la directive \u00ab listen \u00bb est d\u00e9sormais obsol\u00e8te.\n
Renforcement de la protection contre les activit\u00e9s anormales des clients HTTP\/2, en particulier contre les attaques DoS de type \u00ab Rapid Reset \u00bb, qui consistent \u00e0 cr\u00e9er un grand nombre de flux imm\u00e9diatement r\u00e9initialis\u00e9s dans le cadre d'une seule connexion HTTP\/2. Dans la configuration par d\u00e9faut, de telles attaques sont limit\u00e9es par le nombre de requ\u00eates par connexion \u00ab keepalive_requests \u00bb (apr\u00e8s chaque 1000 requ\u00eates, la connexion sera r\u00e9initialis\u00e9e) et par les limitations \u00ab limit_req \u00bb. Pour une r\u00e9action plus rapide aux inondations de requ\u00eates \u00e0 travers un grand nombre de flux, une limitation suppl\u00e9mentaire a \u00e9t\u00e9 ajout\u00e9e, ne permettant pas la cr\u00e9ation par d\u00e9faut de plus de 256 (2 * max_concurrent_streams) nouveaux flux lors de chaque cycle de traitement d'\u00e9v\u00e9nements. Cette nouvelle limitation permet de commencer \u00e0 bloquer les requ\u00eates avant d'atteindre la limite totale du nombre de flux simultan\u00e9s, par exemple lorsque les flux sont trait\u00e9s de mani\u00e8re asynchrone ou r\u00e9initialis\u00e9s.\n