Zeitenwende im Internet durch das QUIC-Protokoll

Eine Zeitenwende vollzieht sich gerade im Internet. Vielen dürfte das gar nicht bewusst sein, denn für die meisten sind die Netzwerk-Protokolle, welche das Internet antreiben, unsichtbar. Nur bei Problemen oder wenn man eine fortgeschrittenere Netzwerk-Anwendung benutzt, dann stößt man schnell auf Abkürzungen wie IP (Internet-Protocol), UDP (User-Datagram-Protocol) und TCP (Transport-Control-Protocol). Diese bezeichnen grundlegende Netzwerk-Protokolle, welche in den 1970 und 80er Jahren entwickelt wurden.

Worum geht es jetzt konkret? Das TCP-Protokoll wird durch das QUIC-Protokoll abgelöst. Am 27.05.2021 wurde der entsprechende Standard verabschiedet (Quelle 1).

Um die Bedeutsamkeit etwas zu betonen. Das TCP-Protokoll ist, als Metapher gesprochen, der Motor des World-Wide-Webs. Der weltweite Abruf von Webseiten erfolgt derzeit über das Protokoll-Gespann HTTP und TCP. Die nächste Version des HTTP-Protokolls (HTTP/3) wird nun aber alleinig auf QUIC als Transport-Protokoll setzen.

Bis das TCP-Protokoll wirklich aus dem Internet verschwindet, vergehen sicherlich noch Jahre, wenn nicht Jahrzehnte. Doch man kann sich darauf einstellen, dass so nach und nach die Webserver auf QUIC umgestellt werden. Vermehrt werden auch andere Netzwerk-Anwendungen in Zukunft auf das QUIC-Protokoll setzen. Und ehe Sie sich versehen, werden Sie plötzlich auch in Ihrem Heimnetzwerk mit dem QUIC-Protokoll konfrontiert werden.

Alles gute Gründe das QUIC-Protokoll in den Grundzügen kennenzulernen. Dieser Artikel soll Ihnen dabei Hilfestellung leisten und die Eckpunkte des QUIC-Protokolls vorstellen.

1. Die wesentlichen Unterschiede zwischen TCP und QUIC
   
2. Sicherheit der Datenübertragung mit QUIC
   
3. Stand der Einführung des QUIC-Protokolls und Rückwärtskompatibilität

Notiz: Der Begriff „QUIC“ ist keine Abkürzung wie viele andere technische Begriffe, sondern steht als Wort für sich (Quelle 2).

Die wesentlichen Unterschiede zwischen TCP und QUIC

Um die Unterschiede zu erläutern, wird erst einmal kurz beschrieben was sich nicht ändert. So ist QUIC wie TCP ein verbindungsorientiertes Protokoll. Sprich es wird eine Verbindung aufgebaut, Daten übertragen und dann idealerweise die Verbindung wieder kontrolliert abgebaut. Ebenfalls überträgt QUIC wie TCP die Daten zuverlässig. Das bedeutet, gibt es einen Übertragungsfehler in einem Datenpaket, dann werden die Daten erneut übertragen. Eine Anwendung kann davon ausgehen das aus Ihrer Sicht keine Daten verloren gehen. Als letztes sorgt sich QUIC, wie TCP, um die Flusskontrolle. Die Flusskontrolle ist verantwortlich dafür, dass nur soviel Daten übertragen werden, dass keine oder nur vernachlässigbar kleine Datenstaus auftreten. Damit wird die Zeit minimiert welche ein Datenpaket für die Übertragung benötigt.

Damit soll sich QUIC im Prinzip für alle Anwendungsfälle eignen, für welche derzeitig TCP verwendet wird.

Warum also eine Neuerung ?

1. Der Verbindungsaufbau wird deutlich beschleunigt. So halbiert QUIC für den Verbindungsaufbau ca. die Anzahl der Anfragen/Antworten, im Vergleich zu der Kombination TCP und TLS (Transport-Layer-Security). TLS ist ein Verschlüsselungsprotokoll, welches jetzt Bestandteil des QUIC-Protokolls ist.

2. QUIC erlaubt die parallele Datenübertragung vieler Streams über eine Verbindung, mit einer effizienten Neuübertragung von Daten im Fall von Übertragungsfehlern. Mit ein paar Tricks kann man auch mittels TCP parallel Daten übertragen (siehe z.B. HTTP/2), doch sobald Übertragungsfehler auftreten wird die Fehlerbehandlung unter TCP ineffizient.

3. Wenn z.B. ein Smartphone von einem Mobilfunknetz in ein WLAN wechselt, dann musste bis dato das Smartphone erst feststellen das die TCP-Verbindungen unterbrochen sind und danach diese wieder neu aufbauen. QUIC führt eine Verbindungs-ID ein, welche es ermöglicht eine unterbrochene Verbindung einfach fortzuführen. Ein Wechsel zwischen Netzwerken funktioniert somit mit dem QUIC-Protokoll reibungsloser.

