IETF-Vorsitzender im Interview: Lars Eggert über das QUIC-Protokoll

Seit Beginn der Internet-Ära prägt das Transmission Control Protocol (TCP) die Kommunikation im weltweit größten Netz – zahlreiche Anwendungen setzen auf TCP auf, von denen die Mail- und Webkommunikation nur zwei prominente Beispiele sind. Doch während die Internet-Hardware über Jahrzehnte rasant an Geschwindigkeit zugelegt hat und inzwischen sogar Privatnutzer Gigabit-Anschlüsse bekommen, schöpft TCP trotz vieler Optimierungen die Kapazität von Internet-Leitungen nicht immer aus.

Als größtes Manko gilt der langsame Verbindungsaufbau. Allein für die TCP-Schicht senden Sender und Empfänger üblicherweise drei Datenpakete hin und her (Drei-Wege-Handshake). Danach folgen die Aushandlungen der höheren Protokollschichten, etwa die TLS-Verschlüsselung und HTTP. Während dieses millisekundenfressenden Austauschs geschieht aus Anwendersicht nichts, außer dass sich Sender und Empfänger aufeinander abstimmen. Das klingt zwar nach vernachlässigbarem Zeitverlust, doch bei komplexen Webseiten spürt man leicht einen Verzug, weil für deren Aufbau viele Einzelverbindungen erforderlich sind. Die Macher der Internet-Protokolle wollen nun so viel Leerlauf wie möglich wegkürzen.

Dafür gibt es verschiedene Ansätze. Beim Protokoll Quick UDP Internet Connections (QUIC), dessen Entwicklung Google 2012 startete, haben die Entwickler Handshake-Wartezeiten durch Verschachtelung mit darüberliegenden Protokollen eingespart und die Verschlüsselung integriert. Die Fortschritte waren so vielversprechend, dass Google die Arbeiten 2017 an die Internet Engineering Task Force (IETF) zur Standardisierung weitergab – die IETF legte sich dann auf QUIC als Eigennamen fest.

Auf QUIC können diverse Anwendungen aufsetzen, etwa Webbrowser und -server. Aber nicht mit dem gängigen HTTP/2, sondern dem eigens angefertigten neuen HTTP/3. Inzwischen steht die Verabschiedung als IETF-Standard kurz bevor. Und schon jetzt läuft weltweit mehr als die Hälfte der Verbindungen zwischen Googles Chrome-Browser und Googles Servern per QUIC ab. Außerdem tüfteln diverse Arbeitsgruppen an eigenen Implementierungen. QUIC steckt auch schon in Beta-Versionen der Browser Microsoft Edge, Mozilla Firefox und Apple Safari. Facebook nutzt QUIC bereits für alle seine Services.

Über die Vorzüge und Nachteile des QUIC-Protokolls sprachen wir mit Lars Eggert, der Co-Vorsitzender der Working Group QUIC ist und mittlerweile die IETF leitet. Im Hauptberuf ist er Technical Director bei NetApp.

c’t: QUIC spart an vielen Stellen Zeit, beispielsweise indem es mehrere Streams parallel abarbeitet. Und bei Paketverlusten wird die Verarbeitung nachfolgender, also außer der Reihe empfangener Pakete nicht ausgebremst. Zudem verschlüsselt es die Nutzlast grundsätzlich. Bedeutet all das den Einstieg in ein komplexeres Internet?

Lars Eggert: Ja, QUIC ist ein sehr komplexes Protokoll. Das liegt aber daran, dass man Protokollschichten miteinander verschränkt. So quetscht man mehr Leistung heraus. Ich weiß nicht genau, von wem das Zitat stammt, aber es hieß immer schon: Das Schichtenmodell ist toll, um Protokolle zu erklären, aber schlecht, um Protokolle zu implementieren. Denn es sorgt für Leistungsverluste. Weil man erst auf dem TCP-Layer einen Handshake macht, dann auf dem TLS-Layer und schließlich auf dem HTTP-Layer. Will man diese Latenzen vermeiden, muss man zwischen den Schichten Abkürzungen herstellen und sie in einem Protokoll vereinen.

c’t: Wie steht QUIC im Vergleich zu ähnlichen Protokollen da?

Eggert: QUIC ist nicht viel komplizierter als TCP, TLS und HTTP zusammen. Für ein einzelnes IETF-Protokoll ist es zwar relativ komplex, doch alle Aufgaben zusammengenommen besteht kein großer Unterschied zu den drei separaten Protokollen.

c’t: Erhöht die Integration von QUIC die Fehleranfälligkeit?

Eggert: Nein. Es ist aber schon komplex, insbesondere beim Pre-Handshake. Denn man kombiniert den Verbindungsaufbau – also das was TCP macht – mit dem TLS-Security-Kontext, und sendet parallel auch den HTTP-Request. Deshalb muss man alle drei Handshakes zusammen betrachten. Was passiert, wenn einer davon scheitert, was ist dann mit den beiden anderen? Es ist schlicht einfacher, wenn man das seriell macht. Wenn man sie verschränkt, entstehen neue Fehlersituationen. Aber man gewinnt an Performance.

c’t: Das ist schon ein großer Wurf.

Eggert: Es ist zumindest in der IETF in letzter Zeit die umfangreichste Standardisierung, an die ich mich erinnern kann.

c’t: Ist QUIC das Transportprotokoll der großen Plattformen?

Eggert: Die haben natürlich den Gewinn, weil sie sehr komplexe Webseiten haben und QUIC diese schneller ausliefert. So profitieren aber auch die Enduser. Nicht nur in Mitteleuropa, sondern auch in den Regionen der Welt, wo die Handshakes wegen langsamerer Leitungen deutlich länger dauern können.

