{"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\/de\/blog\/news\/vypusk-nginx-1-26-0-s-podderzhkoj-http-3","title":{"rendered":"Release von nginx 1.26.0 mit Unterst\u00fctzung f\u00fcr HTTP\/3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach einem Jahr der Entwicklung wurde der neue stabile Branch des hochleistungsf\u00e4higen HTTP-Servers und Multi-Protokoll-Proxy-Servers nginx 1.26.0 ver\u00f6ffentlicht. Dieser enth\u00e4lt die \u00c4nderungen, die in der Hauptlinie 1.25.x gesammelt wurden. Zuk\u00fcnftige \u00c4nderungen im stabilen Branch 1.26 werden sich auf die Behebung ernsthafter Fehler und Sicherheitsanf\u00e4lligkeiten konzentrieren. Bald wird der Hauptbranch nginx 1.27 erstellt, in dem die Entwicklung neuer Funktionen fortgesetzt wird. F\u00fcr regelm\u00e4\u00dfige Benutzer, die keine Kompatibilit\u00e4t mit Drittanbieter-Modulen gew\u00e4hrleisten m\u00fcssen, wird empfohlen, den Hauptbranch zu verwenden, basierend auf dem viertelj\u00e4hrlich eine kommerzielle Version von Nginx Plus ver\u00f6ffentlicht wird. <\/p>\n
Laut dem M\u00e4rzbericht von Netcraft werden etwa 243 Millionen Websites (im letzten Jahr 289 Millionen) von nginx betrieben. Nginx ist auf 18,15 % aller aktiven Websites im Einsatz (im letzten Jahr 18,94 %, vor zwei Jahren 20,08 %), was dem zweiten Platz in dieser Kategorie entspricht (der Anteil von Apache liegt bei 20,09 % (im letzten Jahr 20,52 %, vor zwei Jahren 22,58 %), Cloudflare \u2013 14,12 % (11,32 %, 10,42 %), Google \u2013 10,41 % (9,89 %, 8,89 %). Bei der Betrachtung aller Websites beh\u00e4lt nginx die F\u00fchrung und hat einen Marktanteil von 22,31 % (im letzten Jahr 25,94 %, vor zwei Jahren \u2013 31,13 %), w\u00e4hrend der Anteil von Apache bei 20,17 % liegt (20,58, 23,08 %), Cloudflare \u2013 11,24 % (10,17, 5,49 %), OpenResty (eine Plattform basierend auf nginx und LuaJIT) \u2013 7,93 % (7,94 %, 8,01 %). <\/p>\n
Die bemerkenswertesten Verbesserungen, die im Rahmen der Hauptentwicklung des Branches 1.25.x hinzugef\u00fcgt wurden: <\/p>\n
\n
Es wurde das Modul ngx_http_v3 mit experimenteller Unterst\u00fctzung f\u00fcr das HTTP\/3-Protokoll hinzugef\u00fcgt. F\u00fcr den Bau des Moduls gibt es die Option \u201e--with-http_v3_module\u201c. HTTP\/3 definiert die Verwendung des QUIC-Protokolls (Quick UDP Internet Connections) als Transport f\u00fcr HTTP\/2. QUIC ist eine Erweiterung des UDP-Protokolls und unterst\u00fctzt die Multiplexierung mehrerer Verbindungen und bietet Verschl\u00fcsselungsmethoden, die TLS\/SSL entsprechen. Das Protokoll wurde 2013 von Google als Alternative zu der Kombination aus TCP+TLS f\u00fcr das Web entwickelt, um Probleme mit langen Verbindungsaufbau- und Aushandlungszeiten in TCP zu l\u00f6sen und Verz\u00f6gerungen bei Paketverlusten w\u00e4hrend der Daten\u00fcbertragung zu eliminieren.\n
Eine separate Direktive \u201ehttp2\u201c wurde hinzugef\u00fcgt, um das HTTP\/2-Protokoll selektiv f\u00fcr Serverbindungen zu aktivieren (kann in einzelnen \u201eserver\u201c-Bl\u00f6cken verwendet werden). Der Parameter \u201ehttp2\u201c in der \u201elisten\u201c-Direktive wurde als veraltet erkl\u00e4rt.\n
Der Schutz vor unnormaler Aktivit\u00e4t von HTTP\/2-Clients, insbesondere vor \u201eRapid Reset\u201c-DoS-Angriffen, wurde verst\u00e4rkt. Dabei werden eine gro\u00dfe Anzahl sofort zur\u00fcckgesetzter Streams innerhalb einer HTTP\/2-Verbindung erstellt. In der Standardkonfiguration sto\u00dfen solche Angriffe auf die Grenze f\u00fcr die Anzahl der Anfragen pro Verbindung \u201ekeepalive_requests\u201c (nach jeweils 1000 Anfragen wird die Verbindung zur\u00fcckgesetzt) und auf die Beschr\u00e4nkungen \u201elimit_req\u201c. Um schneller auf Flut-Anfragen \u00fcber eine gro\u00dfe Anzahl an Streams reagieren zu k\u00f6nnen, wurde eine zus\u00e4tzliche Einschr\u00e4nkung hinzugef\u00fcgt, die standardm\u00e4\u00dfig nicht mehr als 256 (2 * max_concurrent_streams) neue Streams pro Ereignisverarbeitungszyklus zul\u00e4sst. Diese neue Einschr\u00e4nkung erm\u00f6glicht es, Anfragen zu blockieren, bevor das Gesamtlimit der gleichzeitigen Streams erreicht ist, beispielsweise wenn Streams asynchron verarbeitet oder zur\u00fcckgesetzt werden.\n