TCP war zu kaputt, um repariert zu werden, also baute das Internet ein neues Protokoll auf UDP auf

TCP ist seit 1974 die Transportschicht des Internets. Jede Webseite, die Sie laden, jede API-Anfrage, die Ihre App stellt, jede E-Mail, die Sie senden – seit fünfzig Jahren reist fast alles über TCP. Das Protokoll ist zuverlässig, kampferprobt und auf jedem vernetzten Gerät der Erde installiert. Es wird zunehmend zu einem Engpass für die Art und Weise, wie das moderne Web tatsächlich funktioniert, und es zu reparieren erwies sich als politisch unmöglich. Also baute die Industrie stattdessen etwas Neues auf UDP auf.

Dieses Neue ist QUIC, das 2021 von der IETF als RFC 9000 standardisiert wurde. HTTP/3, die neueste Version des Protokolls, das das Web antreibt, läuft auf QUIC. Cloudflare hat HTTP/3 an über 40 % seines Traffics ausgeliefert. Google hat QUIC seit 2013 in seinen eigenen Diensten eingesetzt. Das Protokoll, das ein Experiment sein sollte, transportiert jetzt einen erheblichen Teil des Internets.

Was mit TCP nicht stimmte

Das grundlegende Design von TCP wurde für eine Welt fester, zuverlässiger kabelgebundener Verbindungen entwickelt. Das Protokoll geht davon aus, dass das Netz überlastet ist, wenn ein Paket verloren geht, und es verlangsamen muss. Das war 1974 vernünftig. Im Jahr 2026, wenn Mobilnutzer ständig zwischen WLAN und Mobilfunk wechseln, werden Pakete aus Gründen verworfen, die nichts mit Überlastung zu tun haben – Signalstörungen, Übergaben zwischen Funkmasten, kurze Abdeckungslücken. TCP kann nicht zwischen „Das Netz ist überlastet“ und „Der Benutzer hat gerade einen Aufzug betreten“ unterscheiden und verlangsamt sich in beiden Fällen.

Das größere strukturelle Problem ist das Head-of-Line-Blocking. Eine einzelne TCP-Verbindung ist ein geordneter Datenstrom. Wenn Paket 7 verloren geht, warten Pakete 8 bis 100 alle, obwohl sie korrekt angekommen sind. HTTP/2 hat eine Version dieses Problems behoben, indem es mehrere Anfragen über eine einzige TCP-Verbindung multiplexte – aber das verschlimmerte das Head-of-Line-Blocking auf der TCP-Ebene tatsächlich, anstatt es zu verbessern. Ein einzelnes verlorenes Paket kann jetzt alle gemultiplexten Ströme auf der Verbindung gleichzeitig anhalten.

Es gab auch den Overhead beim Verbindungsaufbau. TCP erfordert einen Drei-Wege-Handshake, bevor Daten fließen können. TLS fügt 1-2 weitere Roundtrips für die kryptografische Aushandlung hinzu. Das Laden einer Ressource von einem neuen Server erfordert 2-3 vollständige Roundtrips, bevor das erste Byte des Inhalts ankommt. Für einen Benutzer in Tokio, der eine Verbindung zu einem Server in Virginia herstellt, dauert jeder Roundtrip etwa 170 Millisekunden. Multiplizieren Sie das mit der Anzahl der verschiedenen Server, mit denen eine moderne Webseite spricht, und der Latenz-Overhead ist erheblich.

Warum sie es auf UDP aufbauten

Die logische Frage ist: Warum TCP nicht reparieren? Die Antwort ist, dass TCP im Kernel jedes Betriebssystems, jedes Routers, jeder Firewall, jedes Load Balancers und jeder Middlebox im Internet implementiert ist. Das Verhalten von TCP zu ändern, würde Updates für Milliarden von Geräten erfordern. Einige dieser Geräte sind Jahrzehnte alt und werden nie aktualisiert. Netzwerk-Middleboxen – die Geräte, die Traffic inspizieren, routen und filtern – gehen von TCP-Verhalten aus und brechen auf unvorhersehbare Weise, wenn TCP modifiziert wird. Die IETF hat im Laufe der Jahre mehrere TCP-Erweiterungen ausprobiert und festgestellt, dass sie von Middleboxen im Feld einfach blockiert oder entfernt wurden.

UDP hingegen ist im Wesentlichen eine leere Leinwand. Es ist ein Fire-and-Forget-Protokoll ohne inhärenten Verbindungszustand, Reihenfolge oder Zuverlässigkeit. Middleboxen pfuschen nicht so an UDP herum wie an TCP, weil es nichts zu pfuschen gibt. QUIC auf UDP aufzubauen bedeutet, dass QUIC seine eigene Verbindungsverwaltung, Zuverlässigkeit, Reihenfolge und Überlastungssteuerung im Userspace implementieren kann – wo es ohne Kernel-Änderungen aktualisiert werden kann – während es dennoch unverändert durch die bestehende Internet-Infrastruktur gelangt.

