Release von nginx 1.28.0 und dem Fork FreeNginx 1.28.0

Nach einem Jahr der Entwicklung wurde der neue stabile Branch des leistungsstarken HTTP-Servers und Multi-Protokoll-Proxy-Servers nginx 1.28.0 veröffentlicht, der die Änderungen aus dem Haupt-Branch 1.27.x aufgenommen hat. In Zukunft werden alle Änderungen im stabilen Branch 1.28 darauf abzielen, schwerwiegende Fehler und Sicherheitsanfälligkeiten zu beheben. Bald wird der Haupt-Branch nginx 1.29 gebildet, in dem die Entwicklung neuer Funktionen fortgesetzt wird. Für normale Benutzer, die keine Kompatibilität mit externen Modulen sicherstellen müssen, wird empfohlen, den Haupt-Branch zu verwenden, aus dem alle drei Monate Versionen des kommerziellen Produkts Nginx Plus erstellt werden.

Laut dem Märzbericht von Netcraft laufen etwa 245 Millionen Websites (vor einem Jahr 243 Millionen, vor zwei Jahren 289 Millionen) unter nginx. Nginx wird auf 17,89 % aller aktiven Websites verwendet (vor einem Jahr 18,15 %, vor zwei Jahren 18,94 %), was dem ersten Platz in dieser Kategorie entspricht (der Anteil von Apache beträgt 16,03 % (vor einem Jahr 20,09 %, vor zwei Jahren 20,52 %), Cloudflare - 17,81 % (14,12 %, 11,32 %), Google - 9,89 % (10,41 %, 9,89 %).

Bei der Betrachtung aller Websites behält nginx die Führung und hat einen Marktanteil von 20,48 % (vor einem Jahr 22,31 %, vor zwei Jahren 25,94 %), während der Anteil von Apache 16,03 % beträgt (20,17 %, 20,58 %), Cloudflare - 12,87 % (11,24 %, 10,17 %), OpenResty (eine Plattform auf Basis von nginx und LuaJIT) - 9,36 % (7,93 %, 7,94 %).

Unter den Millionen der meistbesuchten Websites weltweit belegt nginx den zweiten Platz mit einem Anteil von 20,37 % (vor einem Jahr 20,63 %, vor zwei Jahren 21,37 %). Den ersten Platz hält Cloudflare - 22,32 % (vor einem Jahr 22,59 %, vor zwei Jahren 21,62 %). Der Anteil von Apache httpd beträgt 17,95 % (20,09 %, 21,18 %).

Laut W3Techs wird nginx auf 33,8 % der Websites aus einer Million der meistbesuchten genutzt (im April letzten Jahres lag dieser Wert bei 34,3 %, im Jahr davor bei 34,5 %). Der Anteil von Apache ist im Laufe eines Jahres von 30,1 % auf 26,3 % gesunken, während der Anteil von Microsoft IIS von 5 % auf 4 % gesunken ist. Der Anteil von Node.js stieg von 3,2 % auf 4,4 %, und der Anteil von LiteSpeed stieg von 12,9 % auf 14,6 %.

Die bemerkenswertesten Verbesserungen, die im Prozess der Bildung des Haupt-Branches 1.27.x hinzugefügt wurden:

• Für Verbindungen, die das QUIC-Protokoll verwenden, wurde die Unterstützung des Netzwerküberlastungsmanagement-Algorithmus CUBIC (RFC 9438) hinzugefügt. Dieser Algorithmus erhöht kontinuierlich die Größe des Überlastfensters, bis Paketverluste auftreten, wonach die Fenstergröße auf den Wert vor dem Verlust zurückgesetzt wird. In durchgeführten Tests konnte mit CUBIC die Übertragungszeit einer Datei mit 500 MB um 24 % bei einer Verzögerung von 40 ms und BDP von 750K (Bandwidth Delay Product) und um 73 % bei einer Verzögerung von 100 ms und BDP von 9M verkürzt werden.
• Im Stream-Modul wurde die Unterstützung für die Überprüfung des Widerrufs von Client-Zertifikaten unter Verwendung des OCSP-Protokolls (Online Certificate Status Protocol) hinzugefügt.
• Im Modul stream wurde die Unterstützung der Technik zur Überprüfung von Zertifikatswiderrufen OCSP Stapling implementiert, bei der das von der Zertifizierungsstelle bestätigte OCSP-Antwort während der Aushandlung der TLS-Verbindung vom Server, der die Website bedient, ohne direkte Anfrage an die Zertifizierungsstelle übermittelt wird.
• Beim Start und bei der Aktualisierung der Konfiguration wurde Caching implementiert SSL-Zertifikaten, von Schlüsseln und CRL (Zertifikatssperrliste).
• Es wurden Möglichkeiten zur Reduzierung des Ressourcenverbrauchs und der CPU-Last bei der Verwendung von TLS in Konfigurationen mit einer großen Anzahl von Server- und Standortblöcken hinzugefügt. Die vorgenommenen Änderungen erlauben es, anstelle von für jeden Konfigurationsblock einen separaten SSL-Kontext (SSL_CTX in OpenSSL) zu erstellen, den bereits vorhandenen SSL-Kontext aus dem übergeordneten Block zu verwenden.
• In der Direktive „ssl_client_certificate“ wurde die Unterstützung für Zertifikate mit zusätzlichen Informationen gewährleistet.
• Zur Überprüfung von Client-SSL-Zertifikaten ist die Direktive „ssl_client_certificate“ jetzt nicht mehr obligatorisch.
• Im ngx_mail_proxy_module wurde die Unterstützung für den spezifischen IMAP LOGIN-Modus von SmarterMail mit einer nicht taggierten CAPABILITY-Antwort hinzugefügt.
• Im ngx_http_proxy_module wurde die Direktive „proxy_pass_trailers“ hinzugefügt, die die Übertragung von Headerfeldern am Ende der Antwort vom proxierten Server an den Client erlaubt.
• In die Direktive „server“, die im Block „upstream“ verwendet wird, wurde die Unterstützung für den Parameter „resolve“ hinzugefügt, der die Verfolgung von Änderungen für den verwendeten Domänennamen und die automatische Aktualisierung der Konfiguration des „upstream“-Blocks ohne die Notwendigkeit eines nginx-Neustarts bei Adressänderungen beinhaltet. IP-Adressen die Konfiguration des „upstream“-Blocks automatisch aktualisiert, ohne dass ein Neustart von nginx erforderlich ist, wenn sich die Adresse ändert.
• Die Verwendung von Variablen in den Direktiven „proxy_limit_rate“, „fastcgi_limit_rate“, „scgi_limit_rate“ und „uwsgi_limit_rate“ wurde eingeführt.
• In den Direktiven „proxy_bind“, „fastcgi_bind“, „grpc_bind“, „memcached_bind“, „scgi_bind“ und „uwsgi_bind“ sowie als Client-Adresse im Modul ngx_http_realip_module ist es nun erlaubt, IPv6-Adressen in eckigen Klammern ohne Portnummer anzugeben.
• Die Direktive „keepalive_min_timeout“ wurde hinzugefügt, die den Timeout definiert, innerhalb dessen nginx die Keep-Alive-Verbindung mit dem Client nicht schließt.
• Standardmäßig sind die Protokolle TLSv1 und TLSv1.1 deaktiviert.
• Die Probleme mit der langen Ladezeit von Konfigurationsdateien aufgrund der mehrfachen Analyse desselben Satzes von TLS-Zertifikaten, Schlüsseln und Zertifizierungsstellenlisten wurden gelöst. Der Neustart der Konfiguration wurde durch die Wiederverwendung unveränderter TLS-Objekte wie Zertifikate, Schlüssel und CRLs beschleunigt. Um die Vererbung von Objekten beim Aktualisieren der Konfiguration zu deaktivieren, wurde die Direktive „ssl_object_cache_inheritable“ hinzugefügt.
• Ein Cache für Zertifikate und Schlüssel, die mit Variablen in den Direktiven geladen werden (zum Beispiel „ssl_certificate /etc/ssl/$ssl_server_name.crt“), wurde hinzugefügt. Für die Cache-Verwaltung wurden die Direktiven „ssl_certificate_cache“, „proxy_ssl_certificate_cache“, „grpc_ssl_certificate_cache“ und „uwsgi_ssl_certificate_cache“ hinzugefügt. Über die angegebenen Direktiven können die maximale Cache-Größe, die Gültigkeitsdauer der Einträge und die Zeit für die Bereinigung ungenutzter Einträge konfiguriert werden. Zum Beispiel: „ssl_certificate_cache max=1000 inactive=20s valid=1m;“.
• Der Speicherverbrauch bei der Verarbeitung von lang laufenden Anfragen in Konfigurationen, in denen die Direktiven „gzip“, „gunzip“, „ssi“, „sub_filter“ oder „grpc_pass“ verwendet werden, wurde gesenkt.
• Die maximale Größe der in gemeinsamem Speicher zwischengespeicherten SSL-Sitzungen wurde auf 8192 erhöht.
• Die Integration mit der C-Bibliothek Musl wurde optimiert.
• Optimierungsarbeiten zur Leistungssteigerung und Fehlerbehebung in der HTTP/3-Implementierung wurden durchgeführt.

Zusätzlich kann die Veröffentlichung der Projektversion FreeNginx 1.28.0 erwähnt werden, die ein Fork von Nginx entwickelt. Die Entwicklung des Forks wird von Maxim Dunin geleitet, einem der Schlüsselentwickler von Nginx. FreeNginx wird als gemeinnütziges Projekt positioniert, das die Entwicklung der Codebasis von Nginx ohne Unternehmensintervention gewährleistet. Zu den spezifischen Änderungen in der Version FreeNginx 1.28 gehören:

• Der Parameter „off“ in der Direktive „pid“, der die Erstellung einer PID-Datei deaktiviert.
• Eine Begrenzung der Intensität von Fehlermeldungen im Fehlerprotokoll zum Schutz vor einer Überfüllung des Protokolls mit typischen Meldungen.
• Die Implementierung des Parameters multipath in der Direktive listen zur Unterstützung von Multipath TCP.
• Unterstützung des HTTP-Headers „Age“ zur Bestimmung der Lebensdauer von Einträgen im Cache.
• Hinzufügen der Authentifizierungsmethoden XOAUTH2 und OAUTHBEARER im Modul mail_proxy.

Quelle: opennet.ru