Eine Einführung in QUIC-Netzwerke und -Verschlüsselung in NGINX

Robert HaynesManager für technisches Marketing

QUIC und HTTP/3 wurden erstmals vor vier Jahren (!) im NGINX-Blog erwähnt. Wie Sie freuen auch wir uns nun darauf, dass unsere QUIC-Implementierung in Kürze in den Mainline-Branch von NGINX Open Source integriert wird. Angesichts der langen Entwicklungszeit ist es verständlich, wenn Sie sich bisher noch nicht viele Gedanken über QUIC gemacht haben.

An diesem Punkt müssen Sie sich als Entwickler oder Website-Administrator jedoch darüber im Klaren sein, dass QUIC die Verantwortung für einige Netzwerkdetails vom Betriebssystem auf NGINX (und alle HTTP-Anwendungen) verlagert. Selbst wenn Netzwerktechnik nicht Ihr Fachgebiet ist, bedeutet die Einführung von QUIC, dass Sie sich nun (zumindest ein wenig) auch um das Netzwerk kümmern müssen.

In diesem Beitrag befassen wir uns eingehend mit den wichtigsten Netzwerk- und Verschlüsselungskonzepten, die in QUIC zum Einsatz kommen. Um die Verständlichkeit zu erhöhen, vereinfachen wir dabei einige Details und lassen unwesentliche Informationen weg. Auch wenn dadurch möglicherweise einige Feinheiten verloren gehen, möchten wir Ihnen genügend Informationen an die Hand geben, damit Sie QUIC erfolgreich in Ihrer Umgebung einsetzen können – oder zumindest eine Grundlage schaffen, auf der Sie Ihr Wissen aufbauen können.

Wenn QUIC für Sie völliges Neuland ist, empfehlen wir Ihnen, zunächst einen unserer früheren Beiträge zu lesen und sich unser Übersichtsvideo anzusehen.

 

Für eine ausführlichere und umfassendere Erläuterung von QUIC empfehlen wir das hervorragende Dokument „Manageability of the QUIC Transport Protocol“ der IETC-QUIC-Arbeitsgruppe sowie die weiteren Materialien, auf die in diesem Dokument verwiesen wird.

Warum sollten Netzwerkkommunikation und Verschlüsselung in QUIC für Sie relevant sein?

Die unschönen Details der Netzwerkverbindung zwischen Clients und NGINX waren für die meisten Benutzer bislang nicht sonderlich relevant. Schließlich kümmert sich bei HTTP/1.x und HTTP/2 das Betriebssystem darum, die Verbindung über das Transmission Control Protocol (TCP) zwischen Clients und NGINX herzustellen. NGINX nutzt die Verbindung einfach, sobald sie hergestellt ist.

Mit QUIC geht die Verantwortung für den Aufbau, die Validierung und die Verwaltung von Verbindungen jedoch vom zugrunde liegenden Betriebssystem auf NGINX über. Statt eine bereits hergestellte TCP-Verbindung zu erhalten, empfängt NGINX nun einen Strom von Datagrammen des User Datagram Protocol (UDP), die es in Clientverbindungen und Streams aufteilen muss. NGINX ist nun außerdem für den Umgang mit Paketverlusten, Verbindungsneustarts und Überlastungssteuerung verantwortlich.

Darüber hinaus fasst QUIC den Verbindungsaufbau, die Versionsaushandlung und den Austausch von Verschlüsselungsschlüsseln in einem einzigen Vorgang zum Herstellen der Verbindung zusammen. Obwohl die TLS-Verschlüsselung bei QUIC+HTTP/3 und TCP+HTTP/1+2 weitgehend ähnlich gehandhabt wird, gibt es Unterschiede, die für nachgelagerte Geräte wie Layer-4-Load-Balancer, Firewalls und Sicherheits-Appliances von Bedeutung sein können.

