TLS-Leistung: QUIC und HTTP/3

HTTP/2 multiplexiert mehrere Streams über eine einzige TCP-Verbindung und löst damit das Head-of-Line-Blocking pro Verbindung von HTTP/1.1. TCP selbst verursacht jedoch Head-of-Line-Blocking auf der Transportschicht: Wenn ein TCP-Segment verloren geht, wartet die gesamte dahinter in der Warteschlange befindliche Datenmenge auf die erneute Übertragung und blockiert gleichzeitig alle HTTP/2-Streams. Bereits 1 % Paketverlust kann die Leistung von HTTP/2 unter die von HTTP/1.1 mit mehreren Verbindungen verschlechtern. QUIC (Quick UDP Internet Connections) löst dieses Problem, indem es multiplexte Streams über UDP implementiert, wobei die Verlustbehandlung auf Stream-Ebene andere Streams nicht blockiert.

QUIC ist ein auf UDP basierendes Transportprotokoll, das von Google (2012–2015) entwickelt und von der IETF als RFC 9000 (2021) standardisiert wurde. QUIC integriert TLS 1.3 auf der Transportschicht – es gibt keinen separaten TLS-Handshake über QUIC; TLS ist direkt in den QUIC-Handshake eingebettet. QUIC bietet: multiplexte Streams ohne Head-of-Line-Blocking, Verbindungsmigration (Aufrechterhaltung der Verbindung beim Wechsel des Netzwerks, z. B. von WiFi zu LTE), Verbindungsaufbau mit 0 RTT bei wiederholten Verbindungen sowie integrierte Verlustprüfung und Überlastungssteuerung. HTTP/3 (RFC 9114) ist HTTP-Semantik über QUIC-Streams.

Der QUIC-Handshake kombiniert den Verbindungsaufbau und die TLS-Aushandlung. Beim ersten Paketflug (in der QUIC-Terminologie 0 RTT) sendet der Client Initial-Pakete, die TLS ClientHello enthalten. Der Server antwortet mit eigenen Initial-Paketen (ServerHello) sowie Handshake-Paketen (verschlüsselte Erweiterungen, Zertifikat, Finished). Der Client sendet Handshake Finished und kann anschließend Anwendungsdaten senden – dies entspricht 1 RTT. Bei 0-RTT-Verbindungen sendet der Client neben dem ClientHello 0-RTT-Pakete (Anwendungsdaten) mit einem aus dem Resumption Secret der vorherigen Sitzung abgeleiteten Schlüssel und erreicht so null zusätzliche Round Trips für zwischengespeicherte Sitzungen.

QUIC verwendet vier unterschiedliche Verschlüsselungsebenen, die den Phasen des TLS-Schlüsselplans entsprechen: Initial (von QUIC abgeleitete AEAD mit einem bekannten konstanten Schlüssel – bietet Integrität, aber keine Vertraulichkeit gegenüber versierten Angreifern), Handshake (abgeleitet aus dem TLS handshake_secret – bietet Vertraulichkeit für TLS-Handshake-Nachrichten), 0-RTT (abgeleitet aus dem early_secret der vorherigen Sitzung – verschlüsselt 0-RTT-Anwendungsdaten) und 1-RTT (abgeleitet aus dem TLS master_secret – verschlüsselt alle Anwendungsdaten). QUIC-Header werden teilweise verschlüsselt: Die Paketnummer und der Payload werden verschlüsselt, einige Routing-Informationen (Connection ID) bleiben jedoch für Load-Balancer sichtbar.

