QUIC - Quick UDP Internet Connections

QUIC (Quick UDP Internet Connections) ist ein Transport-Protokoll, das von Google initiiert wurde und als Grundlage für einen Standard dient, mit dem Ziel die etablierte Kombination aus HTTP + TLS + TCP abzulösen, um die Übertragung und damit den Aufbau von Webseiten zu beschleunigen.
Dazu bringt QUIC viele Elemente von UDP, TCP, TLS und HTTP/2 zusammen. Es ist ein Versuch, mehrere einzelne aufeinander abgestimmte und aufbauende Protokolle durch ein einziges, integriertes Protokoll zu ersetzen.

Beim Protokoll Quick UDP Internet Connections (QUIC) werden Wartezeiten, die durch viele einzelner TCP-Verbindungen entstehen, durch Verschachtelung mit darüberliegenden Protokollen eingespart und sogar die TLS-Verschlüsselung integriert.
Auf QUIC können alle Anwendungen aufsetzen, die nach dem Client-Server-Modell arbeiten. Allerdings funktioniert das nur mit HTTP Version 3 und nicht mit den HTTP-Versionen 1.1 oder 2.

TCP-Schwächen

Die Entwicklung von QUIC wird hauptsächlich durch die Schwächen von TCP begründet. Während die Geschwindigkeit von Internet-Anschlüssen über Jahrzehnte zugelegt hat, schöpfen die vielen Optimierungen an TCP die Geschwindigkeit der Internet-Anschlüsse nicht immer aus.
Die meisten meisten vorgeschlagenen und standardisierten TCP-Verbesserungen sind nie zum Einsatz gekommen. Was auch daran liegt, weil diese optional sind.

  1. Eine Schwäche von TCP ist die Verzögerung durch den Verbindungsaufbau vor der eigentlichen Datenübertragung. Dieser Handshake überträgt mindestens 3 Pakete zwischen Client und Server. Bei einer einzelnen Übertragung wäre das kein Problem. Doch Webseiten bestehen heute aus sehr vielen einzelnen Elementen, die auch noch von unterschiedlichen Servern abgerufen werden. Insgesamt kommt es zu vielen einzelnen Verzögerungen, was sich nach allen abgeschlossenen Übertragungen erheblich aufsummieren kann.
  2. Nach dem Verbindungsaufbau mit TCP entstehen weitere Zeitverluste durch den Verbindungsaufbau mit den Protokollen TLS und HTTP. Da fragt man sich zu Recht, warum kann ein Verbindungsaufbau bzw. Handshake nicht für alle beteiligten Protokolle gelten.
  3. TCP beinhaltet eine Fehlerbehandlung, bei der jedes eingehende Paket vom Empfänger bestätigt werden muss (ACK-Paket). Wenn ein TCP-Paket verloren geht, dann wird es erneut gesendet, wenn das dazugehörige ACK-Paket nach einer gewissen Zeit ausbleibt. Diese Zeit und die Zeit der erneuten Übertragung müssen zur Verzögerung addiert werden. Diese Verzögerung kann auch dazu führen, dass weitere Ressourcen erst angefordert werden, wenn die vorhergehende Datenübertragung vollständig war.

Leistungsmerkmale von QUIC

QUIC versucht durch einen integrierten Ansatz alle Schwächen von TCP und die separate Verarbeitung aller beteiligten Protokolle auszugleichen. Von TCP bekannte Merkmale wie Fehlererkennung und -korrektur gehören genauso zur Definition von QUIC dazu, wie ein integriertes Stau- und Engpass-Management.

  • Beschleunigung durch einen kombinierten Verbindungsaufbau
  • Beschleunigung durch höheren Datendurchsatz
  • Roaming und Multipath
  • Multiplexing
  • eigenes Schlüsselmanagement
  • integrierte Verschlüsselung

Beschleunigung durch einen kombinierten Verbindungsaufbau

Das größte Problem bei TCP ist der langsame bzw. verzögerte Verbindungsaufbau. Die meisten Internet-Nutzer werden von dem Zeitverlust kaum etwas bemerken. Doch bei komplexen Webseiten, für deren Aufbau viele Einzelverbindungen erforderlich sind, kann man eine Verzögerung deutlich wahrnehmen.
Mit QUIC findet ein kombinierter Verbindungsaufbau statt. Vergleichbar mit TCP, allerdings in einem Security-Kontext und parallel dazu der HTTP-Request. Bereits im ersten Paket werden Nutzdaten mitgeschickt.

Hinweis: Es stellt sich die Frage, ob komplexe und mit vielen Elementen überladene Webseiten überhaupt sein müssen. Es stellt sich außerdem die Frage, warum muss man an der Datenübertragung optimieren, wenn die Optimierung an den Inhalten viel einfacher wäre (Reduzierung der Objekte, Begrenzung der Ressourcen-Quellen, Reduzierung der Dateigröße, ...).

Beschleunigung durch höheren Datendurchsatz

