HTTP/3 erklärt (für Webentwickler)

HTTP/3 stellt ein wichtiges Feature der künftigen Web-Landschaft dar.
Robert Avgustin | shutterstock.com



Die Anwendungsprotokolle, die dem weltweiten Netz zugrunde liegen, weiterzuentwickeln, ist ein relativ episches Unterfangen. Entsprechend ist es auch keine Überraschung, dass zwischen HTTP/2 (ab 2015) und HTTP/3 (2022) sieben Jahre liegen.



Die aktuelle HTTP-Version verspricht im Vergleich zu ihrem Vorgänger eine verbesserte Performance und ein Mehr an Sicherheit – unter anderem dank der Einbindung des QUIC-Protokolls. In diesem Artikel erfahren Sie, was Webentwickler in Sachen HTTP/3 wissen sollten.



HTTP/3 vs. HTTP/2



HTTP/3 will das Internet für alle sicherer, schneller und einfacher machen. Wenn Ihnen das irgendwie bekannt vorkommt, dann deshalb, weil das bereits bei HTTP/2 der Fall war.



Der entscheidende Unterschied ist, dass das QUIC-Protokoll als Basis für HTTP/3 dient. Dabei handelt es sich letztlich um ein Transportprotokoll, das auf dem verbindungslosen User Datagram Protocol (UDP) aufbaut. Bei HTTP/2 kommt dafür TCP zum Einsatz.



Das Vorgehen begründet sich darin, dass das Gros der Soft- und Hardware darauf konzipiert ist, mit den existierenden Protokollen zu kommunizieren. Netzwerkgeräte vollständig umzukonfigurieren, damit sie mit einer neuen TCP-Version zusammenarbeiten, wäre eigentlich der richtige Ansatz – ist aber in der Praxis nicht umsetzbar. Das würde zwar viele HTTP(/2)-Probleme lösen, aber Massen von ausfallenden Devices nach sich ziehen. 



Wie HTTP/3 funktioniert



Bei HTTP/3 geht es im Kern um zwei Spezifikationen. Die des Standards selbst und die des QUIC-Protokolls. In Kombination entsteht ein Dickicht aus technischer und praktischer Komplexität. Um die Technologie und die Zielsetzungen dahinter zu durchdringen, lohnt sich deshalb eine Betrachtung aus höherer Ebene.



Dazu teilen wir die Funktionen von HTTP/3 in drei wesentliche (Ziel-)Bereiche auf, die wir im Anschluss näher beleuchten:




Integrierte Verschlüsselung



Multiplexing



Connection-Resilienz




Integrierte Verschlüsselung



Obwohl die integrierte Verschlüsselung ein Sicherheitsmerkmal ist, stellt sie auch eine Performance-Verbesserung dar. Das liegt daran, dass die Art und Weise, wie die Verschlüsselung in HTTP/3 ausgehandelt wird, die Anzahl der erforderlichen Roundtrips reduziert.



