QUIC – Transferprotokoll

QUIC - Definition und Hintergründe des Transferprotokolls

QUIC ist ein von Google entwickeltes Netzwerkprotokoll, welches gegenüber anderen Protokollen einige Vorteile besitzt und als experimentelles Transferprotokoll erstmalig 2013 der Öffentlichkeit vorgestellt wurde. Der Name sollte ursprünglich ein Akronym sein und für die ausgeschriebene Bezeichnung “Quick UDP Internet Connections” stehen. Gemäß dem Namen soll QUIC die Datenpakete einfach und schnell über das UDP (User Datagram Protocol) versenden.

Google hat QUIC mit dem Ziel entwickelt, eine zuverlässige Alternative zur etablierten Sicherheitslösung (TCP, HTTP/2 sowie TLS/SSL) zu schaffen. Diese Alternative soll eine reduzierte Transport- und Verbindungsverzögerung aufweisen, den gleichen Schutz wie die etablierte Sicherheitslösung bieten und darüber hinaus Multiplex-Verbindungen ermöglichen.

Laut den Vorstellungen von Google soll QUIC die Verbindungskontrolle eigenständig regeln. Erfolgt der erste Handshake zwischen dem Sender und dem Empfänger, werden automatisch die Zertifikate und die Schlüssel ausgetauscht, die für eine Verschlüsselung der gesendeten Datagramme benötigt werden. Beim Multiplexing orientiert sich das Netzwerkprotokoll an dem experimentellen, TCP-basierten SPDY-Protokoll.

Google hat als Weiterentwicklung vom HTTP-Protokoll in der Vergangenheit das Protokoll SPDY entwickelt, jedoch konnte dieses aufgrund der vorhandenen Beschränkungen des TCP (Transmission Control Protocol) nicht voll umfänglich genutzt werden. Die Beschränkungen soll nun das auf UDP basierende QUIC-Protokoll aufheben.

QUIC wird hauptsächlich von HTTP/3 verwendet und kann darüber hinaus auch für weitere Protokolle wie DoQ (DNS over QUIC) als Basis dienen. Die ursprüngliche Form des Netzwerkprotokolls QUIC wurde am 20. Juli 2016 von Google zur Standardisierung eingebracht. Die IETF (Internet Engineering Task Force) arbeitet seit Februar 2017 an einer Standardisierung und konnte den QUIC-Standard im Mai 2021 als RFC 9002, RFC 9001, RFC 9000 und RFC 8999 veröffentlichen.

Ende 2020 gab das soziale Netzwerk Facebook bekannt, dass sowohl die Android- und iOS-Apps als auch die Server-Infrastruktur von Facebook auf QUIC umgestellt wurden. Mittlerweile werden 75 Prozent des Facebook-Datenverkehrs über das Netzwerkprotokoll übertragen. Dadurch profitieren die Nutzer von einigen messbaren Verbesserungen in Form von geringeren Latenzzeiten und Fehlerraten.

quic mit http/3

Eigenschaften und Besonderheiten von QUIC

Das Netzwerkprotokoll schreibt vor, dass alle gesendeten Daten stets mit TLS 1.3 (Transport Layer Security) verschlüsselt übertragen werden müssen. Darüber hinaus werden 2 unterschiedliche Header (Köpfe) verwendet:

– ein längerer Header, der mehr Informationen enthält und dem Verbindungsaufbau dient
– ein kürzerer Header, der zum Einsatz kommt sobald die Verbindung hergestellt worden ist

Ist der Host bekannt, wird die TLS-Verschlüsselung beim Herstellen einer neuen Verbindung nicht mehr neu ausgehandelt und dadurch wird automatisch ab dem ersten gesendeten Datenpaket verschlüsselt übertragen. Der Header wird größtenteils verschlüsselt und somit können bei QUIC im Vergleich zu älteren Netzwerkprotokolle deutlich weniger Metadaten ausgelesen werden. Dies schützt auf der einen Seite die Privatsphäre der beteiligten Nutzer und erschwert auf der anderen Seite das Netzwerk-Management und -Monitoring.

