Zum Autor:

Über ein Stream Multiplexing wurde bei HTTP/2 die Zuordnung der Antwortreihenfolge aufgehoben. Somit konnten einzelne Anfragen, deren Verarbeitung auf dem Server länger braucht, nicht mehr den gesamten Stream blockieren bzw. ausbremsen. Es bleibt jedoch dabei, dass bei verlorenen Paketen in HTTP/1.1 und HTTP/2 durch das zugrunde liegende Transportprotokoll TCP alle nachfolgenden Pakete auf die Retransmission warten müssen. Dies ist bei HTTP/3 auf Basis von QUIC, wie in Bild 3 dargestellt, nicht mehr der Fall. Wie HTTP/2 ermöglicht auch HTTP/3 ein serverseitiges Pushen von Daten, was jedoch recht aufwendig in der Implementierung sein kann. Dies kann beispielsweise zur Signalisierung von neuen Anrufen oder Nachrichten in UCC Applikationen zum Einsatz kommen.
Neu in HTTP/3 ist zudem die Möglichkeit eines Wechsels des Transportmediums innerhalb einer bestehenden Verbindung, wie z. B. beim Wechsel von LAN oder WLAN zu einem Mobilfunknetz, wenn der Arbeitsplatz verlassen wird. Dieses Feature basiert auf der Entkopplung von IP-Adresse und Portinformation bei QUIC auf Basis von sogenannten Connection Identifiers. Innerhalb der QUIC-Kommunikation kommen diese für die Zuordnung der Verbindung zum Einsatz. Innerhalb dieser Connection können dann mehrere Streams übertragen werden.

Unterstützung auf Client und Serverseite

Der beste Standard nutzt jedoch im Fall fehlender Praxisimplementierungen nichts. Dort tut sich aktuell einiges. So unterstützen auf Clientseite Google Chrome, Microsoft Edge, Mozilla Firefox sowie Safari bereits HTTP/3. Auf Serverseite fehlt aktuell jedoch noch eine Implementierung im beliebten Apache Webserver. Microsofts aktuelle Serverversion 2022, genauer gesagt der darauf aufbauende Webserverdienst Internet Information Server (IIS), kann bereits mit HTTP/3 umgehen. Gleiches gilt für den LiteSpeed Webserver sowie in einer Preview auch für NGINX.

Grundlage des SIP-Nachfolgers

Die Entwicklung von HTTP/3 ist für Systemhäuser im Hinblick auf den potenziellen SIP-Nachfolger »Real-Time Internet Peering for Telephony Protocol« (RIPT) von Interesse, da er auf QUIC und HTTP/3 aufbaut (VAF Report berichtete in Ausgabe 2/2020). Die ersten Entwürfe erschienen Anfang 2020 bei der IETF, die jedoch aktuell als »abgelaufen« geführt werden. Man kann jedoch davon ausgehen, dass dies daran liegt, dass zunächst die finalen Versionen von QUIC und HTTP/3 veröffentlicht werden sollten.
Dies war in Form von QUIC im RFC 9000 im Mai 2021 und bei HTTP/3 im Juni 2022 der Fall. RIPT soll perspektivisch SIP, SDP, RTP und WebRTC ersetzen. Somit wären dann
sowohl Signalisierungs- als auch die Mediendaten obligatorisch verschlüsselt.

Bild 4: Einsortierung HTTP/3 in Protokollstapel für den potenziellen SIP-Nachfolger RIPT (rechts); klassischer Protokollstapel mit SIP und RTP (links)

Verbindungsab- und aufbau

Bevor eine HTTP/3-Anfrage vom Client an den Server versendet werden kann, braucht es eine bestehende QUIC-Connection. Dafür wird, wie in Bild 2 dargestellt, initial ein sogenannter 1-RTT-Handshake (One RoundTrip Time) von QUIC benötigt, bei dem der TLS-Handshake integriert ist. Sobald durch den ersten Handshake entsprechendes Schlüsselmaterial auf Clientseite vorhanden ist, kann der Client bei neuen Anfragen darauf aufbauen und muss keinen Handshake mehr durchführen. Er kann also seine Anfrage direkt an den Server versenden ohne Verzögerung durch einen zusätzlichen neuen Handshake. Dies nennt man bei QUIC 0-RTT (Zero Round-Trip Time). Auf diesem Feature kann auch HTTP/3 aufbauen. Ob HTTP/3 zur Anwendung kommt, kann trotz der TLS-Verschlüsselung wie in Bild 5 ersichtlich im QUIC-Handshake am Application-Layer Protocol Negotiation (ALPN) »h3« erkannt werden. Dabei muss zwingend auch der Zielserver anhand der Angabe zur Server Name Indication (SNI) erkennbar sein. Im Beispiel in Bild 5 war dies update.googleapis.com.
Jede Seite der Verbindung muss zu Beginn der Verbindung einen Kontrollstream aufbauen und einen Frame mit den entsprechenden SETTINGS übermitteln. HTTP-Requests senden Clients jeweils in einem Request Stream. Dieser ist als bidirektionaler QUIC-Stream definiert. Über einen Stream darf nur ein einzelner Request laufen, um das zuvor genannte Head-ofLine Blocking zu verhindern. Nach dem Request muss der Client den Stream sendeseitig schließen. Nachdem der Server seine finale Antwort gesendet hat, schließt auch er seine Senderichtung des bidirektionalen Streams. Die gesamte HTTP/3-Connection (nicht der Stream) besteht jedoch über alle Requests hinweg. Push-Ereignisse des Servers erfolgen hingegen über serverinitiierte unidirektionale QUIC-Streams.

Bild 5: Trotz der zwingenden Verschlüsselung mit TLS 1.3 kann das Protokoll HTTP/3 am ALPN „h3“ erkannt werden. Selbst der Beispiel-Zielserver „update.googleapis. com“ kann erkannt werden.

Eine HTTP/3-Connection kann über einen sogenannten GOAWAY-Frame sanft beendet werden, der dem Empfänger die Requests oder Pushes darstellt, die in dieser Verbindung verarbeitet wurden oder verarbeitet werden sollen. Über einen QUIC CONNECTION_CLOSE kann jederzeit allerdings auch eine sofortige Beendigung erfolgen.

Kompatibilität

Konnektivitätsprobleme, also falls beispielsweise UDP komplett oder der spezifisch genutzte Port geblockt sein sollte, können zu Fehlern beim QUIC-Verbindungsaufbau führen. Der Client sollte gemäß dem RFC versuchen, TCP-basierende Versionen von HTTP einzusetzen.

Kritische Punkte

Forscher hegen jedoch Bedenken gegen QUIC und HTTP/3. In mehreren Papers, die auch in den Quellen dargestellt sind, stellen sie Datenschutzprobleme aufgrund von Website-Fingerprinting dar. Aber auch die Performance einzelner Implementierungen verbessert sich nicht zwingend im Vergleich zu HTTP/2. Dabei stellen die Forscher dar, dass dies eher an der Art der Implementierung von QUIC als an der Protokollspezifikation liegt. QUIC erzeugt jedoch gemäß Angaben einiger Experten bei hohen Datenraten auch wesentlich höhere CPU-Lasten als HTTP/2 in Kombination mit TCP und TLS.
Eine weitere Herausforderung birgt HTTP/3 im Zusammenhang mit einer Inhaltskontrolle auf Sicherheitssystemen wie Proxy-Servern. Da HTTP/3 zwingend TLS-1.3-Verschlüsselung voraussetzt, ist eine Kontrolle der Inhalte der übertragenen Pakete nicht mehr ohne Weiteres möglich. Dies war in TLS 1.2 in Kombination mit schwachen Verschlüsselungsalgorithmen ohne Perfect Forward Secrecy (PFS) noch anders. Jedoch steigt auch der Anteil an verschlüsselter Kommunikation von Schadsoftware, um kriminelle Aktivitäten zu verschleiern. Um Schadsoftware zu erkennen, bedarf es nun erweiterter Analysen der Metadaten, wie der Extraktion von Daten aus dem Handshake sowie der Auswertung von Paketlängen und der Byte-Verteilung. Zum Aufbrechen der Verschlüsselung kommen in einigen Fällen auch sogenannte »Downgrades«, also die Abschwächung der Verschlüsselung, zum Einsatz. Konkret wird beispielsweise der UDP-Port 443 geblockt, um auf HTTP/2 und TLS 1.2 mit schwachen Algorithmen zu wechseln und folglich den Datenverkehr inspizieren zu können. Dies birgt zusätzliche Risiken. Einige Hersteller bieten jedoch bereits Sicherheitssysteme an, die TLS-1.3-Datenverkehr entschlüsseln, analysieren und anschließend verschlüsseln können. Wenn jedoch sogenanntes Zertifikatspinning zum Einsatz kommt, also nur das reale Serverauthentifizierungszertifikat vom Client akzeptiert wird, scheitern diese Ansätze.

Fazit

Es bleibt abzuwarten, ob und wann sich HTTP/3 durchsetzen wird. Zwar bringt es interessante Ansätze, welche insbesondere bei der mobilen Nutzung eine große Rolle spielen, wie Verbesserung im Verhalten bei Paketverlusten und Verbesserung im Verhalten bei IP-Changes des Clients bei QUIC. Jedoch sind dies keine Killerfeatures im Vergleich zu HTTP/2. Die entscheidenden Vorteile kommen eher aus der Verwendung von QUIC als von HTTP-spezifischen Protokollanpassungen. Aktuell mangelt es noch an einigen Server­im­ple­men­tier­ungen. Jedoch könnte über die positiven Eigenschaften von HTTP/3 ein noch stärkerer Drang zur »HTTPisierung« des Netzes, also der Abbildung von immer mehr Applikationen auf Basis von HTTP, erfolgen. Dies macht ein Firewalling immer schwieriger. Auch bleibt der Einfluss von UDP-Filtern und IDSVerhalten (Intrusion Detection System) bei größerer Verbreitung abzuwarten.