Einführung von NGINX 1.18 und 1.19

Heute veröffentlichen wir NGINX 1.19, die neueste Version von NGINX Open Source, dem beliebtesten Webserver im Internet . Diese Version markiert den Start des Entwicklungszweigs NGINX 1.19, nach der Veröffentlichung des stabilen Zweigs NGINX 1.18 im letzten Monat.

In diesem Blog besprechen wir das NGINX-Versionierungsschema, blicken zurück auf die Ereignisse während des Entwicklungszyklus von NGINX 1.17 und blicken voraus auf das, was uns mit NGINX 1.19 erwartet.

Erläuterung der NGINX-Versionierung

Bei NGINX pflegen wir zwei Zweige im NGINX Open Source-Code-Repository, genannt mainline und stable :

• Mainline ist der aktive Entwicklungszweig, in dem die neuesten Funktionen und Fehlerbehebungen hinzugefügt werden. Dies wird durch eine ungerade Zahl im zweiten Teil der Versionsnummer gekennzeichnet, beispielsweise 1.19.0.
• Die stabile Version erhält Korrekturen für schwerwiegende Fehler, wird jedoch nicht mit neuen Funktionen aktualisiert. Dies wird durch eine gerade Zahl im zweiten Teil der Versionsnummer gekennzeichnet, beispielsweise 1.18.0.

Was es bedeutet, „stabil“ zu sein

Bei NGINX Open Source bezieht sich das Wort „stabil“ auf Funktionalität und Aktualisierungshäufigkeit, nicht auf die Softwarequalität. Der stabile Zweig erhält während seines Lebenszyklus nie neue Funktionen und erhält normalerweise nur ein oder zwei Updates zur Fehlerbehebung.

Der stabile Zweig hat einen jährlichen Lebenszyklus. Jedes Jahr im April stellen wir den aktuellen stabilen Zweig ein. Danach werden keine weiteren Fehlerbehebungen mehr vorgenommen. Dies löst zwei Ereignisse aus:

1. Der aktuelle Hauptzweig wird geforkt, um den nächsten stabilen Zweig zu erstellen. Der neue stabile Zweig übernimmt alle Fehlerbehebungen, Funktionen und anderen Änderungen, die im vergangenen Jahr in den Hauptzweig eingeflossen sind. Letzten Monat wurde NGINX 1.17.10 geforkt, um NGINX 1.18.0 zu erstellen. Beachten Sie, dass „stable“ bis zur Veröffentlichung des neuen Hauptzweigs mit dem aktuellen Hauptzweig identisch ist und neue Funktionen enthalten kann, die erst wenige Tage alt sind (dieser Zustand endet heute für den NGINX 1.18-Zweig).
2. Der Hauptzweig erhält einen „Versionsschub“, d. h. der zweite Teil der Versionsnummer wird auf die nächste ungerade Zahl erhöht. Die laufende Entwicklung wird im Hauptzweig fortgesetzt, wobei alle vier bis sechs Wochen neue Versionen aus dem Hauptzweig erstellt werden. Heute erscheint mit NGINX 1.19.0 die erste Version auf der NGINX 1.19-Hauptlinie.

Welchen Zweig verwendet NGINX Plus?

NGINX Plus , die kommerzielle Version von NGINX, wird in einem separaten, privaten Code-Repository verwaltet. Es basiert immer auf der neuesten Version der NGINX-Hauptlinie, zusammengeführt mit den zusätzlichen proprietären Funktionen und Fähigkeiten in NGINX Plus. Zum Zeitpunkt des Schreibens ist die neueste Version NGINX Plus R21 , basierend auf NGINX 1.17.10.

Welchen Zweig soll ich verwenden?

Wir empfehlen grundsätzlich die Verwendung des Hauptzweigs. Hier stellen wir alle neuen Funktionen, Leistungsverbesserungen und Erweiterungen bereit. Wir führen für den Hauptzweig aktive Tests und eine Qualitätssicherung durch und als Quelle der NGINX Plus-Builds ist er vollständig für den Produktionseinsatz geeignet.

Wenn Sie sich über den Aufwand Gedanken machen, der mit der Überwachung des Hauptzweigs hinsichtlich neuer Funktionen und Fehlerbehebungen verbunden ist, dann bedeutet die Verwendung des stabilen Zweigs, dass Sie neue Funktionen nur einmal im Jahr und Fehlerbehebungen nur selten überprüfen müssen.

NGINX 1.17 im Rückblick bzw. Was ist neu im stabilen Zweig von NGINX 1.18?

Der Entwicklungszyklus von NGINX 1.17 führte einige neue Funktionen und Verbesserungen ein, darunter Verbesserungen der Anforderungsrate und der Verbindungsbegrenzung in ngx_http_limit_req_module bzw. ngx_http_limit_conn_module , das Hinzufügen einer Direktive zur Authentifizierungsverzögerung zu ngx_http_core_module , die Einführung von Variablenunterstützung für die Direktive grpc_pass und Variablen, die die Serveradresse und den Port mit dem PROXY-Protokoll erfassen, und mehr. Bevor wir uns die wichtigsten Verbesserungen im Detail ansehen, hier NGINX 1.17 in Zahlen:

• 10 Hauptveröffentlichungen
• 37 Fehlerbehebungen
• 11 neue Funktionen

Verbesserungen bei der HTTP-Anforderungsrate und Verbindungsbegrenzung

Die Anweisungen „limit_rate“ und „limit_rate_after“ steuern die Bandbreite (Rate in Bytes pro Sekunde), mit der NGINX auf Anfragen antwortet. In NGINX 1.17.0 und höher kann der Parameter, der die Rate festlegt, eine Variable sein, die eine dynamische Steuerung basierend auf Attributen der Anforderung ermöglicht. Ein Beispiel finden Sie unter Dynamische Bandbreitensteuerung .

NGINX 1.17.1 hat mit der Direktive „limit_req_dry_run“ einen Dry-Run-Modus zur Begrenzung der Anforderungsrate hinzugefügt. Im Probelaufmodus erzwingt NGINX Plus keine Ratenbegrenzungen, verfolgt aber dennoch die Rate übermäßiger Anfragen in der gemeinsam genutzten Speicherzone und schreibt für jede Anfrage, die die konfigurierte Begrenzung überschreitet, einen Eintrag in das Fehlerprotokoll. So können Sie leichter bestimmen, welche Ratenbegrenzung für die Verkehrsmuster auf Ihrer Site angemessen ist. Weitere Einzelheiten finden Sie unter Testen der Ratenbegrenzungen im Probelaufmodus .

Um den Dry‑Run‑Modus noch nützlicher zu machen, wurde in NGINX 1.17.6 die Variable $limit_req_status hinzugefügt, die in Zugriffsprotokolleinträge aufgenommen werden kann, um die Auswirkungen der Ratenbegrenzung auf die Anforderungsverarbeitung zu erfassen – insbesondere, ob eine Anforderung:

• Bestanden (wurde ohne Verzögerung an die Backend-Server weitergeleitet) [ BESTANDEN ]
• Wurde verzögert [ VERZÖGERT ]
• Wurde abgelehnt [ ABGELEHNT ]
• Wurde im Probelaufmodus als verzögert gezählt [ DELAYED_DRY_RUN ]
• Wurde im Probelaufmodus als abgelehnt gezählt [ REJECTED_DRY_RUN ]

NGINX 1.17.6 hat außerdem einen Dry‑Run‑Modus zur Verbindungsbegrenzung mit der Direktive limit_conn_dry_run und die Variable $limit_conn_status hinzugefügt, um zu erfassen, wann eine Verbindungsanforderung:

• Bestanden (wurde an die Backend-Server weitergeleitet) [ BESTANDEN ]
• Wurde abgelehnt [ ABGELEHNT ]
• Wurde im Probelaufmodus als abgelehnt gezählt [ REJECTED_DRY_RUN ]

Eine Beispielkonfiguration finden Sie unter Verbesserungen der Verbindungsbeschränkung .

Neue auth_delay- Direktive

Die Direktive auth_delay (hinzugefügt in NGINX 1.17.10) ermöglicht die verzögerte Verarbeitung nicht autorisierter Anfragen mit dem Statuscode 401(Unbefugt) an den Client zurückgesandt. Dadurch werden Timing-Angriffe bei der Verarbeitung von Zugriffsanfragen verhindert. Zu den verfügbaren Authentifizierungsmethoden gehören:

