Wer nicht gerade als Admin mit der Optimierung von Webservern beschäftigt ist, dürfte kaum zufällig über HTTP/3 stolpern. Und wer doch versucht, sich in das Thema einzulesen, trifft erst einmal auf eine verwirrende Anzahl von Akronymen und Bezeichnungen wie qQUIC, iQUIC, HTTP-over-QUIC oder HTTP/QUIC, die nicht gerade selbsterklärend sind. Was sich hinter dieser Armada von Abkürzungen versteckt, was sie verbindet und wie es mit HTTP weitergeht, darum geht es in diesem Artikel.

Das Hypertext Transfer Protocol, kurz HTTP, gehört neben dem URL und HTML zu den drei Grundpfeilern des World Wide Web. Und natürlich gibt es auch für das HTTP verschiedene Entwicklungsstufen, die sich an der Versionierung ablesen lassen. Allerdings hat sich hier, im Gegenteil zum halbwegs gut gepflegten HTML-Standard, in den letzten Jahren relativ wenig getan. Das 1999 vorgestellte HTTP/1.1 wird heute noch von der überwiegenden Mehrheit von Webseiten eingesetzt. Der nun schon fast vier Jahre alte Nachfolger HTTP/2 verspricht zwar enorme Geschwindigkeitsvorteile, bringt es aber trotzdem nur auf eine Verbreitung von knapp 34 Prozent.

Die aktuelle Protokollversion HTTP/2 ist also kaum bekannt, geschweige denn verbreitet – da steht schon der Nachfolger vor der Tür: HTTP/3. Die dritte Version soll einige radikale Änderungen mitbringen.

Eine Vier-Klassen-Gesellschaft, oder: das Schichtenmodell

Der Hauptgrund für die neue Protokollversion beruht auf einer technologischen Neuerung. Genau genommen soll das altgediente TCP durch das neue Transportprotokoll QUIC ersetzt werden. Das ist auch der Grund dafür, warum man in diesem Zusammenhang von HTTP-over-QUIC, HTTP/QUIC oder Ähnlichem spricht. Um die Technologie und den Einsatz von QUIC besser verstehen zu können, ist es hilfreich, sich in das erste Informatiksemester zurückzuversetzen und noch einmal das TCP/IP-Schichtenmodell anzuschauen (Abb. 1).

Um die elektronischen Signale aus dem Netzwerkkabel als Webseite darstellen zu können, durchlaufen diese vier Schichten. Im etwas ausführlicheren OSI-Schichtenmodell sind es derer sieben, für unsere Zwecke reicht aber die vereinfachte Betrachtung mit vier Schichten völlig aus. Jede Schicht wird dabei durch ein bestimmtes Protokoll repräsentiert, das die Signale bzw. Daten der benachbarten Schicht annimmt, verarbeitet und an die nächste Schicht weitergibt.

Angefangen bei der reinen physikalischen Übertragung von Signalen über die Qualitätssicherung bis hin zur Darstellung in einer Anwendung, etwa dem Browser, kommt jeder Ebene so eine eigene Bedeutung zu. HTTP ist ein Protokoll der letzten Schicht, der Anwendungsschicht. Es ist nicht nur zur Übertragung der Hypertext Markup Language (HTML) gedacht, sondern auch von z. B. Audio, Video und Bildern. Findet eine Verschlüsselung statt, wird dazu zwischen der vierten und fünften Schicht Transport Layer Security (TLS) genutzt. Auf der Transportschicht wird das nun schon ziemlich in die Jahre gekommene TCP (Transmission Control Protocol) eingesetzt. Ein alternatives und durchaus schnelleres Transportprotokoll ist UDP (User Datagram Protocol). Da über UDP aber nicht sichergestellt werden kann, dass alle Datenpakete übertragen werden, kam es bisher nicht als Transportprotokoll für HTTP infrage.

Bei der Videoübertragung fällt es kaum auf, wenn bei einem von 24 Bildern pro Sekunde einige Informationen fehlen. Eine HTML-Datei ist aber nahezu unbrauchbar bei nur einer nicht übermittelten Klammer eines HTML-Tags.

Es war einmal…

Da jede gute Informatikvorlesung auch einen geschichtlichen Ausflug beinhaltet, soll an dieser Stelle auch die Entwicklung von HTTP kurz angerissen werden (Abb. 2). Erstmals erwähnt wurde HTTP von Tim Berners-Lee im Sommer 1991. Sein Konzept für das WWW bestand aus den drei Komponenten HTML, Uniform Resource Locator (damals noch Universal Document Identifier, UDI) und eben HTTP. HTTP war zu der Zeit noch ein sehr einfach aufgebautes, textbasiertes Protokoll, das für jede Übertragung eine eigene TCP-Verbindung benötigte. Die Anfrage war ein Einzeiler, die Antwort vom Server enthielt lediglich die gewünschte Ressource.