c’t: … weil Handshakes um so länger dauern, je länger ein Round-Trip dauert, also Hin- und Rückweg zusammengenommen. Und bei Übertragungsfehlern kommen zusätzliche Round-Trips durch Sendewiederholungen hinzu.

Eggert: Genau. Bei einem Round-Trip von 200 Millisekunden dauert es mit HTTPS schon mal zwei Sekunden, bis erste Bausteine einer Webseite ankommen. Mit QUIC dauert es meistens weniger als eine Sekunde.

c’t: Und in Westeuropa sind die Unterschiede kleiner, weil die Latenzen oft deutlich unter 50 Millisekunden liegen. Du hast immer gesagt, QUIC wird einen erklecklichen Teil des Verkehrs an sich ziehen. Was bleibt TCP-Land?

Eggert: Das ist schwer abschätzbar. Aber Webserver mit HTTP/2 werden zügig zum neuen HTTP/3 migrieren. Denn die Semantik ändert sich zu HTTP/3 nur minimal. Was mit Servern passiert, die noch HTTP 1.1 verwenden, ist offen. Die zugehörigen Applikationen sind wohl nicht so performancesensitiv und werden daher wohl nicht schnell wechseln. Es gibt noch andere Aspekte, die die Migration erschweren.

c’t: Kannst du ein Beispiel geben?

Eggert: HTTP/2 und HTTP/3 setzen die TLS-Verschlüsselung voraus, wobei TLS-Zertifikate an Domainnamen gebunden werden. Um diese zu validieren, müssen Clients mit dem Domain Name System kommunizieren. Es gibt aber in Firmen viele interne Anwendungen, die vom DNS abgekoppelt sind und daher keine global verifizierbaren Zertifikate einsetzen.

Und wenn Firmen-Administratoren auf Transparenz pochen und als Man-in-the-Middle TLS entschlüsseln wollen, dann werden sie QUIC unterbinden. Denn das übliche Entschlüsseln funktioniert mit QUIC nicht. Dieser Nutzerkreis wird auch TLS 1.3 unterbinden. Meine Hoffnung ist aber: Wenn QUIC Geschwindigkeitszuwächse bringt, werden die Benutzer über kurz oder lang sagen, liebe IT, wir brauchen das. Aber wenn QUIC in einem Szenario keinen Gewinn bringt, ist es auch nicht schlimm, wenn es dort ungenutzt bleibt.

c’t: Wann wird der Nerd QUIC auf seinem Webserver im Keller nutzen können?

Eggert: Mit dem Webserver im Keller ist ein Betrieb mit tagesaktueller Technik schwierig und die Geschwindigkeitsvorteile sind auch kaum messbar. Wenn man vorne mit dabei sein will und Milliardeneinnahmen dran hängen, dann ist man ein Großer und hat auch die Möglichkeiten, QUIC auszuschöpfen. Auch Apache wird irgendwann QUIC bieten und dann schaltest du das als kleiner Betreiber ein und es läuft. Der Gewinn ist dann nicht die Leistung, sondern die zusätzliche Sicherheit und Vertraulichkeit.

QUIC-Implementierungen

• Towards Securing the Internet of Things with QUIC
• interop status of various QUIC client and server implementations
• QUIC: A UDP-Based Multiplexed and Secure Transport (draft-ietf-quic-transport-34)
• Multipath Extension for QUIC (draft-an-multipath-quic-00)
• Beyond QUIC v1 – A First Look at Recent Transport Layer IETF Standardization Efforts

c’t: Wie spielt QUIC in die Verschlüsselungsdebatte hinein?

Eggert: Ziemlich stark. QUIC bietet keinen unverschlüsselten Modus an. Man kann natürlich geheime Schlüssel als Key-Logfiles exportieren. Damit kann man in Wireshark entschlüsseln und die Nutzdaten anschauen. Dafür muss der Client oder der Server unter deiner Kontrolle sein.

c’t: Aber mit dem Export der Key-Logfiles ist es nicht mehr sicher.

Eggert: Genau. Denn man hat keine Kontrolle darüber, was mit den Keys oder den Mitschnitten passiert. Facebook implementiert das daher nicht. Die sagen, wir wollen keinen Code-Pfad für Key-Files haben. Wir wollen nicht, dass unser Stack über Code-Injection oder anderweitig angreifbar wird.

c’t: Was sind die Zukunftspläne für QUIC? Die Liste der Entwürfe für Erweiterungen wird ja langsam unüberschaubar.

Eggert: Zu den großen Themen gehört Multipath, also Kommunikation mit einem Server über mehr als eine Leitung. Dafür gibt es mehrere Vorschläge. Version-Aliasing soll helfen, die Privacy weiter zu verbessern. Dabei kennen nur Client und Server die tatsächliche Versionsnummer des verwendeten QUIC-Protokolls.

c’t Ausgabe 9/2021

In c’t 9/2021 zeigen wir, wie sich der Raspberry Pi etwa als Router fürs VPN in Unternehmen und zu Hause nützlich machen kann. Wir haben Komfort, Hygiene und Sicherheit beim Bezahlen per Smartphone und Smartwatch untersucht, Büromäuse getestet und einen Farmbot für den heimischen Garten gebaut. Dies und noch viel mehr lesen Sie in Ausgabe 9/2021, die ab dem 9. April im Heise-Shop und am gut sortierten Zeitschriftenkiosk erhältlich ist.

(dz)