Flucht aus dem Kernel – QUIC, HTTP/3 und das Ende der TCP-Versteinerung

Der Aufhänger

Zwischen September 2010 und April 2011 schickte eine Gruppe von Forschern aus Tokio, Bukarest und London ein merkwürdiges Messwerkzeug an Freiwillige in aller Welt. Das Programm baute TCP-Verbindungen zu einem Server auf und packte in die Pakete Dinge, die dort nicht hingehörten: unbekannte TCP-Optionen, absichtliche Lücken in der Sequenznummernfolge, widersprüchliche Neuübertragungen. Die Frage war nicht, ob das Internet diese Pakete transportiert. Die Frage war, ob es sie unverändert transportiert.

Die Antwort war ernüchternd. Auf Port 80 kam bei 14 % der gemessenen Pfade eine unbekannte TCP-Option im SYN-Paket nicht mehr beim Empfänger an – jemand auf dem Weg hatte sie entfernt. 18 % der Pfade auf Port 80 schrieben in mindestens einer Richtung die Sequenznummern um. Und als die Forscher testeten, ob man eine Lücke in der Sequenznummernfolge offenlassen darf – eine Technik, die jede Erweiterung bräuchte, die Daten außerhalb der Reihenfolge überträgt –, scheiterte das selbst auf einem völlig unauffälligen, nicht registrierten Port in etwa einem Viertel der Fälle.

Dieses Papier heißt „Is it Still Possible to Extend TCP?" (Honda et al., ACM IMC 2011). Sein Befund wurde zum Gründungsmythos eines neuen Transportprotokolls – und wird dabei fast immer falsch zitiert. Die Autoren kommen nämlich nicht zu dem Schluss, dass TCP nicht mehr erweiterbar sei. Ihr Abstract sagt wörtlich: Man könne TCP durchaus noch erweitern, aber der Entwurf solcher Erweiterungen sei stark eingeschränkt, weil er verbreitetes Middlebox-Verhalten berücksichtigen müsse.

Sechs Jahre später formulierten 21 Google-Ingenieure dasselbe Problem ökonomisch statt technisch. In ihrem SIGCOMM-Papier von 2017 steht der Satz, der die Richtung der nächsten Dekade vorgab: Das Ausrollen von TCP-Änderungen habe einen Punkt abnehmender Erträge erreicht, an dem selbst einfache Protokolländerungen voraussichtlich über ein Jahrzehnt brauchen, bis sie signifikant verbreitet sind. Nicht weil die Ideen fehlten. Sondern weil TCP im Betriebssystemkern steckt – und weil zwischen Sender und Empfänger Geräte sitzen, die glauben, TCP zu verstehen.

Die Konsequenz war radikal: Man baut den Transport neu, im User Space, auf UDP, und verschlüsselt ihn so vollständig, dass unterwegs niemand mehr genug sieht, um mitzureden. Das Ergebnis heißt QUIC, ist seit Mai 2021 ein IETF-Standards-Track-Dokument und wird heute laut einer kommerziellen Erhebung von über 40 % aller Websites unterstützt.

Und dann kommt die Pointe, die diesen Artikel erst interessant macht: Auf einer Gigabit-Leitung war QUIC im Chrome-Browser in einer Messung von 2024 bis zu 45,2 % langsamer als das alte TCP-Gespann – schlanke Kommandozeilen-Clients verloren im selben Aufbau nur 7–16 % (cURL) bzw. 8–12 % (quic_client). Nicht weil der Entwurf falsch war – sondern weil die Flucht aus dem Kernel einen Preis hat, den der Kernel vorher bezahlt hatte.

Teil 1: Das Problem – warum Protokolle versteinern

Zwei Schichten Beton

