Parallel zu unserer Folge des Datenkanals über Quic und Http 3 will ich hier noch meine gesammelten Informationen und Quellen über Quic zusammentragen.

Die reale Geschichte zu Quic

Google als Unternehmen hat natürlich ein Interesse daran, seinen Nutzern ein bestmögliches Erlebnis zu bieten, damit sie immer wiederkehren. Bis auf die kapitalistischen Auswüchse, die solches Streben leicht treibt, ist dieses Ziel aber vorteilhaft für beide Seiten. So haben wir auch viele Entwicklungen wie Chrome, SPDY/Http 2, Fortschritte bei Html 5 und Webanwendungen mit Javascript zu verdanken.

Ein Faktor, der den Benutzung einer Webseite beeinflusst, ist die Leistungsfähigkeit des Browsers und wie geschickt die Webseite gebaut ist, also dabei auch den Browser unterstützt. Hier hat Google mit Chrome zu seiner Einführung neue Maßstäbe gesetzt und mit viel Hirnschmalz die Schnelligkeit bei der Darstellung von Webseiten vorangetrieben. Dies vor allem auch im Zusammenspiel mit entsprechenden Anpassungen am Html und Javascript – man denke zum Beispiel an die nicht Html 4-konformen Seiten der Google-Suche, um Redundanz zu entfernen. Dies hat ja auch maßgeblich Html 5 beeinflusst und zur Standardisierung vieler Anpassungen geführt.

Ein weiterer Einflussfaktor ist die Menge der übertragenen Daten und wie Browser und Server miteinander kommunizieren. Anfang der 1990er Jahre, als Html und Http entwickelt wurden, waren Webseiten statisch und enthielten neben Text nur ein paar Bilder. Für die Darstellung einer Webseite waren also nur wenige Anfragen an den Server notwendig. Dies hat sich aber durch die veränderte Nutzung von Webseiten, insbesondere der Interaktivität des Web 2.0, massiv verändert: Der Aufruf einer Seite kann heute zum Abruf mehrerer Megabyte an Daten über fünfzig und mehr Verbindungen bei fünf und mehr Servern führen. Hinzu kommt, dass früher viele Inhalte über Wochen hin gleich blieben und somit vom Browser gepuffert werden konnten, wohingegen heute jeder Abruf einer Seite ein anderes Ergebnis liefern kann. Die Menge in Anzahl und Umfang ist sehr stark gewachsen; gut zu sehen im Netzwerkmonitor des Browsers, der mit der Taste F12 geöffnet werden kann.

Eine weitere, wesentliche Veränderung durch das Web 2.0 ist eine fast dauerhafte Verbindung zum Server und viele kleine Anfragen zum Abgleich von Informationen. An diese veränderten Anforderungen hatte schon 1999 Http 1.1 versucht sich anzupassen, aber es blieben noch schwächen und so hat Google 2012 mit SPDY, das 2015 zu Http 2 führte, noch einmal viele Verbesserungen und Neuerungen wie Server-Push eingebracht, um den Anforderungen der Zeit besser gerecht zu werden und Seiten schneller laden und darstellen zu können.

Ein Dienst, den Google betreibt, ist Gmail und für Gmail war es schon sehr frühzeitig wichtig, dass die Verbindung verschlüsselt ist. Auch bei anderen Diensten hat Google über die Zeit hin nachgerüstet und alle auf Verschlüsselungspflicht umgestellt. In SPDY war deshalb schon TLS ein notwendiger Bestandteil. Allerdings hat diese Kombination von Http über TLS über TCP in der Praxis einige Schwächen. Eine davon ist der Verbindungsaufbau: Der Beginn einer TCP-Verbindung benötigt drei Pakete und dazu kommen noch vier Pakete für den TLS-Verbindungsstart. Wenn jedes Paket 100 ms für den Weg benötigt, vergeht so schon eine halbe Sekunde, ohne dass der Client überhaupt sagen konnte, was er will. Dazu kommt dann der hohe Kommunikationsbedarf mit mehreren Verbindungen und vielen Daten, so dass leicht mehrere Sekunden vergehen können, bis der Browser auch nur einen Strich auf dem Bildschirm zeichnen kann – zu viel Zeit, um dem Benutzer einen flüssigen Übergang von Seite zu Seite und ein angenehmes Erlebnis bieten zu können.