Die ersten beiden Punkte machen sich besonders beim Abruf von Webseiten bemerkbar. Sowohl der schnellere Verbindungsaufbau als auch die zuverlässigere gleichzeitige Übertragung vieler Daten, ermöglicht ein beschleunigtes Laden. Das kann sich für den einzelnen Endanwender etwas bemerkbar machen, wenn komplexe Webseiten geladen werden. Einen deutlicheren Gewinn haben die Unternehmen welche große Rechenzentren unterhalten, dort summiert sich der Leistungsgewinn. Auch die Betreiber komplexer Webseiten gewinnen deutlich, da die Webseiten schneller geladen werden und damit wird die Akzeptanz bei den Anwendern verbessert.

Notiz: Wer übrigens selbst mal gerne schauen möchte wie der Abruf einer Webseite von statten geht kann folgende Webseite verwenden, www.uptrends.de/tools/website-ladezeit-check . Dort die URL (Namen) einer beliebigen Webseite eingeben und sich das Ergebnis ansehen.

Notiz: Schon in der Vergangenheit war es so, dass jedweder Effizienzgewinn bei einer Technologie an anderer Stelle aufgebraucht wurde, um mal mehr, mal weniger sinnvolle Neuerungen einzuführen. Dieses Phänomen wird durch den Begriff „Rebound-Effekt“ beschrieben. Es steht zu befürchten, dass das auch im Internet passiert und Webseiten eher noch komplexer werden. Das würde den spürbaren Effekt für den Endanwender konterkarieren.

Das nachfolgende Diagram illustriert den Unterschied im Protokollaufbau. Bei Interesse finden Sie mehr Informationen über das Schichtenkonzept von Protokollen hinter diesem Link.

QUIC soll sich dabei nahtlos in die vorhandene Netzwerkinfrastruktur einfügen. Das wird dadurch erreicht, dass QUIC auf UDP (User-Datagram-Protocol) aufsetzt und aus Sicht eines Netzwerks „nur“ eine Anwendung darstellt. Spätestens hier wird es für auch für den technisch affinen Heimnetzwerkbetreiber interessant.

Zu einem wird man unversehens mit UDP-Datenpaketen für den Port 443 konfrontiert. Ohne das Wissen über QUIC würde man misstrauisch werden und evtl. einen Trojaner vermuten. Sie, der Sie diesen Artikel lesen, wissen es jetzt aber besser.

Zum anderen wird manchmal die Firewall im Internet-Router so konfiguriert das für Gäste nur HTTP(s) über die TCP-Ports 80 und 443 zugelassen ist, also der Abruf von Webseiten, bzw. Anwendungen welche HTTP(s) verwenden. Mittelfristig sollte man aber auch die Verwendung von UDP mit dem Port 443 erlauben.

Notiz: Der Port 443 ist unter TCP für die Übertragung von HTTPS vordefiniert. Also im Prinzip die verschlüsselte Übertragung von Webseiten. Unter UDP war dieser Port unbenutzt. Da mit QUIC eine Übertragung immer verschlüsselt abläuft, hat man jetzt einfach diesen bekannten Wert für UDP verwendet.

Bringt die Einführung des QUIC-Protokolls auch Nachteile ?

Die Antwort ist, ja.

Der Nachteil ist schlicht, dass das Internet komplexer und schwerer verständlich wird. Zu einem verschwindet TCP nicht sofort und man muss jetzt für sehr lange Zeit Kenntnis von beiden Protokollen haben, wenn man das Internet bzw. die Datenübertragung verstehen möchte.

Ferner ist das QUIC-Protokoll selbst komplexer als TCP, alleine dadurch das die Funktionalitäten von TCP und TLS in einem Protokoll zusammengefasst werden. Komplexität beinhaltet auch immer das Risiko von Fehlern, somit ist zu erwarten das Fehler auftreten. Ob und wann diese Fehler auftreten, wie sich diese bemerkbar machen, das wird man als Endanwender kaum mitbekommen, da sich QUIC sozusagen unter der Motorhaube Ihres Computers, bzw. Ihres Browsers befindet.

Als letztes vermute ich das Administratoren von Unternehmensnetzwerken das QUIC-Protokoll für die Konfiguration und Kontrolle der Firewalls in betracht ziehen müssen. Einfacher wird ihre Arbeit dadurch nicht.

Sicherheit der Datenübertragung mit QUIC

Es wurde eingangs schon erwähnt, dass die Verschlüsselung von Verbindungen fester Bestandteil des QUIC-Protokolls ist. Zu diesem Zweck wurde das schon existierende TLS-Protokoll 1.3 in das QUIC-Protokoll integriert (Quelle 3).

Somit sind QUIC-Verbindungen immer verschlüsselt. Eine Option für experimentelle Zwecke unverschlüsselte QUIC-Verbindungen zuzulassen, wurde, soweit mir ersichtlich, nicht umgesetzt.