HTTP wuchs in den nächsten Jahren an seinen Aufgaben und wurde von vielen Seiten, mehr oder weniger unorganisiert, mit neuen Funktionen ausgestattet. Fünf Jahre später, im Sommer 1996, fasste die Internet Engineering Task Force (IETF) die gängigsten Funktionen zusammen und beschrieb HTTP/1 in dem Memo RFC1945. Man legte allerdings Wert darauf, dass es sich dabei nicht um einen Standard handele: „This memo does not specify an Internet standard of any kind“, hieß es damals ganz lapidar.

Die Arbeit an einem offiziellen Standard begann ein Jahr vor dem besagten Memo, zunächst unter dem Namen HTTP/NG (NG für Next Generation). 1997 wurde daraus kraft RFC2068 die Version HTTP/1.1, die nun auch als „echter“ Standard eingeführt wurde.

Die wichtigsten Änderungen waren die keepalive-Funktion, die erstmals persistente Verbindungen erlaubte. Es war nun möglich, eine offene TCP-Verbindung für mehr als nur eine Datenübertragung zu nutzen. Außerdem unterstützte das Protokoll erstmals auch das Senden von Daten zum Server (PUT-Methode). Mit dem Pipelining gab es theoretisch auch die Möglichkeit, Anfragen abzusetzen, ohne auf die Antwort warten zu müssen – eine Funktion, die damals nur von wenigen Browser unterstützt wurde.

Danach wurde es eine ganze Weile ruhig um HTTP. Erst 2012 folgte ein Entwurf für HTTP/2, der im Wesentlichen auf SPDY basierte, einem alternativen Protokoll, an dem Google seit 2009 arbeitete. Der HTTP/2-Standard wurde 2015 offiziell vorgestellt. Die wichtigsten Änderungen: Mit Multiplexing wurde ein verbesserter asynchroner Datenaustausch ermöglicht. Außerdem handelte es sich erstmals um ein binäres Protokoll. Die Daten werden also nicht mehr im Klartext übertragen (Kasten: „Transitory, Persistent, Pipelining und Multiplexing“, Abb. 3).

Das Akronympotpourri – der Weg zu HTTP/3

QUIC (Quick UDP Internet Connections) ist ein Protokoll, das Google erstmals 2012 vorgestellt hat. Seitdem wurde QUIC in viele Google-Produkte implementiert, server- sowie clientseitig. 2016 gründete das IETF eine Arbeitsgruppe, die sich mit der Standardisierung dieser neuen Google-Technologie auseinandersetzen sollte, um sie für HTTP nutzbar zu machen. Man übernahm zwar kurzerhand den Namen QUIC, bestand aber darauf, dass es sich nicht um eine Abkürzung handele: „QUIC is a name, not an acronym“.

Um den Fork besser unterscheiden zu können, nannte man die Entwicklung aus Kalifornien qQUIC und wählte iQUIC für den geplanten IETF-Standard. Natürlich musste auch das darüber liegende HTTP für die Nutzung von QUIC angepasst werden. Der Arbeitstitel für dieses Vorhaben war zunächst HTTP-over-QUIC oder HTTP/QUIC. Ende 2018 verkündete man dann offiziell, dass man damit an nichts Geringerem arbeitete als an der neuesten Version des Protokolls: HTTP/3.

Das Beste aus zwei Welten und mehr

TCP war dem WWW lange Zeit ein treuer Diener, ist den modernen Anforderungen aber bei Weitem nicht mehr gewachsen. Das Protokoll erfordert nicht nur eine festgelegte Sendereihenfolge, sondern auch eine Empfangsbestätigung für gesendete Daten. Dadurch ist das Protokoll zuverlässig, aber auch langsam. UDP ist schneller, aber weniger zuverlässig. Das Protokoll prüft die Integrität der Daten, ergreift aber bei Fehlern oder Datenverlust keine korrigierenden Maßnahmen.

Mit HTTP/2 und einer Vielzahl neuer Funktionen versuchte man, die Vorteile beider Protokolle zu kombinieren, ohne jedoch die Abhängigkeit von TCP zu lösen. Ein Problem, das aber trotz HTTP/2 und Multiplexing weiter auftrat, ist das Head-of-Line Blocking auf TCP-Ebene. Geht bei der TCP-Übertragung ein Paket verloren, müssen alle nachfolgenden Pakete auf die neue Übertragung des Paketes warten. QUIC hingegen ermöglicht nun echtes Multiplexing: Anfragen können asynchron abgesetzt werden, die Reihenfolge der Antworten spielt keine Rolle, verlorene Pakete halten die Warteschlange nicht mehr auf (Abb. 4).

Gleiches gilt für die persistenten Verbindungen, die bereits in HTTP/2 dafür sorgen sollten, die Anzahl benötigter TCP-Verbindungen zu reduzieren. Ändert sich jedoch das Netzwerk, z. B. wenn man mit dem Smartphone aus dem WLAN in das mobile Netz wechselt, verliert man die TCP-Verbindung. Anders als die Identifikation von TCP-Verbindungen, basierend auf den IP-Adressen und Ports auf Sender- und Empfängerseite, werden QUIC-Verbindungen mit einer eindeutigen 64-Bit-Kennung versehen. Diese wird netzwerkübergreifend erhalten und ermöglicht somit echte persistente Verbindungen.

