Ankündigung von NGINX Plus R27

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 27 (R27) bekannt zu geben. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Software-Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.

Zu den neuen und erweiterten Funktionen in NGINX Plus R27 gehören:

• Keepalive-Verbindungen für Integritätsprüfungen – In früheren Versionen hat NGINX Plus für jede Integritätsprüfung eine neue Verbindung hergestellt. Der neue Parameter „keepalive_time“ für die HTTP-Direktive „health_check“ aktiviert Keepalive-Verbindungen für Integritätsprüfungen und legt deren Lebensdauer fest. Das Herstellen neuer Verbindungen ist rechenintensiv, daher kann die Wiederverwendung von Verbindungen die CPU-Auslastung erheblich reduzieren, wenn eine große Anzahl von Upstream-Servern vorhanden ist.
• Unterstützung für Kernel TLS – NGINX Plus unterstützt jetzt Kernel TLS (kTLS) auf drei Betriebssystemen, die die Anforderungen zur Unterstützung erfüllen: FreeBSD 13, RHEL 9.0+ und Ubuntu 22.04 LTS .
• TLS-Metriken für Upstream- und virtuelle Server – NGINX Plus generiert jetzt zusätzlich zu den globalen Statistiken, die es in früheren Versionen generiert hat, TLS-Statistiken für einzelne Upstreams und virtuelle Server, wenn die Proxy-Funktion über HTTPS aktiviert ist. Bei der Behebung von Problemen mit TLS-Handshakes ist es hilfreich, Metriken sowohl von der Client- als auch von der Serverseite zu haben.
• Anpassen des Fehlercodes bei JWT-Validierungsfehlern – In NGINX Plus R25 und R26 können Sie benutzerdefinierte JWT-Validierungsprüfungen definieren, aber der für einen Validierungsfehler zurückgegebene Fehlercode ist immer 401(Nicht autorisiert) . NGINX Plus R27 führt den Fehlerparameter in die Anweisung auth_jwt_require ein, mit dem Sie den Code so einstellen können,401 oder 403(Verboten) für jede Prüfung, um besser zwischen Authentifizierungs- und Autorisierungsfehlern unterscheiden zu können.
• Verbesserungen an den NGINX JavaScript- und Prometheus-njs-Modulen – Zu den Verbesserungen am NGINX JavaScript-Modul gehören neue Anweisungen zur Feinabstimmung des Verhaltens der Funktion ngx.fetch und ein neues Objekt, das die njs-Version als Hexadezimalzahl meldet. Das Modul Prometheus-njs kann jetzt zusätzliche NGINX Plus-Metriken in ein Prometheus-kompatibles Format konvertieren: das Codefeld (das die Anzahl der einzelnen HTTP-Statuscodes für Upstream- und virtuelle Server meldet) und von den Modulen „Limit Connections“ und „Limit Requests“ generierte Metriken.

Abgerundet wird die Version durch eine neue Versionsnummer (8) für die NGINX Plus API und eine gleichmäßigere Verteilung der Verbindungen bei Verwendung des EPOLLEXCLUSIVE-Modus in Linux-Kerneln.

Wichtige Verhaltensänderungen

Notiz: Wenn Sie von einer anderen Version als NGINX Plus R26 aktualisieren, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den Ankündigungsblogs für alle Versionen zwischen Ihrer aktuellen und dieser.

Neue unterstützte Betriebssysteme:

• Alpine Linux 3.16
• RHEL 9.0+ (nach der Erstveröffentlichung zu NGINX Plus R26 hinzugefügt)
• Ubuntu 22.04 LTS (nach der Erstveröffentlichung zu NGINX Plus R26 hinzugefügt)

Ältere Betriebssysteme und Architekturen entfernt:

• Alpine 3.12, das am 1. Mai 2022 das Ende seiner Lebensdauer (EOL) erreichte
• CentOS 8.1+, das am 31. Dezember 2021 das EOL erreichte (RHEL 8.1+ wird weiterhin unterstützt, da sein EOL-Datum anders ist)
• Power 8-Architektur (ppc64le; betrifft CentOS und RHEL)

Ältere Betriebssysteme und Architekturen, die veraltet sind und deren Entfernung in NGINX Plus R28 geplant ist:

• Debian 10, das im August 2022 das EOL erreichen wird

Neue Features im Detail

