Binärpakete jetzt für die Vorschau der NGINX QUIC+HTTP/3-Implementierung verfügbar

[ Herausgeber : NGINX unterstützt jetzt offiziell HTTP/3 mit QUIC. Es ist als Teil der NGINX 1.25.1-Hauptversion für Open-Source-Benutzer und als NGINX Plus R30 für Unternehmenskunden verfügbar.]
[ngx_snippet name='Tabellenstil-Blog']
Wir freuen uns, Ihnen mitteilen zu können, dass unsere Vorschauimplementierung der NGINX-Unterstützung für QUIC+HTTP/3 jetzt als vorgefertigte Binärpakete für zwei Distributionen verfügbar ist:

• Red Hat Enterprise Linux 9 und binärkompatible Varianten
• Ubuntu 22.04

Die Binärdateien sind das neueste Lieferobjekt aus dem Quic- Zweig des separaten Nginx-Quic -Repository, das die Vorschauimplementierung hostet. Wie schon seit Beginn unserer Arbeit an QUIC+HTTP/3 in NGINX können Sie NGINX Open Source weiterhin mit QUIC+HTTP/3 und einer Auswahl von SSL/TLS-Bibliotheken, die QUIC unterstützen, herunterladen und erstellen . Obwohl der Code als experimentell gekennzeichnet ist, haben mehrere Community-Mitglieder berichtet, dass sie nginx-quic erfolgreich in der Produktion verwenden.

Unser Hauptgrund für die Veröffentlichung vorgefertigter Binärdateien besteht darin, das Testen von NGINX mit QUIC+HTTP/3 schneller und einfacher zu machen. Die Binärdateien müssen nicht mehr aus dem Quellcode kompiliert werden und können mit Standardtools zur Paketverwaltung installiert werden.

Zum Zeitpunkt des Schreibens unterstützt der De-facto-Standard für Open Source SSL/TLS, OpenSSL, QUIC nicht. Wir erstellen die Binärverteilungen daher mit einem quictls -Bibliothekspaket, das automatisch als Abhängigkeit installiert wird. Wir haben uns für Quictls entschieden, weil es derzeit die beste Mischung aus Stabilität, Kompatibilität und Funktionen bietet.

Installationsanweisungen für die Binärverteilung sind auf der NGINX QUIC-Website verfügbar.

Konfigurieren von NGINX für QUIC+HTTP/3

Es gibt mehrere neue Anweisungen zum Konfigurieren von NGINX für QUIC+HTTP/3, aber es ist einfach, diese mit Anweisungen für HTTP/1.1 und HTTP/2 in vorhandenen Konfigurationsblöcken für virtuelle Server ( server{} ) zu kombinieren.

Für die grundlegendste Funktionskonfiguration müssen Sie lediglich drei Anweisungen in den Block server{} (und child location{} ) aufnehmen:

Hier ist ein Beispiel für einen Server{} -Block:

server { # für bessere Kompatibilität empfehlen wir
# die Verwendung derselben Portnummer für QUIC und TCP
listen 443 quic reuseport; # QUIC
listen 443 ssl; # TCP

ssl_certificate certs/example.com.crt;
ssl_certificate_key certs/example.com.key;
ssl_protocols TLSv1.3;

location / {
# bekannt geben, dass QUIC auf dem konfigurierten Port verfügbar ist
add_header Alt-Svc 'h3=":$server_port"; ma=86400';

#proxy_pass <Upstreamgruppe>; 
        #Wurzel       /<Stammverzeichnis>; 
}
}

Es gibt mehrere neue optionale HTTP/3-bezogene Anweisungen und Variablen (nicht im Snippet angezeigt), darunter diese:

• $http3 – (Variable) Auf h3 gesetzt, wenn die Anfrage während einer HTTP/3-Sitzung gesendet wird (ansonsten ist es eine leere Zeichenfolge).
• quic_retry – (Richtlinie) Wenn auf „on “ gesetzt, weist es NGINX an, eine QUIC-Wiederholungsnachricht an den Anforderer zurückzusenden, in der die zu verwendende neue Verbindungs-ID angegeben wird, um die IP-Adresse des Anforderers zu validieren. Das QUIC-Wiederholungspaket kompensiert teilweise die Tatsache, dass ein TCP-Dreiwege-Verbindungs-Handshake nicht zur Validierung der Verbindung verwendet werden kann, da QUIC über UDP ausgeführt wird.

• ssl_early_data – (Richtlinie) Wenn auf „on “ gesetzt, weist diese Option NGINX an, Anwendungsdaten in der ersten von einem Client über eine neue TLS 1.3-Verbindung gesendeten Anfrage zu akzeptieren, sofern von diesem Client zuvor eine Verbindung bestand. Dies wird als Verbindungswiederaufnahme mit Null-Roundtrip-Zeit (0-RTT) bezeichnet. Die Unterstützung für das Senden von „Early Data“ ist eine Funktion von TLS 1.3 und trägt zur verbesserten Leistung von QUIC+HTTP/3 bei, indem der zusätzliche Roundtrip-Nachrichtenaustausch, der für einen TLS-Handshake erforderlich ist, entfällt.

  Notiz: Die Wiederaufnahme einer 0‑RTT-Verbindung kann ein Sicherheitsrisiko darstellen, da die frühen Daten Replay-Angriffen ausgesetzt sind, wenn sie eine andere HTTP-Anforderungsmethode als GET enthalten. Weitere Einzelheiten finden Sie im Abschnitt zu TLS 1.3 in der Ankündigung von NGINX Plus R17 in unserem Blog.