Eine weitere Verbesserung betrifft die Verschlüsselung der Kommunikation. Bisher fungierte Transport Layer Security (TLS) als zusätzliche Schicht zwischen HTTP und TCP. Die Verwendung von TLS ist aber nicht verbindlich vorgeschrieben, auch nicht im HTTP/2-Standard. Vielmehr haben die gängigen Browser eine verschlüsselte Verbindung für HTTP/2 vorausgesetzt, sozusagen als Quasistandard. QUIC geht hier einen radikaleren Weg und implementiert die Verschlüsselung gleich direkt. Die TLS-Zwischenschicht entfällt also, QUIC übernimmt die Verschlüsselung und Authentifizierung der Verbindung. Das wirkt sich zusätzlich positiv auf die Performance aus. Doch damit nicht genug: TLS verschlüsselt nur die Payload, die Metadaten der Verbindung sind im Klartext lesbar. QUIC hingegen verschlüsselt auch die Verbindungsmetadaten, was zusätzliche Sicherheit bietet.

QUIC in der freien Wildbahn

Wer sich jetzt schon ein Bild von dem technologischen Vorbild qQUIC machen will, kann einen der zahlreichen Google-Dienste nutzen. In der Entwicklerkonsole des Browsers Chrome zeigt der Netzwerktab das verwendete Protokoll an, wenn man die entsprechende Spalte vorher über das Kontextmenü aktiviert hat (Abb. 5). Über die offizielle Webseite von Googles QUIC gelangt man außerdem zu einer ausführlichen Dokumentation sowie einigen Codebeispielen.

Auch das Netzwerkdiagnoseprogramm Wireshark ist in der Lage, die binären QUIC-Daten anzuzeigen und unterscheidet dabei sogar zwischen gQUIC und iQUIC. Um den qQUIC-Verkehr im Klartext zu sehen, muss in den Einstellungen des Protokolls GQUIC [sic] das Häkchen bei Force decode of all (Google) QUIC Payload aktiviert werden. Dabei wird der Inhalt freilich nur soweit entschlüsselt, wie es das Protokoll zulässt. Eine Suchanfrage lässt sich nicht im Klartext darstellen. Der Schnellfilter für das Protokoll lautet gquic. Um sich z. B. die initiale gQUIC-Anfrage anzeigen zu lassen, nutzt man den Schnellfilter gquic.tag == CHLO. Abbildung 6 zeigt einen Auszug der Daten, die gQUIC, hier in der Version Q043, unverschlüsselt übermittelt.

Daneben gibt es eine Vielzahl experimenteller aber auch kommerzieller Implementierungen von QUIC. So bietet die kommerzielle Serversoftware LiteSpeed QUIC-Support an. Für nginx gibt es ein experimentelles QUIC-Modul, ebenso für Caddy. Caddy nutzt eine Implementierung in Go, die sich an gQUIC sowie iQUIC orientiert. Eine offizielle Liste aller QUIC-Implementierungen findet sich auf GitHub unter.

Bei den Browsern gibt es natürlich Chrome, der das hauseigene gQUIC bereits seit 2012 unterstützt. Grundsätzlich ist jeder Browser für QUIC vorbereitet, wenn er die Render-Engine Chromium ab mindestens Version 29 einsetzt – wie es z. B. Opera seit 2013 tut. In Opera muss QUIC gegebenenfalls manuell über die Einstellungsseite opera:flags aktiviert werden.

Ausblick

Der eigentliche Star hinter der nächsten HTTP-Evolutionsstufe ist QUIC. Das neue Transportprotokoll soll das altehrwürdige TCP mit dem Ziel ablösen, Geschwindigkeit, Mobilität und Sicherheit zu steigern und wird so auch die Versprechen von HTTP/2 noch etwas konsequenter umsetzen.

Wann QUIC bzw. HTTP/3 als Standard vorgestellt werden, ist noch völlig unklar. Entwicklern und Admins bleibt also noch etwas Zeit, Zukunftspläne zu schmieden oder in Panik zu verfallen. Panik ist dabei eigentlich gar nicht angebracht. QUIC läuft im userpace und sollte damit ohne große Umstände implementierbar sein. Da als Unterbau auf das weit verbreitete UDP gesetzt wird, reicht ein Update der Browsersoftware aus, ohne auf das nächste Betriebssystemrelease warten zu müssen. Außerdem wird QUIC als abwärtskompatibel beschrieben. So ist ein Fallback zu TCP vorgesehen, sollte die Gegenstelle für das neue Protokoll noch nicht bereit sein.

Bei Cloudflare geht man davon aus, dass die QUIC-Arbeitsgruppe zum Ende des Jahres einen ersten fertigen Entwurf vorstellen wird. Die HTTP-Arbeitsgruppe indes hat sich noch nicht zu der Ankündigung eines festen Datums hinreißen lassen. Es wird aber zumindest angekündigt, dass man sich zu gegebener Zeit mit der Entwicklung der notwendigen Extensions beschäftigen wird, um HTTP für QUIC vorzubereiten. Das ist doch schon was.