Ein weiteres Problem rührt von TCP her und verschlimmert sich noch in Kombination mit TLS, durch dessen Zeitvorgaben (Timeouts) und die Verschlüsselung über Paketgrenzen hinweg. Denn im Internet werden Daten nicht als großes Ganzes verschickt, sondern in kleine, standardisierte Häppchen zerlegt, die beim Empfänger wieder zusammengesetzt werden. Wenn ein Paket mit einem Teil der Daten verloren geht oder beschädigt ankommt, kümmert sich TCP darum, dieses Paket erneut zu übertragen und am Ende die Pakete in der richtigen Reihenfolge anzuordnen. Hinzu kommen noch unterschiedliche, komplexe Verfahren zur Steuerung der Übertragungsgeschwindigkeit (Flow-Control), also in Summe sehr viel Programmcode, der auf Server- und Client-Seite gleich arbeiten muss, sodass man dies sinnvollerweise als eigenständiges Protokoll TCP zusammenfasst und einer Anwendung die Illusion eines kontinuierlichen, korrekten Datenstroms gibt.

Aber so schön eben die Theorie ist, so hässlich kann die Praxis zuschlagen. Wenn nämlich ein Paket nicht ankommt, kann die Anwendung nicht auf die Folgedaten zugreifen, solange das Paket nicht beschafft ist. Erschwerend kommt hinzu, dass man nicht angekommen schwer erkennen kann. Man kann nur nach einer gewissen Wartezeit (Timeout) sagen, dass es wahrscheinlich nicht mehr ankommen wird. In ungünstigen Fällen blockiert dann ein verlorenes Paket eine große Anzahl an Folgedaten; das sogenannte head-of-line-blocking. Bei Video- oder Musik-Streams ist dies besonders störend, weil der kleine Verlust/Aussetzer in der Anwendung verkraftbar ist, aber es muss nicht das gesamte System anhalten.

Einige Anwendungen, denen die unblockierte Übertragung wichtiger war als die Annehmlichkeiten von TCP, sind daher schon früher auf UDP ausgewichen; Anwendungen hatten in dem Punkt die Wahl zwischen Pest und Cholera – sofern sie denn die Wahl hatten, denn viele Anwendungen laufen heutzutage im Web und das kennt nur Http mit TCP und TLS. Google war genauso betroffen von diesen Problemen und hat sich daher auch dieses Themas angenommen und herausgekommen ist Quick UDP Internet Connections oder kurz Quic.

Http über UDP war zwar auch vorgehen, aber in der Praxis wurde es nicht genutzt. Diese Chance hat Google genutzt, eben über Port 443 das neue Protokoll zu entwickeln, um all die erläuterten Probleme anzugehen.

Die Eigenschaften von Quic

Da Quic immer Verschlüsselung nutzt, benötigt man immer ein Programm zur Analyse des Datenverkehrs und deshalb ist Quic kein Klartextprotokoll wie HTTP mehr. Die oben erläuterten Probleme beim Verbindungsaufbau sind bei Quic auch verbessert worden, insbesondere hat man den sehr häufigen Fall, dass ein Client erneut eine Verbindung zu einem Server aufbaut, optimiert und mithilfe einer Kennung lässt sich so eine Verbindung mit einem Paket, indem bereits Nutzdaten enthalten sind, aufnehmen; 0-RTT bzw. Zero Round-Trip-Time, auch bekannt von TCP fast open.

