Ein Gespräch über QUIC mit Jana Iyengar: Die Neugestaltung grundlegender Standards im Web
Seit ich vor einigen Monaten zu Fastly kam, durfte ich spannenderweise miterleben, wie Fastly sich für das Wohl des Internets einsetzt. Ich hatte auch die Gelegenheit, mich mit einigen der Leute, die das Ganze vorantreiben, eingehender zu unterhalten. Zu den Verbesserungen, die aus dieser Initiative hervorgegangen sind, gehört unter anderem QUIC, ein bahnbrechendes Transport-Layer-Netzwerkprotokoll, das das bisherige TCP ersetzt. Mehr als eine Milliarde Nutzer verwenden QUIC im Rahmen ihrer täglichen Aktivitäten im Internet.
Eines der zentralen Mitglieder des Teams, das diese Bemühungen bei Fastly leitet, ist Jana Iyengar, unser VP of Product for Infrastructure Services. Er ist ein langjähriger Veteran in der Welt der Transportstandards und Netzwerke. Im Laufe der Jahre hat er (unter anderem) an der Entwicklung und Implementierung von QUIC und HTTP/3 mitgearbeitet und war als Redakteur der QUIC-Spezifikationen der IETF tätig.
Angesichts seines Backgrounds konnte ich mir die Gelegenheit nicht entgehen lassen, mit Jana über seine Erfahrungen in der Zusammenarbeit mit einer ganzen Community brillanter Nutzer zu sprechen, die an der Neugestaltung der grundlegenden Standards für das Internet beteiligt sind. Und mal ehrlich: Solch direkte Einblicke in die Geschichte eines ganz normalen Menschen, der einen so großen Beitrag zur Verbesserung des gesamten Internets leistet, bekommt man nicht jeden Tag!
Anil Dash: Im Jahr 2010 habe ich Vint Cerf – einem der „Väter des Internets“ – bei den Webby Awards einen Preis für sein Lebenswerk verliehen: die Entwicklung von TCP/IP. Inzwischen wurde TCP von QUIC abgelöst, was ein gewaltiges Unterfangen ist! Wie ist es dazu gekommen und wie sieht das Ganze in der Praxis aus?
Jana Iyengar: Lass mich zunächst einmal aus der Warte von jemandem sprechen, der sich seit 23 Jahren mit der Datenübertragung im Internet beschäftigt, und zwar nicht nur mit QUIC, sondern ganz allgemein.
Seit der „Jahrhundertwende“.
Ganz genau. Wir wollten ein bestehendes Problem lösen. Der Grundstein für Next-Generation-HTTP (kurz HTTPNG) wurde bereits Ende der 90er Jahre gelegt. Aber nachdem die Dot-Com-Blase geplatzt war, hatte die Branche dieses Projekt nicht weiterverfolgt.
Dabei sollte man nicht außer Acht lassen, dass die Branche von der Community profitiert, aber ihr nichts zurückgegeben hat. Niemand hat in die Grundlagen des Internets investiert.
Niemand verstand damals wirklich das wahre Potenzial des Internets. Die Nutzer dachten, es läge in den Webportalen. Alle wollten ein eigenes Portal einrichten. Als dieser Trend abflaute, zeigte das Internet aber, was es wirklich drauf hat, und man begann, seine Potenziale auszuschöpfen. Immer mehr Unternehmen verließen sich auf das Internet. Eine ansprechende Website war nicht mehr nur eine Frage des Wollens, sondern eine des Brauchens. Wir mussten also irgendwie dafür sorgen, dass das Web funktioniert. Im Jahr 2010 war man sich darüber einig, dass Sicherheit und Geschwindigkeit wichtig waren, aber Datenschutz war noch kein wirkliches Thema. Der Wendepunkt kam um das Jahr 2013 herum – vermutlich als Reaktion auf die Enthüllungen von Edward Snowden über die staatliche Überwachung des Internet-Traffics.
Lass uns darüber sprechen.
Zunächst müssen wir den Unterschied zwischen Security und Datenschutz klären. Wenn wir von Security sprechen, meinen wir die Verschlüsselung bei der Übertragung. Datenschutz bedeutet den Schutz von personenbezogenen Daten. Die Enthüllungen durch Edward Snowden, wonach der Traffic von Exchange Points ständig überwacht wird, haben deutlich gemacht, dass keine Kommunikation sicher ist. Außenstehende konnten alle Daten der Nutzer einsehen. Es gab Bedenken, weil Security bis zu diesem Zeitpunkt nicht aus dem Blickwinkel der Performance betrachtet wurde und zur Auslastung von Serverressourcen führen konnte. Die Ineffizienzen bei der Security bekam vor allem die Infrastruktur zu spüren. Außerdem wurde Security als kostenintensiv angesehen.
Inzwischen hat sich der Spieß umgedreht und sichere Kommunikation ist zur Priorität geworden. Die End-to-End-Verschlüsselung wurde zur einzigen Möglichkeit, Security zu gewährleisten, und zum Standard für alles, sogar innerhalb von Datacentern und zwischen Services. Gleichzeitig bestand der Wunsch nach einer Verringerung der Latenzzeiten weiter. Die Nutzer wollten eine schnelle und sichere Kommunikation.
Inzwischen haben sich die Nutzer an TCP gewöhnt, aber die Verfügbarkeit neuer Geräte und der allgemeine Wachstumstrend bringen das Protokoll an seine Grenzen. Was ist der nächste Schritt?
Der nächste Schritt war QUIC. Die Performance-Probleme von TCP bei Web-Traffic sind schon seit 1995 bekannt.
QUIC entstand aus dem Bedürfnis nach Sicherheit, geringer Latenz und schneller Bereitstellung. Es musste schnell gehen. Es war bereits eine Menge interessanter Arbeit geleistet worden, aber die Zeit war noch nicht reif dafür. QUIC kam zu einem Zeitpunkt, an dem sich die Gelegenheit bot. Die treibende Kraft bei der Entwicklung von QUIC war der Wunsch, den Kostenaufwand für die Latenzzeiten der TCP- und TLS-Handshakes zu eliminieren, die Teil der gesamten Webkommunikation waren.
Mit QUIC wurden die vorhandenen Fortschritte vereint. Im Jahr 2015 war HTTP/2 bereits auf dem Markt. Jeder hatte versucht, die Latenzzeit am oberen Ende des Stacks zu verringern, aber die eigentliche Chance lag viel tiefer im Stack. Begonnen hat alles bei Google, wo ich damals beschäftigt war. Wir haben intern an QUIC gearbeitet, es überarbeitet und anschließend ausgeliefert. Jetzt mussten wir nur noch andere Nutzer dazu bringen, es zu verwenden. Das Standardisierungsgremium IETF trat auf den Plan, und glücklicherweise schlossen sich aufgrund von Googles Proof of Concept viele andere Unternehmen wie Mozilla, Apple, Microsoft und Fastly an.
Ein Prototyp ist also tatsächlich mehr wert als tausend Meetings.
Ja, auf alle Fälle. Unser Prototyp war live und funktionierte, was es den Nutzern leichter machte, auf den Zug aufzuspringen.
Gab es irgendwelche Einwände? Das Setzen neuer Standards ist eine heikle Sache. Ich nehme also an, dass einige Leute Probleme damit hatten.
Wir hatten Nutzer, die uns sagten: „In meinem Netzwerk hat das nichts zu suchen.“
Und wir haben ihnen gesagt: „Im Grunde arbeitet Ihr Netzwerk bereits mit diesem Protokoll.“
Wenn es nicht funktioniert hätte, wäre alles auf uns zurückgefallen. Schließlich hatten wir es ja bereitgestellt. Da es aber von vornherein funktioniert hatte, blieb uns eine Menge Aufregung erspart.
Wir wollten die Sicherheit und Verschlüsselung bei der Datenübertragung mit QUIC immer weiter ausbauen und haben uns dabei viel gestritten.
Kannst du uns verraten, worüber ihr gestritten habt?
Es war schwierig für uns, neue Technologien für den Transport Layer im Netzwerk zu implementieren. Viele Mechanismen funken dazwischen und lesen und manipulieren TCP Header, was es unmöglich macht, neue Transportprotokolle einzusetzen.
Die Header des QUIC-Protokolls waren fast vollständig verschlüsselt. Viele Netzwerkbetreiber haben sich darüber beschwert (und tun es immer noch). Aber wir haben das Protokoll geschützt, damit es überarbeitet und verfeinert werden kann. Niemand kann darin herumpfuschen. Jetzt behalten wir die Kontrolle über das Protokoll, da die Header für die Übertragungssysteme nicht sichtbar sind.
Die Geschichte von QUIC enthält noch viele weitere Kapitel auf GitHub, in Mailinglistenarchiven und in den Erinnerungen der Nutzer an persönliche Gespräche. Über einen Teil der Geschichte von QUIC habe ich bereits in einem früheren Artikel über die Entwicklung von QUIC berichtet.
Heute ist QUIC das unsichtbare Protokoll, mit dem wir alle arbeiten. Was kommt als Nächstes? Wir haben ein neues TCP, was kann man damit machen?
QUIC wurde für das Web entwickelt. Fast alle Browser unterstützen QUIC jetzt nativ. iOS und Microsoft unterstützen es auf Plattformebene. Die meisten CDN-Plattform-Anbieter unterstützen es.
Das Web war aber nur ein Mittel, um QUIC in diese Server- und Client-Stacks zu bringen. QUIC ist sowohl eine Plattform als auch ein Protokoll. MASQUE bietet Tunnel, mit denen Sie Ihre Identität verschleiern können. Dies ist zum Beispiel die Grundlage von iCloud Private Relay und des Relay-Produkts, an dem wir gemeinsam mit INVISV gearbeitet haben.
Du stehst in einer gemeinsamen Tradition mit Pionieren des Internets, die einen langen Schatten werfen. Wie ordnest du dich selbst in ihre Reihen ein?
Ich weiß gar nicht, wie ich diese Frage beantworten soll. Ich habe mit einigen von ihnen gesprochen, und keiner von ihnen hatte jemals mit einem solchen Einfluss gerechnet. IPv4 sollte ein Experiment sein. Es sollte nie das produktive Internet werden. Ich glaube nicht, dass man seine beste Leistung erbringt, wenn man über seinen Einfluss nachdenkt. Man leistet seine beste Arbeit, wenn man sein Bestes gibt. QUIC war eine große Gemeinschaftsleistung. Es gab mehrere führende Köpfe in dieser Community.
Ich kann nicht sagen, dass ich persönliche Ambitionen in Bezug auf meinen Einfluss habe. Es war einfach eine super interessante Herausforderung. Ich beschäftige mich seit 23 Jahren mit der Datenübertragung im Internet und habe in der Vergangenheit versucht, Dinge umzusetzen. Ich nannte mich früher den „Schutzpatron der gescheiterten Datenübertragungen“. Es waren viele verschiedene Menschen nötig, um QUIC möglich zu machen und es auf den Stand zu bringen, auf dem es sich heute befindet. Ich bin gespannt, wie es weitergehen wird.
Dieser Blogpost erscheint unter der Rubrik „Privacy Week“. Hier veröffentlicht Fastly Wissenswertes über engmaschige Integrationsmöglichkeiten für Datenschutzpraktiken und -technologien in die Strukturen des Internets.