Keepalive-Verbindungen für Integritätsprüfungen

Keepalive-Verbindungen zwischen NGINX Plus und Upstream-Servern verbessern die Leistung für Anwendungsfälle mit Reverse-Proxy und Lastausgleich erheblich. Insbesondere beim Proxy über HTTPS kann der Rechenaufwand des vollständigen TLS-Handshakes, der für jede neue Verbindung erforderlich ist, Ihre Computerressourcen belasten, vor allem in Produktionsumgebungen mit einer großen Anzahl von Upstream-Servern.

In früheren Versionen verwendete NGINX Plus keine Keepalive-Verbindungen für Integritätsprüfungen, sondern stellte für jede Integritätsprüfung eine neue Verbindung her. NGINX Plus R27 führt Keepalive-Verbindungen für HTTP-Integritätschecks ein. Der neue Parameter „keepalive_time“ der Direktive „health_check“ legt die Lebensdauer jeder Keepalive-Verbindung fest, nach deren Ablauf eine neue Verbindung hergestellt wird. Unsere Tests zeigen, dass Keepalive-Verbindungen bei Proxy über HTTPS die CPU-Auslastung für Integritätsprüfungen auf NGINX Plus-Servern um den Faktor 10 bis 20 reduzieren. Sie sparen außerdem CPU-Ressourcen auf Upstream-Servern.

Das folgende Beispiel aktiviert Keepalive-Verbindungen mit einer Lebensdauer von 60 Sekunden. Angesichts der durch den Intervallparameter festgelegten Häufigkeit der Integritätsprüfungen von 1 Sekunde fallen bei NGINX Plus die Kosten für den TLS-Handshake und die Verbindungsherstellung nur einmal pro 60 Integritätsprüfungen an.

Unterstützung für Kernel-TLS

Transport Layer Security (TLS) ist das De-facto-Standardprotokoll zur Datenverschlüsselung im Internet. Leider führt der Schutz der Daten auch zu Latenzzeiten. Durch die Implementierung von TLS im Kernel (kTLS) wird die Leistung beim Bereitstellen statischer Inhalte verbessert, indem die Notwendigkeit von Kopiervorgängen zwischen Benutzerbereich und Kernel erheblich reduziert wird.

Durch die Kombination von kTLS und dem Systemaufruf sendfile() werden die Daten direkt im Kernelspeicher verschlüsselt, bevor sie zur Übertragung an den Netzwerkstapel übergeben werden, anstatt sie zur Verschlüsselung mithilfe von TLS-Bibliotheken in den Benutzerspeicher zu kopieren und vor der Übertragung wieder in den Kernelspeicher zurückzukopieren. kTLS ermöglicht außerdem die Auslagerung der TLS-Verarbeitung auf die Hardware, einschließlich der Auslagerung der symmetrischen TLS-Kryptoverarbeitung auf Netzwerkgeräte.

Für die Unterstützung von kTLS gibt es drei Voraussetzungen:

1. Der Betriebssystemkernel unterstützt es
2. Die Betriebssystemdistribution umfasst die mit kTLS-Unterstützung kompilierte Kryptobibliothek OpenSSL 3.0+
3. NGINX Plus (oder NGINX Open Source) basiert auf der Kryptobibliothek OpenSSL 3.0+

Im Oktober 2021 haben wir Unterstützung für kTLS zu NGINX Open Source 1.21.4 auf Plattformen hinzugefügt, die die Anforderungen 1 und 2 erfüllen. Jetzt fügen wir auf diesen Plattformen Unterstützung für kTLS in NGINX Plus hinzu:

• FreeBSD 13 (in NGINX Plus R26 und höher)
• RHEL 9.0+
• Ubuntu 22.04 LTS

TLS-Metriken für Upstream- und virtuelle Server

Wenn NGINX Plus als Reverse-Proxy oder Load Balancer eingesetzt wird, bietet die NGINX Plus-API einen umfangreichen Satz an Metriken zu Datenverkehr, Antwortcodes und Latenz für jeden Upstream- und virtuellen Server, sodass Kunden die Serverleistung und -verfügbarkeit beobachten und überwachen können.

