IETF erhebt HTTP/3 zum RFC

Durch die Einführung von QUIC wandelt sich das Transportprotokoll im Web von TCP nach UDP – mit allen Vor- und Nachteilen. Dies unterstreicht auch der nun frisch veröffentlichte Proposed Standard zu HTTP/3, der ebenfalls auf QUIC aufbaut.

Der neue RFC 9114 nutzt einige positive Eigenschaften von QUIC. Darunter ein Stream Multiplexing, das die Vermeidung von Head of Line Blocking sicherstellen soll. Beim Head of Line Blocking blockiert eine hängende Transaktion folgende Transaktionen. Zusätzlich kommt eine Flusskontrolle je Stream zum Einsatz. Ein entscheidender Vorteil dürfte der beschleunigte Verbindungsaufbau sein, da QUIC den TLS-Handshake bereits in den QUIC Handshake integriert hat und somit zusätzliche Latenz vermieden wird. Die TLS1.3 Verschlüsselung ist obligatorisch.

Zudem bietet HTTP/3 nun auch die insbesondere bei mobiler Nutzung und langlebigen Sessions sinnvolle Entkopplung von IP und Port durch die Nutzung von QUIC Connection IDs, was den Wechsel von IP-Adressen innerhalb einer Connection ermöglicht.

Verbindungsauf- und -abbau

Neben dem klassischen 1-RTT Handshake von QUIC, bei dem der TLS-Handshake integriert ist, kann HTTP/3 auch auf 0-RTT aufbauen. Dies bedeutet, dass der Client den Request auf Basis einer vorherigen Verbindung direkt an den Server versenden kann, ohne zusätzliche Latenz durch einen neuen Handshake. Ob HTTP/3 zur Anwendung kommt, kann im Handshake am Application-Layer Protocol Negotiation (ALPN) h3 erkannt werden. Dabei ist die Angabe zur Server Name Indication (SNI) zwingend.

Jede Seite der Verbindung muss zu Beginn der Verbindung einen Kontrollstream aufbauen und einen Frame mit den entsprechenden SETTINGS übermitteln.

HTTP Requests senden Clients in einem Request Stream, der einen bidirektionalen QUIC-Stream nutzt. Über einen Stream darf nur ein einzelner Request laufen, um das Head of Line 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 vom Server erfolgen hingegen über serverinitiierte unidirectionale QUIC Streams.

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 sollen. Über einen QUIC CONNECTION_CLOSE kann zudem jederzeit eine sofortige Beendigung erfolgen.

Konnektivitätsprobleme, also falls beispielsweise UDP 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.

Datenschutz und Performance

Forscher hegen allerdings Bedenken bezüglich QUIC und HTTP/3: In mehreren Papern 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 ferner gemäß Angaben einiger Experten wesentlich höhere CPU-Lasten, als HTTP/2 in Kombination mit TCP und TLS. Zudem gibt es aktuell noch keine Implementierung für den beliebten Webserver Apache.

(fo)