Für Verschlüsselungen ist es nützlich, wenn es nur einen Datenstrom zwischen den beiden Parteien gibt, denn so kann ein Zuhörer eine Informationen daraus ableiten, wenn mehrere Verbindungen bestehen und in welcher zeitlichen Abfolge diese beginnen und enden. Auf für die Organisation ist es praktischer, wenn es nur eine große Mantelverbindung gibt und darin für die unterschiedlichen Anfragen einzelne Teilverbindungen (Streams genannt). Die Nutzer der Streams können bestimmen, ob sie die Daten in geordneter (in-order) oder beliebiger Reihenfolge (out-of-order) empfangen wollen.

Die Steuerung der Bandbreite soll für die einzelnen Teilverbindungen erfolgen, so dass eine Priorisierung des Datenverkehrs gemäß den Anforderungen der Anwendung passieren kann und nicht alles gleich behandelt wird, weil Zwischenstationen der Übertragung nur eine einzige Verbindung sehen.

Es ist auch angedacht, dass nicht nur Fehler erkannt, sondern auch korrigiert werden können. Wenn also ein Übertragungsweg als unzuverlässig erweist, könnten wichtige Pakete doppelt versendet werden oder mit bestimmten Verfahren robuster ausgelegt werden.

Eine Anforderung, die vor 30 Jahren noch völlig absurd erschien, aber heute üblich ist, sind wechselnde IP-Adressen. Ein Benutzer hört mit seinem Handy einen Musik-Stream oder hat sein Chatprogramm geöffnet und geht von seiner Wohnung aus über die Straße in ein Café, dabei wechselt er vom WLAN zum Mobilfunknetz und zu einem neuen WLAN und erhält jedes Mal eine neue IP-Adresse. Die Anwendungen müssen bei jedem Wechsel die Verbindungen zum Server neu aufbauen, was man bei einigen Musik-Streams daran merkt, dass wieder die Begrüßungswerbung gespielt wird. Mit Quic merkt die Anwendung nichts von dem Wechsel und es gehen auch keine Daten verloren.

Eine Phantasiegeschichte zu Quic

Aus der Mathematik kennt man das Vorgehen, dass aus didaktischen Gründen der Ablauf eines Beweises in einer ganz anderen Reihenfolge erzählt wird, als der ursprüngliche Pfad mit allen seinen Irrungen und Wirrungen verlaufen ist. Da werden zuvor unverständliche Lemmata bewiesen, die sich plötzlich in spätere Schritten einfügen, und Hilfsvariablen eingeführt, die am Schluss alles plötzlich rund und schlüssig aussehen lassen. In diesem Sinne könnte man auch die Geschichte von Quic ein wenig anders erzählen.

Wenn im Jahr 2015 eine Arbeitsgruppe mit dem Ziel, dem Internet eine Generalüberholung zu verpassen, zusammengetreten wäre, was hätte sie denn als neue Anforderungen vorgefunden:

Die schöne heile Welt von 1980, als jeder jemanden kannte, der irgendwen kannte, der den Bösewicht persönlich schlagen konnte, der gerade Unsinn verzapft hatte, die gibt es 2015 nicht mehr: Internet-Provider greifen in den Datenverkehr ein und reichern ihn mit Werbung an, schleusen Cookies zur Verfolgung ein oder »optimieren« Bilder um die Bandbreite zu reduzieren, mit WLANs ist die inhärente Abhörabsicherung von Kabeln verloren gegangen und an vielen Knotenpunkten geschieht eine Tiefendurchleuchtung (Deep packet inspection) aus allerlei wichtigen Gründen.

Deshalb ist Verschlüsselung für alle Anwendungen essenziell geworden und sollte gemeinsam und standardisiert an zentraler Stelle passieren. Mit Blick auf das ISO/OSI-Schichtenmodell heißt das, die Schicht 6 muss runter über die Schicht 3 (IP). Damit würde man auch ein Entwurfskriterium des Internets – die Trennung der Schichten – auch wiederherstellen.

Angedacht war einmal, dass die Zwischenstationen auf dem Weg der Übertragung sich nur nach den Metainformationen richten und die Nutzdaten durchreichen: Ein Switch für Schicht 2 sollte sich nur mit MAC-Adressen befassen und ein Router für die Schicht 3 nur mit den IP-Adressen. Aber da die Technik irgendwann die Leistungsfähigkeit erreicht hatte, dass auch ein Switch genug Daten puffern und so feststellen konnte, dass das Paket zu einer Http-Get-Anfrage für ein Video gehört, kamen Knotenbetreiber auf die Idee, anhand solcher Informationen Pakete zu verzögern oder sie vorrangig zu behandeln, was zu obskuren Problemen führen kann. Mit der Verschlüsselung aller Nutzdaten ab IP-Ebene würde man solche Schichtenübergriffe konsequent unterbinden. Damit würde wieder das Prinzip gelten: »Intelligenz an den Endpunkten und dazwischen einfach Übertragungspunkte.«

Die Umsetzung

Schön der Traum des Aufräumens, aber wie diesen umsetzen? Untersuchungen von Google haben gezeigt, dass SCTP, das bereits viele der Ideen beinhaltet, leider nicht verwendet werden kann, weil zu viele Zwischenstationen aufgrund zu großer »Intelligenz« diese Paket nicht durchlassen: »Router: Ach, bevor ich mich entscheide, schaue ich doch mal in das IP-Paket rein. Oh, was steckt denn da drin? Das kenne ich ja gar nicht, das muss was böses sein.« Diese Probleme sind ja auch bereits von IPv6 bekannt. Selbst Windows unterstützt IPv6, aber viele Geräte für Endanwender oder für große Netzwerkbetreiber lassen sich IPv6 besonders vergolden oder unterstützen es gar nicht.

Daher ist auch die elegante Lösung, UDP zu verwenden, denn des Schichtenmodell bietet gerade diese Freiheit zur kreativen Nutzung – ein Glanzpunkt des alten Entwurfs.

Für die Verschlüsselung sollte die neuste Technik zum Einsatz kommen und daher bietet sich TLS 1.3 auch als gut erprobtes Verfahren an. Die alten Zöpfe SSL bis TLS 1.2 werden gleich abschnitten und das Protokoll etwas auf die speziellen Gegebenheiten zugeschnitten.

Um all die Leiden, die mit Paketzersplitterung (packet fragmention) entstanden sind, aus der Welt zu schaffen, könnte man gleich das Verfahren von IPv6 für die Path-MTU einsetzen. Und für den Verbindungsaufbau kann man gleich die Ideen von TCP-fast-open für eine Beschleunigung im Falle eines Neuaufbaus verwenden.

Dennoch sollten genau diese zwei Anwendungsszenarien von TCP und UDP möglich bleiben: eines korrekten, geordneten Datenstroms (in-order modus) und eines unverzögerten, verlustbehafteten Datentransports (out-of-order modus). Dementsprechend können auch viele der bekannten und erprobte Verfahren zur Datenflusssteuerung übernommen werden.

Man merkt also, dass auch mit einem Neuentwurf würde man nicht bei einer wesentlich anderen Lösung als Quic herauskommen. Mathematisch gesehen, fallen also obere und untere Schranke für dieses Problem zusammen.

Was die Zukunft bringen könnte

Das Verschlüsselung notwendig ist, bestreiten heute nur wenige. Jedoch ist der Schritt zur Verschlüsselung der IP-Nutzdaten erheblich (praktisch liegt bei Quic noch ein bisschen UDP mit langweiligen Informationen dazwischen). Wenn die Knotenpunkte des Internets noch stärker entmachtet werden, würde ich dort einigen Widerstand erwarten.

In der jetzigen Ausbaustufe gibt es noch viele Optimierungen für die Leistungsfähigkeit von Quic. Für TCP gibt bereits TCP-offloading, um bestimmte Operationen wie die Prüfsummenberechnung an die Netzwerkkarte zu übergeben, die spezielle Chips dafür verwendet und wesentlich schneller als die generische CPU ist. Auch AES-Algorithmen wurden direkt in einigen CPUs eingebaut, so dass auch die Verschlüsselung in der Netzwerkkarte passieren kann.

Die Verbindung wird in zwei Phasen geteilt: eine organisatorische Phase in der Benutzerrückfragen zum Beispiel zur Bestätigung eines Zertifikats möglich sind, weshalb diese den der Anwendung durchgeführt wird. Dabei ergibt sich dann der Sitzungsschlüssel, der während der Phase der Datenübertragung auch an den Kernel oder gar die Netzwerkkarte gegeben werden könnte. Innerhalb des IPv6-Headers gibt es keine Prüfsumme, weshalb des Anfang der Nutzdaten für die Schicht 2 konstant ist und den Rest könnte gar die Netzwerkkarte mit dem Sitzungsschlüssel und den Klartextdaten berechnen. Das könnte theoretisch das neue Verfahren schneller werden lassen als die alte Kombination.

Wenn Quic dann die Unterstützung des Kernels erhält, wird hoffentlich auch eine Abhörschnittstelle ähnlich pcap eingebaut, sodass man Wireshark zur Analyse auf den Endsystemen nutzen kann. Sollte sich eine Standardbibliothek für Quic herausbilden, könnten die Tracing-Technologien des Kernels helfen, die Daten vor der Verschlüsselung abzugreifen.

Everything is a resource

In einer völlig verwegenen Vision könnte sich Http auch zum Standard für Prozesskommunikation entwickeln. Bereits jetzt werden DNS-Abfragen über Https von den Browsern Chrome und Firefox angeboten und DNS mit Quic ist in Vorbereitung (IETF-Entwurf). Warum also keine Quic-Verbindung zu seinem Lieblings-DNS-Server aufbauen und dort ein GET /domain/host.domain.tld?rec=aaa,mx abfragen? SMTP könnte so zu POST /smtp/user@domain.tld mit einem Authorization-Header werden und Imap wird zu einem GET /imap/user@domain.tld/INBOX und einem anschließenden GET /imap/user@domain.tld/INBOX/<ID>. Dies ließe sich für eine Fernsteuerung dann bis hin zu DELETE /sys/proc/42 ausbauen.

Eine solche Art Verteilung der Anfragen aufgrund des Pfades gibt es bereits unter Windows mit dem Http-Service und diese Verteilung wird in Webanwendungen mit einem Router häufig genutzt. Http ist mit den Konzepten VERB (für die Aktion), dem Ressourcenpfad (der URL) und den optionalen Metadaten im Header (für Cookies, Anmeldedaten, Content-Negotiation) so flexibel aufgestellt, dass damit sehr viele Nutzungsszenarien abgedeckt sind – aber definitiv nicht alle, es muss noch einen UDP-ähnlichen Weg geben, bei den man frei agieren kann und nicht das enge Korsett von Http trägt.

In dieser Vision könnte curl dann zum ultimativen Schweizer Taschenmesser für Skripting werden. Aus ssh host cmd könnte dann curl -d cmd /sys/proc werden.

Offene Fragen

Und dennoch bleiben trotz der vielen Träumereien ein paar offene Fragen:

Globale Macht als Antrieb der Entwicklung

Zu Anfang habe ich ein kleines Loblied auf Google gesunden, wie viele Verbesserungen und Neuerungen sie in den letzten Jahren dem Internet beschert haben.

Weitere Informationsquellen

Die echte Geschichte zu Quic

Eine Phantasiegeschichte von Quic

Aus der Mathematik kennt man das Vorgehen, dass aus didaktischen Gründen der Ablauf eines Beweises in einer ganz anderen Reihenfolge erzählt wird, als der ursprüngliche Pfad mit allen seinen Irrungen und Wirrungen verlaufen ist. Da werden zuvor unverständliche Lemmata bewiesen, die sich plötzlich in spätere Schritten einfügen. In diesem Sinne könnte man auch die Geschichte von Quic ein wenig anders erzählen.

Umsetzung

Google hat die Macht

Wünsche und Ziele für die Zukunft

Fragen