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_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.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.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.
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:
Ältere Betriebssysteme und Architekturen entfernt:
Ältere Betriebssysteme und Architekturen, die veraltet sind und deren Entfernung in NGINX Plus R28 geplant ist:
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.
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:
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:
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 }
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:
auth_jwt_require
, aber nicht mit dem Fehlerparameter
konfiguriert sindWenn 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).
NGINX Plus R27 enthält Versionen0.7.3 Und0.7.4 des NGINX JavaScript-Moduls und umfasst die folgenden Verbesserungen.
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.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.)
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
Codes-
Feld (das die Anzahl der einzelnen HTTP-Statuscodes<.htmla> angibt) unter /http/server_zones
und /http/upstreams
/stream/limit_conns
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.
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.
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.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."