Was QUIC tatsächlich ändert

Die am unmittelbarsten spürbare Verbesserung ist die Verbindungsaufbauzeit. QUIC kombiniert den Transport-Handshake und den kryptografischen TLS-1.3-Handshake in einem einzigen Roundtrip. Für eine erste Verbindung zu einem Server benötigt QUIC einen Roundtrip, bevor Daten fließen können, gegenüber zwei oder drei für TCP+TLS. Für einen wiederkehrenden Benutzer, der zuvor eine Verbindung zum Server hergestellt hat, unterstützt QUIC die 0-RTT-Wiederaufnahme – der Client kann mit dem allerersten Paket Anwendungsdaten senden, mit null Roundtrips. Die Leistungsverbesserung ist am stärksten in Mobilfunknetzen mit hoher Latenz ausgeprägt.

Verbindungsmigration (Connection migration) löst das Problem des Mobilfunk-Handoffs direkt. Eine QUIC-Verbindung wird durch eine vom Endpunkt gewählte Verbindungs-ID identifiziert, nicht durch das 4-Tupel (Quell-IP, Quell-Port, Ziel-IP, Ziel-Port), das eine TCP-Verbindung identifiziert. Wenn ein Telefon von WLAN auf Mobilfunk umschaltet und eine neue IP-Adresse erhält, brechen alle TCP-Verbindungen ab und müssen neu aufgebaut werden. QUIC-Verbindungen überleben den IP-Wechsel – der Client gibt seine neue Adresse bekannt und die Verbindung wird ohne Unterbrechung fortgesetzt.

Gemultiplexte Ströme ohne Head-of-Line-Blocking ist die strukturelle Lösung, die HTTP/2 benötigte, aber über TCP nicht erreichen konnte. QUIC implementiert mehrere unabhängige Ströme innerhalb einer Verbindung; ein verlorenes Paket für Strom A blockiert nicht die Ströme B, C und D. Jeder Strom hat seine eigene Reihenfolgegarantie, sodass ein Verlust in einem Strom nur diesen Strom anhält.

Die Realität der Bereitstellung

Die Akzeptanz war schneller als bei den meisten Protokollübergängen in der Internetgeschichte, die immer noch „in Jahren gemessen“ wird. Google hat QUIC 2015 in Chrome implementiert, zunächst nur für die eigenen Dienste. Die IETF standardisierte QUIC und HTTP/3 im Jahr 2021. Bis 2023 zeigten W3Techs-Daten, dass HTTP/3 auf etwa 30 % der Websites unterstützt wurde. Cloudflare berichtet, dass QUIC etwa 35-40 % seines Traffics transportiert, und dieser Anteil ist Jahr für Jahr stetig gewachsen.

Die serverseitige Akzeptanz ist bei den großen CDNs (Cloudflare, Fastly, Akamai) und Cloud-Anbietern (AWS CloudFront, Google Cloud) stark. Die meisten modernen Web-Frameworks und Load Balancer unterstützen HTTP/3. Die Client-Seite ist abgedeckt: Chrome, Firefox, Safari und Edge unterstützen HTTP/3 standardmäßig, ebenso wie mobile Browser.

Nicht jede QUIC-Verbindung ist besser als TCP. Bei hochwertigen festen Breitbandverbindungen ist der Unterschied minimal. Die Userspace-Implementierung von QUIC bedeutet, dass es nicht von den CPU-Optimierungen profitiert, die TCP über Jahrzehnte im Kernel angesammelt hat – der Overhead pro Paket ist höher, was bei Hochdurchsatzverbindungen wichtig ist. Für Bulk-Dateiübertragungen über schnelle, zuverlässige Leitungen ist TCP immer noch konkurrenzfähig.

Die Gewinne sind in drei Szenarien am deutlichsten: mobile Netzwerke mit hoher Latenz, Verbindungen, die IP-Adressänderungen überstehen, und Seitenladevorgänge mit vielen kleinen Anfragen an viele Server. Das Web im Jahr 2026 ist stark auf alle drei Szenarien ausgerichtet, weshalb die Migration nachhaltige Dynamik hat, die frühere HTTP-Versionen nicht erreicht haben.

QUIC löst nicht jedes Problem des Internet-Transports – Überlastungssteuerung, Bufferbloat und Letzte-Meile-Kapazität bleiben echte Einschränkungen. Aber es löst die Probleme, die reparierbar waren, ohne die physische Netzwerkinfrastruktur zu ersetzen. Das ist eine bedeutende Verbesserung, die über eine der schnellsten Protokollbereitstellungen in der Geschichte der IETF geliefert wurde.