In früheren Versionen generierte NGINX Plus Metriken zu TLS-Aktivitäten und -Fehlern auf systemweiter Ebene, wenn HTTPS-Verbindungen zwischen NGINX Plus und Upstream-Servern sowohl im HTTP- als auch im Stream- Kontext verwendet wurden (hergestellt mit den Anweisungen proxy_pass https: //path-to-upstream bzw. proxy_ssl on ). Die Statistiken decken Handshakes, Fehler und Sitzungswiederverwendungen ab (wie mit der Direktive proxy_ssl_session_reuse konfiguriert).

NGINX Plus R27 generiert diese TLS-Metriken für einzelne Upstream-Server, deren Konfiguration die Zonendirektive enthält, und für virtuelle Server, deren Konfiguration die Status_Zone -Direktive enthält. Bei der Behebung von Problemen mit TLS-Handshakes ist es hilfreich, Metriken sowohl von der Client- als auch von der Serverseite zu haben.

Das folgende Beispiel aktiviert die Statistikerfassung auf dem Upstreamserver upstream1 und dem virtuellen Server, der den Datenverkehr dorthin weiterleitet.

Diese Ausgabe zeigt an, dass der erste Upstream-Server an vier TLS-Handshakes und zwei wiederverwendeten Sitzungen teilgenommen hat (der Kürze halber zeigen wir die Teilausgabe für den ersten Server und lassen die Ausgabe für die anderen Upstream-Server weg):

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | 0, "Server": "127.0.0.1:8081", "Name": "127.0.0.1:8081", "Backup": false, "Gewicht": 1, „Status“: „aktiv“, „aktiv“: 0, "ssl": { "Handshakes": 4, „Handshakes fehlgeschlagen“: 0, "Sitzung wird wiederverwendet": 2 } , "Anfragen": 4, "Header_Zeit": 4, "Antwortzeit": 4, ... } ... ] }

Diese Ausgabe zeigt, dass NGINX Plus an sieben TLS-Handshakes teilgenommen hat:

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "wird verarbeitet": 0, "Anfragen": 7, "Antworten": { "1xx": 0, "2xx": 7, „3xx“: 0, "4xx": 0, "5xx": 0, "Codes": { "200": 7 }, "gesamt": 7 }, "verworfen": 0, "empfangen": 546, "gesendet": 1134, "ssl": { "Handshakes": 7, „Handshakes fehlgeschlagen“: 0, "Sitzung wird wiederverwendet": 0 } ... }

Beachten Sie, dass die NGINX Plus-API weiterhin die globalen TLS-Metriken erfasst, die in früheren NGINX Plus-Versionen verfügbar waren:

$ curl http://127.0.0.1:8000/api/8/ssl | jq { "Handshakes": 21, „Handshakes fehlgeschlagen“: 0, "Sitzung wird wiederverwendet": 6 }

Anpassen des Fehlercodes für JWT-Validierungsfehler

NGINX Plus R25 hat die Direktive auth_jwt_require zum Definieren benutzerdefinierter Prüfungen während des JWT-Validierungsprozesses eingeführt<.htmla>. In NGINX Plus R25 und R26 lautet der Fehlercode, der bei einem Validierungsfehler zurückgegeben wird, immer 401(Nicht autorisiert) .

NGINX Plus R27 führt den Fehlerparameter in die Direktive auth_jwt_require ein, mit dem Sie den Code so einstellen können,401 oder403 (Verboten) für jede Richtlinie unabhängig. Wenn die Zugriffsanforderung eines Benutzers fehlschlägt, können Sie anhand der Codeauswahl den Unterschied zwischen einem Authentifizierungsfehler (JWT ist ungültig) und einem Autorisierungsfehler (erforderlicher Anspruch fehlt) deutlich machen. Sie können auch benutzerdefinierte Handler für die Fehlercodes erstellen, um beispielsweise eine spezielle Seite mit einer Erläuterung des Fehlers zurückzugeben (mit der Direktive error_page ) oder die Anforderung zur weiteren Verarbeitung an einen benannten internen Speicherort umzuleiten.

Der Standardstatuscode bleibt401 für das Fehlschlagen der folgenden Typen von JWT-Prüfungen:

• Die (nicht benutzerdefinierten) Prüfungen, die immer durchgeführt werden
• Benutzerdefinierte Prüfungen, die mit auth_jwt_require , aber nicht mit dem Fehlerparameter konfiguriert sind

