QUIC: Das steckt hinter dem experimentellen Google-Protokoll

Dank immer schnellerer DSL-Zugänge ist die Ladezeit von Internetseiten im Allgemeinen immer geringer geworden. In der Konsequenz werden schnelle Seitenaufrufe heute als selbstverständlich angesehen, sodass langsam ladende Webprojekte kaum noch Chancen haben, auf dem Markt zu bestehen. Erschwerend kommt hinzu, dass auch das Thema Verschlüsselung zunehmend an Bedeutung gewinnt: Der HTTPS-Standard erweist sich zwar als verlässlicher Verbündeter beim Schutz der Nutzer-Privatsphäre, hat aber durch TLS-Handshake sowie Zertifikats- und Schlüsselaustausch eine zusätzliche Verzögerung des Ladeprozesses zur Folge – eine Situation, die das von Google initiierte QUIC-Protokoll zukünftig lösen soll.

Bei QUIC handelt es sich um ein experimentelles Transportprotokoll des Suchmaschinenriesen Google, das der Öffentlichkeit erstmals im Jahr 2013 vorgestellt wurde. Der Name des Protokolls steht dabei für „Quick UDP Internet Connections“, was darauf zurückzuführen ist, dass es das schnelle und unkomplizierte Versenden einfacher Datenpakete über das verbindungslose UDP-Protokoll (User Datagram Protocol) ermöglicht. Hintergrund der Arbeiten an QUIC war der Wunsch, eine Alternative zu der etablierten Sicherheitslösung aus TCP, HTTP/2 und TLS/SSL zu entwickeln, die den gleichen Schutz bietet, gleichzeitig aber eine reduzierte Verbindungs- und Transportverzögerung aufweist und Multiplex-Verbindungen ermöglicht.

Google hat QUIC zu diesem Zweck so entworfen, dass das Protokoll die Verbindungskontrolle selbst regelt. Beim ersten Handshake zwischen Sender und Empfänger tauschen diese die Zertifikate und Schlüssel aus, die für die Verschlüsselung der versendeten Datagramme benötigt werden. Bei späteren Kommunikationen entfällt dieser Austausch, was die Latenz minimiert. Als Verschlüsselungsprotokoll kommt dabei die aktuelle, geschwindigkeitsoptimierte TLS-Version 1.3 (im März 2017 standardisiert) zum Einsatz, die den Vorzug vor der hauseigenen Crypto-Lösung erhielt. In Sachen Multiplexing orientiert sich QUIC an dem ebenfalls von Google erarbeiteten SPDY-Protokoll, das die Vorlage zu HTTP/2 gab: Über eine einzige Client-Server-Verbindung können mehrere verschiedene Datenströme übertragen werden, wodurch die Ladezeit zusätzlich reduziert wird.

Einige wichtige Eigenschaften und Vorzüge von QUIC sind bereits zur Sprache gekommen, sollen an dieser Stelle gemeinsam mit weiteren Verbesserungen aber noch einmal etwas genauer beleuchtet werden. Als Vergleichsprotokoll dient TCP, das zwar als Wegbereiter im Konzept des aufstrebenden Transportprotokolls eine wichtige Rolle spielt, dem Google-Protokoll aber in einigen Punkten deutlich unterlegen ist, wie folgende Vorteile von QUIC verdeutlichen.

Der Hauptgrund für das Performance-Plus von QUIC gegenüber TCP ist der wesentlich schnellere Verbindungsaufbau. Selbst ohne Verschlüsselung via SSL/TLS setzt eine Verbindung über das klassische Transportprotokoll mit dem sogenannten Drei-Wege-Handshake mehr Schritte voraus als die UDP-basierte Google-Lösung. QUIC startet eine Verbindung mit einem einzigen Paket (bzw. zwei Paketen, wenn es sich um die erste Verbindungsaufnahme handelt) und übermittelt dabei sogar alle notwendigen TLS- bzw. HTTPS-Parameter. In den meisten Fällen kann ein Client also Daten direkt an einen Server senden, ohne auf eine Antwort von diesem angewiesen zu sein, während TCP zunächst die Bestätigung des Servers einholen und verarbeiten muss.

TCP greift auf die TCP-Ports und IP-Adressen der verbundenen Systeme zurück, um eine Verbindung zu identifizieren. Aus diesem Grund ist es nicht möglich, dass ein Client in einer einzigen Verbindung über mehrere Ports mit dem Server kommuniziert. Das QUIC-Protokoll löst die Situation auf andere Weise: Es greift auf eine 64-Bit-Verbindungserkennung und verschiedene „Streams“ zum Transport der Daten innerhalb einer Verbindung zurück. Eine QUIC-Verbindung ist daher nicht an einen bestimmten Port (in diesem Fall UDP-Port), eine IP-Adresse oder einen bestimmten Endpunkt gebunden. Port- und IP-Wechsel sind in der Konsequenz ebenso möglich wie die bereits erläuterten Multiplex-Verbindungen.

Jedes Datensegment einer QUIC-Verbindung erhält eine eigene Sequenznummer, unabhängig davon, ob es sich um ein originales oder um ein weitergeleitetes Segment handelt. TCP macht diesen Unterschied standardmäßig nicht, weshalb ein Host den Status einer Sequenz auch nicht ermitteln kann – erst durch den Einsatz der Timestamps-Erweiterung (dt. „Zeitstempel“) ermöglicht auch das klassische Transportprotokoll eine solche Unterscheidung. Die fortlaufende Markierung der Pakete ist deshalb von Vorteil, weil sie eine akkuratere Schätzung der Paketumlaufzeit (RTT: Round Trip Time) ermöglicht.

Verloren gegangene Pakete stellen beim Datentransport über QUIC kein großes Problem dar. Dank eines einfachen XOR-basierten Fehlerkorrektursystems ist keine erneute Übertragung der entsprechenden Daten notwendig. Diese können jederzeit mithilfe von FEC-Paketen (Forward Error Correction) – Back-ups der Originalpakete für eine Datengruppe – rekonstruiert werden. Die Fehlerkorrektur funktioniert allerdings nicht, wenn mehrere Pakete einer Datengruppe fehlen.

TCP versucht Daten immer so schnell wie möglich zu versenden, was für schnelle Datenverbindungen zwar von Vorteil, aber auch mit einer gewissen Verlustrate verbunden ist. Geht ein Paket verloren, wird ebenso schnell die Neuübertragung (TCP Fast Retransmit) initiiert. Hierfür verkleinert TCP jedoch vorübergehend das Staufenster, was häufig zur Folge hat, dass die Daten stoßweise übertragen werden. Das QUIC-Protokoll wirkt derartigen Lastspitzen mithilfe des sogenannten Packet Pacing entgegen. Das Verfahren sorgt dafür, dass die Übertragungsrate automatisch begrenzt wird. So kommt es auch bei Verbindungen mit geringer Bandbreite nicht zu Überlastungen. Neu ist diese Technik jedoch nicht: Einige Linux-Kernel nutzen das Verfahren auch für das TCP-Protokoll.

Der Sicherheitsaspekt stand bei der Planung und Konzipierung von QUIC von Beginn an im Fokus. Im Zuge dessen haben sich die Entwickler auch einem der größten Probleme von TCP gewidmet: Der Header der verschickten Pakete liegt im Klartext vor und kann ohne vorherige Authentifizierung gelesen werden. Man-in-the-Middle-Attacken und Paketmanipulationen (z. B. der Sequenznummern) sind daher keine Seltenheit. QUIC-Pakete jedoch sind immer authentifiziert und größtenteils verschlüsselt (inklusive Payload). Die Teile des Headers, die nicht in verschlüsselter Form vorliegen, sind aufgrund der Authentifizierung auf Empfängerseite vor Injektion und Manipulation geschützt.

Ein weiterer großer Vorteil von QUIC gegenüber TCP: Das Google-Protokoll ist vom System losgelöst. Während das TCP-Protokoll von den jeweiligen Plattformen bzw. Geräten unterstützt werden muss, damit eine Kommunikation möglich ist, ist die QUIC-Unterstützung lediglich auf Anwendungsebene notwendig. Software-Firmen haben es also prinzipiell selbst in der Hand, das Protokoll einzubinden – sie sind dabei nicht auf die Hardware-Hersteller angewiesen. Bis dato sind es zwar vor allem Google-Anwendungen wie die Google-Server, Chromium oder Chrome, die über QUIC-Implementierungen verfügen. Mit dem Browser Opera, der Server-Software Caddy und den Load-Balancing- und Webserver-Produkten von LiteSpeed Technologies gibt es aber bereits Drittanbieter-Applikationen, die Verbindungen über das neue Transportprotokoll ermöglichen.

Dass QUIC künftig wohl immer häufiger zum Einsatz kommen dürfte, ist vor allem auf das Engagement der IETF zurückzuführen. Dank der Anpassungen an allgemeine Standards seit Gründung der Arbeitsgruppe im Jahr 2016 hat sich das Protokoll von einem stark auf Google ausgerichteten zu einem allgemeinen Netzwerkprotokoll entwickelt, das zunehmend an Bedeutung gewinnt. Der Optimierungsprozess ist allerdings noch lange nicht abgeschlossen: Das QUIC-Team befasst sich auch weiterhin mit bestehenden Problemen, für die es die passenden Lösungen zu finden gilt.

Insbesondere das Thema Sicherheit, eines der wichtigsten bei der Entwicklung des Protokolls, sorgt dabei für Diskussionsstoff. Denn während Authentifizierung und Verschlüsselung zweifelsohne für einen sichereren Datentransport sorgen, sind sie gleichzeitig auch für einen entscheidenden Nachteil von QUIC verantwortlich: Da die Paket-Header weniger Klartextinformationen enthalten als es bei TCP-Verbindungen der Fall ist, sind Aufgaben wie Fehlerbehebung, Traffic-Regulierung oder Netzwerk-Management bei QUIC-Verbindungen deutlich erschwert. Netzbetreiber sowie Hersteller von Firewalls und anderen Mittelboxen sehen deshalb Schwierigkeiten darin, die Qualität ihrer Dienste zu gewährleisten.

Ein weiteres Problem des QUIC-Protokolls ist, dass die automatische Überlastungssteuerung bei Datenverbindungen mit hoher Bandbreite in einigen Fällen zu einer schlechteren Übertragungsrate führen kann.

Wollen Sie das Protokoll deaktivieren, wählen Sie einfach den Eintrag „Disabled“ aus und klicken anschließend auf die Schaltfläche „JETZT NEU STARTEN“. Chrome wird in der Folge beendet – beim nächsten Start des Browsers sind die neuen Einstellungen aktiv. Wollen Sie das Protokoll wieder aktivieren, gehen Sie auf die gleiche Weise vor, wählen jedoch entweder die eigentliche Einstellung „Default“ oder alternativ den Punkt „Enabled“ aus.