QUIC bietet den höher liegenden Schichten Multiplex-Verbindungen an und dadurch können mehrere Datenströme vollkommen unabhängig voneinander gesendet und empfangen werden. Darüber hinaus soll QUIC die Transport- und Verbindungslatenz verringern und durch eine Geschwindigkeitsabschätzung (funktioniert in beide Richtungen) Überlastungen vermeiden.

Im Gegensatz zu anderen Protokollen werden die Staukontrolle-Algorithmen an beide Endpunkte des User-Space (nicht an den Kernel-Space) verlagert und dies ermöglicht eine schnelle Verbesserung der Algorithmen. Des Weiteren lässt sich das Netzwerkprotokoll mit einer FEC (Vorwärtsfehlerkorrektur) versehen, damit die Leistung bei den zu erwartenden Fehlern noch weiter verbessert werden kann.

Die grundlegenden Protokollspezifikationen (QUICv1) sind seit Anfang 2021 standardisiert. Zu den aktuell am häufigsten diskutierten Erweiterungen vom QUIC gehört vor allem Multipath. Die Erweiterung soll analog zu MPTCP (Multipath TCP) einen parallelen Verbindungsaufbau zwischen mehreren Endgeräten und einem Server über mehrere Pfade ermöglichen.

Google Chrome war der erste Internetbrowser, der das ursprünglich von Google entwickelte QUIC-Protokoll clientseitig unterstützt. Seit der Version 72 unterstützt der Mozilla Firefox die von der Internet Engineering Task Force entwickelte QUIC-Version. In Google Chrome ist das QUIC-Protokoll standardmäßig aktiviert, während es in anderen Browsern (unter anderem in Opera) standardmäßig deaktiviert ist und erst manuell freigeschaltet werden muss.

Vorteile von QUIC

Schneller Aufbau von Verbindungen

QUIC besitzt im Vergleich zu TCP eine deutlich höhere Performance und kann dadurch Verbindungen wesentlich schneller aufbauen. Selbst ohne eine zusätzliche Verschlüsselung benötigt das klassische Transportprotokoll aufgrund des “Drei-Wege-Handshakes” um einiges mehr Schritte als die auf UDP basierende Lösung von Google.

Über QUIC werden Verbindungen mit nur einem Paket (bei der ersten Verbindungsaufnahme werden 2 Pakete benötigt) gestartet – nichtsdestotrotz werden alle notwendigen HTTPS- und TLS-Parameter übermittelt. Dadurch kann ein Client sofort Daten an einen beliebigen Server senden, ohne auf eine Antwort von diesem zu warten, während bei TCP zunächst einmal die Server-Bestätigung eingeholt und verarbeitet werden muss.

QUIC ermöglicht Multiplex-Verbindungen

Das TCP-Protokoll identifiziert Verbindungen, indem es auf die IP-Adressen und TCP-Ports der verbundenen Systeme zurückgreift. Dadurch können Clients über eine einzige Verbindung nicht über mehrere Ports mit einem Server kommunizieren. QUIC löst dieses Problem, indem es auf die 64-Bit-Verbindungserkennung und auf verschiedene Streams zurückgreift und dadurch den Datentransport innerhalb einer einzigen Verbindung ermöglicht.

QUIC-Verbindungen sind nicht an eine bestimmte IP-Adresse, an einem bestimmten Endpunkt oder an einen bestimmten Port gebunden. Zusätzlich zu den Multiplex-Verbindungen ermöglicht QUIC auch einen Wechsel der IP-Adresse und des Ports.

Es werden einzigartige Sequenznummern vergeben

Jedes einzelne Datensegment der QUIC-Verbindung bekommt seine eigene Sequenznummer, dabei spielt es keine Rolle, ob es sich um ein weitergeleitetes oder um ein originales Segment handelt. Beim TCP-Protokoll gibt es diesen Unterschied nicht und somit können die Hosts den Sequenzstatus auch nicht ermitteln. Die fortlaufende Paket-Markierung bei QUIC ist ein großer Vorteil, da dies eine noch genauere Schätzung der RTT (Round Trip Time, Paketumlaufzeit) ermöglicht.