Als Resultat müssen Geräte (Server), zu welchen eine Verbindung per QUIC aufgebaut werden soll, sich immer per Zertifikat ausweisen können. Das verringert das Risiko das Verbindungen über einen unbekannten Mittelsmann laufen, welcher mit lauscht oder schlimmer noch bösartige Daten zurück liefert. Die Geräte müssen aber solche Zertifikate integrieren und nach Ablauf erneuern. Das war schon in der Vergangenheit eine Quelle für Fehler (Beispiel: Quelle 4).

Notiz: Sie möchten mehr über Zertifikate, die Ausweise des Internets, wissen, dann lesen Sie doch den hier verlinkten Artikel.

Durch die Integration von TLS in das QUIC-Protokoll, werden nicht nur die Anwendungsdaten verschlüsselt sondern auch viele Daten, welche die Verbindung als solches kontrollieren und steuern. Falls jetzt jemand eine QUIC-Verbindung mitschneidet, finden sich als Resultat weniger auswertbare Transport- und Meta-Daten.

Kurzum, Ihre Privatsphäre wird besser geschützt und das Risiko der Verbindung zu einem bösartigen Ziel sinkt etwas.

Stand der Einführung des QUIC-Protokolls und Rückwärtskompatibilität

Es mag bis lang so klingen, aber wirklich neu ist das QUIC-Protokoll nicht. Google arbeitete schon in der ersten Dekade der 2000er Jahre an einem Nachfolger des TCP-Protokolls. Im Jahr 2012 hat Google eine frühe Version des QUIC-Protokoll zur Standardisierung vorgeschlagen. Es brauchte dann ca. neun Jahre bis das zuständige Standardisierungsgremium, die IETF, und viele, viele Interessensgruppen QUIC überarbeitet und als offiziellen Internet-Standard verabschiedet haben.

Ein Resultat des langen Zeitraums ist, dass es schon Umsetzungen des QUIC-Protokolls gibt bzw. das das QUIC-Protokoll schon heute real im Einsatz ist.

So verwendet der Browser „Chrome” seit geraumer Zeit das QUIC-Protokoll zu Gegenstellen (Webservern), welche dieses Protokoll ebenfalls unterstützen. Der Browser „Firefox” soll QUIC noch in diesem Sommer offiziell integrieren. Apps von Facebook können bereits über das QUIC-Protokoll mit den Facebook-Servern kommunizieren. Und auch Microsoft arbeitet daran das QUIC-Protokoll unter Windows zu integrieren.

Eine Übersicht über verschiedene Implementierungen können Sie hinter folgendem Link finden, https://github.com/quicwg/base-drafts/wiki/Implementations .

Es wird aber noch viele Jahre oder gar Jahrzehnte dauern bis alle Webserver, alle Anwendungen im Internet das QUIC-Protokoll unterstützen. So gibt es z.B. von dem sehr weit verbreiteten Apache-Webserver noch keine veröffentlichte Version welche QUIC unterstützt.

Somit müssen Browser in der Lage sein sich noch lange Zeit zu Zielen zu verbinden, welche rein HTTP/1.1 oder HTTP/2 über TCP anbieten. Gleichzeitig sollen natürlich die Vorteile des QUIC-Protokolls genutzt werden, wenn die Gegenstelle das erlaubt.

Wie kann das funktionieren ?

Der Mechanismus ist simpel. Jeder Browser nimmt als Voreinstellung per HTTP/1.1 oder HTTP/2 Verbindung mit einem gewünschten Webserver auf. Die Webseite wird dann noch mittels der älteren Protokolle an den aufrufenden Browser ausgeliefert. Falls der Server allerdings QUIC unterstützt, wird diese Information ebenfalls mit geliefert. Der Browser kann jetzt diese Information speichern und bei einem zukünftigen Verbindungsaufbau berücksichtigen.

Ich hoffe ich konnte etwas dazu beitragen das Sie, wenn Sie in Zukunft das Schlagwort „QUIC“ hören, eine gute Idee haben was dahinter steckt,

Matthias (22.06.2021)

Quelle [1]: https://datatracker.ietf.org/doc/rfc9000/
Quelle [2]: https://en.wikipedia.org/wiki/QUIC
Quelle [3]: https://datatracker.ietf.org/doc/html/rfc9001
Quelle [4]: https://www.heise.de/news/Elektronische-Gesundheitskarte-Wer-bezahlt-den-Pannendienst-4775747.html
Quelle [5]: https://blog.cloudflare.com/the-road-to-quic/
Quelle [6]: https://www.heise.de/news/IETF-Vorsitzernder-im-Interview-Lars-Eggert-ueber-das-QUIC-Protokoll-6003458.html
Quelle [7]: https://cabulous.medium.com/http-3-quic-and-how-it-works-c5ffdb6735b4