Googles Netz-Protokoll Quic: Werbung und Warnungen beim IETF-Meeting
Ein Carrier-Netz mit eigenen Seekabeln hat Google schon, und einen eigenen Browser natürlich auch. Fehlt nur noch, was dazwischen liegt: ein neues Transportprotokoll. So wirbt das Unternehmen jetzt für den regen Einsatz von Quic.
(Bild: Google)
Das Interesse an Googles neuem Transportprotokoll Quic ist groß: Beim jüngsten Treffen der Netzwerkexperten der Internet Engineering Task Force (IETF) Ende Juli quizzten rund 250 Zuhörer die Quic-Entwicklertruppe. Meist gab es Lob für die Konkurrenz zu TCP, das mit über 35 Jahren ein Dinosaurier von einem Protokoll ist. Doch Quics Leichtigkeit ist nicht ganz umsonst zu haben. In Sachen Vertraulichkeit könnte durchaus nachgebessert werden, meinen Experten.
Auf die Beschleunigung durch Quic sind die Entwickler bei Google sehr stolz. Der Aufbau von Webseiten sei im Mittel fünf Prozent schneller. Fast immer gewinnen Websuchen per Quic bis zu einer Sekunde. Das hat Googles Quic-Entwicklerteam gemessen. Dieser Zeitgewinn, der sich in mehr Anfragen, mehr Transaktionen ummünzen lässt, ist das Hauptmotiv für die Entwicklung des Transportprotokolls. "Google will das Netz schneller machen", sagte Yana Iyengar, einer der Quic-Entwickler.
Verbindungsaufbau ohne Roundtrips
Erreicht wird der Speed unter anderem durch das Einsparen von Roundtrips beim Handshake. 75 Prozent der Verbindungen kommen ganz ohne Hin-und-Her beim Verbindungsaufbau aus. Bei UDP und TCP sind Handshake und, wo nötig, Schlüsseltausch voraus zu erledigen. Der Effekt: Mit Quic ist der Verbindungsaufbau im Mittel doppelt so schnell. Googles aktuelle Zahlen sprechen von einer Verringerung der Latenz beim Verbindungsaufbau um 50 bis 80 Prozent.
Positive Effekte haben die Google-Entwickler auch bei Youtube gemessen. Es gebe 30 Prozent weniger Rebuffering. Das Youtube-"Erlebnis" sei einfach besser. Allerdings muss man bei den schönen Statistiken berücksichtigen, dass die Datenbasis zwar groß ist, aber eben nur aus Chrome-Verbindungen zu Google-Servern besteht. Ein Rückgriff auf TCP war in insgesamt 8 Prozent der Verbindungen notwendig, vor allem bedingt durch ein Rate Limiting von UDP.
Mehr Implementierungen erwünscht
Google wünscht sich jetzt zuerst mehr Implementierungen. Dafür warb bei der IETF-Veranstaltung gleich ein ganzes Team. Das Einbringen in den Standardisierungsprozess steht dagegen nicht im Vordergrund, unterstrich Ted Hardie, Senior Engineer bei Google. Durch die geplante Publikation der Quic-Spezifikation als "individual submission" behält das Unternehmen die Kontrolle über die weitere Entwicklung. Würde man einen IETF-Standard anstreben, dürften alle mitreden. Lieber möchte Google sein Quic erst einmal weiter verbreitet sehen.
Eine positive Rückmeldung kam von Christian Huitema von Microsoft. Auf solche Verbesserungen beim Transportprotokoll habe man lange gewartet, die Multipath-Funktionalität und die Vermeidung von Head-of-Line-Blocking seien wirklich gut. Er könne kein Datum angeben, wann Windows mit Quic ausgeliefert werde, fügte Huitema hinzu. Er hat Quic in 3000 Zeilen Code umgesetzt und spricht von "machbarer Komplexität".
Datenschutzprobleme?
Gleichzeitig gab es auch mahnende Stimmen, die die Datenschutzfreundlichkeit von Quic in Frage stellten. Was die begeisterten Entwickler als großen Vorteil beschrieben, nämlich die Verbesserung beim Aufrechterhalten von Sessions, während man durch verschiedene Netze wandert, erlaubt auch ein aus Nutzersicht wenig attraktives Tracking, warnte Daniel Kahn Gillmore von der American Civil Liberties Union (ACLU). Die ID, die die IP-Adresse zur Identifikation der Sessions ersetzt, ist aus Datenschutzsicht kein Meisterwerk. Der Zero-Roundtrip-Verbindungsaufbau begünstige überdies Replay-Attacken, gab Tanja Lange, Kryptoexpertin der Universität Eindhoven, zu bedenken.
Auch eine Reihe anderer technischer Fragen sind noch offen: Die versprochene Forward Error Correction, mit der mögliche Fehler durch Redundanz in den Verbindungen ausgeglichen werden sollen, sei noch experimentell, hieß es. Iyengar nannte FEC als Punkt, an dem weiter gearbeitet werde und versprach, die Datenschutzfragen aufzugreifen. Spannend wird nun, wie weit große Anbieter sich auf Quic einlassen und es damit zu einem, wenn auch nicht standardisierten, so doch De-facto-Standard neben UDP und TCP machen. Wer die Diskussionen um Quic verfolgen will, kann das in dieser Google-Gruppe tun. (ea)