QUIC-Verbindungen werden durch eine Connection ID (CID) und nicht durch ein 4-Tupel (Quell-IP, Quellport, Ziel-IP, Zielport) identifiziert. Dadurch können Verbindungen Netzwerkänderungen überstehen: Wenn ein mobiler Client von WiFi zu LTE wechselt, ändert sich die IP-Adresse, die CID bleibt jedoch gleich. Der Client sendet auf dem neuen Pfad einen PATH_CHALLENGE-Frame; der Server antwortet mit PATH_RESPONSE und validiert damit die neue Adresse. Die Verbindung wird ohne erneute Aushandlung nahtlos fortgesetzt. TCP kann dies nicht unterstützen – eine TCP-Verbindung ist an ihr 4-Tupel gebunden und muss bei einem Netzwerkwechsel neu aufgebaut werden, was einen neuen TLS-Handshake erfordert. QUIC-Migration verbessert die wahrgenommene Leistung für mobile Nutzer deutlich.

HTTP/3 ordnet die HTTP-Semantik QUIC-Streams zu. Jedes HTTP-Anfrage-Antwort-Paar belegt einen separaten bidirektionalen QUIC-Stream. QUIC-Streams sind unabhängig: Ein Verlust auf Stream 3 blockiert Stream 7 nicht. HTTP/3 verwendet QPACK zur Header-Komprimierung (als Ersatz für HPACK von HTTP/2) – QPACK wurde so neu entworfen, dass es ohne Zustellung in der richtigen Reihenfolge funktioniert. Zwei dedizierte unidirektionale Steuerungs-Streams übertragen Einstellungen sowie Decoder- und Encoder-Anweisungen. Server Push verwendet in HTTP/3 Push-Streams (unidirektional). Insgesamt führt dies dazu, dass HTTP/3 HTTP/2 vor allem bei Paketverlust deutlich übertrifft, etwa in Mobilfunknetzen oder bei überlasteten Pfaden, wo TCP-Head-of-Line-Blocking den größten Schaden verursacht.

Messungen aus der Praxis zur Leistung von QUIC und HTTP/3 zeigen je nach Netzwerkbedingungen gemischte Ergebnisse. In hochwertigen Netzwerken mit geringer Latenz und wenig Paketverlust sind HTTP/3 und HTTP/2 ähnlich leistungsfähig – der QUIC-Overhead durch größere Header und die UDP-Verarbeitung kann HTTP/3 sogar geringfügig langsamer machen. In verlustbehafteten Netzwerken mit mehr als 1 % Paketverlust, wie sie in Mobilfunk- und Satellitennetzen häufig vorkommen, übertrifft HTTP/3 HTTP/2 deutlich. Google berichtete beim Wechsel zu QUIC von einer Verringerung des Rebufferings bei YouTube um 7–8 %. Facebook (Meta) meldete bei Instagram-Feeds über QUIC eine Verbesserung der Anfrage-Latenz um 7–15 %. Die größten Vorteile zeigen sich bei der Tail-Latenz (p95, p99), bei der sich Verzögerungen durch TCP-Wiederholungsübertragungen besonders stark auswirken.

Die Lastverteilung von QUIC-Datenverkehr ist komplexer als bei TCP, weil QUIC UDP-basiert ist und zustandslose UDP-Load-Balancer keine Verbindungsaffinität herstellen können. Der IETF-Entwurf draft-ietf-quic-load-balancers definiert einen Ansatz dafür: Server kodieren Routing-Informationen in die Connection ID, sodass Load-Balancer Pakete derselben Verbindung an denselben Server weiterleiten können, ohne den Zustand jeder Verbindung zu verfolgen. Die Connection ID enthält eine verschlüsselte Server-ID, die einen gemeinsamen Schlüssel zwischen dem Load-Balancer und den Servern verwendet. Cloudflare, Fastly und Nginx implementieren Varianten dieses Ansatzes. Die NAT-Traversierung ist ein weiteres Problem: QUIC-Verbindungen müssen eine NAT-Neuzuordnung überstehen, was durch den Mechanismus zur Verbindungsmigration ermöglicht wird.

