Ankündigung von NGINX Plus R27

Prabhat Dixit

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 27 (R27) bekannt zu geben. Basierend auf NGINX Open Source ist NGINX Plus die einzige All-in-One-Softwarelösung, die Webserver, Load Balancer, Reverse Proxy, Content-Cache und API-Gateway vereint.

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

• Keepalive-Verbindungen für Systemdiagnosen – In früheren Versionen stellte NGINX Plus für jede Systemdiagnose eine neue Verbindung her. Der neue Parameter „keepalive_time“ der HTTP-Direktive „health_check“ ermöglicht Keepalive-Verbindungen für Systemdiagnosen und legt deren Lebensdauer fest. Das Herstellen neuer Verbindungen ist rechenintensiv. Daher kann die Wiederverwendung von Verbindungen die CPU-Auslastung bei einer großen Anzahl von Upstream-Servern erheblich reduzieren.
• Unterstützung für Kernel TLS – NGINX Plus unterstützt jetzt Kernel TLS (kTLS) auf drei Betriebssystemen, die die entsprechenden Anforderungen erfüllen: FreeBSD 13, RHEL 9.0+ und Ubuntu 22.04 LTS.
• TLS-Metriken für Upstream- und virtuelle Server – NGINX Plus erstellt nun zusätzlich zu den globalen Statistiken aus früheren Versionen auch TLS-Statistiken für einzelne Upstreams und virtuelle Server, wenn Proxying über HTTPS aktiviert ist. Metriken sowohl auf Client- als auch auf Serverseite sind bei der Behebung von Problemen mit TLS-Handshakes hilfreich.
• Anpassen des Fehlercodes bei fehlgeschlagener JWT-Validierung – In NGINX Plus R25 und R26 können Sie benutzerdefinierte JWT-Validierungsprüfungen definieren, bei einem Validierungsfehler wird jedoch immer der Fehlercode 401 (Nicht autorisiert) zurückgegeben. Mit NGINX Plus R27 wird der Parameter error für die Direktive auth_jwt_require eingeführt, sodass Sie den Code für jede Prüfung auf 401 oder 403 (Verboten) setzen können, um Authentifizierungs- und Autorisierungsfehler besser voneinander zu unterscheiden.
• Verbesserungen an den Modulen NGINX JavaScript und Prometheus-njs – Zu den Verbesserungen am NGINX-JavaScript-Modul gehören neue Direktiven zur Feinabstimmung des Verhaltens der Funktion ngx.fetch sowie ein neues Objekt, das die njs-Version als Hexadezimalzahl ausgibt. Das Prometheus-njs-Modul kann nun weitere NGINX Plus-Metriken in ein Prometheus-konformes Format konvertieren: das Feld codes (das die Anzahl der einzelnen HTTP-Statuscodes für Upstream- und virtuelle Server angibt) sowie Metriken, die von den Modulen Limit Connections und Limit Requests erzeugt werden.

Abgerundet wird das Release durch eine neue Versionsnummer (8) für die NGINX Plus API und eine gleichmäßigere Verteilung der Verbindungen, wenn der EPOLLEXCLUSIVE-Modus in Linux-Kerneln verwendet wird.

Wichtige Verhaltensänderungen

Hinweis: Wenn Sie ein Upgrade von einer anderen Version als NGINX Plus R26 durchführen, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den Ankündigungsblogs zu allen Versionen zwischen Ihrer aktuellen und dieser Version.

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 wurden entfernt:

• Alpine 3.12, dessen Lebenszyklus (EOL) am 1. Mai 2022 endete
• CentOS 8.1+, dessen Lebenszyklus (EOL) am 31. Dezember 2021 endete (RHEL 8.1+ wird weiterhin unterstützt, da es ein anderes EOL-Datum hat)
• Power-8-Architektur (ppc64le; betrifft CentOS und RHEL)

Ältere Betriebssysteme und Architekturen, die als veraltet eingestuft wurden und deren Unterstützung mit NGINX Plus R28 eingestellt werden soll:

• Debian 10, dessen EOL im August 2022 erreicht wird

Neue Funktionen im Detail

Keepalive-Verbindungen für Integritätsprüfungen

Keepalive-Verbindungen zwischen NGINX Plus und Upstream-Servern verbessern die Leistung bei Reverse-Proxy- und Lastverteilungsszenarien erheblich. Insbesondere beim Proxybetrieb über HTTPS kann der Rechenaufwand für den vollständigen TLS-Handshake, der für jede neue Verbindung erforderlich ist, Ihre Rechenressourcen stark belasten – vor allem in Produktionsumgebungen mit einer großen Anzahl von Upstream-Servern.

In früheren Versionen verwendete NGINX Plus für Systemdiagnosen keine Keepalive-Verbindungen, sondern stellte für jede Systemdiagnose eine neue Verbindung her. Mit NGINX Plus R27 werden Keepalive-Verbindungen für HTTP-Systemdiagnosen eingeführt. Der neue Parameter keepalive_time der Direktive health_check legt die Lebensdauer jeder Keepalive-Verbindung fest. Nach Ablauf dieser Zeit wird eine neue Verbindung hergestellt. Unsere Tests zeigen, dass Keepalive-Verbindungen beim Proxybetrieb über HTTPS die CPU-Auslastung für Systemdiagnosen auf NGINX Plus-Servern um den Faktor 10 bis 20 reduzieren. Außerdem sparen sie CPU-Ressourcen auf Upstream-Servern.