Letztlich sorgen diese Änderungen insgesamt für ein sichereres, schnelleres und zuverlässigeres Benutzererlebnis, während sich an der Konfiguration und dem Betrieb von NGINX nur sehr wenig ändert. NGINX-Administratoren sollten jedoch zumindest ein wenig verstehen, was bei QUIC und NGINX vor sich geht – und sei es nur, um im Problemfall die Zeit bis zum Unschuldsnachweis so kurz wie möglich zu halten.

(Es ist erwähnenswert, dass sich dieser Beitrag zwar auf den HTTP-Betrieb konzentriert, da HTTP/3 QUIC voraussetzt, QUIC jedoch auch für andere Protokolle verwendet werden kann. Ein gutes Beispiel ist DNS über QUIC, wie in RFC 9250, „DNS über dedizierte QUIC-Verbindungen“, definiert.)

Nachdem wir diese Einführung hinter uns haben, wollen wir uns nun mit einigen Besonderheiten der QUIC-Netzwerktechnik befassen.

TCP im Vergleich zu UDP

QUIC führt eine wesentliche Änderung am zugrunde liegenden Netzwerkprotokoll ein, das zur Übertragung von HTTP-Anwendungsdaten zwischen einem Client und einem Server verwendet wird.

Wie bereits erwähnt, war TCP schon immer das Protokoll zur Übertragung von Daten aus HTTP-Webanwendungen. TCP ist darauf ausgelegt, Daten zuverlässig über ein IP-Netzwerk zu übertragen. Es verfügt über einen klar definierten und bewährten Mechanismus zum Herstellen von Verbindungen und zum Bestätigen des Datenempfangs sowie über eine Vielzahl von Algorithmen und Verfahren zur Bewältigung von Paketverlusten und Verzögerungen, wie sie in unzuverlässigen und überlasteten Netzwerken häufig auftreten.

TCP bietet zwar eine zuverlässige Datenübertragung, bringt jedoch Abstriche bei Leistung und Latenz mit sich. Darüber hinaus ist die Datenverschlüsselung nicht in TCP integriert und muss separat implementiert werden. Angesichts sich ändernder HTTP-Datenverkehrsmuster hat es sich zudem als schwierig erwiesen, TCP zu verbessern oder zu erweitern. Da die TCP-Verarbeitung im Linux-Kernel erfolgt, müssen Änderungen sorgfältig konzipiert und getestet werden, um unerwartete Auswirkungen auf die Gesamtleistung und Stabilität des Systems zu vermeiden.

Ein weiteres Problem besteht darin, dass der HTTP-Datenverkehr zwischen Client und Server in vielen Szenarien mehrere Geräte durchläuft, die TCP verarbeiten, etwa Firewalls oder Load Balancer (zusammenfassend als „Middleboxes“ bezeichnet). Diese setzen Änderungen an TCP-Standards möglicherweise nur langsam um.

QUIC verwendet stattdessen UDP als Transportprotokoll. UDP ist wie TCP für die Übertragung von Daten über ein IP-Netzwerk ausgelegt, verzichtet jedoch bewusst auf den Verbindungsaufbau und eine zuverlässige Zustellung. Da dieser zusätzliche Aufwand entfällt, eignet sich UDP für viele Anwendungen, bei denen Effizienz und Geschwindigkeit wichtiger sind als Zuverlässigkeit.

Für die meisten Webanwendungen ist eine zuverlässige Datenübertragung jedoch unerlässlich. Da die zugrunde liegende UDP-Transportschicht keine zuverlässige Datenübertragung gewährleistet, müssen diese Funktionen von QUIC (oder der Anwendung selbst) bereitgestellt werden. Glücklicherweise bietet QUIC in dieser Hinsicht einige Vorteile gegenüber TCP:

• Die QUIC-Verarbeitung erfolgt im Linux-Benutzerbereich, wo Probleme bei einem bestimmten Vorgang ein geringeres Risiko für das Gesamtsystem darstellen. Dadurch lassen sich neue Funktionen schneller entwickeln.
• Die oben erwähnten „Middleboxes“ verarbeiten UDP-Datenverkehr in der Regel nur minimal und schränken daher Erweiterungen des QUIC-Protokolls nicht ein.

Vereinfachter Aufbau eines QUIC-Netzwerks

QUIC-Streams sind die logischen Objekte, die HTTP/3-Anfragen oder -Antworten (oder beliebige andere Anwendungsdaten) enthalten. Für die Übertragung zwischen Netzwerkendpunkten werden sie, wie im Diagramm dargestellt, in mehrere logische Schichten gekapselt.

Von außen nach innen betrachtet sind dies die logischen Schichten und Objekte:

• UDP-Datagramm – Enthält einen Header, der die Quell- und Zielports (sowie Längen- und Prüfsummendaten) angibt, gefolgt von einem oder mehreren QUIC-Paketen. Das Datagramm ist die Informationseinheit, die über das Netzwerk vom Client an den Server übertragen wird.
• QUIC-Paket – Enthält einen QUIC-Header und einen oder mehrere QUIC-Frames.
• QUIC-Header – Enthält Metadaten über das Paket. Es gibt zwei Arten von Headern:
  • Der Long Header, der beim Verbindungsaufbau verwendet wird.
  • Der kurze Header, der nach dem Verbindungsaufbau verwendet wird. Er enthält unter anderem die Verbindungs-ID, die Paketnummer und die Schlüsselphase (mit der zur Unterstützung der Schlüsselrotation nachverfolgt wird, welche Schlüssel zur Verschlüsselung des Pakets verwendet wurden). Paketnummern sind für eine bestimmte Verbindung und Schlüsselphase eindeutig (und werden stets größer).
• Frame – Enthält den Typ, die Stream-ID, den Offset und die Stream-Daten. Die Stream-Daten sind auf mehrere Frames verteilt, können jedoch anhand der Verbindungs-ID, der Stream-ID und des Offsets zusammengesetzt werden, sodass die Datenblöcke in der richtigen Reihenfolge dargestellt werden.
• Stream – Ein unidirektionaler oder bidirektionaler Datenfluss innerhalb einer einzelnen QUIC-Verbindung. Jede QUIC-Verbindung kann mehrere unabhängige Streams unterstützen, die jeweils über eine eigene Stream-ID verfügen. Geht ein QUIC-Paket verloren, das einige Streams enthält, beeinträchtigt dies nicht den Fortschritt der Streams, die nicht im fehlenden Paket enthalten sind (dies ist entscheidend, um das bei HTTP/2 auftretende Head-of-Line-Blocking zu vermeiden). Streams können bidirektional sein und von beiden Endpunkten erstellt werden.

Verbindungsaufbau

Der bekannte SYN / SYN-ACK / ACK-Drei-Wege-Handshake stellt eine TCP-Verbindung her:

Abbildung 2. Der Drei-Wege-Handshake, der eine TCP-Verbindung herstellt

Der Aufbau einer QUIC-Verbindung erfolgt in ähnlichen Schritten, ist jedoch effizienter. Zudem ist die Adressvalidierung als Teil des kryptografischen Handshakes in den Verbindungsaufbau integriert. Die Adressvalidierung schützt vor Angriffen durch Datenverkehrsverstärkung, bei denen ein Angreifer ein Paket mit gefälschten Quelladressinformationen des vorgesehenen Angriffsziels an den Server sendet. Der Angreifer hofft, dass der Server mehr oder größere Pakete an das Opfer sendet, als der Angreifer selbst erzeugen kann, sodass eine überwältigende Menge an Datenverkehr entsteht. (Weitere Einzelheiten finden Sie in Abschnitt 8 von RFC 9000, QUIC: Ein UDP-basiertes, multiplexiertes und sicheres Transportprotokoll.)

Im Rahmen des Verbindungsaufbaus stellen Client und Server jeweils eigene Verbindungs-IDs bereit, die im QUIC-Header codiert werden. Dadurch lässt sich die Verbindung unabhängig von der Quell-IP-Adresse des Clients einfach identifizieren.

Da der anfängliche Aufbau einer QUIC-Verbindung jedoch auch Vorgänge zum Austausch von TLS-Verschlüsselungsschlüsseln umfasst, ist er für den Server rechenintensiver als die einfache SYN-ACK-Antwort, die er beim Aufbau einer TCP-Verbindung erzeugt. Dadurch entsteht außerdem ein potenzieller Angriffsvektor für Distributed-Denial-of-Service(DDoS)-Angriffe, da die IP-Adresse des Clients nicht überprüft wird, bevor der Schlüsselaustausch stattfindet.

Sie können NGINX jedoch so konfigurieren, dass die IP-Adresse des Clients vor Beginn komplexer kryptografischer Operationen validiert wird, indem Sie die Direktive „quic_retry“ auf „on“ setzen. In diesem Fall sendet NGINX dem Client ein Retry-Paket mit einem Token, das der Client in die Pakete zum Verbindungsaufbau aufnehmen muss.

Abbildung 3. Aufbau einer QUIC-Verbindung ohne und mit Retry-Paket

Dieser Mechanismus ähnelt in gewisser Weise dem Drei-Wege-Handshake von TCP und stellt vor allem sicher, dass der Client tatsächlich über die von ihm angegebene Quell-IP-Adresse verfügt. Ohne diese Überprüfung könnten QUIC-Server wie NGINX leicht durch DoS-Angriffe mit gefälschten Quell-IP-Adressen angegriffen werden. (Ein weiterer QUIC-Mechanismus zur Abwehr solcher Angriffe besteht darin, dass alle anfänglichen Verbindungspakete auf mindestens 1200 Byte aufgefüllt werden müssen, wodurch ihr Versand aufwendiger wird.)

Darüber hinaus schwächen Retry-Pakete einen Angriff ab, der einem TCP-SYN-Flood-Angriff ähnelt (bei dem die Serverressourcen durch eine große Anzahl im Arbeitsspeicher abgelegter, begonnener, aber nicht abgeschlossener Handshakes erschöpft werden), indem sie Details der Verbindung in der an den Client gesendeten Verbindungs-ID codieren. Dies bietet den zusätzlichen Vorteil, dass keine serverseitigen Informationen gespeichert werden müssen, da die Verbindungsinformationen aus der Verbindungs-ID und dem Token rekonstruiert werden können, die der Client anschließend übermittelt. Diese Technik entspricht den TCP-SYN-Cookies. Darüber hinaus können QUIC-Server wie NGINX ein zeitlich begrenztes Token bereitstellen, das für zukünftige Verbindungen des Clients verwendet werden kann, um die Wiederaufnahme der Verbindung zu beschleunigen.

Durch die Verwendung von Verbindungs-IDs wird die Verbindung von der zugrunde liegenden Transportschicht unabhängig, sodass Änderungen am Netzwerk nicht zum Abbruch von Verbindungen führen müssen. Dies wird unter „Eleganter Umgang mit Änderungen der Client-IP-Adresse“ erläutert.

Verlusterkennung

Sobald eine Verbindung hergestellt (und die Verschlüsselung aktiviert) ist, wie weiter unten erläutert, können HTTP-Anfragen und -Antworten zwischen dem Client und NGINX ausgetauscht werden. UDP-Datagramme werden gesendet und empfangen. Es gibt jedoch viele Faktoren, die dazu führen können, dass einige dieser Datagramme verloren gehen oder verzögert werden.

TCP verfügt über komplexe Mechanismen, um die Paketzustellung zu bestätigen, Paketverluste oder -verzögerungen zu erkennen und die erneute Übertragung verlorener Pakete zu steuern. Dadurch werden die Daten in der richtigen Reihenfolge und vollständig an die Anwendungsschicht übermittelt. UDP bietet diese Funktion nicht, weshalb Überlastungssteuerung und Verlusterkennung in der QUIC-Schicht implementiert sind.

• Sowohl der Client als auch der Server senden für jedes empfangene QUIC-Paket eine explizite Empfangsbestätigung (Pakete, die ausschließlich Frames mit niedriger Priorität enthalten, werden jedoch nicht sofort bestätigt).
• Wenn ein Paket, das Frames enthält, die zuverlässig zugestellt werden müssen, nach Ablauf einer festgelegten Zeitspanne nicht bestätigt wurde, gilt es als verloren. Die Zeitüberschreitungsintervalle hängen vom Inhalt des Pakets ab. Beispielsweise ist das Intervall bei Paketen kürzer, die zum Einrichten der Verschlüsselung und zum Herstellen der Verbindung benötigt werden, da sie für die Leistungsfähigkeit des QUIC-Handshakes entscheidend sind.
• Wenn ein Paket als verloren gilt, werden die fehlenden Frames in einem neuen Paket mit einer neuen Sequenznummer erneut übertragen.
• Der Empfänger des Pakets verwendet die Stream-ID und den Offset der Pakete, um die übertragenen Daten in der richtigen Reihenfolge zusammenzusetzen. Die Paketnummer gibt lediglich die Sendereihenfolge vor, nicht aber, wie die Pakete zusammengesetzt werden sollen.
• Da die Datenzusammensetzung beim Empfänger unabhängig von der Übertragungsreihenfolge erfolgt, wirkt sich ein verlorenes oder verzögertes Paket nur auf die einzelnen darin enthaltenen Streams aus, nicht auf alle Streams der Verbindung. Dadurch wird das Head-of-Line-Blocking-Problem beseitigt, das HTTP/1.x und HTTP/2 betrifft, da Streams nicht Teil der Transportschicht sind.

Eine vollständige Beschreibung der Verlusterkennung würde den Rahmen dieser Einführung sprengen. Einzelheiten zu den Mechanismen für die Bestimmung von Zeitüberschreitungen und dazu, wie viele unbestätigte Daten sich in Übertragung befinden dürfen, finden Sie in RFC 9002, „QUIC-Verlusterkennung und Überlastungssteuerung“.

Änderungen der Client-IP-Adresse reibungslos handhaben

Die IP-Adresse eines Clients (im Kontext einer Anwendungssitzung als „Quell-IP-Adresse“ bezeichnet) kann sich während der Sitzung ändern, beispielsweise wenn ein VPN oder Gateway seine öffentliche Adresse ändert oder ein Smartphone-Nutzer einen WLAN-Bereich verlässt und dadurch zu einem Mobilfunknetz wechseln muss. Außerdem legen Netzwerkadministratoren für UDP-Datenverkehr traditionell kürzere Zeitüberschreitungen fest als für TCP-Verbindungen, wodurch die Wahrscheinlichkeit einer erneuten Bindung bei der Netzwerkadressübersetzung (NAT) steigt.

QUIC bietet zwei Mechanismen, um die daraus möglicherweise entstehenden Unterbrechungen zu minimieren: Ein Client kann den Server proaktiv darüber informieren, dass sich seine Adresse ändern wird, und Server können eine ungeplante Änderung der Clientadresse ohne Verbindungsabbruch verarbeiten. Da die Verbindungs-ID während des Übergangs unverändert bleibt, können unbestätigte Frames erneut an die neue IP-Adresse übertragen werden.

Änderungen der Quell-IP-Adresse während QUIC-Sitzungen können für nachgelagerte Load Balancer (oder andere Netzwerkkomponenten auf Layer 4) problematisch sein, wenn diese anhand der Quell-IP-Adresse und des Ports bestimmen, welcher Upstream-Server ein bestimmtes UDP-Datagramm empfangen soll. Um eine korrekte Datenverkehrssteuerung zu gewährleisten, müssen Anbieter von Layer-4-Netzwerkgeräten diese aktualisieren, damit sie QUIC-Verbindungs-IDs verarbeiten können. Weitere Informationen zur Zukunft von Load Balancing und QUIC finden Sie im IETF-Entwurf QUIC‑LB: Generierung routingfähiger QUIC-Verbindungs-IDs.

