Ankündigung von NGINX Plus R30

NGINX | 15. August 2023

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 30 (R30) 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 R30 gehören:

  • Native Unterstützung für QUIC+HTTP/3 – NGINX Plus bietet jetzt offizielle Unterstützung für HTTP/3. Die Implementierung ist nicht auf Drittanbieterbibliotheken angewiesen, um die fehlende OpenSSL-TLS-Funktionalität bereitzustellen, die für die HTTP/3-Unterstützung über das QUIC-Protokoll erforderlich ist. Sie verwendet eine vom NGINX-Team entwickelte OpenSSL-Kompatibilitätsschicht, um die Herausforderungen durch QUIC-TLS-Schnittstellen zu umgehen, die von OpenSSL nicht unterstützt werden.
  • Verbindungstelemetrie pro Worker – Die Überwachung von Verbindungen auf Worker-Ebene wird jetzt unterstützt. Dadurch können Benutzer die Leistung von NGINX optimieren, indem sie die Anzahl der Worker-Prozesse anpassen und die Verbindungen für eine optimale Leistung effizient auf die Worker verteilen.
  • Diagnosepaket – Das NGINX-Diagnosepaket erfasst alle für die Fehlerbehebung erforderlichen Daten in einer einzigen komprimierten Datei. Dies verbessert die Kommunikation zwischen Benutzern von NGINX Plus und dem F5-Support, steigert die Effizienz und verkürzt die Bearbeitungszeit bei der Problembehebung.

Abgerundet wird das Release durch neue Funktionen und Fehlerbehebungen aus NGINX Open Source sowie Aktualisierungen des NGINX-JavaScript-Moduls.

Wichtige Verhaltensänderungen

Hinweis: Wenn Sie ein Upgrade von einer anderen Version als NGINX Plus R29 durchführen, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den früheren Ankündigungs-Blogbeiträgen für alle Versionen zwischen Ihrer aktuellen Version und dieser Version.

Veraltung der listen … http2-Direktive

Die Direktive listen … http2 ist seit NGINX 1.25.1 veraltet. Bei der Überprüfung der NGINX-Konfiguration mit nginx -t wird eine entsprechende Warnung ausgegeben.

nginx -t

nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in etc/nginx/nginx.conf :15

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Allen bestehenden Nutzern dieser Direktive wird dringend empfohlen, NGINX zu aktualisieren und die http2-Direktive zu verwenden, mit der HTTP/2 für jeden Server einzeln aktiviert werden kann.

Ändern Sie Folgendes:

listen 443 ssl http2;

Zu diesem:

listen 443 ssl;
http2 on;

Nichtverfügbarkeit des GeoIP2-Moduls unter Amazon Linux 2

Frühere Versionen von NGINX Plus verwendeten die Bibliothek „libmaxminddb“ aus dem EPEL-Repository von Amazon Linux 2, um das GeoIP2-Modul zu erstellen. Das EPEL-Repository stellt diese Bibliothek nicht mehr bereit, und sie ist auch nicht nativ über die Amazon-Linux-2-Distribution verfügbar. Daher ist das Modul in NGINX Plus R30 nicht mehr verfügbar, da es keine praktikable Möglichkeit gibt, es für Amazon Linux 2 zu erstellen.

Änderungen an MQTT-Direktiven

Die Direktive „mqtt_rewrite_buffer_size“, mit der die Größe des Puffers zum Erstellen von MQTT-Nachrichten festgelegt wird, wurde durch die Direktive „mqtt_buffers“ ersetzt. Mit der neuen Direktive können sowohl die Anzahl der Puffer, die pro Verbindung zugewiesen werden können, als auch die Größe der einzelnen Puffer festgelegt werden.

Aktualisierte API-Version

Die Versionsnummer der NGINX Plus API wurde von 8 auf 9 aktualisiert, um die unter „Verbindungstelemetrie pro Worker“ beschriebenen Metriken pro Worker zu berücksichtigen. Frühere Versionsnummern funktionieren weiterhin, die Ausgabe enthält jedoch keine Metriken, die in späteren API-Versionen hinzugefügt wurden.

Änderungen bei der Plattformunterstützung

Neu unterstützte Betriebssysteme:

  • Debian 12
  • Alpine 3.18

Ältere Betriebssysteme wurden entfernt:

  • Alpine 3.14, dessen Lebenszyklus (EOL) am 1. Mai 2023 endete
  • Ubuntu 18.04, dessen Lebenszyklus (EOL) am 26. April 2023 endete

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

  • Alpine 3.15, dessen Support im November 2023 endet