Große CDNs haben QUIC und HTTP/3 im großen Maßstab bereitgestellt. Cloudflare stellt seit 2019 HTTP/3 bereit und berichtet, dass etwa 20 % des Datenverkehrs QUIC verwendet, sofern es von Client und Server unterstützt wird. Fastly, Akamai und AWS CloudFront unterstützen HTTP/3 an ihren Edge-Standorten. Googles eigene Infrastruktur (Search, YouTube, Gmail) verwendet QUIC seit 2013 intern und stellt HTTP/3 öffentlich bereit. CDN-Bereitstellungen profitieren von der Wiederaufnahme mit 0 RTT bei QUIC: Wiederkehrende Besucher bauen Verbindungen schneller auf, und die Verbindungsmigration verbessert die Leistung für mobile Nutzer, die während der Inhaltsauslieferung zwischen Zugangspunkten wechseln.

Das UDP-basierte Design von QUIC führt zu spezifischen Sicherheitsaspekten. Bei Amplification-Angriffen kann ein Angreifer eine Quell-IP fälschen und kleine Initial-Pakete senden, wodurch der Server große Handshake-Antworten an das Opfer sendet. QUIC mindert dieses Risiko, indem es die Antworten des Servers auf das Dreifache der empfangenen Datenmenge begrenzt, bis die Adressvalidierung über den RETRY-Mechanismus abgeschlossen ist. Gegen Verbindungsflutung müssen QUIC-Server neue Verbindungsversuche von derselben IP durch Ratenbegrenzung kontrollieren. Angriffe auf die Versionsaushandlung werden verhindert, indem die Version in den kryptografisch geschützten Handshake aufgenommen wird. Die integrierte Verschlüsselung von QUIC bedeutet, dass Inspection-Appliances den QUIC-Payload nicht analysieren können, ohne sich mit dem Serverzertifikat im Übertragungsweg zu befinden – dadurch wird die Privatsphäre im Vergleich zu inspizierbarem TCP-Datenverkehr verbessert.

Für die Bereitstellung von HTTP/3 benötigen Sie: (1) einen QUIC-fähigen Server (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed oder eine Lösung auf Anwendungsebene über die Bibliotheken quic-go, aioquic, ngtcp2). (2) Den UDP-Port 443 in Firewalls öffnen – viele Unternehmens-Firewalls blockieren UDP 443, wodurch QUIC auf TCP/TLS zurückfällt. (3) Die Unterstützung für HTTP/3 über den Alt-Svc-Antwortheader bekanntgeben: Alt-Svc: h3=":443"; ma=86400, wodurch HTTP/2-Clients zum Upgrade aufgefordert werden. (4) QUIC-fähige Load-Balancer oder L4-UDP-Passthrough. (5) QUIC-spezifische Metriken überwachen: Ereignisse bei Verbindungsmigration, Annahmerate von 0-RTT und Rate des Protokoll-Fallbacks. Ein schrittweiser Rollout mit Fallback auf HTTPS ist für Clients, die QUIC nicht unterstützen, transparent.

Wie löst QUIC das Head-of-Line-Blocking-Problem, das HTTP/2 über TCP betrifft?

QUIC integriert TLS 1.3 auf der Transportschicht über UDP und beseitigt TCP-Head-of-Line-Blocking durch eine unabhängige Verlustbehandlung pro Stream. Connection IDs ermöglichen die Migration über Netzwerkänderungen hinweg ohne erneute Aushandlung. HTTP/3 ordnet HTTP mithilfe der QPACK-Header-Komprimierung QUIC-Streams zu. Der Verbindungsaufbau mit 0 RTT verwendet TLS-Sitzungsgeheimnisse erneut. QUIC übertrifft HTTP/2 vor allem bei Paketverlust, etwa in Mobilfunknetzen und überlasteten Netzwerken. Für die Lastverteilung von QUIC müssen Server-Routing-Informationen in Connection IDs kodiert werden. Die Bereitstellung erfordert UDP 443, QUIC-fähige Server und Alt-Svc-Header zur Bekanntgabe des Protokolls.