Verschlüsselung

Unter „Verbindungsaufbau“ haben wir bereits angedeutet, dass der anfängliche QUIC-Handshake mehr leistet, als lediglich eine Verbindung herzustellen. Anders als beim TLS-Handshake für TCP erfolgt bei UDP der Austausch von Schlüsseln und TLS-1.3-Verschlüsselungsparametern im Rahmen des anfänglichen Verbindungsaufbaus. Dadurch entfallen mehrere Kommunikationsschritte, und bei der Wiederaufnahme einer früheren Verbindung durch den Client wird eine Zero Round-Trip Time (0-RTT) ermöglicht.

QUIC integriert nicht nur den Verschlüsselungs-Handshake in den Verbindungsaufbau, sondern verschlüsselt auch einen größeren Teil der Metadaten als TCP+TLS. Bereits vor dem Schlüsselaustausch werden die ersten Verbindungspakete verschlüsselt. Zwar kann ein Lauscher die Schlüssel weiterhin ableiten, doch ist dies aufwendiger als bei unverschlüsselten Paketen. Dadurch werden Daten wie die Server Name Indication (SNI), die sowohl für Angreifer als auch für potenzielle staatliche Zensurbehörden von Interesse sind, besser geschützt. Abbildung 5 veranschaulicht, dass QUIC mehr potenziell sensible Metadaten (rot dargestellt) verschlüsselt als TCP+TLS.

Alle Daten in der QUIC-Nutzlast werden mit TLS 1.3 verschlüsselt. Dies bietet zwei Vorteile: Ältere, anfällige Verschlüsselungsverfahren und Hash-Algorithmen sind nicht zulässig, und Schlüsselaustauschverfahren mit Forward Secrecy (FS) sind obligatorisch. Forward Secrecy verhindert, dass ein Angreifer die Daten entschlüsseln kann, selbst wenn er den privaten Schlüssel und eine Kopie des Datenverkehrs erbeutet.

Verbindungen mit niedrigem RTT und Zero-RTT reduzieren die Latenz

Die Reduzierung der Anzahl der Roundtrips, die zwischen Client und Server stattfinden müssen, bevor Anwendungsdaten übertragen werden können, verbessert die Anwendungsleistung – insbesondere in Netzwerken mit höherer Latenz.

TLS 1.3 führte einen einzigen Roundtrip zum Aufbau einer verschlüsselten Verbindung und null Roundtrips zur Wiederaufnahme einer Verbindung ein. Bei TCP bedeutet dies jedoch, dass der Handshake vor dem TLS Client Hello erfolgen muss.

Da QUIC kryptografische Vorgänge mit dem Verbindungsaufbau kombiniert, ermöglicht es eine echte Wiederherstellung der Verbindung mit 0‑RTT, bei der ein Client bereits im allerersten QUIC-Paket eine Anfrage senden kann. Dadurch wird die Latenz reduziert, da der anfängliche Roundtrip für den Verbindungsaufbau vor der ersten Anfrage entfällt.

In diesem Fall sendet der Client eine HTTP-Anfrage, die mit den bei einer vorherigen Verbindung verwendeten Parametern verschlüsselt ist, und fügt zur Adressvalidierung ein Token hinzu, das der Server während der vorherigen Verbindung bereitgestellt hat.

Leider bietet die Wiederaufnahme einer 0‑RTT-Verbindung keine Forward Secrecy, sodass die erste Anfrage des Clients nicht so sicher verschlüsselt ist wie der übrige Datenverkehr bei diesem Austausch. Alle auf die erste Anfrage folgenden Anfragen und Antworten sind durch Forward Secrecy geschützt. Noch problematischer ist möglicherweise, dass die erste Anfrage auch anfällig für Replay-Angriffe ist, bei denen ein Angreifer die erste Anfrage abfangen und mehrfach an den Server senden kann.

Bei vielen Anwendungen und Websites überwiegt der Leistungsgewinn durch die Wiederaufnahme von 0‑RTT-Verbindungen diese potenziellen Sicherheitsrisiken. Diese Entscheidung müssen Sie jedoch selbst treffen.

Diese Funktion ist in NGINX standardmäßig deaktiviert. Um sie zu aktivieren, setzen Sie die Direktive „ssl_early_data“ auf „on“.

Umstieg von HTTP/1.1 auf HTTP/3 mit dem Alt-Svc-Header

Nahezu alle Clients (insbesondere Browser) stellen die erste Verbindung über TCP/TLS her. Wenn ein Server QUIC+HTTP/3 unterstützt, teilt er dies dem Client mit, indem er eine HTTP/1.1-Antwort zurückgibt, die den Parameter h3 im Header Alt-Svc enthält. Der Client entscheidet dann, ob er QUIC+HTTP/3 verwendet oder bei einer früheren HTTP-Version bleibt. (Interessanterweise wurde der Header Alt-Svc, der in RFC 7838 definiert ist, bereits vor QUIC eingeführt und kann auch für andere Zwecke verwendet werden.)

Der Alt-Svc-Header teilt einem Client mit, dass derselbe Dienst über einen alternativen Host, ein alternatives Protokoll oder einen alternativen Port (oder eine Kombination daraus) verfügbar ist. Darüber hinaus können Clients darüber informiert werden, wie lange davon ausgegangen werden kann, dass dieser Dienst weiterhin verfügbar sein wird.

Einige Beispiele:

Alt-Svc: h3=":443" HTTP/3 ist auf diesem Server über Port 443 verfügbarAlt-Svc: h3="new.example.com:8443" HTTP/3 ist auf dem Server new.example.com über Port 8443 verfügbarAlt-Svc: h3=":8443"; ma=600 HTTP/3 ist auf diesem Server über Port 8443 verfügbar und wird mindestens 10 Minuten lang verfügbar sein

Obwohl dies nicht zwingend erforderlich ist, sind Server in den meisten Fällen so konfiguriert, dass sie QUIC-Verbindungen über denselben Port wie TCP+TLS annehmen.

Um NGINX so zu konfigurieren, dass der Alt-Svc-Header eingefügt wird, verwenden Sie die Direktive add_header. In diesem Beispiel bedeutet die Variable $server_port, dass NGINX QUIC-Verbindungen an dem Port akzeptiert, an den der Client seine TCP+TLS-Anfrage gesendet hat, und 86.400 entspricht 24 Stunden:

add_header Alt-Svc 'h3=":$server_port"; ma=86400';

Fazit

Dieser Blogbeitrag bietet eine vereinfachte Einführung in QUIC und vermittelt Ihnen hoffentlich einen ausreichenden Überblick, um die wichtigsten Netzwerk- und Verschlüsselungsvorgänge bei der Verwendung von QUIC zu verstehen.

Ausführlichere Informationen zur Konfiguration von NGINX für QUIC + HTTP/3 finden Sie in unserem Blogbeitrag „Binärpakete jetzt für die Vorschauversion der NGINX-Implementierung von QUIC+HTTP/3 verfügbar“ oder in unserem Webinar „NGINX und QUIC+HTTP/3 praktisch kennenlernen“. Einzelheiten zu allen NGINX-Direktiven für QUIC+HTTP/3 sowie vollständige Anweisungen zur Installation vorkompilierter Binärdateien oder zum Erstellen aus dem Quellcode finden Sie auf der NGINX-QUIC-Webseite.

Über den Autor

Robert HaynesManager für technisches Marketing

Weitere Blogbeiträge von Robert Haynes