Neue Funktionen im Detail

Native Unterstützung für QUIC+HTTP/3

HTTP/3 über QUIC ist eine mit Spannung erwartete Funktion, die von vielen unserer Unternehmenskunden gewünscht wurde. Wir freuen uns, sie mit NGINX Plus R30 offiziell einzuführen. Es handelt sich um eine neue Technologie und Implementierung, auf die wir uns auch in zukünftigen Versionen konzentrieren werden. Wir empfehlen Benutzern von NGINX Plus, sie zunächst in einer Nicht-Produktionsumgebung zu testen und uns wertvolles Feedback mitzuteilen.

NGINX Plus nutzt OpenSSL für sichere Kommunikation und kryptografische Funktionen und greift dabei auf die mit den Betriebssystemen ausgelieferten SSL/TLS-Bibliotheken zurück. Da die TLS-Schnittstellen von QUIC zum Zeitpunkt dieser Version jedoch nicht von OpenSSL unterstützt werden, sind Bibliotheken von Drittanbietern erforderlich, um die fehlende, für HTTP/3 benötigte TLS-Funktionalität bereitzustellen.

Um dieses Problem zu lösen, hat das NGINX-Team eine OpenSSL-Kompatibilitätsschicht entwickelt, sodass TLS-Bibliotheken von Drittanbietern wie quictls, BoringSSL und LibreSSL nicht mehr erstellt und ausgeliefert werden müssen. Dadurch lässt sich die durchgängige QUIC+HTTP/3-Nutzung in NGINX verwalten, ohne eine benutzerdefinierte TLS-Implementierung pflegen zu müssen oder von den Zeitplänen und Roadmaps der Drittanbieterbibliotheken abhängig zu sein. Wir planen, die OpenSSL-Kompatibilitätsschicht in zukünftigen Versionen um weitere Funktionen und Optionen zu erweitern, beispielsweise um die Unterstützung von 0-RTT.

Hier ist die QUIC+HTTP/3-Konfiguration:

http {
        log_format quic '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent" "$http3"';
        access_log logs/access.log quic;

        server {
              # for better compatibility it's recommended
              # to use the same port for quic and https
              listen 8443 quic reuseport;
              listen 8443 ssl;

              ssl_certificate     certs/example.com.crt;
              ssl_certificate_key certs/example.com.key;

              location / {
                  # required for browsers to direct them into quic port
                  add_header Alt-Svc 'h3=":8443"; ma=86400';
              }
          }
      }

Die QUIC+HTTP/3-Unterstützung in NGINX Plus R30 ist in einer einzigen Binärdatei verfügbar – im Gegensatz zur experimentellen HTTP/3-Unterstützung, die in NGINX Plus R29 eingeführt wurde, für die es eine separate Binärdatei für nginx quic gab. Diese Verbesserung erleichtert die Bereitstellung der Funktionalität in Ihrer Umgebung.

Hinweis: Mit NGINX Plus R30 stellen wir den Support und die Updates für die eigenständige QUIC-Binärdatei ein und planen, sie im Laufe dieses Jahres als Download-Option zu entfernen.

Verbindungstelemetrie pro Worker

Benutzer von NGINX Plus können jetzt die Gesamtzahl der Verbindungen pro Worker-Prozess überwachen, um die Direktive worker_connections optimal abzustimmen. Diese Verbesserung bietet Benutzern einen besseren Einblick in die Verteilung der Verbindungen auf die Worker. Durch die Möglichkeit, die Worker-Verbindungen abzustimmen, können Sie außerdem Ihre NGINX-Bereitstellung besser beurteilen.

Die Verbindungsmetriken für einzelne Worker sind über die REST-API verfügbar. Um diese Metriken abzurufen, verwenden Sie den Endpunkt „…/api/9/workers“.

Um die Verbindungsmetriken eines einzelnen Workers abzurufen, verwenden Sie den Endpunkt .../api/9/workers/<worker id> . Die worker id wird ab 0 gezählt.

Hier ist eine Beispielantwort:

{
      {
          "id": 0,
          "pid": 2346,
          "connections": {
              "accepted": 1,
              "dropped": 0,
              "active": 1,
              "idle": 0
          },
          "http": {
              "requests": {
                  "total": 15,
                  "current": 1
              }
          }
      },
      {
          "id": 1,
          "pid": 1234,
          "connections": {
              "accepted": 3,
              "dropped": 0,
              "active": 1,
              "idle": 0
          },
          "http": {
              "requests": {
                  "total": 15,
                  "current": 1
              }
          }
      },

      ...

  }

Die Verbindungsmetriken für die einzelnen Worker sind im NGINX Plus Live Activity Monitoring Dashboard verfügbar, wie unten dargestellt. Eine Live-Demo dieser Funktion ist unter demo.nginx.com verfügbar.

NGINX Plus Live Activity Monitoring Dashboard mit den unten aufgeführten Informationen zu Verbindungen und Anfragen von NGINX Plus

Das Dashboard zeigt die folgenden Informationen zu Verbindungen und Anfragen von NGINX Plus.

Verbindungen:

  • Akzeptierte Verbindungen pro Worker
  • Aktive Verbindungen pro Worker
  • Inaktive Verbindungen pro Worker
  • Getrennte Verbindungen pro Worker

Anfragen:

  • Aktuelle Anfragen pro Worker
  • Gesamtzahl der Anfragen pro Worker
  • Anfragen/Sek. pro Worker

Diagnosepaket

Um die Bearbeitungszeit bei der Problembehebung zu verkürzen, optimiert das Diagnosepaket die Erfassung der Daten, die zur Fehlerbehebung in Ihrer NGINX-Umgebung erforderlich sind. Das Diagnosepaket trägt außerdem dazu bei, Unstimmigkeiten und Verzögerungen zu vermeiden, die durch das manuelle Anfordern und Erfassen der für die Fehlerbehebung benötigten Informationen entstehen, und gestaltet so die Zusammenarbeit zwischen Kunden von NGINX Plus und dem F5-Support effizienter.

Das Diagnosepaket erfasst Folgendes:

  • NGINX-Informationen – NGINX Plus-Version, Konfigurationen, Prozessinformationen, Drittanbietermodule, Protokolle sowie API-Statistiken und -Endpunkte
  • Systeminformationen – Host-Befehle (ps, lsof, vmstat, usw.)
  • Dienstinformationen – systemd, usw.
  • NGINX Agent – Protokolle und Konfigurationen (falls vorhanden)
  • NGINX App Protect – Protokolle und Konfigurationen (falls vorhanden)
  • Supportpaket-Protokoll – Protokoll mit einer Liste aller erfassten Dateien

Unser Ziel bei der Einführung des Diagnosepakets ist es, den Benutzern gegenüber transparent zu machen, welche Befehle das im Paket enthaltene Skript ausführt und welche Daten erfasst werden. Weitere Informationen finden Sie auf der Seite „NGINX Plus Diagnostic Package“.

Hinweis: Die Verfügbarkeit des Diagnosepakets wird im Rahmen der aktuellen Version NGINX Plus R30 angekündigt. Das Diagnosepaket ist jedoch nicht von einer bestimmten Version abhängig. Künftig möchten wir es auf Grundlage Ihres Feedbacks und der Rückmeldungen des F5-Supports aktualisieren, um die Erfassung von Daten zur Fehlerbehebung zu verbessern.

Weitere Verbesserungen in NGINX Plus R30

MQTT-Optimierungen

Durch Verbesserungen beim Speicherverbrauch des Filtermoduls für Message Queuing Telemetry Transport (MQTT) konnte der Durchsatz um das 4- bis 5-Fache gesteigert werden.

Die Direktive mqtt_rewrite_buffer_size wurde entfernt. Stattdessen wurde die neue Direktive mqtt_buffers <num> <size> eingeführt, mit der festgelegt wird, wie viele Puffer das Modul pro Verbindung zuweisen darf und wie groß die einzelnen Puffer sind. Standardmäßig beträgt die Anzahl der Puffer 100 und die Größe jedes Puffers 1024 Byte. Daraus ergibt sich für die Variable der Standardwert mqtt_buffers <100> <1024>.

Optimierungen beim Neuladen von DNS

NGINX Plus behält nun die Ablaufzeiten von DNS-Namen für dynamisch aufgelöste Upstream-Hosts über Neuladevorgänge hinweg bei, sodass bei einem erneuten Laden der Konfiguration keine erneute Auflösung erforderlich ist. Vor diesem Update wurden DNS-Auflösungen für alle Upstreams ausgelöst. Mit diesem Update behält NGINX die DNS-Auflösungen und Ablaufzeiten für alle Upstreams bei und löst beim erneuten Laden DNS-Auflösungen nur für neue oder geänderte Upstreams aus.

Diese Optimierung wirkt sich am stärksten auf NGINX-Umgebungen mit einer großen Anzahl von Upstream-Hosts aus. Wenn Ihre NGINX-Konfiguration mindestens 100 Upstream-Hosts umfasst, sind die Verbesserungen am deutlichsten spürbar.