Wenn ein Standortblock mehrere auth_jwt_require -Direktiven enthält, werden sie in der Reihenfolge ausgewertet, in der sie erscheinen. Die Verarbeitung wird beim ersten Fehler gestoppt und der angegebene Fehlercode wird zurückgegeben.

In diesem Beispiel gibt die Direktive auth_jwt_require zurück403 wenn entweder $req1 oder $req2 einen leeren Wert ergibt oder0 (null).

Verbesserungen an den NGINX JavaScript- und Prometheus-njs-Modulen

NGINX Plus R27 enthält Versionen0.7.3 Und0.7.4 des NGINX JavaScript-Moduls und umfasst die folgenden Verbesserungen.

Zusätzliche Anweisungen für die njs Fetch API

NGINX Javascript 0.5.3, integriert in NGINX Plus R24 , führte die Funktion ngx.fetch (auch als Fetch-API bezeichnet) zum Instanziieren eines einfachen HTTP-Clients im Kontext einer TCP/UDP-Verbindung ein. (Eine Erörterung der Anwendungsfälle für die Funktion finden Sie unter „Nutzung von HTTP-Diensten für TCP.htmlUDP mit einem einfachen HTTP-Client“ in unserem Blog.)

NGINX Plus R27 führt die folgenden Anweisungen zur Feinabstimmung des Verhaltens der Fetch-API ein:

• js_fetch_buffer_size [ HTTP ][ Stream ] – Legt die Größe des zum Lesen und Schreiben verwendeten Puffers fest.
• js_fetch_max_response_buffer_size [ HTTP ][ Stream ] – Legt die maximale Größe der mit der Fetch-API empfangenen Antwort fest.
• js_fetch_timeout [ HTTP ][ Stream ] – Definiert das Timeout für Lesen und Schreiben zwischen zwei aufeinanderfolgenden Lese- oder Schreiboperationen (nicht für die gesamte Antwort). Werden innerhalb der Timeout-Zeit keine Daten übertragen, wird die Verbindung geschlossen.
• js_fetch_verify [ HTTP ][ Stream ] – Aktiviert oder deaktiviert die Überprüfung des HTTPS-Serverzertifikats.

Als Hexadezimalzahl gemeldete Versionsnummer

Das neue Objekt njs.version_number meldet die Version des NJS-Moduls als Hexadezimalzahl. (Das vorhandene njs.version- Objekt gibt die Version als Zeichenfolge zurück.)

Prometheus-njs-Modul konvertiert zusätzliche Metriken

Das Modul Prometheus-njs , das NGINX Plus-Metriken in ein Prometheus-kompatibles Format konvertiert, kann jetzt Metriken konvertieren, die an diesen zusätzlichen Endpunkten verfügbar sind:

• /http/limit_conns
• /http/Anforderungslimit
• Das Codes- Feld (das die Anzahl der einzelnen HTTP-Statuscodes<.htmla> angibt) unter /http/server_zones und /http/upstreams
• /stream/limit_conns

Weitere Verbesserungen in NGINX Plus R27

NGINX Plus API Versionsänderung

Die Versionsnummer der NGINX Plus-API wird von 7 auf 8 aktualisiert, um die Ergänzung des SSL- Felds zu den für Upstream- und virtuelle Server gemeldeten Metriken widerzuspiegeln, wie in TLS-Metriken für Upstream- und virtuelle Server beschrieben. Frühere Versionsnummern funktionieren weiterhin, aber die Ausgabe enthält keine Metriken, die in späteren API-Versionen hinzugefügt wurden.

Bessere Verteilung der Verbindungen im Linux EPOLLEXCLUSIVE-Modus

NGINX Plus R27 verteilt Verbindungen gleichmäßiger unter den NGINX-Arbeitsprozessen, wenn der EPOLLEXCLUSIVE-Modus in Linux-Kerneln verwendet wird. Normalerweise benachrichtigt der Kernel in diesem Modus nur den Prozess, der als erster den Abhörsocket zur EPOLL-Instanz hinzugefügt hat. Daher werden die meisten Verbindungen vom ersten Arbeitsprozess gehandhabt. NGINX fügt den Socket jetzt regelmäßig erneut hinzu, um anderen Arbeitsprozessen die Möglichkeit zu geben, Verbindungen anzunehmen.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R27 zu aktualisieren. Sie erhalten außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen.