Heute veröffentlichen wir NGINX 1.19, die neueste Version von NGINX Open Source, dem beliebtesten Webserver im Internet. Mit dieser Version startet der Entwicklungszweig von NGINX 1.19, nachdem im vergangenen Monat der stabile Zweig von NGINX 1.18 veröffentlicht wurde.
In diesem Blogbeitrag erläutern wir das Versionierungsschema von NGINX, blicken auf die Entwicklungen während des Entwicklungszyklus von NGINX 1.17 zurück und geben einen Ausblick darauf, was uns mit NGINX 1.19 erwartet.
Die NGINX-Versionierung erklärt
Bei NGINX pflegen wir zwei Zweige im Code-Repository von NGINX Open Source: Mainline und Stable:
- Mainline ist der aktive Entwicklungszweig, in den die neuesten Funktionen und Fehlerbehebungen einfließen. Er ist an einer ungeraden Zahl im zweiten Teil der Versionsnummer zu erkennen, zum Beispiel 1.19.0.
- Stable erhält Korrekturen für schwerwiegende Fehler, wird jedoch nicht um neue Funktionen erweitert. Diese Version ist an einer geraden Zahl im zweiten Teil der Versionsnummer zu erkennen, zum Beispiel 1.18.0.
Was „stabil“ bedeutet
Bei NGINX Open Source bezieht sich das Wort „stabil“ auf den Funktionsumfang und die Aktualisierungshäufigkeit, nicht auf die Softwarequalität. Der stabile Zweig erhält während seines Lebenszyklus keine neuen Funktionen und in der Regel nur ein oder zwei Aktualisierungen zur Behebung kritischer Fehler.
Der Stable-Branch hat einen jährlichen Lebenszyklus. Jedes Jahr im April stellen wir den aktuellen Stable-Branch ein. Danach werden keine weiteren Fehlerbehebungen mehr vorgenommen. Dies löst zwei Ereignisse aus:
- Der aktuelle Mainline-Branch wird abgezweigt, um den nächsten Stable-Branch zu erstellen. Der neue Stable-Branch übernimmt alle Fehlerbehebungen, Funktionen und sonstigen Änderungen, die im Laufe des vergangenen Jahres in den Mainline-Branch eingeflossen sind. Im vergangenen Monat wurde NGINX 1.17.10 abgezweigt, um NGINX 1.18.0 zu erstellen. Beachten Sie, dass „Stable“ bis zur Veröffentlichung des neuen Mainline-Branches mit dem aktuellen Mainline-Branch identisch ist und neue Funktionen enthalten kann, die erst wenige Tage alt sind (für den NGINX 1.18-Branch endet dieser Zustand heute).
- Der Mainline-Branch erhält einen „Versionssprung“; das heißt, der zweite Teil der Versionsnummer wird auf die nächste ungerade Zahl erhöht. Die kontinuierliche Entwicklung wird im Mainline-Branch fortgesetzt, wobei alle vier bis sechs Wochen neue Releases aus der Mainline erstellt werden. Heute erscheint mit NGINX 1.19.0 das erste Release der NGINX 1.19-Mainline.
Welchen Branch verwendet NGINX Plus?
NGINX Plus, die kommerzielle Version von NGINX, wird in einem separaten, privaten Code-Repository gepflegt. Sie basiert stets auf der neuesten Mainline-Version von NGINX, ergänzt um die zusätzlichen proprietären Funktionen und Möglichkeiten von NGINX Plus. Zum Zeitpunkt der Erstellung ist die neueste Version NGINX Plus R21, basierend auf NGINX 1.17.10.
Welchen Branch sollte ich verwenden?
Wir empfehlen grundsätzlich die Verwendung des Mainline-Branches. Dort werden alle neuen Funktionen, Leistungsverbesserungen und Optimierungen eingepflegt. Wir testen den Mainline-Branch aktiv und unterziehen ihn einer Qualitätssicherung. Da er zudem als Grundlage für NGINX Plus-Builds dient, ist er uneingeschränkt für den produktiven Einsatz geeignet.
Wenn Sie den Aufwand scheuen, den Mainline-Branch auf neue Funktionen und Fehlerbehebungen zu überwachen, müssen Sie bei Verwendung des Stable-Branch neue Funktionen nur einmal jährlich und Fehlerbehebungen nur gelegentlich prüfen.
NGINX 1.17 im Rückblick, auch bekannt als: Neuerungen im stabilen NGINX-1.18-Zweig
Der Entwicklungszyklus von NGINX 1.17 brachte einige neue Funktionen und Verbesserungen mit sich, darunter Verbesserungen bei der Begrenzung der Anfragerate und der Verbindungen in ngx_http_limit_req_module bzw. ngx_http_limit_conn_module, eine Direktive zur Verzögerung der Authentifizierung in ngx_http_core_module, die Unterstützung von Variablen für die Direktive grpc_pass sowie Variablen, die Serveradresse und -port mit dem PROXY-Protokoll erfassen, und vieles mehr. Bevor wir uns die wichtigsten Verbesserungen genauer ansehen, hier einige Zahlen zu NGINX 1.17:
- 10 Mainline-Releases
- 37 Fehlerbehebungen
- 11 neue Funktionen
Verbesserungen bei der Begrenzung der HTTP-Anfragerate und der Verbindungsanzahl
Die Direktiven „limit_rate“ und „limit_rate_after“ steuern die Bandbreite (Rate in Byte pro Sekunde), mit der NGINX auf Anfragen antwortet. Ab NGINX 1.17.0 kann der Parameter, der die Rate festlegt, eine Variable sein. Dies ermöglicht eine dynamische Steuerung anhand von Attributen der Anfrage. Ein Beispiel finden Sie unter „Dynamische Bandbreitensteuerung“.
Mit NGINX 1.17.1 wurde mit der Direktive limit_req_dry_run ein Probelaufmodus für die Begrenzung der Anfragerate eingeführt. Im Probelaufmodus setzt NGINX Plus die Ratenbegrenzungen nicht durch, erfasst jedoch weiterhin die Rate überzähliger Anfragen in der Shared-Memory-Zone und schreibt für jede Anfrage, die den konfigurierten Grenzwert überschreitet, einen Eintrag in das Fehlerprotokoll. So können Sie leichter ermitteln, welche Ratenbegrenzung für die Datenverkehrsmuster auf Ihrer Website geeignet ist. Weitere Informationen finden Sie unter „Testen von Ratenbegrenzungen im Probelaufmodus“.
Um den Probelaufmodus noch nützlicher zu machen, wurde in NGINX 1.17.6 die Variable „$limit_req_status“ hinzugefügt. Sie kann in Zugriffsprotokolleinträge aufgenommen werden, um die Auswirkungen der Anfrageratenbegrenzung auf die Verarbeitung von Anfragen zu erfassen – insbesondere, ob eine Anfrage:
- Durchgelassen (wurde ohne Verzögerung an die Backend-Server weitergeleitet) [
PASSED] - Wurde verzögert [
DELAYED] - Wurde abgelehnt [
REJECTED] - 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 führte außerdem mit der Direktive limit_conn_dry_run einen Probelaufmodus für die Verbindungsbegrenzung sowie die Variable $limit_conn_status ein, um zu erfassen, wenn eine Verbindungsanfrage:
- Zugelassen (wurde an die Backend-Server weitergeleitet) [
PASSED] - Wurde abgelehnt [
REJECTED] - Wurde im Probelaufmodus als abgelehnt gezählt [
REJECTED_DRY_RUN]
Eine Beispielkonfiguration finden Sie unter „Verbesserungen bei der Verbindungsbegrenzung“.
Neue auth_delay-Direktive
Die auth_delay-Direktive (hinzugefügt in NGINX 1.17.10) ermöglicht die verzögerte Verarbeitung nicht autorisierter Anfragen, wobei der Statuscode 401 (Nicht autorisiert) an den Client zurückgegeben wird. Dies verhindert Timing-Angriffe bei der Verarbeitung von Zugriffsanfragen. 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
Die native Unterstützung für gRPC-Datenverkehr wurde in NGINX 1.13.10 hinzugefügt, einschließlich der Direktive grpc_pass, mit der die Server angegeben werden, 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 in Upstream-Servergruppen zu unterstützen. Wenn der Domänenname nicht gefunden wird, verwendet NGINX ersatzweise einen Resolver, um die Serveradressen zu ermitteln.
Zusätzliche PROXY-Protokollvariablen
Das PROXY-Protokoll ermöglicht es einem Layer-4-Proxy, Informationen über den ursprünglichen Client an den nächsten Proxy oder Load Balancer weiterzugeben, der die Anfrage verarbeitet. Dies ist wichtig für Anwendungsfälle, in denen Sie die IP-Adresse des Clients kennen müssen – beispielsweise um die Anzahl der Verbindungen pro Client zu begrenzen (mithilfe der least_conn-Direktive). Diese Daten sind in der Variable $proxy_protocol_addr verfügbar (HTTP | Stream).
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. Mit NGINX 1.17.6 wurden die folgenden Variablen zu den HTTP- und Stream-Modulen hinzugefügt, um sie zu erfassen:
Hinweis: Die Variablen werden nur mit Werten belegt, wenn Sie zusätzlich den Parameter proxy_protocol in die Direktive listen aufnehmen, um die Verarbeitung des PROXY-Protokolls zu aktivieren.
Unterstützung für Variablen in den Direktiven „proxy_upload_rate“ und „proxy_download_rate“ hinzugefügt
Die Direktiven proxy_upload_rate und proxy_download_rate im Stream-Modul steuern jeweils die Rate, mit der NGINX Daten von einem Client bzw. einem Proxyserver liest. Ab NGINX 1.17.0 akzeptieren die Direktiven einen variablen Parameter, sodass Sie bedingungsspezifische Raten definieren können.
Unterstützung für den Systemaufruf „ioctl(FIONREAD)“ hinzugefügt
Auf Linux-Systemen gibt der Systemaufruf ioctl() die Anzahl der vom Hostgerät lesbaren Bytes zurück. In NGINX 1.17.5 wurde ioctl(FIONREAD) hinzugefügt, um Schleifen zu verhindern, wenn dem Socket-Puffer Daten schneller hinzugefügt werden, als NGINX sie lesen und verarbeiten kann. Wenn der Kernel die Anzahl der verfügbaren Bytes nicht bereitstellt, können wir ioctl(FIONREAD) verwenden, um diese Information aus einem gefüllten Puffer abzurufen.
Angeben einer benannten Location in der Perl-Funktion internal_redirect Function
In NGINX 1.17.2 und höher kann der Parameter „uri“ der Funktion „internal_redirect“ im NGINX-Perl-Modul ein maskierter URI oder eine benannte Location sein.
Was Sie in NGINX 1.19 erwartet
Die erste Version des NGINX 1.19-Mainline-Zweigs erscheint in Kürze. NGINX 1.19.0 unterstützt QUIC (HTTP/3), die nächste bedeutende Aktualisierung der Transportprotokolle für die Kommunikation zwischen Clients und Websites, Anwendungen und APIs.
Wenn Sie die erweiterten Funktionen von NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Über den Autor
Ähnliche Blogbeiträge
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
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
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
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 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
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.