Google: Internet-Transportprotokoll Quic könnte TCP-Entwicklung voranbringen
Die Entwicklung eines neuen Transportprotokolls fürs Internet im Hause Google ließ Experten aufhorchen. Jetzt liegt Quic einem Editor der IETF vor. Eine komplette Standardisierung strebt der Konzern aber überraschenderweise zunächst nicht an.
(Bild: Google)
Googles neues Transportprotokoll Quic wird zunächst als individueller Entwurf bei der Internet Engineering Task Force landen (IETF). Google hatte unlängst das TC-Protokoll mit Quic in Frage gestellt. TCP nutzen beispielsweise Browser, um Web-Seiten abzurufen. Kritiker sehen dabei zwar durchaus den Bedarf, Internet-Übertragungen zu beschleunigen, zweifeln jedoch, ob sich ein gänzlich neues Protokoll durchsetzen kann – die noch junge Internet-Historie kennt bereits mehrere vielversprechende Ansätze, Verbesserungen an den IP-Protokollen einzubrigen, die aber in der Praxis scheiterten.
Googles Entwickler Jana Iyengar will nun die Ergebnisse der Quic-Entwicklung in Kürze erstmals unabhängigen Fachleuten auf der IETF 93 in Prag vorstellen. Dabei strebt Google keine Anerkennung der Quic-Technik als IETF-Standard an, wie Iyengar jetzt gegenüber heise Netze erklärte. "Im Moment handelt es sich bei Quic um individuelle Entwürfe", teilte Iyengar auf Anfrage mit, "es sind keine Vorschläge für eine Arbeitsgruppe."
Als solche werden die beiden Entwürfe zur Quic-Architektur und zu Loss Recovery and Congestion Control lediglich von einem RFC-Editor auf Lesbarkeit und Konsistenz geprüft. Außerdem wird sichergestellt, dass Quic zu keinen IETF-Arbeiten im Widerspruch steht – und das war's. Anschließend werden die Inhalte als Informations-Dokumente in die RFC-Reihe aufgenommen.
Google treibt Entwicklung an
Der Verzicht auf eine vollumfängliche Standardisierung des Transportprotokolls mag auf den ersten Blick verwundern, erscheint aber sinnvoll, kommentiert Martin Stiemerling, einer der Vorsitzenden für den Bereich Transportprotokolle bei der IETF. Würde Quic in die Hände einer IETF-Arbeitsgruppe gegeben, würden die Google-Entwickler den Zugriff darauf und den Einfluss auf weitere Änderungen verlieren, erklärt Stiemerling. Erklärtes Ziel der Quic-Entwickler, die gleichzeitig eine Patentanmeldung eingetragen haben, ist aber, das Protkoll als Entwicklungsplattform für ein neues Transportprotokoll zu nutzen. Damit hoffen sie durchaus auch, TCP Beine machen zu können.
Seit Jahren wird an den beiden Haupttransportprotokollen für das Internet, TCP und UDP, gebastelt. Doch alle bisher vorgeschlagenen und standardisierten Fortentwicklungen verhungerten auf dem langen Weg zur Übernahme in der Praxis, in der – oft aus verständlichen Gründen – beharrlich am status quo festgehalten wird. Google hat jedoch schon mindestens einmal massiv die Entwicklungen eines Kernprotokolls in der IETF vorangetrieben, und zwar bei HTTP 2.0; mit seinem im Alleingang gestarteten Speedy steuerte Google wesentliche Konzepte dafür bei. Quic bezeichnen die Google-Entwickler jetzt gerne als Fortentwicklung und als eine Art "Speedy over UDP mit einigen zusätzlichen Features".
Schneller und sicherer?
Das Hauptanliegen des UDP-basierten Quic ist wie so oft: besserer Datendurchsatz. Erreichen wollen das die Quic-Entwickler unter anderem durch Reduktion der Round Trips zwischen Client und Server. Statt des üblichen TCP Handshake – oder den im Falle einer per TLS verschlüsselten Verbindung erforderlichen drei Round Trips – sei "häufig" kein einziger notwendig. Im ersten Paket könnten, sofern der Diffie-Hellman-Schlüsselaustausch zuvor schon mal vollzogen wurde, bereits erste Applikationsdaten abgeschickt werden.
Verschlüsselungstechnisch, so das Versprechen der Macher, sei Quic praktisch genauso sicher wie das aktuelle TLS. Der Quic-Verschlüsselungsentwurf aus der Feder von Googles Kryptografie-Experten Adam Langely und einigen weiteren Autoren liegt noch nicht als IETF-Dokument vor. Im Kern bietet Quic gegen IP-Address-Spoofing – bei TCP durch Sequenznummern oder SYN-Cookies verhindert – ein dem Client zugewiesenes "source address token" auf.
Der Schutz gegen Replay-Attacken setzt dabei zwar erst nach der ersten Antwort des Servers ein. Aber in Chrome würden vor dem Einschlagen in den Handshake ohnehin nur get-Anfragen gesendet, verteidigen die Entwickler das Konzept. Ganz ohne Kompromisse ist die Leichtfüßigkeit von Quic offensichtlich nicht zu herzustellen. TLS 1.3 könne in Zukunft das derzeit für Quic eingesetzte eigene Verschlüsselungskonzept jedoch ablösen, heißt es im aktuellen Quic-Verschlüsselungsentwurf.
Nahtloser Wechsel trotz IP-Adressänderung
Gleichzeitig wirbt Quic mit einer Reihe von weiteren Neuerungen gegenüber TCP, zum Beispiel einem intelligenten Multiplexing, das ein "head of line blocking" verhindert sowie strikt aufsteigenden Paketnummern, die, anders als bei TCP, deutlich zeigen, welche Pakete ein zweites Mal losgeschickt wurden. Das erleichtere nicht zuletzt das Loss Recovery, argumentieren die Experten.
Interessant ist auch, dass Quic-Pakete nicht durch IP-Adressen identifiziert werden, sondern durch 64 Bit lange, eindeutige Verbindungs-IDs. Quic-Übertragungen überleben auf diese Weise IP-Adressänderungen etwa beim Wechsel vom WLAN zum Mobilfunk und kommen auch mit der Network Address Translation besser zurecht.
Wie gut Quic unter Chrome aktuell funktioniert, das weiss derzeit nur Google; alle Messdaten dazu haben bisher nur Googles Entwickler gesehen. Bei der IETF in Prag wird Iyengar dazu erste Einblicke geben. (dz)