QUIC basiert auf UDP, bei dem es sich um ein verbindungsloses Transport-Protokoll handelt. Anders als TCP arbeitet UDP ohne eigenes Verbindungsmanagement und ohne absenderseitige Quittierungen (ACK-Pakete). Das verkürzt die Round Trips zwischen Client und Server (hin und zurück).
Das simple UDP kann natürlich den Erfolg der Übertragung einzelner Pakete nicht garantieren. Darum muss sich das darüberliegende Anwendungsprotokoll selber kümmern. Bei QUIC wird dem Paketverlust durch eine Fehlerkorrektur (Forward Error Correction, FEC) vorgebeugt und so die Latenz durch die erneute Übertragung eines Pakets verringern.

Roaming und Multipath

Bei Verbindungen über TCP/IP besteht das Problem, dass ein Wechsel der Verbindung von WLAN zu Mobilfunk oder umgekehrt dazu führt, dass sich die IP-Adresse ändert. Das bedeutet, die Verbindung wird auf TCP/IP-Ebene abgebrochen und muss erneut aufgebaut werden. Bei QUIC werden die Pakete nicht anhand der IP-Adresse einer Verbindung zugeordnet, sondern über eine 64 Bit lange, eindeutige Verbindungs-ID. Auf diese Weise ist eine Verbindung nicht mehr an eine IP-Adresse gebunden. Somit ist Roaming, Multipath und sogar Link Aggregation möglich. Außerdem kommt QUIC dadurch auch mit jeglicher Form von NAT zurecht.

Multipath bezeichnet die Kommunikation mit einem Server über mehr als eine Leitung. Mehrere HTTP-Requests und -Responses lassen sich ohne zusätzliche Handshakes auf mehreren QUIC-Streams verteilen. Das reduziert die Latenz. Die Reihenfolge der Pakete spielt bei QUIC keine Rolle, sodass einzelne Datenströme andere nicht ausbremsen können.

Multiplexing

Ohne Multiplexing muss ein Server alle Anfragen eines Clients sequenziell, also nacheinander abarbeiten. Bei umfangreichen Webseiten kann das den Aufbau und die Darstellung der Webseiten im Client verzögern. Im Normalfall passiert das nicht. Aber es gibt das Phänomen des Head-of-Line-Blockings, bei dem eine Anfrage durch Paketverlust auf TCP-Ebene die Abarbeitung nachfolgender Anfragen blockiert. Das wird dadurch vermieden, dass es UDP-basiert arbeitet.

Authentifizierung und Verschlüsselung

QUIC bietet keinen unverschlüsselten Modus an, sondern erzwingt die Verschlüsselung auf Basis von TLS Version 1.3. Dabei wird der Header authentifiziert und zum großen Teil auch verschlüsselt. QUIC-Verbindungen sind damit besser gegen Replay-Attacken und Spoofing geschützt. Dem Client wird dazu ein "source address token" zugewiesen.
Version-Aliasing soll helfen, den Datenschutz weiter zu verbessern. Nur Client und Server kennen die tatsächliche Versionsnummer des verwendeten QUIC-Protokolls.

Probleme mit QUIC

Wie jedes andere Protokoll auch, führt die Nutzung von QUIC zu Problemen.

  • Keine unverschlüsselten Verbindungen
  • Erschwerte Verkehrssteuerung
  • Anfällig gegen Reflection- und Amplification-Angriffe
  • Erschwertes Firewalling

Keine unverschlüsselten Verbindungen

QUIC setzt die Verschlüsselung mit TLS zwingend voraus, wobei TLS-Zertifikate an Domain-Namen gebunden werden. Um diese zu validieren, müssen Clients mit dem Domain Name System kommunizieren. Was aber, wenn es in einem Unternehmen Anwendungen gibt, die vom DNS abgekoppelt sind und keine global verifizierbaren Zertifikate einsetzen?

In Unternehmen, die Datenverkehr in und aus ihrem Netzwerk kontrollieren wollen, tun sich ebenfalls schwer mit QUIC. Grundsätzlich wäre das kein Problem, weil QUIC Daten aus HTTP-Verbindungen enthält, allerdings geben QUIC-Pakete zu wenig Informationen über die Verbindung preis, weshalb die Gefahr besteht, dass UDP-Pakete und damit auch QUIC-Pakete netzseitig blockiert werden. Anwendungen, die nicht auf TCP umschalten können, würden dann nicht mehr funktionieren.
Durch Middleboxen und Firewalls unterbundene Verbindungen sind für Anwender besonders schwer zu identifizieren. In der Regel sieht es für den Anwender so aus, als ob das System nicht erreichbar ist.
Viele Sicherheitsexperten fordern das Ende-zu-Ende-Prinzip konsequent umzusetzen.

Erschwerte Verkehrssteuerung

Immer mehr Internet-Anwendungen nutzen verschlüsselte Protokolle. Was gut für die Privatsphäre ist, ist schlecht für die Verkehrssteuerung. Netzbetreiber können nur mit viel Mühe Datenpakete bestimmten Diensten zuordnen.
Das hat auch Folgen für Server-Betreiber. Sie können unter einer einzigen IP-Adresse viele Domains und Webseiten anbieten (virtuelles Hosting), was mit QUIC nicht mehr so gut funktioniert.