Die Versteinerung („Ossification") von TCP hat zwei unabhängige Ursachen, und es lohnt, sie zu trennen, weil QUIC gegen beide unterschiedlich vorgeht.

Erste Schicht: die Implementierungsschicht. TCP ist üblicherweise im Kern des Betriebssystems implementiert. Das Google-Papier beschreibt die Folge nüchtern: Änderungen an TCP-Stacks erfordern in der Regel Betriebssystem-Upgrades, und selbst Server-Upgrades, die man selbst kontrolliert, können viele Monate dauern. Bei Clients – Millionen Mobiltelefone, Fernseher, eingebettete Geräte – wird aus Monaten ein Jahrzehnt oder gar nie.

Zweite Schicht: die Pfadschicht. Unterwegs sitzen Firewalls, NATs, Load Balancer, Transparent Proxies, Traffic Shaper. Das Google-Papier formuliert es so, dass Middleboxen versehentlich zu zentralen Kontrollpunkten in der Architektur des Internets geworden seien. Diese Geräte parsen TCP-Header. Was sie nicht kennen, behandeln sie konservativ: Sie löschen es, schreiben es um, oder verwerfen das Paket.

Was Honda et al. tatsächlich gemessen haben

Die Messung umfasste 142 Zugangsnetze in 24 Ländern (Heimanschlüsse, Hotspots, Mobilfunk, Universitäten, Unternehmen, Hosting) und drei Ports: 80, 443 und den nicht zugewiesenen Port 34343 als Kontrollgruppe.

Drei Dinge fallen auf.

Erstens: Der Port entscheidet mit. Port 80 ist der feindlichste, weil dort HTTP-spezifische Middleboxen und Proxies besonders häufig sind. Dasselbe Protokoll, dieselben Pakete, anderer Port – anderes Ergebnis. (Eine Randnotiz zur Quellentreue: Im Fließtext von Abschnitt 4.1 nennen die Autoren für Port 80 „nur 80 % der Pfade", während ihre Tabelle 3 dort 86 % ausweist. Die Tabellenwerte stehen oben; die Abweichung ist eine Inkonsistenz im Papier, nicht in diesem Artikel.)

Zweitens: Die ACK-Zeile ist die eigentliche Katastrophe. Nur drei Viertel der Pfade erlaubten eine Sequenzlücke, die von einem ACK-Segment aufgerissen wurde. Die Autoren selbst nennen dieses Ergebnis überraschend: Selbst auf Port 34343 hätten Middleboxen in 24 % der Fälle in das Ende-zu-Ende-Verhalten eingegriffen. Jede Erweiterung, die Daten bewusst außer der Reihe überträgt – und genau das braucht man, um Head-of-Line-Blocking zu vermeiden –, stößt hier gegen eine Wand.

Drittens: Die Mittelwerte sind nicht das Problem, die Minderheit ist es. Wenn eine Erweiterung auf 86 % der Pfade funktioniert, kann man sie nicht einschalten – man braucht einen Rückfallpfad auf regulären TCP-Betrieb, und dieser Rückfall muss immer verfügbar bleiben. Genau das ist der Grund, warum Honda et al. zu „eingeschränkt erweiterbar" statt „nicht erweiterbar" kommen: Erweiterungen müssen im SYN-Austausch verhandelt werden, und der Rückfall auf normales TCP muss akzeptabel sein.

Der Ausweg, der kein Ausweg war

Man kann Middleboxen nicht reparieren. Es gibt keine Instanz, die sie aktualisiert. Also bleiben zwei Strategien: Man umgeht sie, oder man macht sich für sie unlesbar. QUIC tut beides.

Teil 2: Der Entwurf – was QUIC tatsächlich ist

RFC 9000, „QUIC: A UDP-Based Multiplexed and Secure Transport", herausgegeben von Jana Iyengar (Fastly) und Martin Thomson (Mozilla), erschien im Mai 2021 als Standards-Track-Dokument. Sein Abstract ist bemerkenswert knapp: Das Dokument definiere den Kern des QUIC-Transportprotokolls; QUIC stelle Anwendungen flussgesteuerte Streams für strukturierte Kommunikation, Verbindungsaufbau mit geringer Latenz und Migration des Netzwerkpfads bereit, zusammen mit Sicherheitsmaßnahmen für Vertraulichkeit, Integrität und Verfügbarkeit. Alles Weitere – TLS-Integration, Verlusterkennung, ein exemplarischer Congestion-Control-Algorithmus – ist in Begleitdokumenten ausgelagert.

UDP ist Mittel, nicht Zweck

QUIC läuft nicht auf UDP, weil UDP gut wäre. RFC 9000 begründet die Wahl in Abschnitt 1 ausdrücklich damit, dass QUIC-Pakete in UDP-Datagrammen transportiert werden, um die Verbreitung („deployment") in bestehenden Systemen und Netzen zu erleichtern. UDP ist der Lastwagen, der durch die bestehenden Tore passt. Alles, was ein Transportprotokoll ausmacht – Verbindungszustand, Streams, Flusskontrolle, Verlusterkennung, Congestion Control – baut QUIC darüber neu auf.

Dass QUIC daraus folgend typischerweise im User Space implementiert wird, ist für den Standard übrigens kein Thema: In Abstract und Abschnitt 1 von RFC 9000 steht dazu nichts. Der User-Space-Charakter ist eine Eigenschaft der verbreiteten Implementierungen – prominent im Google-Papier von 2017 als Entwurfsmotiv genannt –, keine Festlegung des Protokolls. Das klingt wie eine Spitzfindigkeit, wird aber in Teil 7 der entscheidende Punkt.

Streams: Unabhängigkeit, präzise formuliert

Die populäre Erzählung lautet: „QUIC beseitigt Head-of-Line-Blocking." Das ist der Punkt, an dem man beim Faktenprüfen vorsichtig werden muss. In Abstract, Abschnitt 1 und Abschnitt 2 von RFC 9000 kommt der Begriff „head-of-line blocking" überhaupt nicht vor – er taucht in dieser Dokumentenfamilie in RFC 9114 auf, und zwar in Abschnitt 4.2.1, wo er die Kompression betrifft und nicht den Transport. Was dort steht, ist präziser und schwächer:

Streams können von beiden Endpunkten erzeugt werden, können Daten verschränkt mit anderen Streams gleichzeitig senden und können abgebrochen werden. Und dann der Schlüsselsatz aus Abschnitt 2: QUIC stelle keinerlei Mittel bereit, eine Ordnung zwischen Bytes auf verschiedenen Streams sicherzustellen.

Das ist eine Aussage über Ordnungsgarantien, nicht direkt über Blockierung. Sie ist aber die Grundlage, aus der die Blockierungsfreiheit folgt: Wenn es keine Ordnung zwischen Streams gibt, kann ein Empfänger Stream B ausliefern, während in Stream A noch eine Lücke klafft. Innerhalb eines Streams bleibt die Reihenfolge dagegen bindend – Abschnitt 4.3 hält fest, dass Paketverlust Lücken im Empfangspuffer erzeugen kann, die die Anwendung am Konsumieren der Daten hindern. Head-of-Line-Blocking verschwindet also nicht; es wird vom Verbindungs- auf die Stream-Ebene herabgestuft.

Diese Unterscheidung ist kein Haarspalten. Sie erklärt, warum HTTP/3 ein neues Header-Kompressionsverfahren brauchte (Teil 5) und warum ein einzelner großer Download von QUIC strukturell wenig profitiert.

Flusskontrolle auf zwei Ebenen

RFC 9000 Abschnitt 4.1 beschreibt ein limitbasiertes Flusskontrollschema mit zwei Ebenen:

• Stream-Ebene – verhindert, dass ein einzelner Stream den gesamten Empfangspuffer der Verbindung belegt. Kredit wird über MAX_STREAM_DATA erteilt, Blockierung über STREAM_DATA_BLOCKED signalisiert.
• Verbindungsebene – begrenzt die Summe über alle Streams. Kredit über MAX_DATA, Signal über DATA_BLOCKED.

Sender dürfen keines der beiden Limits überschreiten. Zusätzlich ist die Anzahl gleichzeitig offener Streams begrenzt (MAX_STREAMS, STREAMS_BLOCKED; Abschnitt 4.6, „Controlling Concurrency"). Wer in verteilten Systemen schon einmal einen Backpressure-Mechanismus gebaut hat, erkennt hier ein sauber zweistufiges Kreditsystem – und die Erkenntnis, dass ein einziges globales Fenster nicht genügt, sobald Multiplexing ins Spiel kommt.

Connection IDs und Migration – mit einer harten Einschränkung

TCP identifiziert eine Verbindung über das Vier-Tupel aus IP-Adressen und Ports. Wechselt die Adresse – WLAN zu Mobilfunk, NAT-Rebinding –, ist die Verbindung tot. QUIC entkoppelt Identität von Adresse: Verbindungen sind nicht streng an einen Netzwerkpfad gebunden, und Connection IDs erlauben es, eine Verbindung auf einen neuen Pfad zu übertragen. Damit überlebt eine Verbindung Änderungen der Netztopologie oder der Adresszuordnung, wie sie etwa durch NAT-Rebinding entstehen.

Und jetzt der Satz, den fast jede Zusammenfassung unterschlägt – RFC 9000, Abschnitt 1, wörtlich: Nur Clients können in dieser Version von QUIC migrieren. Server-Migration ist in QUIC Version 1 nicht vorgesehen. Ein Server, der keinen Mechanismus hat, Verbindungen über Adresswechsel hinweg fortzuführen, soll laut Abschnitt 5.2.3 sogar aktiv signalisieren, dass er Migration nicht unterstützt (Transportparameter disable_active_migration).

Auch die Kehrseite steht im Dokument: Connection IDs der Länge Null sind erlaubt, führen aber bei geteilter IP/Port-Kombination zu Fehlern in Gegenwart von Peer-Migration, NAT-Rebinding und Port-Wiederverwendung (Abschnitt 5.1). Und Abschnitt 5.1.2 hält als gegebenes Verhalten fest, dass Endpunkte – wie in Abschnitt 9.5 erörtert – die Verwendung einer Connection ID auf Pakete von einer einzelnen lokalen zu einer einzelnen Ziel-Adresse beschränken – sonst wird die Connection ID selbst zum Linkbarkeitsmerkmal über Netzwechsel hinweg.

Was QUIC bewusst nicht tut

Ein Standard wird dadurch gut, dass er seine Grenzen benennt. RFC 9000 tut das an mehreren Stellen ausdrücklich:

• Keine Priorisierung. Abschnitt 2.3: QUIC stelle keinen Mechanismus zum Austausch von Priorisierungsinformationen bereit. Priorität kommt aus der Anwendung.
• Keine API. Abschnitte 2.4 und 5.3: Das Dokument definiere keine API für QUIC. Jede Bibliothek erfindet ihre eigene – wer je von quiche zu msquic zu quic-go gewechselt ist, hat das gespürt.
• Versionsverhandlung nur halb spezifiziert. Abschnitt 6 trägt die Überschrift „Version Negotiation" und definiert Version-Negotiation-Pakete und ihre Behandlung (6.1, 6.2); offen bleibt das Wie. Abschnitt 6.2: Wie Versionsverhandlung durchzuführen sei, bleibe künftiger Arbeit überlassen. Das ist für ein Protokoll, dessen Existenzgrund die Entversteinerung ist, eine bemerkenswerte Lücke – dazu Teil 8.
• Kein Replay-Schutz für 0-RTT. Abschnitt 5 hält fest, dass 0-RTT keinen Schutz gegen Replay-Angriffe bietet, und verweist auf RFC 9001.

Teil 3: Verschlüsselung als Panzerung, nicht als Beigabe

Hier liegt der eigentliche architektonische Trick. Bei TLS über TCP ist die Verschlüsselung ein Mieter in einem fremden Haus: TLS-Records liegen im TCP-Bytestrom, der TCP-Header selbst bleibt im Klartext und damit lesbar – und veränderbar – für jede Middlebox.

QUIC dreht das um. RFC 9001, „Using TLS to Secure QUIC" (Martin Thomson, Mozilla; Sean Turner, sn3rd; Mai 2021), beschreibt in Abschnitt 3, dass TLS-Handshake- und Alert-Nachrichten nicht als TLS-Records über QUIC getragen werden, wie es bei TCP der Fall ist, sondern direkt über den QUIC-Transport – und dass QUIC die Aufgaben der TLS-Record-Schicht übernimmt. Abschnitt 4.1.3 sagt es noch knapper: TLS-Record-Schutz wird von QUIC nicht verwendet. Handshake-Daten reisen in CRYPTO-Frames (Abschnitt 4).

Die Folgen sind konkret:

• TLS 1.3 ist Pflicht. Abschnitt 4.2: Clients dürfen keine TLS-Versionen älter als 1.3 anbieten, und ein Endpunkt muss die Verbindung beenden, wenn eine Version älter als 1.3 verhandelt wird. Eine neuere Version ist erlaubt, sofern sie die von QUIC genutzten TLS-1.3-Funktionen unterstützt.
• Kein ChangeCipherSpec, kein TLS-KeyUpdate. Abschnitt 2.1: Diese Nachrichten werden von QUIC nicht verwendet. QUIC hat sein eigenes Schlüsselwechsel-Verfahren (Abschnitt 6).
• Header Protection. Teile des QUIC-Headers – unter anderem die Paketnummer – werden mit einem separat abgeleiteten Schlüssel geschützt. Für eine Middlebox ist damit nicht einmal mehr die Paketnummer sichtbar. Sichtbar bleibt aber genau das, was sichtbar bleiben muss: RFC 8999 („Version-Independent Properties of QUIC", Martin Thomson, Mai 2021) legt die Eigenschaften fest, die über QUIC-Versionen hinweg stabil bleiben – das Header-Form-Bit, bei Long-Header-Paketen das Versionsfeld und die Connection IDs. Dasselbe Dokument weist in Abschnitt 7 darauf hin, dass die Versionsnummer nicht in allen QUIC-Paketen auftaucht und Middleboxen daher für jede gesehene Connection ID Zustand halten müssten, um verlässlich versionsspezifische Merkmale auszulesen. Die Angriffsfläche für Klassifikatoren schrumpft also drastisch; sie verschwindet nicht.

Das ist Entversteinerung durch Kryptographie: Nicht Verbote halten Middleboxen davon ab, QUIC-Semantik zu interpretieren, sondern Unlesbarkeit.

Der Preis: 0-RTT und Replay

Der Verbindungsaufbau verschmilzt kryptographische und Transportparameter-Verhandlung. RFC 9000, Abschnitt 1: Der QUIC-Handshake kombiniert die Verhandlung kryptographischer und Transportparameter; QUIC integriert den TLS-Handshake, verwendet aber ein eigenes Framing zum Schutz der Pakete. Der Handshake sei so strukturiert, dass Anwendungsdaten so früh wie möglich ausgetauscht werden können – einschließlich der Option für Clients, Daten sofort zu senden (0-RTT), was irgendeine Form vorheriger Kommunikation oder Konfiguration voraussetzt.

Und dann die Warnung, die man sich als Architekt tätowieren lassen sollte. RFC 9001, Abschnitt 2.1, Kern der Aussage: Bei einem 0-RTT-Handshake nutzt der Client zuvor gelernte Informationen über den Server, um Anwendungsdaten unmittelbar zu senden. Diese Anwendungsdaten können von einem Angreifer wiederholt eingespielt werden – 0-RTT ist daher nicht geeignet, um Anweisungen zu übertragen, die bei Replay unerwünschte Wirkungen auslösen könnten.

Praktisch heißt das: Ein idempotentes GET darf in 0-RTT. Ein POST /zahlungen darf es nicht. Wer 0-RTT global einschaltet, weil es in der Konfiguration so verlockend nach „schneller" klingt, baut sich eine Replay-Schwachstelle in die Zahlungsstrecke.

Teil 4: Verlusterkennung ohne Ambiguität

RFC 9002, „QUIC Loss Detection and Congestion Control" (Jana Iyengar, Fastly; Ian Swett, Google; Mai 2021), hat das knappste Abstract der Serie: Das Dokument beschreibe Verlusterkennungs- und Congestion-Control-Mechanismen für QUIC. Abschnitt 4 ordnet es ein: Wer TCPs Verlusterkennung und Congestion Control kenne, finde hier Algorithmen, die bekannten TCP-Verfahren entsprechen – Protokollunterschiede zwischen QUIC und TCP führten jedoch zu algorithmischen Unterschieden.

Vier dieser Unterschiede sind es wert, einzeln genannt zu werden, weil sie zeigen, wo ein Neuentwurf Komplexität entfernt:

1. Monoton steigende Paketnummern. Abschnitt 3: Paketnummern wiederholen sich innerhalb eines Paketnummernraums für die Lebensdauer einer Verbindung nie und werden in monoton steigender Reihenfolge gesendet, was Ambiguität verhindert. Derselbe Abschnitt zieht die Konsequenz: Dieser Entwurf erübrige die Unterscheidung zwischen Übertragungen und Neuübertragungen und beseitige damit erhebliche Komplexität aus QUICs Interpretation der TCP-Verlusterkennungsmechanismen. In TCP identifiziert die Sequenznummer Daten; ein ACK sagt nicht, welche Übertragung dieser Daten angekommen ist. RFC 9002 benennt dieses Problem in Abschnitt 4.2 als „retransmission ambiguity". Ich bin der Meinung, dass ein erheblicher Teil der historisch gewachsenen TCP-Komplexität auf genau diese Ambiguität zurückgeht – die geprüften Quellen führen die einzelnen TCP-Mechanismen dazu nicht auf. QUIC trennt Übertragungsreihenfolge von Auslieferungsreihenfolge (Abschnitt 4.2) – und spart damit zwei Jahrzehnte Reparaturarbeit.

2. Getrennte Paketnummernräume. Abschnitt 4.1: QUIC nutzt getrennte Paketnummernräume für jede Verschlüsselungsebene, mit der Ausnahme, dass 0-RTT und alle Generationen von 1-RTT-Schlüsseln denselben Raum verwenden.

3. Explizite Korrektur verzögerter ACKs. Abschnitt 4.6: QUIC-Endpunkte messen die Verzögerung zwischen Empfang eines Pakets und Senden der zugehörigen Bestätigung, sodass der Peer eine genauere RTT-Schätzung führen kann. In TCP ist eine verzögerte Bestätigung vom Sender nicht von Netzwerklatenz zu unterscheiden; QUIC macht sie zu einem gemeldeten Feld.

4. Kein Reneging. Abschnitt 4.4: QUIC erlaubt es nicht, eine Paketbestätigung zurückzunehmen, was Implementierungen auf beiden Seiten erheblich vereinfacht und den Speicherdruck beim Sender reduziert.

Bei der Congestion Control ist das Dokument ausdrücklich zurückhaltend. Abschnitt 7 spezifiziert einen senderseitigen Congestion Controller ähnlich TCP NewReno. Die Signale, die QUIC für Congestion Control bereitstelle, seien generisch und darauf ausgelegt, verschiedene senderseitige Algorithmen zu unterstützen; ein Sender könne einseitig einen anderen Algorithmus wählen, etwa CUBIC. Verpflichtend ist nur: Wer einen anderen Controller verwendet, muss die Congestion-Control-Leitlinien aus RFC 8085 einhalten. NewReno ist also die Referenz, nicht die Vorschrift – und in der Praxis sprechen die großen Deployments längst CUBIC oder BBR.

Teil 5: HTTP/3 – wenn die Anwendung dem Transport folgen muss

RFC 9114, „HTTP/3", herausgegeben von Mike Bishop (Akamai) im Juni 2022, ist das Dokument, in dem sich zeigt, dass ein neuer Transport nicht gratis ist: Die Anwendungsschicht muss nachziehen.

Das Abstract beschreibt das Vorgehen offen: Das QUIC-Transportprotokoll habe mehrere Eigenschaften, die für einen HTTP-Transport wünschenswert seien – Stream-Multiplexing, Flusskontrolle pro Stream und Verbindungsaufbau mit geringer Latenz; das Dokument beschreibe eine Abbildung von HTTP-Semantik auf QUIC, identifiziere HTTP/2-Funktionen, die von QUIC übernommen („subsumed") werden, und beschreibe, wie HTTP/2-Erweiterungen auf HTTP/3 portiert werden können.

Ein Stream pro Anfrage-Antwort-Paar

Abschnitt 2 sagt es wörtlich: Jedes Anfrage-Antwort-Paar verbraucht einen einzelnen QUIC-Stream. Abschnitt 4.1 präzisiert: Eine Anfrage wird auf einem Request Stream gesendet – einem client-initiierten bidirektionalen QUIC-Stream –, und ein Client darf auf einem gegebenen Stream nur eine einzige Anfrage senden. Der Client schließt danach seine Senderichtung, der Server nach der endgültigen Antwort die seine.

Damit ist die Zuordnung so einfach, wie sie bei HTTP/2 nie war: Ein Request ist ein Stream, nicht ein Stream-Identifier innerhalb eines gemeinsamen TCP-Bytestroms. Fällt ein Paket aus, betrifft die Lücke zunächst nur diesen einen Request – mit einer Ausnahme, die der nächste Abschnitt behandelt.

HPACK musste sterben

Und hier schlägt der Satz aus Teil 2 zurück. Abschnitt 2 von RFC 9114, wörtlich sinngemäß: Weil HPACK auf in-order-Übertragung komprimierter Feldabschnitte angewiesen ist – eine Garantie, die QUIC nicht bietet –, ersetzt HTTP/3 HPACK durch QPACK. QPACK verwende separate unidirektionale Streams, um den Zustand der Feldtabelle zu verändern und nachzuhalten, während kodierte Feldabschnitte sich auf den Tabellenzustand beziehen, ohne ihn zu verändern.

Das ist ein lehrreiches Muster für jeden, der Protokolle oder verteilte Caches entwirft: HPACK war ein zustandsbehafteter, inkrementeller Kompressor, dessen Korrektheit von der Reihenfolge abhing. Genau diese Annahme hat QUIC entfernt. Der Preis war ein neues Format – und QPACK muss den Zielkonflikt explizit verwalten: RFC 9114 beschreibt es in Abschnitt 4.2.1 als Variante von HPACK, die dem Encoder etwas Kontrolle darüber gibt, wie viel Head-of-Line-Blocking die Kompression verursachen kann. Man bekommt die Blockierungsfreiheit also nicht geschenkt; man bekommt einen Regler.

Und hier ist die Ausnahme zu „ein Paketverlust, ein betroffener Request": Dass der QPACK-Tabellenzustand über separate unidirektionale Streams reist, steht in Abschnitt 2. Dass Verlust auf diesem Stream andere Anfragen aufhält, sagt RFC 9114 nicht ausdrücklich – es folgt aus Abschnitt 4.2.1, wo die Kompression selbst als möglicher Verursacher von Head-of-Line-Blocking benannt wird; die Mechanik beschreibt RFC 9204 (QPACK). Ich bin der Meinung, dass die Entkopplung damit gut, aber nicht vollständig ist.

Weitere Festlegungen: QUIC Version 1 verwendet TLS 1.3 oder neuer als Handshake-Protokoll (Abschnitt 3.2), das ALPN-Token lautet h3 (Abschnitt 3.1), und HTTP/3 verlässt sich darauf, dass QUIC Vertraulichkeits- und Integritätsschutz der Daten liefert (Abschnitt 1.2). Server Push existiert weiter und wird über die Frames PUSH_PROMISE, MAX_PUSH_ID und CANCEL_PUSH verwaltet; RFC 9114 beschreibt es als Abwägung von Netzwerknutzung gegen potenziellen Latenzgewinn.

Teil 6: Was die Messung von 2017 sagte – und was sie schon damals einschränkte

Das Google-Papier „The QUIC Transport Protocol: Design and Internet-Scale Deployment" (21 Autoren, alle Google, SIGCOMM '17, Los Angeles, 21.–25. August 2017) ist die größte veröffentlichte Feldmessung zu QUIC. Eine Einschränkung muss man ihm aber voranstellen, die es selbst macht: Das Papier beschreibt Prä-IETF-QUIC – also Googles eigene Variante, nicht RFC 9000. Details, so die Autoren, würden sich in der IETF-Standardisierung ändern. Jede Übertragung dieser Zahlen auf heutiges HTTP/3 ist also eine Extrapolation, nicht ein Messergebnis.

Die Kernzahlen aus der Einleitung, wörtlich belegt:

Dabei bedeutet „Desktop" Chrome auf Desktop-Plattformen und „mobil" Apps auf Android-Geräten – die Mobilwerte spiegeln also sowohl Netzumgebung als auch eine andere Implementierung.

Weitere belegte Werte:

• 0-RTT: QUICs Handshake-Latenz sei weitgehend unempfindlich gegenüber der RTT, weil 0-RTT-Handshakes einen festen (nämlich null) Latenzaufwand haben – und diese machten etwa 88 % aller QUIC-Handshakes aus (Abschnitt 6.2). Differenziert: ~88 % der Desktop-Verbindungen bei Search, 68 % bei der mobilen Search-App, durchschnittlich 85 % bei Desktop-Video, aber nur 65 % in der YouTube-App.
• Verbreitung 2017: QUIC mache zu diesem Zeitpunkt über 30 % des gesamten Egress-Verkehrs von Google in Bytes aus und damit geschätzt 7 % des globalen Internetverkehrs. Der Sprung von 15 % auf über 30 % fiel damit zusammen, dass die YouTube-App im September 2016 auf QUIC umstellte und den QUIC-Anteil an Googles Egress-Verkehr verdoppelte.
• Erreichbarkeit: QUIC werde für 95,3 % der Video-Clients, die es versuchen, erfolgreich verwendet; 4,4 % der Clients können QUIC nicht nutzen (QUIC oder UDP blockiert oder Pfad-MTU zu klein); die verbleibenden 0,3 % sind in Netzen, die QUIC bzw. UDP offenbar ratenlimitieren (Messung November 2016).
• CPU-Kosten: Als man begann, die Kosten der YouTube-Auslieferung über QUIC zu messen, lag QUICs Server-CPU-Auslastung etwa 3,5-mal höher als bei TLS/TCP (Abschnitt 6.7). Nach Optimierungen senkte man die CPU-Kosten der Web-Auslieferung über QUIC auf etwa das Doppelte von TLS/TCP.

Beim letzten Punkt ist die Ursachenzuschreibung entscheidend, weil sie gern falsch gemacht wird. Abschnitt 6.7 nennt als drei große Quellen von QUICs CPU-Kosten: Kryptographie, das Senden und Empfangen von UDP-Paketen und das Halten des internen QUIC-Zustands. Und das Papier räumt ausdrücklich ein, die Implementierung sei zunächst mit Blick auf schnelle Feature-Entwicklung und leichte Fehlersuche geschrieben worden, nicht auf CPU-Effizienz. Dass der Transport im User Space läuft, nennen die Autoren nicht als Ursache; Kernel-Bypass erscheint bei ihnen nur als möglicher künftiger Hebel. Ich bin der Meinung, dass der Umzug aus dem Kernel ein Teil dieses Preises ist – aber das ist meine Deutung und nicht der Befund des Papiers.

Die Einschränkung, die 2017 schon dastand

Abschnitt 6.8 des Papiers trägt die Überschrift „Performance Limitations", und dort steht wörtlich: In Netzen mit reichlich Bandbreite, geringer Verzögerung und geringer Verlustrate zeige die Verwendung von QUIC geringen Gewinn und gelegentlich negative Performance-Auswirkungen. Deutlicher noch: Bei Verwendung über eine Verbindung mit sehr hoher Bandbreite (über 100 Mbit/s) und/oder sehr niedriger RTT (wenige Millisekunden) könne QUIC schlechter abschneiden als TCP. Als Vermutung nennen die Autoren CPU-Grenzen auf dem Client und/oder Ineffizienzen des Schedulers im Betriebssystem oder in der Anwendung.

Man sollte diesen Absatz zweimal lesen. Die Leute, die QUIC gebaut und ausgerollt haben, haben die Schwachstelle 2017 benannt – inklusive der richtigen Vermutung über die Ursache. Sieben Jahre später hat sie jemand nachgemessen.

Teil 7: Der Gegenbefund – „QUIC is not Quick Enough over Fast Internet"

2024 erschien auf der ACM Web Conference (WWW '24, Singapur, 13.–17. Mai 2024) ein Papier mit einem Titel, der das Marketing von zehn Jahren in Frage stellt: „QUIC is not Quick Enough over Fast Internet", von Xumiao Zhang, Shuowei Jin, Yi He, Z. Morley Mao (University of Michigan), Ahmad Hassan und Feng Qian (University of Southern California) sowie Zhi-Li Zhang (University of Minnesota).

Der zentrale gemessene Befund laut Abstract: eine Datenratenreduktion von bis zu 45,2 % für UDP+QUIC+HTTP/3 gegenüber TCP+TLS+HTTP/2 – und die Feststellung, dass die Leistungslücke zwischen QUIC und HTTP/2 mit steigender zugrunde liegender Bandbreite wächst.

Die Struktur der Messung ist wichtiger als die Schlagzahl:

Unterhalb von etwa 600 Mbit/s finden die Autoren für cURL und quic_client vergleichbare Leistung; Chrome fällt bereits oberhalb von etwa 500 Mbit/s zurück. (Randnotiz zur Quellentreue, analog zu der bei Honda et al.: Diese Zuordnung steht in Abschnitt 3.2, in Abschnitt 3.3 – dort ausdrücklich im Vergleich zum „600 Mbps bottleneck point identified in the lightweight client tests" – und in der Einleitung. Der zusammenfassende Satz in Abschnitt 4.1 vertauscht die beiden Werte. Die Inkonsistenz liegt im Papier, nicht in diesem Artikel.) Das heißt: Der Befund ist keine Absage an QUIC, sondern eine Bandbreitenschwelle. Wer mit 100 Mbit/s auf einer Leitung mit 40 ms RTT arbeitet, ist von diesem Papier nicht betroffen.

Die Ursache: der Empfänger, nicht das Netz

Die Autoren benennen als Ursache eine hohe empfängerseitige Verarbeitungslast, insbesondere übermäßig viele Datenpakete und QUICs User-Space-ACKs. Sie zerlegen das in zwei Schichten:

• Kernelseitig: Keine der untersuchten QUIC-Implementierungen verwende UDP Generic Receive Offload (GRO). Dadurch entstehen mehr netif_receive_skb-Aufrufe als bei TCP und damit mehr CPU-Last pro Byte. TCP profitiert hier von GRO/LRO, einem Mechanismus, der viele kleine Pakete vor der Protokollverarbeitung zu großen zusammenfasst.
• User-Space-seitig: Zusätzlicher Aufwand durch überzählige Pakete, die User-Space-Natur der QUIC-ACKs und das Fehlen bestimmter Optimierungen wie Delayed ACK.

Zur Einordnung: Ein schnellerer Client-Prozessor (Core i7-10700, 4,80 GHz) erreichte 530 Mbit/s – die Lücke verengte sich damit nur geringfügig. Der Flaschenhals ist also nicht einfach „zu langsame CPU", sondern der Pfad, den jedes Paket durch den Empfänger nimmt.

Was dieses Papier ausdrücklich nicht behauptet

Hier ist Disziplin gefragt, weil dieses Papier ein beliebtes Zitat für „QUIC ist schlecht" geworden ist:

• Es spricht bei niedriger Bandbreite von vergleichbarer Leistung („QUIC and HTTP/2 exhibit similar performance when the network bandwidth is relatively low") – das ist eine Aussage über Ähnlichkeit, kein Freispruch von jeder Verschlechterung. Die Schwelle von etwa 600 Mbit/s für die schlanken Clients steht in Abschnitt 3.2, nicht im selben Satz.
• Es untersucht nicht alle Implementierungen; serverseitig liefen OpenLiteSpeed v1.7.15 (auf LSQUIC) und nginx-quic, clientseitig Chrome v102, Firefox v105, Edge v106 und Opera v93, das Profiling hauptsächlich auf Chromium v102. quic-go, picoquic und MsQuic sind nicht getestet.
• Es klassifiziert die Ursache nicht eindeutig als Entwurfsfehler. Fehlendes UDP-GRO und User-Space-ACKs sind Implementierungs- und Betriebssystemeigenschaften; gleichzeitig verweisen die Autoren auf „unique challenges" aus QUICs Entwurf bei der Datenannahme.
• Die genannten Abhilfen sind mit Vorbehalten versehen: UDP-GRO stehe vor Schwierigkeiten, GSO-Pacing sei nur in Rechenzentrumsnetzen getestet, parallele Downloads könnten Fairness-Probleme verursachen.

Ich bin der Meinung, dass die richtige Lesart dieses Papiers folgende ist: Es ist kein Befund über QUIC als Protokoll, sondern über den aktuellen Reifegrad der Empfängerpfade. Genau diesen Unterschied zu halten, ist der Unterschied zwischen einer begründeten Technologieentscheidung und einem Zitat aus zweiter Hand.

Teil 8: Das Paradox der Entversteinerung

Jetzt lässt sich der Bogen schließen, und er endet in einem Widerspruch, den man aushalten muss.

Was gewonnen wurde: QUIC hat die Angriffsfläche der Pfadschicht drastisch verkleinert – besiegt hat es sie nicht. Indem fast alles verschlüsselt und authentifiziert ist, inklusive Paketnummer über Header Protection, bleibt Middleboxen deutlich weniger, worauf sie sich festlegen können. Die Invarianten aus RFC 8999 bleiben jedoch sichtbar, und reines Blockieren oder Ratenlimitieren von UDP funktioniert weiterhin: In Googles Messung konnten 4,4 % der Video-Clients QUIC nicht nutzen und 0,3 % wurden ratenlimitiert. Die Implementierungsschicht hat QUIC umgangen, indem es den Transport aus dem Kernel in die Anwendung verlegt: Ein Browser-Update rollt einen neuen Transport aus, ohne ein Betriebssystem anzufassen.

Was bezahlt wurde: CPU. Google maß anfänglich eine 3,5-fache, nach Optimierung noch etwa doppelte Server-CPU-Last gegenüber TLS/TCP – als Ursachen nennt das Papier Kryptographie, UDP-Paketverarbeitung und Zustandshaltung, nicht die Verlagerung als solche. Zhang et al. messen die Spiegelseite auf dem Empfänger, wo die über Jahrzehnte gewachsenen Kernel- und NIC-Optimierungen für TCP – GRO, Offloads, Delayed ACK – zum Messzeitpunkt (Chromium v102, LSQUIC) für UDP/QUIC noch nicht gleichwertig griffen. Dass dieser Posten eher an Offloads und Implementierung hängt als an der Schicht, ist ein aktives Forschungsthema: Die Publikationsliste des Lehrstuhls für Netzarchitekturen und Netzdienste der TU München führt für NOMS 2026 einen Beitrag von Johannes Späth, Stefan Lachnit, Marcel Kempf, Kilian Holzinger, Georg Carle und Johannes Zirngibl mit dem Titel „Kernel Bypass Surgery: A Viable Procedure for Maximizing QUIC Bandwidth?" – die Fragestellung ist damit belegt, die Ergebnisse habe ich in diesem Lauf nicht geprüft.

Was offen ist: Ob QUIC selbst gegen Versteinerung immun bleibt, ist nicht erwiesen, sondern beabsichtigt. RFC 9000 Abschnitt 6.2 hält ausdrücklich fest, dass offen bleibt, wie Versionsverhandlung durchzuführen ist. Und das Google-Papier erzählt in Abschnitt 7.5 eine Geschichte, die man als Warnung lesen sollte: Eine Änderung von einem Bit in den Flags im Oktober 2016 führte dazu, dass hinter dem Klassifikator eines bestimmten Firewall-Herstellers Pakete verschwanden. Ein Bit. Verschlüsselung schützt nur, was tatsächlich verschlüsselt ist – alles, was im Klartext bleiben muss, kann zum Festlegungspunkt werden.

Die allgemeine Lehre, und das ist meine Lesart und nicht die eines der Papiere: Entversteinerung ist kein Zustand, den man erreicht, sondern ein laufender Preis, den man zahlt. Man bezahlt ihn in CPU-Zyklen, in Implementierungsvielfalt ohne gemeinsame API (RFC 9000, Abschnitte 2.4 und 5.3) und in der Notwendigkeit, bewegliche Teile aktiv beweglich zu halten.

Teil 9: Wo wir 2026 stehen

Die Standardisierung ist abgeschlossen: RFC 9000 (Transport), RFC 9001 (TLS), RFC 9002 (Verlusterkennung und Congestion Control) seit Mai 2021, RFC 9114 (HTTP/3) seit Juni 2022.

Zur Verbreitung gibt es keine peer-reviewte Quelle, die 2026 aktuell wäre. Die kommerzielle Erhebung von W3Techs weist für Oktober 2026 aus, dass HTTP/3 von 41,1 % aller Websites verwendet wird (abgerufen am 27.10.2026). Diese Zahl ist mit Vorsicht zu lesen: W3Techs ist eine kommerzielle Marktforschungserhebung mit eigener Stichprobenlogik, keine wissenschaftliche Messstudie, und „verwendet von einer Website" ist nicht dasselbe wie „trägt Verkehrsanteil X".

Was man seriös sagen kann: QUIC ist von einem Google-Experiment zu einem standardisierten, breit implementierten Transport geworden, dessen Vorteile sich dort materialisieren, wo Handshake-Runden und Verlust dominieren – und dessen Nachteile sich dort zeigen, wo der Empfängerpfad der Flaschenhals ist.

Die zentrale Erkenntnis zum Mitnehmen

1. Head-of-Line-Blocking verschwindet nicht, es wird herabgestuft. RFC 9000 verspricht keine Blockierungsfreiheit; es stellt in Abschnitt 2 lediglich fest, dass es keine Ordnungsgarantie zwischen Streams gibt. Innerhalb eines Streams blockiert Verlust weiter. Konsequenz für den Entwurf: Ein einzelner großer Download profitiert strukturell wenig – der Handshake-Gewinn bleibt, der Multiplexing-Gewinn entfällt, weil es dort keine unabhängigen Streams gibt, zwischen denen eine Ordnung entfallen könnte. Ich bin der Meinung, dass der Gewinn mit der Anzahl unabhängiger Ressourcen steigen kann – belegt ist das durch keine der hier geprüften Quellen; und RFC 9114 nennt in Abschnitt 4.2.1 die Header-Kompression selbst als möglichen Verursacher von Head-of-Line-Blocking. Die Entkopplung reicht also nicht bis in die Anwendungsschicht.

2. Die belegten Gewinne liegen bei Handshake-Runden und Verlustrobustheit, nicht beim Durchsatz. Googles Messung – erhoben an Prä-IETF-QUIC und damit auf heutiges HTTP/3 nur extrapolierbar – zeigt im Mittel 8,0 % (Desktop) bzw. 3,6 % (Mobil) weniger Search-Latenz und 18,0 % bzw. 15,3 % weniger Rebuffering, getragen vor allem davon, dass etwa 88 % der Handshakes 0-RTT waren. Auf einer schnellen, verlustfreien Leitung bleibt davon wenig – das sagen beide Papiere, Google 2017 für über 100 Mbit/s und Zhang et al. 2024 messbar oberhalb von etwa 500 Mbit/s im Browser (Chrome) bzw. etwa 600 Mbit/s bei schlanken Clients.

3. Praktischer Handlungsanstoß: Schalte HTTP/3 dort ein, wo die Pfadbedingungen schlecht sind, und messe dort, wo es weh tut. Für eine Anwendung mit mobilen Nutzern, hoher RTT oder Verlust ist HTTP/3 die naheliegende Wahl – und zwar zusätzlich zu HTTP/2, nicht statt dessen, denn in Googles Messung vom November 2016 konnten 4,4 % der Video-Clients Googles QUIC-Variante überhaupt nicht nutzen; eine vergleichbar belastbare aktuelle Zahl für HTTP/3 liegt nicht vor, weshalb HTTP/2 als Rückfallpfad bestehen sollte. Für interne Dienst-zu-Dienst-Kommunikation im Rechenzentrum, mit niedriger RTT und hoher Bandbreite, ist der Gewinn bestenfalls null und möglicherweise negativ. Und messe nicht den Mittelwert: Zhang et al. finden im Mittel 3,0 % längere Seitenladezeiten, im Tail bis zu 74,9 %.

4. Behandle 0-RTT als Sicherheitsentscheidung, nicht als Performance-Schalter. RFC 9001 Abschnitt 2.1 ist unmissverständlich: 0-RTT-Daten können von einem Angreifer wiederholt eingespielt werden. Idempotente Anfragen ja, zustandsändernde nein.

5. Rechne den CPU-Preis mit ein – aber als implementierungsabhängige Größe, nicht als Naturkonstante. Googles Zahl von 2017 (nach Optimierung etwa doppelte Server-CPU-Last gegenüber TLS/TCP) stammt von einem Stack, der nach eigener Aussage zunächst nicht auf CPU-Effizienz hin geschrieben war. Sie taugt als Anhaltspunkt für die Größenordnung, nicht als Preisschild für das Architekturmuster.

Die Reflexionsfrage

QUIC hat die Versteinerung besiegt, indem es sich unlesbar gemacht hat. Das heißt auch: Netzbetreiber, Unternehmens-Firewalls und Schulfilter sehen weniger als vorher, und Diagnose im Netz wird schwerer – aus demselben Grund, aus dem Manipulation schwerer wird.

Wo ziehst du in deiner eigenen Architektur die Grenze zwischen Entwicklungsfähigkeit durch Unlesbarkeit und Betreibbarkeit durch Einsehbarkeit? Und bei welcher Komponente deines Systems hast du diese Entscheidung bisher nicht getroffen, sondern geerbt?

Faktenprüfung

Dieser Artikel wurde nach dem Entwurf einer strukturierten Prüfung in zwei Runden unterzogen: zuerst der vollständige Entwurf, danach noch einmal alle geänderten Passagen. Aus dem Entwurf wurden 154 prüfbare Aussagen extrahiert (88 harte Fakten, 16 Zitate, 24 Quellenzuschreibungen, 26 Synthese-Aussagen) und gegen die Primärquellen geprüft. 123 Aussagen blieben unverändert bestätigt, 31 wurden korrigiert – davon 3 als falsch, 24 als zu stark formuliert und 4 als nicht prüfbar.

Die drei wichtigsten Korrekturen:

1. Falsche Ursachenzuschreibung bei den CPU-Kosten. Der Entwurf schrieb QUICs höhere Server-CPU-Last der Verlagerung in den User Space zu. Das Google-Papier nennt in Abschnitt 6.7 stattdessen Kryptographie, UDP-Paketverarbeitung und Zustandshaltung und räumt ein, die Implementierung sei zunächst nicht auf CPU-Effizienz hin geschrieben worden. Die Deutung ist jetzt als eigene Einschätzung gekennzeichnet.
2. Falsche Aussage zur Unlesbarkeit. Der Entwurf behauptete, nach Header Protection gebe es „praktisch keine stabilen Felder", an denen sich ein Klassifikator festmachen könne. RFC 8999 legt Header-Form-Bit, Versionsfeld und Connection IDs ausdrücklich als versionsunabhängig stabil fest – und der Artikel belegte zwei Abschnitte später selbst, dass ein Klassifikator daran hängen kann.
3. Vertauschte und zu weit gefasste Messwerte. Die 45,2 % aus dem Papier von 2024 gelten für Chrome bei 1 Gbit/s, nicht für QUIC allgemein; schlanke Clients verloren im selben Aufbau nur 7–16 %. Zusätzlich waren die Bandbreitenschwellen vertauscht (etwa 500 Mbit/s für Chrome, etwa 600 Mbit/s für die Kommandozeilen-Clients).

Die zweite Runde fand sechs weitere Stellen, darunter ein Fehlzitat: RFC 9000 Abschnitt 5.1.2 formuliert die Beschränkung einer Connection ID auf ein Adresspaar als gegebenes Verhalten, nicht als „notwendig", wie der korrigierte Entwurf behauptet hatte.

Nicht prüfbar blieben vier Punkte: die Auflösung der DOIs über dl.acm.org (liefert 4xx); die Ergebnisse des NOMS-2026-Beitrags zum Kernel-Bypass (belegt sind nur Titel, Autoren und Venue); die Frage, ob der Begriff „head-of-line blocking" in RFC 9000 hinter Abschnitt 8.2 vorkommt (der abrufbare Volltext bricht dort ab – bis dahin kommt er nicht vor); und aus demselben Grund, ob RFC 9000 Abschnitt 9.5 die Beschränkung der Connection ID als „necessary" formuliert.

Automatisierte KI-Prüfung gegen Primärquellen; keine menschliche Fachprüfung.

Querverweise im Vault

• Der lange Schwanz der Latenz: Tail Latency und warum Mittelwerte in der Cloud lügen – die methodische Grundlage für Punkt 3 der Erkenntnis: Zhang et al. finden im Mittel 3,0 %, im Tail 74,9 %. Genau dieser Abstand ist das Thema.
• Der programmierbare Kern: eBPF und die Sandbox im Herzen des Betriebssystems – die Gegenbewegung: QUIC verlässt den Kernel, eBPF bringt Programmierbarkeit in den Kernel. Zwei Antworten auf dieselbe Frage.
• Der Schlüssel, der nach jeder Nachricht stirbt: Das Signal-Protokoll, die Double Ratchet und die Kunst der Ende-zu-Ende-Verschlüsselung – Schlüsselwechsel und Vorwärtsgeheimnis; QUIC hat sein eigenes Key-Update-Verfahren statt TLS-KeyUpdate.
• Das Ende des Passworts: Passkeys, WebAuthn und die Anatomie phishing-resistenter Anmeldung – ein zweiter Fall, in dem ein Standard sich ausdrücklich gegen Replay absichern muss.
• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – die nächste Migration, die genau durch diesen TLS-1.3-Handshake muss.
• Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas – derselbe Mustertausch: Isolation und Beweglichkeit gegen Effizienz pro Zyklus.

Quellen und zum Weiterlesen

1. J. Iyengar, M. Thomson (Hrsg.), „QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, IETF, Mai 2021 (Standards Track). https://www.rfc-editor.org/rfc/rfc9000.html – Kernspezifikation: Streams, Flusskontrolle, Connection IDs, Migration (nur Clients), ausdrückliche Nicht-Ziele (keine Priorisierung, keine API, Versionsverhandlung offen).
2. M. Thomson, S. Turner (Hrsg.), „Using TLS to Secure QUIC", RFC 9001, IETF, Mai 2021. https://www.rfc-editor.org/rfc/rfc9001.html – TLS 1.3 als Pflicht, CRYPTO-Frames statt TLS-Records, Header Protection, Replay-Warnung zu 0-RTT.
3. J. Iyengar, I. Swett (Hrsg.), „QUIC Loss Detection and Congestion Control", RFC 9002, IETF, Mai 2021. https://www.rfc-editor.org/rfc/rfc9002.html – monotone Paketnummern, getrennte Paketnummernräume, kein Reneging, NewReno als Referenz.
4. M. Bishop (Hrsg.), „HTTP/3", RFC 9114, IETF, Juni 2022. https://www.rfc-editor.org/rfc/rfc9114.html – ein Stream pro Anfrage-Antwort-Paar, QPACK statt HPACK, ALPN-Token h3.
5. A. Langley et al. (21 Autoren), „The QUIC Transport Protocol: Design and Internet-Scale Deployment", SIGCOMM '17, Los Angeles, August 2017. https://doi.org/10.1145/3098822.3098842 – die große Feldmessung (Prä-IETF-QUIC): 8,0 %/3,6 % Search-Latenz, 18,0 %/15,3 % Rebuffering, 88 % 0-RTT, CPU 3,5× → ~2×, und die eigene Einschränkung in Abschnitt 6.8.
6. M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, H. Tokuda, „Is it Still Possible to Extend TCP?", ACM IMC '11, Berlin, November 2011. Volltext geprüft über https://www.cl.cam.ac.uk/teaching/2021/CompNet/files/honda2011still.pdf – 142 Zugangsnetze in 24 Ländern; die Messung, auf der das Ossifikationsargument beruht – mit dem oft übersehenen Fazit „erweiterbar, aber stark eingeschränkt".
7. X. Zhang, S. Jin, Y. He, A. Hassan, Z. M. Mao, F. Qian, Z.-L. Zhang, „QUIC is not Quick Enough over Fast Internet", WWW '24, Singapur, Mai 2024. https://doi.org/10.1145/3589334.3645323 (Preprint: https://arxiv.org/abs/2310.09423) – bis zu 45,2 % Datenratenreduktion oberhalb der Bandbreitenschwelle; Ursache empfängerseitig.
8. W3Techs, „Usage Statistics of HTTP/3 for Websites", Oktober 2026. https://w3techs.com/technologies/details/ce-http3 – 41,1 % aller Websites (abgerufen 27.10.2026). Kommerzielle Erhebung, nicht peer-reviewt.
9. M. Thomson, „Version-Independent Properties of QUIC", RFC 8999, IETF, Mai 2021. https://www.rfc-editor.org/rfc/rfc8999.html – die Eigenschaften, die über QUIC-Versionen hinweg stabil und damit für das Netz erkennbar bleiben: Header-Form-Bit, Versionsfeld (nur Long Header), Connection IDs.
10. Lehrstuhl für Netzarchitekturen und Netzdienste, TU München, Publikationsliste. https://net.cit.tum.de/publications/ – belegt Titel, Autoren und Venue von „Kernel Bypass Surgery: A Viable Procedure for Maximizing QUIC Bandwidth?" (NOMS 2026). Die Ergebnisse des Beitrags sind in diesem Lauf nicht geprüft worden.

← All articles