Von NGINX Open Source übernommene Änderungen

NGINX Plus R30 basiert auf NGINX Open Source 1.25.1 und übernimmt funktionale Änderungen, Features und Fehlerbehebungen, die seit der Veröffentlichung von NGINX Plus R29 vorgenommen wurden (in NGINX 1.25.0 und 1.25.1).

Änderungen

  • Die Unterstützung für HTTP/2 Server Push wurde entfernt. HTTP/2 server_push wurde kaum genutzt und konnte nur in sehr begrenzten Anwendungsfällen eingesetzt werden. (Laut der Referenzdokumentation zu IETF 102 wurde die Funktion in lediglich 0,04 % der Sitzungen verwendet. Gemäß RFC 913 war es „schwierig, sie effektiv einzusetzen“.) HTTP/2 Server Push wurde in Chrome deaktiviert, und zwar ab Version 106. Im Zuge dieser Änderung wurden die Direktiven http2_push, http2_push_preload und http2_max_concurrent_pushes als veraltet eingestuft.
  • Die veraltete ssl-Direktive wird nicht mehr unterstützt. Die ssl-Direktive wurde in NGINX 1.15.0 als veraltet eingestuft und durch den ssl-Parameter der listen-Direktive ersetzt. Die veraltete ssl-Direktive wurde nun entfernt.
  • Wie oben erwähnt, ist die Direktive „listen … http2“ veraltet. Benutzern wird empfohlen, stattdessen die Direktive „http2“ zu verwenden.
    • Bei SSL-Verbindungen mit OpenSSL v1.0.2h oder höher wird das HTTP/2-Protokoll automatisch vom Callback für die Application-Layer Protocol Negotiation (ALPN) ausgewählt, wenn es auf dem durch Server Name Indication (SNI) ausgewählten virtuellen Server aktiviert ist.
    • Bei älteren OpenSSL-Versionen wird das HTTP/2-Protokoll basierend auf der Konfiguration des virtuellen Standardservers aktiviert.
    • Bei unverschlüsselten TCP-Verbindungen wird HTTP/2 nun automatisch anhand der HTTP/2-Präambel erkannt, sofern es im standardmäßigen virtuellen Server aktiviert ist. Stimmt die Präambel nicht überein, wird HTTP/0.9–1.1 angenommen.
  • Die Unterstützung für HTTP/2 über unverschlüsseltes TCP (h2c) und HTTP/1.1 auf demselben Listening-Socket wurde hinzugefügt. Wenn ein Benutzer in der bisherigen Implementierung einen h2c-Listening-Socket konfiguriert (z. B. listen port_num http2), können nur HTTP/2-Verbindungen hergestellt werden. Ein h2-Listening-Socket unterstützt sowohl HTTP/1.1 als auch HTTP/2, wobei das Protokoll über ALPN ausgehandelt wird. In der bisherigen Implementierung schlagen HTTP/1.1-Clients auf diesem Socket jedoch fehl, sodass HTTP Upgrade nicht zur Protokollaushandlung verwendet werden kann. Diese Änderung ermöglicht bei Verwendung von HTTP/2 die gleichzeitige Unterstützung von HTTP/1.1 und HTTP/2 auf einem unverschlüsselten TCP-Socket.
  • Die Vermeidung eines möglichen Pufferüberlaufs bei einigen $sent_http_*-Variablen wurde implementiert. Ein Fehler in der Logik zur Auswertung von Multi-Header-Variablen des Typs $sent_http_ führte zu möglichen Pufferüberläufen, wenn bestimmte Elemente gelöscht wurden, aber in der verketteten Liste verblieben. Dieses Problem trat auf, wenn Drittanbietermodule zum Überschreiben von Multi-Header-Werten verwendet wurden. Das Update führt verbesserte Grenzprüfungen ein und gewährleistet so eine sicherere Verarbeitung und Auswertung dieser Variablen.

Funktionen

  • Die vollständige Unterstützung für HTTP/3 wurde hinzugefügt. Mit der Mainline-Version NGINX 1.25.0 wurde die Unterstützung für HTTP/3 eingeführt, die nun in NGINX Plus R30 integriert wurde. Die Implementierung in NGINX Plus R30 weist gegenüber den mit NGINX Plus R29 bereitgestellten experimentellen Paketen folgende Änderungen auf:
    • Die Direktive „quic_mtu“ wurde entfernt
    • Die Direktive „http3 parameter of listen“ wurde entfernt
    • QUIC-Unterstützung aus dem Stream-Modul entfernt
    • HTTP/3-Server-Push entfernt
    • Die Kompilierung der OpenSSL-Kompatibilitätsschicht mit OpenSSL 3.2+ wurde korrigiert

Fehlerbehebung

  • Ein Speicherzugriffsfehler wurde behoben, der auftrat, wenn die Zuordnung der Study-Liste für einen regulären Ausdruck (Regex) fehlschlug.

Eine vollständige Liste der neuen Änderungen, Funktionen, Fehlerbehebungen und Problemumgehungen aus den letzten Versionen finden Sie in der NGINX-Datei CHANGES.

Änderungen am NGINX-JavaScript-Modul

NGINX Plus R30 enthält Änderungen aus Version 0.8.0 des NGINX-JavaScript-Moduls (njs).

Funktionen

  • Globale NGINX-Eigenschaften eingeführt:
    ngx.build, ngx.conf_file_path, ngx.error_log_path, ngx.prefix, ngx.version, ngx.version_number, und ngx.worker_id.
  • Die Direktive js_shared_dict_zone für http und stream wurde eingeführt. Sie ermöglicht die Deklaration eines von Worker-Prozessen gemeinsam genutzten Dictionarys.
  • ES13-konforme Array-Methoden hinzugefügt: Array.from(), Array.prototype.toSorted(), Array.prototype.toSpliced(), Array.prototype.toReversed().
  • ES13-konforme TypedArray-Methoden hinzugefügt: %TypedArray%.prototype.toSorted(), %TypedArray%.prototype.toSpliced(), %TypedArray%.prototype.toReversed().
  • CryptoKey-Eigenschaften in der WebCrypto API hinzugefügt. Folgende Eigenschaften wurden hinzugefügt: algorithm, extractable, type, usages.

Änderungen

  • Die in der Fetch API mit Version 0.7.10 eingeführte Sonderbehandlung unzulässiger Header wurde entfernt.
  • Removed r.requestBody() wurde aus dem HTTP-Modul entfernt, nachdem die Methode in Version 0.5.0 als veraltet gekennzeichnet worden war. Stattdessen sollte die Eigenschaft r.requestBuffer oder r.requestText verwendet werden.
  • Removed r.responseBody() wurde aus dem HTTP-Modul entfernt, da die Funktion seit Version 0.5.0 veraltet war. Stattdessen sollte die Eigenschaft r.responseBuffer oder r.responseText verwendet werden.
  • Auslösen einer Ausnahme in r.internalRedirect() während der Filterung im http-Modul.
  • Native Methoden erhalten ein retval-Argument. Diese Änderung führt zu einer Inkompatibilität mit C-Erweiterungen für njs, sodass der Code angepasst werden muss.
  • Nicht standardkonforme, veraltete String-Methoden wurden entfernt. Die folgenden Methoden wurden entfernt: String.bytesFrom(), String.prototype.fromBytes(), String.prototype.fromUTF8(), String.prototype.toBytes(), String.prototype.toUTF8(), String.prototype.toString(encoding).
  • Die Unterstützung für die Kompilierung mit GNU readline wurde entfernt.

Fehlerbehebungen

  • Fehler beim r.status-Setter während der Filterung im http-Modul behoben.
  • Fehler beim Setzen des Location-Headers im http-Modul behoben.
  • Rückgabewert von „сrypto.getRandomValues()“ korrigiert.
  • Die Auswertung berechneter Eigenschaftsnamen mit Funktionsausdrücken wurde korrigiert.
  • Impliziten Namen für einen in Arrays deklarierten Funktionsausdruck korrigiert.
  • Das Parsen von for-in-Schleifen wurde korrigiert.
  • Fehler bei Date.parse() mit ISO-8601-Format und UTC-Zeitverschiebung behoben.

Eine vollständige Liste aller Funktionen, Änderungen und Fehlerbehebungen finden Sie im njs-Änderungsprotokoll.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R30 durchzuführen. Neben all den großartigen neuen Funktionen erhalten Sie damit auch mehrere zusätzliche Fehlerbehebungen und Verbesserungen. Zudem kann NGINX Sie bei einer Supportanfrage besser unterstützen, wenn Ihre Version auf dem neuesten Stand ist.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es sich einmal anzusehen. Sie können es für Sicherheits-, Lastverteilungs- und API-Gateway-Anwendungsfälle oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs einsetzen. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.


Teilen
Schlagwörter: F5 NGINX, 2023, News

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.