Die Verschlüsselung im Web hat eine lange Historie, zu der auch die Abschaffung von SSL zugunsten von TLS gehört. Im Allgemeinen hat sich eine Entwicklung hin zu optimierten Implementierungen und Verschlüsselung als Standard vollzogen. Inzwischen ist HTTPS die Standardoption für Web Traffic – mit HTTP/3 wird die Plaintext-Option (http://…) vollständig abgeschafft.



HTTPS wird auch weiterhin als Mechanismus verwendet, um sichere Verbindungen im Web aufzubauen – aber der Datenverkehr wird auf HTTP/3-Ebene verschlüsselt. Man könnte auch sagen, TLS ist in das Protokoll integriert – statt parallel zu laufen. Somit wird die Encryption vom Applikations- in den Transport-Layer verlagert. Das bedeutet standardmäßig mehr Sicherheit (sogar die Header in HTTP/3 sind verschlüsselt) – zieht aber auch entsprechende Kosten nach sich, in Form von CPU-Last.



Zusätzlich zur Verschlüsselung bietet QUIC auch einen integrierten DDoS-Schutz und „Forward“-Security. Das macht es Angreifern schwerer, frühere Kommunikations-Sessions zu kompromittieren – selbst, wenn die Teilnehmer Geheimnisse preisgeben.



Multiplexing



Multiplexing war eines der wesentlichen Features von HTTP/2. Bei HTTP/3 läuft das auf eine neue und optimierte Weise. Insbesondere versucht HTTP/3, das Head-of-Line-Blocking-Problem zu lösen.



Idealerweise würden wir dieses direkt in TCP beheben. Wenn wir HTTP über TCP laufen lassen, können wir mehrere verschiedene Dateien gleichzeitig senden. Das ist die derzeitige Inkarnation des Multiplexing. Wenn Sie eine Website öffnen, möchte der Server so viele Dateien wie möglich auf einmal senden. Das ist der Geschwindigkeit und Effizienz zuträglich. HTTP/2 ermöglicht das, TCP versteht allerdings keine „multiplexed“-Dateien sondern betrachtet sie quasi als einen großen Brocken. Damit nicht genug: Wenn eine dieser Dateien ausfällt, müssen alle innerhalb des Streams neu gesendet werden.



Deswegen nutzt HTTP/3 das QUIC-Protokoll mit UDP als Basis. Das realisiert so etwas ähnliches wie „TCP 2.0“ und ermöglicht, die Dateien in den Streams granular neu zu starten.



Connection-Resilienz



Unter Connection-Resilienz versteht man einen Mechanismus, der dafür sorgt, dass die Verbindung zwischen Client und Server bestehen bleibt, wenn sich ein Device von einem Netzwerk in ein anderes bewegt. Diese Kontinuität ist im Fall von TCP nicht möglich, weil das Protokoll lediglich die IP-Adresse und Portnummer versteht. Ändert sich eine dieser beiden Variablen, muss eine komplett neue Verbindung aufgebaut werden. Das mündet wiederum in einer vorhersehbaren Minderung der Performance.



Das QUIC-Protokoll führt an dieser Stelle Connection IDs oder CIDs ein. Die werden aus Sicherheitsgründen von Server und Client ausgehandelt. HTTP/3-Verbindungen verwenden also eine IP-Adresse, einen Port und eine CID, um eine logische Verbindung aufrechtzuerhalten, wenn sich das Netz ändert, eine neue IP oder ein neuer Port eingerichtet wird.



HTTP/3-Implementierung



Das QUIC-Protokoll baut mehrere Funktionen auf der Grundlage von UDP auf. Das 1980 eingeführte Protokoll ist simpel gehalten und wird von vielen Softwarelösungen und Devices genutzt – etwa für Onlinespiele oder IP-Telefonie. Seine ausgeprägte Verbreitung macht es zu einer soliden Grundlage für HTTP/3 – ein etabliertes Protokoll, das eine minimale Baseline für die Implementierung bietet.



Im Gegensatz zu TCP ist UDP verbindungslos und verfügt nicht über eine Logik zur Netzwerkoptimierung. Diese essenziellen Elemente fügt das QUIC-Protokoll hinzu. Um eine Verbindung herzustellen und aufrechtzuerhalten, verwendet QUIC sogenannte Acknowledgments (ACKs). Zudem unterstützt das Protokoll auch Packet Redelivery. Diese Funktionen entsprechen denen von TCP, wurden aber optimiert, um integrierte Verschlüsselung, reduzierte Netzwerk-Roundtrips und dauerhafte Verbindungen zu realisieren.



QUIC bildet das Herzstück von HTTP/3 und ist zudem auf Erweiterbarkeit konzipiert: Das Protokoll nutzt sogenannte Frames, um bestimmte Datagram-Nutzungen zu kapseln und in der Zukunft hinzuzufügen – ohne dabei existierende Use Cases zu unterbrechen.



Die HTTP/3-Zukunft



Alle Funktionen, Protokolle und die HTTP/3-Spezifikation selbst werden laufend weiterentwickelt, auch wenn QUIC bereits in Browsern und anderen Projekten eingesetzt wird.



HTTP/1, HTTP/2 und HTTP/3 werden auf absehbare Zeit nebeneinander existieren. Im Moment stellt HTTP/3 das fortschrittlichere Anwendungsprotokoll dar, das sich in dem Maße durchsetzen wird, in dem es Support erfährt. Ob HTTP/3 seinen Versprechungen gerecht werden kann, wird sich zeigen, wenn es auf breiter Basis eingesetzt wird.



Die folgenden Ressourcen halten weitere, tiefgehende Infos zu HTTP/3 und seinen Komponenten bereit:




RFC 9114 enthält die Details und Historie des HTTP/3-Vorschlags.



RFC 9000 enthält die Details und Historie des QUIC-Vorschlags.



Das „Smashing Magazine“ bietet eine ausführliche HTTP/3-Serie – inklusive Beiträgen zu Performance-Verbesserungen.










Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!