Packet Pacing (Überlastungssteuerung)

Das TCP-Protokoll versendet die Daten so schnell als möglich, was für eine schnelle Verbindung zwar vorteilhaft aber mit einer gewissen Verlustrate verbunden ist. Gehen Pakete verloren wird automatisch eine neue Übertragung initiiert. Hierfür verkleinert das Protokoll jedoch das Staufenster und dadurch werden die Daten meist nur stoßweise übertragen.

Beim QUIC-Protokoll werden solche Lastspitzen mithilfe des Packet Pacing (Überlastungssteuerung) vermieden. Die Übertragungsrate wird automatisch begrenzt und somit kommt es bei Verbindungen mit einer geringen Bandbreite auf keinen Fall zu Überlastungen.

Laut Cloudflare werden schon über 12% des Datenverkehrs mit quic über http/3 transferiert.

QUIC bietet eine Vorwärtsfehlerkorrektur

Sollte ein Paket beim Datentransport über das QUIC-Protokoll verloren gehen, ist dies kein großes Problem. Dank des einfachen auf XOR basierten Fehlerkorrektursystems müssen die Daten in einem solchen Fall nicht erneut übertragen werden. Sie können zu jeder Zeit mithilfe der FEC-Pakete (Forward Error Correction) über Back-ups der originalen Pakete rekonstruiert werden. Die Vorwärtsfehlerkorrektur von QUIC funktioniert jedoch nicht, falls mehrere Pakete in einer Datengruppe fehlen.

Authentifizierung und Verschlüsselung

Sowohl bei der Planung als auch bei der Konzeptionierung von QUIC stand der Sicherheitsaspekt stets im Mittelpunkt.

Beim TCP-Protokoll liegt der Header der verwendeten Datenpakete stets im Klartext vor und lässt sich somit ohne eine Authentifizierung lesen. Dadurch sind Paketmanipulationen und Man-in-the-Middle-Attacken keine Seltenheit bei TCP.

QUIC-Datenpakete sind zum größten Teil verschlüsselt (samt Payload) und immer authentifiziert. Alle Header-Teile, die nicht verschlüsselt werden, sind durch die Authentifizierung vor Manipulation und Injektion geschützt.

QUIC ist von der Hardware unabhängig

Während TCP von den Geräten und Plattformen unterstützt werden muss, muss das QUIC-Protokoll einfach nur auf Anwendungsebene unterstützt werden. Somit können die Softwareentwickler selbst entscheiden, ob sie das QUIC-Protokoll einbinden oder nicht.

Aktuell sind Verbindungen über das QUIC-Protokoll über Google Chrome, Opera, das Serverprogramm Caddy und über die Webserver- und Load-Balancing-Produkte aus dem Hause LiteSpeed Technologies möglich. Darüber hinaus gibt es noch mehrere Applikationen von Drittanbietern, die das Protokoll unterstützen.

QUIC - Nachteile und Probleme

Das QUIC-Protokoll wird in der Zukunft höchstwahrscheinlich immer häufiger verwendet werden und dies liegt vor allem an dem großen Engagement der IETF. Seit Gründung dieser Arbeitsgruppe hat sich das QUIC-Protokoll von einem zuvor stark auf Google ausgerichteten Protokoll zu einem universelle Netzwerkprotokolle entwickelt. Der Optimierungsprozess von QUIC ist jedoch längst noch nicht erfolgreich abgeschlossen, denn das QUIC-Team muss noch einige Probleme lösen.

Das Thema Sicherheit spielt eine zentrale Rolle und sorgt immer wieder für Diskussionsstoff. Durch die Authentifizierung und die Verschlüsselung wird ein sicherer Datentransport gewährleistet, jedoch sorgt dies für einen größeren Nachteil: Im Header sind deutlich weniger Klartextinformationen als bei TCP-Verbindungen enthalten und dies erschwert die Traffic-Regulierung, das Netzwerk-Management und die Fehlerbehebung bei QUIC-Verbindungen.