Das Diagramm zeigt, wie die 0-RTT-Verbindungswiederherstellung mit QUIC+HTTP/3 die Leistung verbessert, da der Client beim Fortsetzen einer QUIC-Verbindung zu NGINX in seiner ersten Nachricht eine HTTP-Anforderung senden kann. Bei TCP mit TLS hingegen muss der Client einen neuen TLS-Handshake mit NGINX durchführen, um eine sichere Verbindung herzustellen, was mehrere zusätzliche Roundtrips kostet.

Informationen zu allen neuen Anweisungen und Variablen finden Sie unter 3. Konfigurationsabschnitt der nginx-quic- README-Datei .

Testen von NGINX mit QUIC+HTTP/3

Wie bereits erwähnt, besteht einer unserer Beweggründe für die Veröffentlichung vorgefertigter Binärdateien darin, dass wir einfacher testen möchten, ob NGINX den HTTP/3-Verkehr korrekt verarbeitet. Für einfache Befehlszeilentests können Sie curl mit HTTP/3-Unterstützung erstellen oder einen vorgefertigten Container verwenden . Darüber hinaus unterstützen neuere Versionen der meisten Browser QUIC+HTTP/3.

Um zu überprüfen, ob Ihre QUIC-fähige Site HTTP/3-Verbindungsanforderungen von Browsern erfüllt, können Sie die von NGINX zurückgegebenen HTTP-Header mithilfe der Entwicklertools eines Browsers untersuchen. Die QUIC+HTTP/3-Implementierung funktioniert ordnungsgemäß, wenn NGINX den oben beschriebenen Alt-Svc -Header in seine Antwort auf die anfängliche HTTP-Anforderung des Browsers über TCP einschließt.

An diesem Punkt stellt ein QUIC-fähiger Browser eine QUIC-Verbindung über den in der Alt-Svc- Direktive angegebenen Port her, und nachfolgende HTTP-Anfragen und -Antworten erfolgen über QUIC. Eine weitere Möglichkeit, zu überprüfen, ob QUIC+HTTP/3 verwendet wird, besteht darin, eine weitere add_header- Direktive einzuschließen, um den Wert eines benutzerdefinierten HTTP-Headers auf das von der Variable $server-protocol erfasste Protokoll festzulegen. Sie können den Wert des Headers verfolgen, wenn er sich von HTTP/1. x vor dem Herstellen der QUIC-Verbindung zu HTTP/3.0 ändert, wenn QUIC verwendet wird.

Hier ist ein Beispiel für einen Standortblock , in dem der benutzerdefinierte HTTP-Header X-protocol ist:

location / { # bekannt geben, dass QUIC auf dem konfigurierten Port verfügbar ist 
add_header Alt-Svc 'h3=":$server_port"; ma=86400'; 

# signalisieren, ob wir QUIC+HTTP/3 verwenden
add_header X-protocol $server_protocol always; 

#proxy_pass <Upstreamgruppe>; 
    #Wurzel /<Stammverzeichnis>; 
}

Alternativ gibt es Tools wie die Chrome HTTP Indicator- Erweiterung, die das verwendete Protokoll visuell anzeigen. (Beachten Sie, dass dies keine Empfehlung für eine Browsererweiterung darstellt und Sie selbst sicherstellen müssen, dass alle möglichen Sicherheitsauswirkungen einer Erweiterung unter Ihren Umständen akzeptabel sind.)

Was kommt als nächstes

Wir werden unsere Lösung für QUIC+HTTP/3 weiterhin bereitstellen und in den kommenden Wochen weitere Beispiele für NGINX-Optimierungen liefern. Teilen Sie uns in der Zwischenzeit bitte Ihre eigenen Testergebnisse mit, damit wir unsere Entscheidungen besser beeinflussen können. Sie können Ihr Feedback auf der NGINX-Entwicklungs-Mailingliste und im Kanal #quic‑http3 auf NGINX Community Slack teilen.

Abonnieren Sie die Ankündigungs-Mailingliste von NGINX , um aktuelle Informationen zu unserer Arbeit an QUIC+HTTP/3 zu erhalten, einschließlich des nächsten wichtigen Meilensteins – der Zusammenführung des nginx-quic -Repos mit dem Hauptzweig von NGINX Open Source.

Sehen Sie sich das Webinar an

Wir empfehlen Ihnen auch, an unserem kommenden Webinar „Get Hands-On with NGINX and QUIC+HTTP/3“ am Mittwoch, den 19. April 2023 teilzunehmen:

• Nordamerika – 10:00 Uhr PST
• EMEA – 11:00 Uhr MEZ
• APCJ – 10:00 Uhr SGT