• Ein Passwort (bei Verwendung von ngx_http_auth_basic_module )
• Das Ergebnis einer Unteranfrage (verfügbar in ngx_http_auth_request_module )
• Das Vorhandensein eines JWT (verfügbar in ngx_http_auth_jwt_module )

Variablenunterstützung für die grpc_pass- Direktive

In NGINX 1.13.10 wurde native Unterstützung für gRPC-Verkehr hinzugefügt, einschließlich der Direktive grpc_pass , die die Server angibt, an die NGINX gRPC-Anfragen weiterleitet. In NGINX 1.17.8 haben wir die Möglichkeit hinzugefügt, Domänennamen in die Serverkennung aufzunehmen, um die Suche zwischen Upstream-Servergruppen zu unterstützen. Wenn der Domänenname nicht gefunden wird, greift NGINX auf einen Resolver zurück, um Serveradressen zu identifizieren.

Zusätzliche PROXY-Protokollvariablen

Das PROXY-Protokoll ermöglicht es einem Layer-4-Proxy, dem nächsten Proxy oder Load Balancer, der die Anfrage verarbeitet, ursprüngliche Client-Informationen bereitzustellen. Dies ist wichtig für Anwendungsfälle, in denen Sie die IP-Adresse des Clients kennen müssen – beispielsweise um die Anzahl der Verbindungen für jeden Client zu begrenzen (mithilfe der Direktive least_conn ). Diese Daten sind in der Variable $proxy_protocol_addr ( HTTP | Stream ) verfügbar.

Wenn mehrere Layer-4-Proxys eingesetzt werden, kann es für NGINX wichtig sein, die IP-Adresse und den Port des Proxyservers zu kennen, mit dem der Client ursprünglich verbunden war. Die Metadaten des PROXY-Protokolls enthalten diese Informationen, und NGINX 1.17.6 hat den HTTP- und Stream-Modulen die folgenden Variablen hinzugefügt, um sie zu erfassen:

• $proxy_protocol_server_addr ( HTTP | Stream )
• $proxy_protocol_server_port ( HTTP | Stream )

Notiz: Die Variablen werden nur aufgefüllt, wenn Sie auch den Parameter „proxy_protocol“ in die Listen- Direktive aufnehmen, um die Verarbeitung des PROXY-Protokolls zu ermöglichen.

Unterstützung für Variablen zu den Anweisungen proxy_upload_rate und proxy_download_rate hinzugefügt

Die Anweisungen proxy_upload_rate und proxy_download_rate im Stream-Modul steuern die Rate, mit der NGINX Daten von einem Client bzw. einem Proxy-Server liest. In NGINX 1.17.0 und höher akzeptieren die Anweisungen einen variablen Parameter, sodass Sie zustandsspezifische Raten definieren können.

Unterstützung für den Systemaufruf ioctl(FIONREAD) hinzugefügt

In Linux-Systemen gibt der Systemaufruf ioctl() die Anzahl der vom Hostgerät lesbaren Bytes an. NGINX 1.17.5 hat ioctl(FIONREAD) hinzugefügt, um eine Schleife zu verhindern, wenn Daten schneller zum Socket-Puffer hinzugefügt werden, als NGINX sie lesen und verarbeiten kann. Wenn der Kernel die Anzahl der verfügbaren Bytes nicht bereitstellt, können wir diese Information mit ioctl(FIONREAD) aus einem gefüllten Puffer abrufen.

Angeben eines benannten Speicherorts in der Perl-Funktion internal_redirect

In NGINX 1.17.2 und höher kann der URI- Parameter für die Funktion internal_redirect im NGINX- Perl-Modul eine Escape-URI oder ein benannter Ort sein.

Was kommt in NGINX 1.19?

Die erste Version der NGINX 1.19-Hauptlinie erscheint in Kürze. NGINX 1.19.0 beinhaltet Unterstützung für QUIC (HTTP/3), das nächste bedeutende Update der Transportprotokolle für die Kommunikation zwischen Clients und Websites, Anwendungen und APIs.

Wenn Sie die erweiterten Funktionen in NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .