aus dem Netzwerk Insider Oktober 2022
Vor 25 Jahren wurde die Domain google.com registriert – davon haben Sie sicher gehört. Inzwischen beherrscht die Firma Google einen wesentlichen Teil des Internets. Das betrifft vor allem die Welt der Anwendungen. Doch wussten Sie, dass Google inzwischen sogar ein neues Transport-Protokoll entwickelt hat, das in Konkurrenz zum altbekannten TCP tritt? Das neue Protokoll heißt QUIC.
Es gibt wohl kaum ein Protokoll, an dem so lange und viel geforscht wurde wie an TCP. Schließlich ist es bald 50 Jahre alt. Zahlreiche Optimierungen haben es dazu ertüchtigt, auch in modernen Netzen gute Performance zu bieten. Wozu brauchen wir nun etwas Neues?
Das Problem liegt weniger in der Datenübertragung selbst als vielmehr in der Tatsache begründet, dass heutzutage die meisten Informationen in Websites stecken. Websites bestehen aus zahlreichen Elementen. Neben der eigentlichen HTML werden Graphiken verschiedener Formate, Style Sheets und Scripts geladen. Auf der Website https://www.comconsult.com sind es ca. 30. Bei einer großen Tageszeitung fand ich mehr als 350 Elemente, die von zig verschiedenen Quellen geladen wurden. Die Größe der einzelnen Elemente lag zwischen wenigen Bytes und 500 KB.
Die Performance von Websites ist demzufolge weniger eine Frage der optimierten Datenübertragung mittels TCP. Sie hängt vielmehr davon ab, wie sich viele Einzelelemente in kurzer Zeit laden lassen. Die Antwortzeit (Round Trip Time, RTT) wird zum entscheidenden Faktor. Und dabei lässt sich in der Tat noch einiges optimieren.
Schauen wir uns an, welche Schritte zum Laden eines einzelnen Elements benötigt werden:
- Zunächst ist eine TCP-Verbindung zum passenden Server aufzubauen. Hierfür werden drei Pakete benötigt (SYN – SYN/ACK – ACK), die aus Sicht des Clients einen Round Trip benötigen.
- Anschließend ist ein verschlüsselter Tunnel mittels Transport Layer Security (TLS) zu etablieren. Das benötigt in der Regel zwei Round Trips.
- Nun kann die eigentliche Anfrage des Hypertext Transfer Protocol (HTTP) durch den verschlüsselten Tunnel erfolgen. Hierfür wird eine weitere RTT zuzüglich der Zeit für die Datenübertragung verbraucht.
Der Aufruf eines Website-Elements auf herkömmliche Weise benötigt somit also mindestens vier Round Trips. Optimal wäre einer. Zugegeben, es haben sich bereits andere vor Google mit diesem Problem beschäftigt. Folgendes ist dabei herausgekommen:
- Bündeln mehrerer HTTP-Requests in einer TCP-Session: Das funktioniert bereits mit HTTP/1.1.
- Paralleler Abruf mehrerer Elemente: Das sogenannte Stream Multiplexing wurde mit HTTP/2 eingeführt.
- Einsatz von TLS 1.3: Der Aufbau des verschlüsselten Kanals erfolgt mit einem Round Trip statt wie bisher mit zweien.
- Verzicht auf TCP: Dabei herausgekommen ist QUIC [1], das auf UDP basiert.
UDP ist bekanntlich verbindungslos und besitzt keine Möglichkeiten der Flusskontrolle. Verbindungs-Management und Flusskontrolle sind stattdessen in QUIC selbst implementiert, wobei man im Prinzip auf wohlbekannte Mechanismen des TCP zurückgreift. Übrigens nutzt QUIC bei UDP dasselbe Well-known-Port wie HTTPS bei TCP, nämlich 443.
Letztlich schafft QUIC es, den HTTP-Request mit zwei Round Trips abzusetzen. TLS 1.3 wurde in dieses Protokoll integriert. Und auch HTTP wurde unter der Bezeichnung HTTP/3 integriert, um weitere Features zu ermöglichen. Beispielsweise wird nach einem Paketverlust nur noch das davon betroffene Element durch die Retransmission verzögert. Alle übrigen Streams laufen davon unbeeindruckt weiter.
Der Verzicht auf TCP hat im Übrigen einen weiteren Vorteil. Sie erinnern sich vielleicht noch an unseren Artikel aus dem Netzwerk-Insider vom März 2021. Darin ging es um das Problem des Wechsels einer Ethernet-Verbindung zu WLAN und umgekehrt. TCP-Verbindungen sind in diesen Fällen neu aufzubauen, weil der entsprechende Flow durch das „5-Tupel“ aus IP-Adressen, Ports und Protokoll eindeutig bestimmt wird.
Bei QUIC dagegen wird die Verbindung eindeutig durch einen Connection Identifier bezeichnet, der unabhängig von IP-Adressen und Portnummern ist. Ein Wechsel der Quell-IP-Adresse hat keinen Verbindungsabbruch zur Folge. Damit ist QUIC besonders geeignet für die Verwendung auf mobilen Endgeräten.
Wie bereits erwähnt ist QUIC vollständig verschlüsselt. Bei der Protokollanalyse werden Sie außer IP-Adressen und Connection ID nicht viel sehen. Das war für mich erst einmal ein Schock: Die Analyse von TCP-Streams ist mir beim Trouble Shooting ein unverzichtbares Werkzeug – meine Seminarteilnehmer können ein Lied davon singen. Und das soll bei QUIC alles Geschichte sein? Inzwischen lerne ich jedoch, wie es trotzdem geht. Ich werde beizeiten darüber berichten.
Verweis
[1] Die Protokolldefinition findet sich im RFC 9000. Darin wird betont, dass QUIC kein Akronym sei, sondern ein Name. Ungeachtet dessen fand ich an anderer Stelle die Bezeichnung „Quick UDP Internet Connection Protocol“.