Aufgrund der fehlenden Klartextinformationen können die Hersteller von Firewalls und die Netzbetreiber eine konstant hohe Qualität ihrer Internetdienste nicht sicher gewährleisten. Ein aktuell weiteres Problem von QUIC: Die automatische Überlastungssteuerung kann bei den Datenverbindungen mit hohen Bandbreiten in Ausnahmefällen zu schlechteren Übertragungsraten führen.

DNS over QUIC

Fast alle Internetdienste beginnen die Kommunikation mit der Namensauflösung der Domain. Die dafür nötigen Nutzeranfragen und Antworten der DNS-Server (Domain Name System Server) werden meistens unverschlüsselt gesendet und können von unbefugten Dritten eingesehen werden. Somit lässt sich ohne großen Aufwand herausfinden, welche Internetseiten die Nutzer besuchen.

Die Internet Engineering Task Force will den bedeutsamen Datenverkehr bereits seit längerem verschlüsseln und hat die beiden Verfahren DoH (DNS over HTTPS) und DoT (DNS over TLS) entwickelt. Nun haben die Experten ein neues Verschlüsselungsverfahren namens DoQ (DNS over QUIC) veröffentlicht. Da das QUIC-Protokoll moderne Verschlüsselungsverfahren wie TSL 1.3 unterstützt, soll die Namensauflösung von einer höheren Sicherheit und einer besseren Performance profitieren.

QUIC arbeitet UDP-basiert, unterstützt das Multiplexing und verhindert das unerwünschte Head-of-Line-Blocking. Laut Christian Huitema von IEFT ist die bereits so gut wie fertige Version 1.0 von QUIC die beste Gelegenheit, um dem Protokoll den DNS-Transport zu lehren. Dank dem implementierten TLS 1.3 wird es für unerwünschte Dritte um einiges schwerer den DNS-Verkehr abzuhören.

Darüber hinaus landen bei QUIC noch mehr Daten des Headers in dem sicher verschlüsselten Body und können von Dritten nicht eingesehen werden. Das QUIC-Protokoll ähnelt an dieser Stelle dem DNS-over-TLS und verbindet die Vorteile von DoT mit den Vorteilen von UDP.

Aktuell spezifiziert DNS over QUIC ausschließlich die Verbindungen vom Stub-Resolver der Nutzer und dem rekursiver Resolver des DNS-Providers. Die IETF will in Zukunft auch das Teilstück der DNS-Kommunikation – vom rekursiven Resolver zum autoritativen Nameserver – verschlüsseln. Dies erfordert jedoch eine Zusammenarbeit zwischen allen Nameserver-Betreibern weltweit.

DoQ im Vergleich zu DoT und DoH

DoQ besitzt eine große Ähnlichkeit zu DoT, jedoch kommt das TCP-Protokoll bei QUIC nicht mehr zum Einsatz. DoH setzt aktuell direkt auf TCP, es kann aber zukünftig auf das fast fertig gestellte HTTP/3 wechseln. Dadurch wird aus der Bezeichnung DoH in Zukunft die Abkürzung DoH3 (DNS-over-HTTPS3). Laut Huitema wird aus dem aktuellen Dreikampf womöglich ein Zweikampf zwischen DoH3 und DoQ.

Produkte mit QUIC und http/3

Alle Webhosting Tarife bei uns beinhalten bereits QUIC als Transferprotokoll mit http/3 Unterstützung. Es ist bei uns immer alles auf dem neuesten Stand der Technik ohne Aufpreis nutzbar. Managed Server bieten wir ebenfalls seit langer Zeit mit QUIC an. Agenturen nutzen für ihre Kunden bei uns die neueste Technik und finden es einfach klasse.

Leave a Reply

Your email address will not be published. Required fields are marked *

Teile diesen Beitrag
Share on facebook
Share on twitter
Share on pinterest
Share on telegram
Share on whatsapp
Share on email