Das folgende Beispiel aktiviert Keepalive-Verbindungen mit einer Lebensdauer von 60 Sekunden. Bei der mit dem Parameter interval festgelegten Systemdiagnosehäufigkeit von 1 Sekunde fällt der Aufwand für den TLS-Handshake und den Verbindungsaufbau bei NGINX Plus nur einmal pro 60 Systemdiagnosen an.

Codebeispiel wird geladen…

Unterstützung für Kernel-TLS

Transport Layer Security (TLS) ist das De-facto-Standardprotokoll für die Datenverschlüsselung im Internet. Leider erhöht der Schutz von Daten auch die Latenz. Die Implementierung von TLS im Kernel (kTLS) verbessert die Leistung bei der Bereitstellung statischer Inhalte, da deutlich weniger Kopiervorgänge zwischen dem Userspace und dem Kernel erforderlich sind.

Durch die Kombination von kTLS mit dem Systemaufruf sendfile() werden Daten direkt im Kernel-Space verschlüsselt, bevor sie zur Übertragung an den Netzwerk-Stack übergeben werden. Dadurch müssen sie nicht zur Verschlüsselung mithilfe von TLS-Bibliotheken in den User-Space und anschließend vor der Übertragung wieder zurück in den Kernel-Space kopiert werden. kTLS ermöglicht außerdem die Auslagerung der TLS-Verarbeitung auf Hardware. Dazu gehört auch die Auslagerung der symmetrischen TLS-Kryptografie auf Netzwerkgeräte.

Für die Unterstützung von kTLS müssen drei Voraussetzungen erfüllt sein:

1. Der Betriebssystemkernel unterstützt es
2. Die Betriebssystemdistribution enthält die mit kTLS-Unterstützung kompilierte Kryptobibliothek OpenSSL 3.0+.
3. NGINX Plus (oder NGINX Open Source) wurde mit der Kryptobibliothek OpenSSL 3.0+ kompiliert

Im Oktober 2021 haben wir Unterstützung für kTLS in NGINX Open Source 1.21.4 auf Plattformen hinzugefügt, die die Anforderungen 1 und 2 erfüllen. Nun 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, stellt die NGINX Plus API umfangreiche Metriken zu Datenverkehr, Antwortcodes und Latenz für jeden Upstream- und virtuellen Server bereit. So können Kunden die Leistung und Verfügbarkeit der Server beobachten und überwachen.

In früheren Versionen generierte NGINX Plus systemweite Metriken zu TLS-Aktivitäten und -Fehlern, wenn HTTPS-Verbindungen zwischen NGINX Plus und Upstream-Servern verwendet wurden, und zwar sowohl im http- als auch im stream-Kontext (eingerichtet mit den Direktiven proxy_pass https://path-to-upstream beziehungsweise proxy_ssl on). Die Statistiken umfassen Handshakes, Fehler und Sitzungswiederverwendungen (wie mit der Direktive proxy_ssl_session_reuse konfiguriert).

NGINX Plus R27 generiert diese TLS-Metriken für einzelne Upstream-Server, deren Konfiguration die Direktive „zone“ enthält, sowie für virtuelle Server, deren Konfiguration die Direktive „status_zone“ enthält. Metriken sowohl von der Client- als auch von der Serverseite sind bei der Behebung von Problemen mit TLS-Handshakes hilfreich.

Das folgende Beispiel aktiviert die Erfassung von Statistiken auf dem Upstream-Server upstream1 und dem virtuellen Server, der den Datenverkehr an ihn weiterleitet.

Codebeispiel wird geladen…

Diese Ausgabe zeigt, dass der erste Upstream-Server an vier TLS-Handshakes beteiligt war und zwei Sitzungen wiederverwendet wurden (der Kürze halber zeigen wir nur einen Teil der Ausgabe 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 | jq{
  "peers": [
    {
      "id": 0,
      "server": "127.0.0.1:8081",
      "name": "127.0.0.1:8081",
      "backup": false,
      "weight": 1,
      "state": "up",
      "active": 0,
      "ssl": { "handshakes": 4, "handshakes_failed": 0, "session_reuses": 2 },
      "requests": 4,
      "header_time": 4,
      "response_time": 4,
      ...
    }
    ...
  ]
}

Diese Ausgabe zeigt, dass NGINX Plus an sieben TLS-Handshakes beteiligt war:

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq{
  "processing": 0,
  "requests": 7,
  "responses": {
    "1xx": 0,
    "2xx": 7,
    "3xx": 0,
    "4xx": 0,
    "5xx": 0,
    "codes": {
      "200": 7
    },
    "total": 7
  },
  "discarded": 0,
  "received": 546,
  "sent": 1134,
  "ssl": { "handshakes": 7, "handshakes_failed": 0, "session_reuses": 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_failed": 0,
  "session_reuses": 6
}

Anpassen des Fehlercodes bei fehlgeschlagener JWT-Validierung

NGINX Plus R25 führte die auth_jwt_require-Direktive ein, mit der benutzerdefinierte Prüfungen während der JWT-Validierung definiert werden können. In NGINX Plus R25 und R26 lautet der bei einem Validierungsfehler zurückgegebene Fehlercode immer 401 (Nicht autorisiert).

NGINX Plus R27 führt den Parameter „error“ für die Direktive „auth_jwt_require“ ein, mit dem Sie den Code für jede Direktive unabhängig auf 401 oder 403 (Verboten) setzen können. Wenn die Zugriffsanforderung eines Benutzers fehlschlägt, können Sie durch die Wahl des Codes zwischen einem Authentifizierungsfehler (JWT ist ungültig) und einem Autorisierungsfehler (erforderlicher Anspruch fehlt) unterscheiden. Sie können auch benutzerdefinierte Handler für die Fehlercodes erstellen, beispielsweise um eine spezielle Seite mit einer Erläuterung des Fehlers zurückzugeben (mit der Direktive „error_page“) oder um die Anforderung zur weiteren Verarbeitung an einen benannten internen Speicherort umzuleiten.

Der standardmäßige Statuscode bleibt 401 bei einem Fehlschlagen der folgenden Arten von JWT-Prüfungen:

• Die (nicht benutzerdefinierten) Prüfungen, die immer durchgeführt werden
• Benutzerdefinierte Prüfungen, die mit auth_jwt_require konfiguriert wurden, jedoch ohne den Parameter error parameter

Wenn mehrere auth_jwt_require-Direktiven in einem location-Block vorhanden sind, werden sie in der Reihenfolge ausgewertet, in der sie aufgeführt sind. Die Verarbeitung wird beim ersten Fehler abgebrochen und der angegebene Fehlercode zurückgegeben.

In diesem Beispiel gibt die Direktive „auth_jwt_require“ den Statuscode 403 zurück, wenn entweder $req1 oder $req2 als leerer Wert oder als 0 (null) ausgewertet wird.

Codebeispiel wird geladen…

Verbesserungen an den Modulen NGINX JavaScript und Prometheus-njs

NGINX Plus R27 enthält die Versionen 0.7.3 und 0.7.4 des NGINX-JavaScript-Moduls und umfasst die folgenden Verbesserungen.

Zusätzliche Direktiven für die njs Fetch API

Mit NGINX Javascript 0.5.3, das in NGINX Plus R24 integriert wurde, wurde die Funktion „ngx.fetch“ (auch als Fetch API bezeichnet) eingeführt, mit der sich im Kontext einer TCP/UDP-Verbindung ein einfacher HTTP-Client instanziieren lässt. (Eine Erläuterung der Anwendungsfälle für diese Funktion finden Sie im Beitrag „Nutzung von HTTP-Diensten für TCP.htmlUDP mit einem einfachen HTTP-Client“ in unserem Blog.)

NGINX Plus R27 führt die folgenden Direktiven 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] – Legt das Zeitlimit für Lese- und Schreibvorgänge zwischen zwei aufeinanderfolgenden Lese- oder Schreibvorgängen fest (nicht für die gesamte Antwort). Werden innerhalb dieses Zeitraums keine Daten übertragen, wird die Verbindung geschlossen.
• js_fetch_verify[HTTP][Stream] – Aktiviert oder deaktiviert die Überprüfung des HTTPS-Serverzertifikats.

Versionsnummer wird als Hexadezimalzahl ausgegeben

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

Prometheus-njs-Modul konvertiert zusätzliche Metriken

Das Prometheus-njs-Modul, das NGINX Plus-Metriken in ein Prometheus-kompatibles Format konvertiert, kann jetzt auch Metriken konvertieren, die an diesen zusätzlichen Endpunkten bereitgestellt werden:

• /http/limit_conns
• /http/limit_reqs
• Das Feld codes (das die Anzahl einzelner HTTP-Statuscodes<.htmla> meldet) unter /http/server_zones und /http/upstreams
• /stream/limit_conns

Weitere Verbesserungen in NGINX Plus R27

Änderung der NGINX Plus-API-Version

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

Bessere Verteilung von Verbindungen im Linux-EPOLLEXCLUSIVE-Modus

NGINX Plus R27 verteilt Verbindungen gleichmäßiger auf die NGINX-Worker-Prozesse, wenn in Linux-Kerneln der EPOLLEXCLUSIVE-Modus verwendet wird. Normalerweise benachrichtigt der Kernel in diesem Modus nur den Prozess, der den Listening-Socket zuerst zur EPOLL-Instanz hinzugefügt hat. Daher werden die meisten Verbindungen vom ersten Worker-Prozess verarbeitet. NGINX fügt den Socket nun regelmäßig erneut hinzu, damit auch andere Worker-Prozesse die Möglichkeit erhalten, Verbindungen anzunehmen.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R27 durchzuführen. Dadurch erhalten Sie außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten APIs für Überwachung und Verwaltung. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über den Autor

Prabhat Dixit

Weitere Blogbeiträge von Prabhat Dixit