Revision 709: HTTP/3 und WebTransport, mit Max Inden

Diese Woche ist Max Inden (Mastodon) von Mozilla zu Gast. Mit ihm sprechen wir über den Networking-Stack von Firefox und arbeiten uns dabei von HTTP/1 über HTTP/2 bis zu HTTP/3 und QUIC vor. Ausgangspunkt ist die Frage, warum es nach den Versprechen von HTTP/2 überhaupt noch eine weitere HTTP-Version brauchte und welche praktischen Probleme im echten Netz dabei eine Rolle spielen.

Unser Sponsor

Im Webcafé, dem Podcast zu Webentwicklung, Webdesign und Unternehmenskultur, nehmen euch Felix und Kay mit auf eine spannende Reise durch die Welt moderner Softwareentwicklung. Gerade ihre unterschiedliche Perspektive macht dabei den Reiz aus: Felix schaut als Geschäftsführer der Geenen IT-Systeme GmbH auf Strategie, Führung und Unternehmensentwicklung, Kay bringt als Technical Lead den Blick auf Technik, Tools und Architektur ein. Genau daraus entstehen ehrliche, fundierte und persönliche Gespräche über Webtechnologien, Zusammenarbeit und die Herausforderungen digitaler Arbeit.

Jetzt reinhören: geenen-it-systeme.de

Dabei geht es nicht nur um schnellere Verbindungen, sondern auch um Dinge wie Head-of-Line-Blocking, Connection-Setup, Congestion Control, Connection Migration sowie um angrenzende Themen wie verschlüsseltes DNS, Encrypted Client Hello und WebTransport. Die Folge bleibt dabei bewusst nah an den Grundlagen und erklärt, warum viele Eigenschaften des heutigen Web-Stack genau so aussehen, wie sie aussehen.

Shownotes

[00:00:56] HTTP/3 und WebTransport Max stellt zunächst seinen Hintergrund als Networking-Ingenieur bei Mozilla vor und beschreibt seine Arbeit am Firefox-Netzwerkstack mit Fokus auf QUIC, HTTP/3 und verwandte Technologien. Ausgangspunkt der Diskussion ist die Entwicklung von HTTP: Während HTTP/1 durch parallele TCP-Verbindungen und deren Limitierungen geprägt war, brachte HTTP/2 mit Multiplexing, Header-Compression und Server Push deutliche Verbesserungen. In der Praxis zeigten sich jedoch neue Probleme, insbesondere durch die Abhängigkeit von TCP.

Ein zentrales Thema ist das sogenannte Head-of-Line-Blocking: Wenn auf TCP-Ebene ein Paket verloren geht, blockiert dies potenziell alle nachfolgenden Daten – selbst wenn diese eigentlich unabhängig wären. Dadurch entstehen Latenzen, die besonders im Web-Kontext mit vielen kleinen Requests spürbar sind. Auch der Verbindungsaufbau ist ein Thema: Zwischen TCP-Handshake, TLS-Handshake und dem eigentlichen Request vergehen mehrere Roundtrips, was sich summiert.

QUIC setzt genau hier an und wird als neues Transportprotokoll über UDP realisiert. Es übernimmt die Vorteile von TCP wie Zuverlässigkeit und Congestion Control, erlaubt aber gleichzeitig mehrere unabhängige Streams ohne transportseitiges Head-of-Line-Blocking. Zusätzlich führt QUIC Datagrams ein, also bewusst unzuverlässige, unabhängige Nachrichten, die sich besonders für latenzkritische Anwendungsfälle wie Echtzeitkommunikation eignen.

Ein weiterer Vorteil ist der reduzierte Verbindungsaufbau: QUIC kombiniert Transport- und Sicherhei