HTTP3

Mit diesem Projekt began ich meine Arbeit bei FOKUS. Als erstes habe ich mir ein Grundverständnis von QUIC und WebTransport angeeignet.

Überblick über QUIC/WebTransport/HTTP3

Diese Protokolle sind der neue Antrieb hinter der dritten Version von HTTP. Wohingegen bisherige Versionen von HTTP das Transmission Control Protocol (TCP) als Transportprotokoll verwendet haben, benutzt HTTP/3 das User Datagram Protocol (UDP) in Form von QUIC.

Der große Unterschied zwischen diesen beiden Protkollen ist, dass TCP eine dedizierte Verbindung zwischen dem Client und Server aufbaut und damit garantieren, dass alle Daten korrekt ankommen, d.h. ohne Fehler und auch in der beabsichtigten Reihenfolge. Im Unterschied dazu schickt UDP die Daten einfach los mit der Hoffnung, dass diese auch ankommen. Jedoch ohne Garantie, dass das auch passiert.

Nun fragen Sie sich bestimmt, warum QUIC nicht mehr TCP verwendet, wenn es doch sicherstellt, dass alle korrekt ankommt: TCP ist langsam. Der Verbindungsaufbau von TCP benötigt ein Austausch von Daten, um sicherzustellen, dass beide Seite kompatible sind, ein sogenannter Handshake, bevore die eigentlichen Daten versickt werden können.

Dazu kommt noch dazu, dass heutzutage jede seriöse Webseite das gesicherte HTTPS Protkoll verwendet. Das heißt, dass jegliche Daten in dem Austausch verschlüsst sind. Dies benötigt zusätzlich zu dem TCP Handshake einen Transport Layer Security (TLS) Handshake. Des Weiteren basiert HTTP auf einem Frage-Antwort-System, d.h. ein Client muss Daten spezifisch von Server anfragen, damit dieser antworten kann.

Jeder dieser Schritte ist eine sogenannte Round-Trip-Time (RTT), d.h. Daten gehen vom Client zum Server, welche ggfs. die Anfrage noch verarbeiten muss, und wieder zurück. Im Kontext von Media Streaming bedeutet das, dass bis der Client die ersten Daten des Mediums erhalten, vergehen volle 3-RTT.

Mit QUIC wird all das abgekürzt. Es wird nur ein einziger Handshake gemacht, welcher den QUIC und TLS zugleich in einem Schritt tätigt. Dadurch ist der Verbindungsaufbau betreit auf nur eine RTT halbiert. Des Weiteren ist die Funktionsweise von QUIC sehr ahnlich wie die WebSockets API, d.h. sowohl der Client als auch Server kann Streams aufmachen und darüber jeder Zeit Daten verschicken.

Note

Mit Hilfe dieser Streams stellt QUIC auch im Hintergrund sicher, dass alle Daten korrekt ankommen

Im Kontext von Media Streaming bedeutet das, dass es möglich ist die ersten Daten des Mediums inner halb etwas über einer einzelnen RTT zu erhalten, da es dem Server erlaubt ist direkt nach dem Abschicken der Handshake-Besätigung die erste Daten des Mediums zu verschicken. D.h. der Client kann Daten bereits mit dem Handshake anfragen.

WebTransport ist eine API, welches es ermöglicht QUIC in einem Browser (auf einer Webseite) mittels HTTP/3 zu verwenden

Testbed

Mit diesem Wissen habe ich im Anschluss mein eigenes Streaming Protokoll und komplettes Testbed entwickelt.

Client

Der Client war eine einfache Webseite, gebaut mit Svelte¹, welche die WebTransport Verbindung aufbaut und ein Video Streaming mittels meinem Protokoll empfängt und dann mit Hilfe eines Media Source Extension (MSE) Player abspielt. Dazu gab es noch einige Schaltflächen, um bestimmte Aspekte des Streams zu konfigurieren, z.B. maximale Bitrate, ABR Algorithmus, Netzwerk Limiter und mehr. Schlißlich gab es noch einige Live Datenplots, welche Metadaten des Streams dargestellt haben, wie die aktuelle Bitarte, eingestellter und geschätzer Netzwerkdurchsatz, Latenzschätzung.

Server

Der WebTransport Server verwendete webtransport-go² und hat die gesamte Logik beinhaltet. Er hat die Clientverbundung angenommen und dann die Streams verschickt. Dazu war er in der Lage beim Versenden der Daten den Nettwerkdurchsatz zuschätzen und damit ridumentäre serverseitge Adaptive Bitrate (ABR) Algorithmen anzuwenden, um die Videobitrate an die Netzwerk gegebenheiten anzupassen, damit Clientseitig das Video stetig flüssig abspielen kann.

Das gesamt Testbed wurde in einem Docker Compose Setup gestartet, damit die Netzwerkanbindung des Servers mit Hilfe des Traffic Control (tc) Unix Tool gedrosselt werden kann, um variierende Netzwerkbedingungen zu simulieren.

Protokoll

Der Client baut eine WebTransport Verbindung mit der Server auf. Mit Hilfe der Verbungsaddresse, konnte der Client direkt ein spezifisches Video anfragen und zusätzlich die zugenannten Konfigurationsmöglichkeiten per Query Parameter direkt mitschicken.

Der Server hat dann einfach die Video (und Audio) Segmente der Streams an den Client geschickt, welcher diese abgespielt hat.

Schließlich wurde die selbe Situation mit dem dash.js³ Spieler zum Vergleich getestet.

Diese Projekt hat sich dann zu Media over QUIC weiter entwickelt.