Anfällig gegen Reflection-/Amplification-Angriffe

Alle UDP-Anwendungen sind anfällig als Werkzeug für Reflection- und Amplification-Angriffe missbraucht zu werden. Hier gibt der Angreifer die IP-Adresse des Angriffsziels als Absender-Adresse an. Die gefälschten Anfragen sind meist relativ klein und die Antworten um ein Vielfaches umfangreicher, sodass sie das Angriffsziel überlasten.
Weil kein Handshake erfolgte, kann der Host die gefälschten Anfragen nicht einfach verwerfen.
QUIC setzt hier zumindest eine gewisse Hürde, indem es einen maximalen Faktor drei für den Größenunterschied zwischen Client-Request und Server-Response vor der vollständigen Adressverifikation definiert. Somit benötigen Angreifer zumindest eine entsprechend höhere Bandbreite.

Erschwertes Firewalling

Im Prinzip „tunnelt“ QUIC jeglichen Datenverkehr über UDP auf Port 443. Das verstärkt einen Trend, der seit Jahren im Zusammenhang mit HTTPS zu beobachten ist: Jegliche Art von Datenverkehr wird in Overlay-Protokolle verpackt und verhindert ein effektives und effizientes Firewalling. Der Datenverkehr lässt sich nur noch über aufwendige Verfahren, wie Deep Packet Inspection und das Aufbrechen von TLS-Traffic, analysieren.

QUIC: Ja, nein, vielleicht?

QUIC spart an vielen Stellen der Übertragung Zeit:

  • Mehrere Streams werden parallel abgearbeitet.
  • Bei Paketverlust wird die Verarbeitung nachfolgender Pakete, also außer der Reihe empfangener Pakete, nicht ausgebremst.
  • Es verschlüsselt die Nutzlast von Anfang an.

Wenn man die Funktionsweise von QUIC genau betrachtet, dann dient es lediglich dazu den TCP-Overhead (durch Verbindungsaufbau und Fehlererkennung) aus den HTTPS-Verbindungen herauszunehmen. Von den Vorzügen von QUIC profitieren insbesondere große Webservice-Anbieter, wie Google, Facebook und Microsoft. Diese verfügen über eine eigene Infrastruktur und Netze, die optimiert sind, die beste Qualität liefern und somit wenig von den Stärken von TCP profitieren. Diese Anbieter haben aber auch sehr komplexe Webseiten und Dienste, die durch QUIC schneller übertragen werden. Für die Für die meisten Webseiten-Betreiber ist QUIC völlig irrelevant. Für die funktioniert die Kombination aus TCP + TLS1v3 + HTTPS gut genug und ist insgesamt die bessere Lösung.

Insgesamt ist QUIC ein furchtbar komplexes Protokoll, was daran liegt, dass ursprünglich getrennte Protokollschichten (TCP, TLS und HTTP) bei QUIC ineinandergreifen.
Nun kann man darüber streiten, ob das akademische Trennen der Aufgaben innerhalb von Kommunikationsverbindungen nach einem Schichtenmodell überhaupt noch zeitgemäß ist. Die Trennung macht es leichter die Aufgaben einzelner Protokolle zu erklären, aber nicht, um Protokolle zu implementieren. Denn wenn man die einzelnen Protokolle auf verschiedenen Schichten mit ihren Aufgaben miteinander verschränkt, dann wird das schneller. Aber Vorsicht, es entstehen dabei auch komplexe Fehlersituationen, es wird schwerer wartbar und es wird weniger Spezialisten geben, die das Protokoll beherrschen können. Einfacher ist es, wenn die Protokolle schön nacheinander abgearbeitet werden. Es lässt sich dann zum Beispiel einfacher feststellen, wo der Fehler liegt, und auch leichter beheben.

Übersicht: TCP und UDP

Übersicht: TLS

Übersicht: HTTP

Weitere verwandte Themen:

Teilen

Alles was Sie über Netzwerke wissen müssen.

Netzwerktechnik-Fibel

Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.

Das will ich haben!

Alles was Sie über Netzwerke wissen müssen.

Netzwerktechnik-Fibel

Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.

Das will ich haben!

Videokonferenz-Server im eigenen Netzwerk betreiben

Videokonferenz-Server Jitsi im eigenen Netzwerk betreiben
  • Eigener Videokonferenz-Server auf Basis von Jitsi und WebRTC
  • Sicherer und Datenschutz-konformer durch den Eigenbetrieb
  • Unabhängig von externen Diensten
  • Externe Teilnehmer einladen
  • In jedem Webbrowser einfach zu bedienen
  • Mit Jitsi Meet ist eine Smartphone-App verfügbar

Bestellen Sie Ihre TrutzBox mit integriertem Videokonferenz-Server jetzt mit dem Gutschein-Code "elko50" und sparen Sie dabei 50 Euro.

Mehr über den Videokonferenz-Server