HTTP/3: Von der Wurzel bis zur Spitze

HTTP ist das Anwendungsprotokoll, das die Übertragung von Web-Inhalten ermöglicht. Es nahm seinen Anfang 1991 als sogenanntes HTTP/0.9-Protokoll und hatte sich 1999 zu HTTP/1.1, das von der IETF (Internet Engineering Task Force) standardisiert wurde, entwickelt. HTTP/1.1 war lange Zeit gut genug, aber die sich ständig ändernden Anforderungen des Webs erforderten ein besser geeignetes Protokoll, weshalb im Jahr 2015 HTTP/2 entstand. Kürzlich wurde bekannt gegeben, dass die IETF beabsichtigt, eine neue Version – HTTP/3 – zu veröffentlichen. Für einige Leute kam das ein wenig überraschend und hat für Verwirrung gesorgt. Wenn man die Arbeit des IETF nicht genau mitverfolgt, könnte es scheinen, als wäre HTTP/3 aus heiterem Himmel entstanden. Wir können seine Ursprünge jedoch durch eine Reihe von Experimenten und Entwicklungen von Web-Protokollen verfolgen, insbesondere die des Transportprotokolls QUIC.

Falls Sie mit QUIC nicht vertraut sind: Meine Kollegen haben hervorragende Arbeit geleistet, es von verschiedenen Seiten her zu beleuchten. Johns Blogbeitrag beschreibt einige der realen Ärgernisse mit dem heutigen HTTP, Alessandros Beitrag behandelt die wesentlichen Details der Transportschicht, und Nicks Beitrag zeigt, wie Sie QUIC in der Praxis testen können. Diese Beiträge und weitere Informationen haben wir unter https://cloudflare-quic.com gesammelt. Und wenn das Ihr Interesse geweckt hat, sollten Sie sich quiche ansehen, unsere eigene, in Rust geschriebene Open-Source-Implementierung des QUIC-Protokolls.

HTTP/3 ist das Mapping der HTTP-Anwendung für die QUIC-Transportschicht. Der Name wurde in dem im Oktober 2018 vorgelegten Entwurf, Version 17 (draft-ietf-quic-http-17), offiziell vorgestellt, woraufhin während des IETF-Meetings 103 in Bangkok im November darüber diskutiert und ein grober Konsens erzielt wurde. HTTP/3 war früher als HTTP-über-QUIC bekannt, was wiederum zuvor als HTTP/2-über-QUIC bekannt gewesen war. Davor hatte es HTTP/2-über-gQUIC gegeben, und weit zurück SPDY-über-gQUIC. Tatsache ist jedoch, dass HTTP/3 nur eine neue HTTP-Syntax ist, die auf IETF QUIC, einem UDP-basierten, sicheren Transport mit Multiplexing, funktioniert.

In diesem Blogbeitrag werden wir die Geschichte hinter einigen der früheren Namen von HTTP/3 beleuchten und die Motivation für die letzte Namensänderung vorstellen. Wir werden zu den Anfängen von HTTP zurückgehen und über all die gute Arbeit sprechen, die seitdem geleistet wurde. Wenn Sie das volle Bild haben möchten, können Sie zum Ende des Artikels springen oder diese sehr detaillierte SVG-Version öffnen.

Eine HTTP/3-Schichttorte

Bevor wir uns auf HTTP konzentrieren, sollten wir uns daran erinnern, dass es zwei Protokolle gibt, die den Namen QUIC tragen. Wie wir bereits erklärt haben, wird gQUIC häufig verwendet, um Google QUIC (das ursprüngliche Protokoll) zu identifizieren, und QUIC wird häufig verwendet, um die in Arbeit befindliche IETF-Standardversion darzustellen, die von gQUIC abweicht.

Seit den Anfängen in den neunziger Jahren haben sich die Bedürfnisse des Webs verändert. Es gab neue Versionen von HTTP und zusätzliche Benutzersicherheit in Form von Transport Layer Security (TLS). Wir werden TLS in diesem Beitrag nur kurz anschneiden, aber unsere anderen Blogbeiträge sind eine großartige Ressource, wenn Sie sich genauer über diesen Bereich informieren möchten.

Um die Geschichte von HTTP und TLS besser erklären zu können, begann ich, Details zu Protokollspezifikationen und Daten zu sammeln. Diese Informationen werden in der Regel in Textform dargestellt, z. B. in Form einer Liste mit Angabe der Dokumententitel, geordnet nach Datum. Es gibt jedoch verzweigte Standards, die sich jeweils zeitlich überschneiden, und eine einfache Liste kann die tatsächliche Komplexität der Beziehungen nicht ausdrücken. Für HTTP gab es parallele Arbeiten, die die Kernprotokolldefinitionen für einen einfacheren Gebrauch überarbeiteten, das Protokoll für neue Anwendungen erweiterten und neu definierten, wie das Protokoll Daten über das Internet für Performance austauscht. Wenn man versucht, die Punkte aus fast 30 Jahren Internetgeschichte über verschiedene verzweigte Arbeitsabläufe hinweg zu verbinden, benötigt man eine Visualisierung. Also habe ich eine erstellt – die Cloudflare Zeitleiste des sicheren Webs. (Anmerkung: Technisch gesehen handelt es sich um ein Kladogramm, aber der Begriff Zeitleiste ist weiter verbreitet).

Ich habe mir bei der Erstellung künstlerische Freiheiten genommen und mich auf die erfolgreichen Zweige im IETF-Raum konzentriert. Zu den Dingen, die nicht abgebildet sind, gehören die Bemühungen der Arbeitsgruppe HTTP-NG des W3 Consortium, zusammen mit einigen exotischen Ideen, bei denen die Autoren gerne erklären, wie man sie ausspricht:  HMURR (ausgesprochen wie der englische hammer) und WAKA (ausgesprochen „wah-kah“).

In den nächsten Abschnitten werde ich diese Zeitleiste entlanggehen, um wichtige Kapitel in der Geschichte von HTTP zu erklären. Um die Erkenntnisse dieses Blogbeitrags würdigen zu können, sollte man wissen, warum Standardisierung vorteilhaft ist und wie die IETF sie anstrebt. Deshalb beginnen wir mit einem sehr kurzen Überblick über dieses Thema, bevor wir zur Zeitleiste selbst zurückkehren. Sie können den nächsten Abschnitt überspringen, wenn Sie bereits mit der IETF vertraut sind.

Im Allgemeinen definieren Standards gemeinsame Bezugsrahmen, Umfang, Einschränkungen, Anwendbarkeit und andere Überlegungen. Standards gibt es in vielen Formen und Größen und sie können informell (also de facto) oder formell (vereinbart bzw. veröffentlicht von einer Standardisierungsorganisation wie IETF, ISO oder MPEG) sein. Standards und Normen werden in vielen Bereichen verwendet, es gibt sogar eine offizielle britische Norm für die Teezubereitung – BS 6008.

Das frühe Web verwendete HTTP- und SSL-Protokolldefinitionen, die außerhalb der IETF veröffentlicht wurden; diese sind auf der Zeitleiste des sicheren Webs als rote Linien markiert. Die Übernahme dieser Protokolle durch Clients und Server machte sie zu De-facto-Standards.

Irgendwann wurde beschlossen, diese Protokolle zu formalisieren (einige motivierende Gründe werden in einem späteren Abschnitt beschrieben). Internetstandards werden üblicherweise in der IETF definiert, die sich am informellen Prinzip „grober Konsens und lauffähiger Code“ orientiert. Grundlage dafür sind Erfahrungen mit der Entwicklung und Bereitstellung von Dingen im Internet. Dies steht im Gegensatz zu einem „Reinraum“-Ansatz, bei dem versucht wird, perfekte Protokolle in einem Vakuum zu entwickeln.

IETF-Internetstandards sind allgemein als RFCs bekannt. Dies ist ein komplexer Bereich, der nicht einfach zu erklären ist, deshalb empfehle ich den Blogbeitrag „How to Read an RFC“ des Co-Vorsitzenden der QUIC-Arbeitsgruppe, Mark Nottingham. Eine Arbeitsgruppe (Working Group, WG) ist mehr oder weniger nur eine Mailingliste.

Jedes Jahr hält die IETF drei Meetings ab, die allen WGs die Zeit und Möglichkeit bieten, sich persönlich zu treffen (wenn sie das wünschen). Das Programm für diese Wochen kann sehr voll werden, was bedeutet, dass nur wenig Zeit zur Verfügung steht, um hochtechnische Bereiche eingehend zu diskutieren. Um dem entgegenzuwirken, halten einige WGs in den Monaten zwischen den allgemeinen IETF-Meetings Zwischenmeetings ab. Dies kann dazu beitragen, die Dynamik bei der Entwicklung von Spezifikationen aufrechtzuerhalten. Die QUIC-Arbeitsgruppe hat seit 2017 mehrere Zwischenmeetings abgehalten, eine vollständige Liste ist auf ihrer Meeting-Seite verfügbar.

Diese IETF-Meetings bieten auch für andere mit der IETF in Verbindung stehende Gruppen die Möglichkeit, sich zu treffen, wie beispielsweise das Internet Architecture Board oder die Internet Research Task Force. In den letzten Jahren fand am Wochenende vor dem IETF-Meeting ein IETF-Hackathon statt. Dies bietet der Community die Möglichkeit, lauffähigen Code zu entwickeln und vor allem Interoperabilitätstests im selben Raum mit anderen durchzuführen. Das hilft dabei, Probleme in Spezifikationen zu finden, die dann in den folgenden Tagen diskutiert werden können.

Für die Zwecke dieses Blogbeitrags ist es wichtig zu verstehen, dass RFCs nicht einfach so aus dem Nichts entstehen. Stattdessen durchlaufen sie einen Prozess, der in der Regel mit einem IETF-Internet-Entwurf (Internet Draft, I-D) beginnt, der zur Prüfung auf Annahme eingereicht wird. Für den Fall, dass es bereits eine veröffentlichte Spezifikation gibt, kann die Erstellung eines I-D einfach nur eine Umformatierung sein. I-Ds haben eine aktive Lebensdauer von sechs Monaten ab dem Datum der Veröffentlichung. Damit sie aktiv bleiben, müssen neue Versionen veröffentlicht werden. In der Praxis hat es keine großen Konsequenzen, einen I-D auslaufen zu lassen, und es kommt auch recht häufig vor. Die Dokumente werden für jeden, der sie lesen möchte, fortlaufend auf der Dokumenten-Seite von IETF bereitgestellt.

I-Ds sind auf der Zeitleiste des sicheren Webs als violette Linien dargestellt. Jeder hat einen eindeutigen Namen in der Form draft-{Name des Autors}-{Arbeitsgruppe}-{Thema}-{Version}. Das Feld „Arbeitsgruppe“ ist optional, es kann vorhersagen, welche IETF-WG an der Idee arbeiten wird, was sich aber manchmal ändert. Wenn ein I-D von der IETF angenommen wird oder wenn der I-D direkt innerhalb der IETF initiiert wurde, lautet der Name draft-ietf-{Arbeitsgruppe}-{Thema}-{Version}. I-Ds können sich verzweigen, verschmelzen oder absterben. Die Version beginnt bei 00 und erhöht sich jeweils um 1, wenn ein neuer Entwurf veröffentlicht wird. So wird beispielsweise der 4. Entwurf eines I-D die Version 03 haben. Jedes Mal, wenn sich der Name eines I-D ändert, wird seine Version auf 00 zurückgesetzt.

Es ist wichtig zu beachten, dass jeder einen I-D bei der IETF einreichen kann; man sollte diese nicht als Standards betrachten. Aber wenn der IETF-Standardisierungsprozess eines I-D einen Konsens erreicht und das endgültige Dokument die Überprüfung besteht, erhalten wir schließlich einen RFC. Der Name ändert sich zu diesem Zeitpunkt wieder. Jeder RFC erhält eine eindeutige Nummer, z. B. RFC 7230. Diese werden auf der Zeitleiste des sicheren Webs als blaue Linien dargestellt.

RFCs sind unveränderliche Dokumente. Das bedeutet, dass Änderungen am RFC eine völlig neue Nummer erfordern. Änderungen können vorgenommen werden, um Korrekturen für Errata (redaktionelle oder technische Fehler, die gefunden und gemeldet wurden) vorzunehmen oder einfach um die Spezifikation zu überarbeiten, damit das Layout besser wird. RFCs können frühere Versionen veralten lassen (vollständiger Austausch) oder einfach nur aktualisieren (wesentliche Änderung).

Alle IETF-Dokumente sind frei zugänglich unter http://tools.ietf.org. Persönlich finde ich den IETF Datatracker etwas benutzerfreundlicher, da er eine Visualisierung des von I-D zu RFC fortschreitenden Dokuments bietet.

Nachfolgend ein Beispiel, das die Entwicklung von RFC 1945 – HTTP/1.0 zeigt und offensichtlich eine Inspirationsquelle für die Zeitleiste des sicheren Webs ist.

IETF-Datatracker-Ansicht von RFC 1945

Interessanterweise habe ich im Laufe meiner Arbeit festgestellt, dass die obige Visualisierung falsch ist. Es fehlt aus irgendeinem Grund draft-ietf-http-v10-spec-05. Da die I-D-Lebensdauer 6 Monate beträgt, scheint es eine Lücke zu geben, bevor er zu einem RFC wurde, während in Wirklichkeit Entwurf 05 noch bis August 1996 aktiv war.

Mit einer kleinen Vorstellung davon, wie Internetstandard-Dokumente reifen, können wir beginnen, die Zeitleiste des sicheren Webs abzuschreiten. In diesem Abschnitt finden Sie eine Reihe von Ausschnittdiagrammen, die einen wichtigen Teil der Zeitleiste zeigen. Jeder Punkt steht für das Datum, an dem ein Dokument oder eine Funktion zur Verfügung gestellt wurde. Bei IETF-Dokumenten werden aus Gründen der Übersichtlichkeit die Entwurfsnummern weggelassen. Wenn Sie jedoch all diese Details sehen möchten, schauen Sie sich bitte die komplette Zeitleiste an.

HTTP nahm seinen Anfang 1991 als sogenanntes HTTP/0.9-Protokoll. 1994 wurde der I-D draft-fielding-http-spec-00 veröffentlicht. Dieser wurde kurz darauf von der IETF angenommen, was dazu führte, dass der Name in draft-ietf-http-v10-spec-00 geändert wurde. Der I-D durchlief sechs Entwurfsversionen, bevor er 1996 als RFC 1945 – HTTP/1.0 veröffentlicht wurde.

Noch bevor die Arbeit an HTTP/1.0 abgeschlossen war, begann jedoch eine separate Aktivität für HTTP/1.1. Der I-D draft-ietf-http-v11-spec-00 wurde im November 1995 veröffentlicht und 1997 offiziell als RFC 2068 veröffentlicht. Wer genau hinsieht, wird erkennen, dass die Zeitleiste des sicheren Webs diese Abfolge von Ereignissen nicht ganz erfasst; dies ist ein unglücklicher Nebeneffekt der Werkzeuge, mit denen die Visualisierung erzeugt wurde. Ich habe versucht, solche Probleme nach Möglichkeit zu minimieren.

Mitte 1997 wurde eine Überarbeitung von HTTP/1.1 in Form von draft-ietf-http-v11-spec-rev-00 gestartet. Sie wurde 1999 mit der Veröffentlichung von RFC 2616 abgeschlossen. Dann beruhigten sich die Dinge in der IETF-HTTP-Welt bis zum Jahr 2007. Darauf werden wir gleich noch zurückkommen.

Lassen Sie uns zu SSL kommen. Wir können sehen, dass die SSL-2.0-Spezifikation irgendwann um 1995 veröffentlicht wurde und dass SSL 3.0 im November 1996 veröffentlicht wurde. Interessanterweise wird SSL 3.0 durch RFC 6101 beschrieben, der im August 2011 veröffentlicht wurde. Er befindet sich in der Kategorie Historisch, was „in der Regel mit Dokumentideen geschieht, die in Erwägung gezogen und verworfen wurden, oder mit Protokollen, die bereits historisch waren, als beschlossen wurde, sie zu dokumentieren“, so die IETF. In diesem Fall ist es von Vorteil, ein IETF-eigenes Dokument zu haben, das SSL 3.0 beschreibt, da es an anderer Stelle als kanonische Referenz verwendet werden kann.

Interessanter für uns ist, wie SSL die Entwicklung von TLS inspiriert hat, das im November 1996 als draft-ietf-tls-protocol-00 seinen Anfang nahm. Es durchlief sechs Entwurfsversionen und wurde Anfang 1999 als RFC 2246 – TLS1.0 veröffentlicht.

Zwischen 1995 und 1999 wurden die SSL- und TLS-Protokolle für die Sicherheit der HTTP-Kommunikation im Internet verwendet. Dies funktionierte als De-facto-Standard sehr gut. Erst im Januar 1998 wurde der formelle Standardisierungsprozess für HTTPS mit der Veröffentlichung des I-D draft-ietf-tls-https-00 eingeleitet. Diese Arbeit endete im Mai 2000 mit der Veröffentlichung von RFC 2616 – HTTP over TLS.

TLS entwickelte sich zwischen 2000 und 2007 mit der Standardisierung von TLS 1.1 und 1.2 weiter. Es gab dann eine Pause von sieben Jahren bis zum Beginn der Arbeiten an der nächsten Version von TLS, die im April 2014 als draft-ietf-tls-tls13-00 angenommen und im August 2018 nach 28 Entwürfen als RFC 8446 – TLS 1.3 abgeschlossen wurde.

Ich hoffe, dass Sie durch diesen kleinen Blick auf die Zeitleiste ein Gefühl dafür entwickeln konnten, wie die IETF arbeitet. Verallgemeinert formuliert nehmen Internetstandards dadurch Gestalt an, dass Forscher oder Entwickler experimentelle Protokolle entwerfen, die auf ihren spezifischen Anwendungsfall zugeschnitten sind. Sie experimentieren mit Protokollen, ob öffentlich oder privat, auf verschiedenen Ebenen. Mit den Daten können Verbesserungen oder Probleme besser identifiziert werden. Die Arbeit kann veröffentlicht werden, um das Experiment zu erklären und einen breiteren Input zu sammeln oder andere Implementierer zu finden. Die Übernahme dieser frühen Arbeit durch andere kann sie zu einem De-facto-Standard machen; schließlich kann es genügend Dynamik geben, um eine formelle Standardisierung in Betracht zu ziehen.

Der Status eines Protokolls kann ein wichtiger Aspekt für Organisationen sein, die darüber nachdenken, es zu implementieren, bereitzustellen oder in irgendeiner Weise zu nutzen. Ein formeller Standardisierungsprozess kann einen De-facto-Standard attraktiver machen, da er in der Regel für Stabilität sorgt. Die Verantwortung und Führung wird von einer Organisation wie der IETF übernommen, die ein breiteres Spektrum an Erfahrungen widerspiegelt. Es ist jedoch hervorzuheben, dass nicht alle formellen Standards erfolgreich sind.

Der Prozess der Erstellung eines endgültigen Standards ist fast so wichtig wie der Standard selbst. Eine Anfangsidee aufzunehmen und Menschen mit mehr Wissen, Erfahrung und Anwendungsfällen zum Mitmachen einzuladen, kann zu einem Ergebnis führen, das für breitere Bevölkerungskreise von größerem Nutzen sein wird. Der Standardisierungsprozess ist jedoch nicht immer einfach. Es gibt Fallstricke und Hürden. Manchmal dauert der Prozess so lange, dass das Ergebnis nicht mehr relevant ist.

Jede Standardisierungsorganisation hat ihren eigenen Prozess, der sich an ihrem Gebiet und ihren Teilnehmern orientiert. Alle Details der Funktionsweise der IETF zu erklären, ginge weit über den Rahmen dieses Blogbeitrags hinaus. Die Seite „How we work“ der IETF ist ein ausgezeichneter Ausgangspunkt auf Englisch, der viele Aspekte abdeckt. Die beste Methode, Verständnis zu entwickeln, ist wie immer, sich selbst zu beteiligen. Dies kann so einfach sein, wie einer E-Mail-Liste beizutreten oder zu einer Diskussion über ein relevantes GitHub-Repository beizutragen.

Cloudflare ist stolz darauf, frühzeitiger Anwender neuer und entstehender Protokolle zu sein. Wir haben eine lange Tradition in der frühzeitigen Einführung neuer Standards, wie z. B. HTTP/2. Wir testen auch Funktionen, die experimentell oder noch nicht endgültig sind, wie TLS 1.3 und SPDY.

Im Zusammenhang mit dem IETF-Standardisierungsprozess können wir durch Bereitstellung dieses lauffähigen Codes in realen Netzwerken für eine Vielzahl von Websites besser verstehen, wie gut das Protokoll in der Praxis funktionieren wird. Wir kombinieren unser vorhandenes Fachwissen mit experimentellen Daten, um den lauffähigen Code zu verbessern, und teilen der Arbeitsgruppe, die ein Protokoll standardisiert, Probleme oder Verbesserungsvorschläge mit, wenn es sinnvoll ist.

Das Testen neuer Dinge ist nicht die einzige Priorität. Zum Innovationsgeist gehört auch zu wissen, wann es an der Zeit ist, nach vorne zu blicken und ältere Innovationen hinter sich zu lassen. Manchmal bezieht sich dies auf sicherheitsorientierte Protokolle; z. B. hat Cloudflare SSLv3 aufgrund der POODLE-Schwachstelle standardmäßig deaktiviert. In anderen Fällen werden Protokolle durch technologisch fortschrittlichere ersetzt; Cloudflare hat beispielsweise zugunsten von HTTP/2 SPDY-Unterstützung als veraltet markiert.

Wenn relevante Protokolle eingeführt bzw. als ausgemustert werden, wird dies auf der Zeitleiste des sicheren Webs in Form orangefarbener Linien dargestellt. An gepunkteten vertikalen Linien kann man erkennen, wie Cloudflare-Ereignisse mit relevanten IETF-Dokumenten zusammenhängen. So führte Cloudflare beispielsweise im September 2016 die Unterstützung von TLS 1.3 ein, während das endgültige Dokument RFC 8446 erst fast zwei Jahre später im August 2018 veröffentlicht wurde.

HTTP/1.1 ist ein sehr erfolgreiches Protokoll und die Zeitleiste zeigt, dass es nach 1999 nicht viel Aktivität in der IETF gab. Eine wirkliche Arbeitsrückschau zeigt jedoch auch, dass jahrelange aktive Nutzung zu Implementierungserfahrungen führte, durch die latente Probleme mit RFC 2616 aufgedeckt werden konnten, die einige Interoperabilitätsprobleme verursachten. Darüber hinaus wurde das Protokoll durch weitere RFCs wie 2817 und 2818 erweitert. Im Jahr 2007 wurde beschlossen, eine neue Aktivität zur Verbesserung der HTTP-Protokollspezifikation zu starten. Diese wurde HTTPbis genannt (wobei „bis“ aus dem Lateinischen stammt und „zwei“, „zweimal“ oder „zum zweiten Mal“ bedeutet) und nahm die Form einer neuen Arbeitsgruppe an. Die ursprüngliche Charta beschreibt sehr gut die Probleme, für die eine Lösung gesucht wurde.

Kurz gesagt, HTTPbis entschied sich für eine Überarbeitung von RFC 2616. Sie sollte Fehlerbehebungen enthalten und einige Aspekte anderer Spezifikationen, die in der Zwischenzeit veröffentlicht wurden, einbeziehen. Man entschied, das Dokument in Teile aufzuteilen. Dies führte im Dezember 2007 zur Veröffentlichung von sechs I-Ds:

• draft-ietf-httpbis-p1-messaging

• draft-ietf-httpbis-p2-semantics

• draft-ietf-httpbis-p4-conditional

• draft-ietf-httpbis-p5-range

• draft-ietf-httpbis-p6-cache

• draft-ietf-httpbis-p7-auth

Das Diagramm zeigt, wie diese Arbeit in einem sieben Jahre lang andauernden Entwicklungsprozess voranschritt, mit 27 Entwürfen vor der endgültigen Standardisierung. Im Juni 2014 wurde die sogenannte RFC-723x-Serie veröffentlicht (wobei x von 0 bis 5 reicht). Der Vorsitzende der HTTPbis-WG feierte diese Leistung mit dem Jubelruf „RFC2616 ist tot“. Wenn das noch nicht klar genug war, durch diese neuen Dokumente war der ältere RFC 2616 veraltet.

Während die IETF eifrig an der RFC-723x-Serie arbeitete, hat die Erde sich weitergedreht. Man hat HTTP im Internet weiter verbessert, es erweitert und damit experimentiert. Das hat auch Google getan und begonnen, mit etwas namens SPDY (ausgesprochen speedy) zu experimentieren. Dieses Protokoll wurde als Performance-Verbesserung für das Surfen im Internet angepriesen, ein Hauptanwendungsfall für HTTP. Ende 2009 wurde SPDY v1 angekündigt, sehr schnell gefolgt von SPDY v2 im Jahr 2010.

Ich möchte auf die technischen Details von SPDY nicht weiter eingehen. Das ist ein Thema für eine andere Gelegenheit. Man muss nur wissen, dass bei SPDY die Kernparadigmen von HTTP übernommen und das Austauschformat leicht modifiziert wurde, um Verbesserungen zu erzielen. Im Nachhinein können wir sehen, dass HTTP eine klar abgegrenzte Semantik und Syntax hat. Semantik beschreibt das Konzept des Anforderungs- und Antwort-Austauschs, einschließlich Methoden, Statuscodes, Header-Felder (Metadaten) und Bodys (Nutzdaten). Die Syntax beschreibt, wie Semantik bei der Übertragung in Bytes abgebildet wird.

HTTP/0.9, 1.0 und 1.1 haben viele Semantiken gemeinsam. Sie besitzen auch gleiche Syntax in Form von Zeichenketten, die über TCP-Verbindungen gesendet werden. SPDY nahm die HTTP/1.1-Semantik und änderte die Syntax von Zeichenketten auf binär. Das ist ein wirklich interessantes Thema, aber wir werden uns heute darin nicht weiter vertiefen.

Googles Experimente mit SPDY zeigten, dass es vielversprechend sein kann, die HTTP-Syntax zu ändern und die bestehende HTTP-Semantik beizubehalten. So konnten beispielsweise durch die Beibehaltung des Formats https:// für URLs viele Probleme vermieden werden, die die Akzeptanz hätten beeinträchtigen können.

Nachdem die IETF einige der positiven Ergebnisse gesehen hatte, entschied sie, dass es an der Zeit war, zu überlegen, wie HTTP/2.0 aussehen könnte. Die Folien der HTTPbis-Sitzung während der IETF 83 im März 2012 zeigen die Anforderungen, Ziele und Erfolgsmaßstäbe, die festgelegt wurden. Es wird auch klar formuliert, dass „HTTP/2.0 nur bedeutet, dass das Übertragungsformat nicht mit dem von HTTP/1.x kompatibel ist“.

Während dieses Meetings wurde die Community aufgefordert, Vorschläge auszutauschen. Zu den zur Prüfung vorgelegten I-Ds gehörten draft-mbelshe-httpbis-spdy-00, draft-montenegro-httpbis-speed-mobility-00 und draft-tarreau-httpbis-network-friendly-00. Letztendlich wurde der SPDY-Entwurf angenommen und im November 2012 mit der Arbeit an draft-ietf-httpbis-http2-00 begonnen. Nach 18 Entwürfen über einen Zeitraum von etwas mehr als zwei Jahren wurde 2015 RFC 7540 – HTTP/2 veröffentlicht. Während dieses Spezifikationszeitraums divergierte die genaue Syntax von HTTP/2 gerade so weit, dass HTTP/2 und SPDY inkompatibel wurden.

Diese Jahre waren eine sehr arbeitsreiche Zeit für die auf HTTP bezogene Arbeit bei der IETF, zumal die HTTP/1.1-Umarbeitung und die HTTP/2-Standardisierung parallel stattfanden. Dies steht im krassen Gegensatz zu den vielen ruhigen Jahren im ersten Jahrzehnt des 21. Jahrhunderts. Wenn Sie sich den Arbeitsaufwand wirklich klarmachen möchten, sollten Sie sich die vollständige Zeitleiste ansehen.

Obwohl sich HTTP/2 im Prozess der Standardisierung befand, war es dennoch auch von Vorteil, SPDY zu nutzen und damit zu experimentieren. Cloudflare hat die Unterstützung von SPDY im August 2012 eingeführt und erst im Februar 2018 eingestellt, als unsere Statistiken zeigten, dass weniger als 4 % der Web-Clients SPDY weiterhin wünschten. Unterdessen haben wir im Dezember 2015, kurz nach der Veröffentlichung des RFC, die HTTP/2-Unterstützung eingeführt, als unsere Analyse ergab, dass ein bedeutender Teil der Web-Clients es nutzen könnte.

Die Web-Client-Unterstützung der Protokolle SPDY und HTTP/2 bevorzugte die sichere Option der Verwendung von TLS. Die Einführung von Universal SSL im September 2014 trug dazu bei, dass alle bei Cloudflare registrierten Websites die Vorteile dieser neuen Protokolle bei ihrer Einführung nutzen konnten.

Google setzte seine Experimente zwischen 2012 und 2015 fort und veröffentlichte SPDY v3 und v3.1. Dort begann man auch mit der Arbeit an gQUIC (damals wie das englische quick ausgesprochen) und die erste öffentliche Spezifikation wurde Anfang 2012 veröffentlicht.

Für die frühen Versionen von gQUIC wurde die SPDY-v3-Form der HTTP-Syntax verwendet. Diese Wahl war sinnvoll, da HTTP/2 noch nicht fertig war. Die binäre SPDY-Syntax wurde in QUIC-Pakete gepackt, die in UDP-Datagrammen gesendet werden konnten. Dies war eine Abkehr vom TCP-Transport, auf den sich HTTP traditionell stützte. Übereinander geschichtet sah es so aus:

SPDY-über-gQUIC-Schichttorte

gQUIC hat mit cleveren Tricks die Performance gesteigert. Einer davon war es, die klare Schichtung zwischen Anwendung und Transport zu durchbrechen. In der Praxis bedeutete dies, dass gQUIC immer nur HTTP unterstützte. So sehr, dass gQUIC, damals „QUIC“ genannt, gleichbedeutend mit der nächsten Kandidatenversion von HTTP war. Trotz kontinuierlicher Änderungen an QUIC in den letzten Jahren, auf die wir gleich kurz eingehen werden, wird der Begriff QUIC bis heute von vielen als diese erste Nur-HTTP-Variante verstanden. Leider sorgt dies bei der Diskussion des Protokolls regelmäßig für Verwirrung.

Die Experimente mit gQUIC wurden fortgesetzt und es wurde schließlich auf eine Syntax umgestellt, die HTTP/2 viel näher kam. So nah, dass die meisten Leute es einfach „HTTP/2-über-QUIC“ nannten. Aufgrund technischer Einschränkungen gab es jedoch einige sehr feine Unterschiede. Ein Beispiel hat damit zu tun, wie die HTTP-Header serialisiert und ausgetauscht wurden. Der Unterschied ist nur klein, bedeutete aber letztendlich, dass HTTP/2-über-gQUIC mit dem HTTP/2 der IETF nicht kompatibel war.

Nicht zuletzt müssen wir bei Internetprotokollen immer auch die Sicherheitsaspekte berücksichtigen. gQUIC hat sich entschieden, TLS nicht zur Gewährleistung der Sicherheit einzusetzen. Stattdessen entwickelte Google einen anderen Ansatz namens QUIC Crypto. Einer der interessanten Aspekte dabei war eine neue Methode zur Beschleunigung des Sicherheits-Handshake-Verfahrens. Ein Client, der zuvor eine sichere Sitzung mit einem Server eingerichtet hatte, konnte Informationen wiederverwenden, um einen „Null-Paketumlaufzeit (zero round-trip time)“-Handshake, einen 0-RTT-Handshake, durchzuführen. 0-RTT wurde später in TLS 1.3 integriert.

Fast.

Mittlerweile sollten Sie wissen, wie Standardisierung funktioniert, und mit gQUIC verhielt es sich nicht viel anders. Es gab genügend Interesse, sodass die Google-Spezifikationen im I-D-Format formuliert wurden. Im Juni 2015 wurde draft-tsvwg-quic-protocol-00 mit dem Titel „QUIC: A UDP-based Secure and Reliable Transport for HTTP/2“ („QUIC: Ein UDP-basierter sicherer und zuverlässiger Transport für HTTP/2“) eingereicht. Denken Sie an meine frühere Aussage, dass die Syntax fast-HTTP/2 war.

Google kündigte an, dass auf dem IETF 93 in Prag ein Bar BoF stattfinden würde. Wenn Sie neugierig sind, was ein „Bar BoF“ ist, konsultieren Sie bitte RFC 6771. Tipp: BoF steht für Birds of a Feather, Gleichgesinnte.

Das Ergebnis dieser Zusammenarbeit mit der IETF war, kurz gesagt, dass QUIC viele Vorteile auf der Transportschicht zu bieten schien und dass es von HTTP entkoppelt werden sollte. Die klare Trennung zwischen den Schichten sollte wieder eingeführt werden. Darüber hinaus gab es eine Präferenz für die Rückkehr zu einem TLS-basierten Handshake (was nicht so schlimm war, da TLS 1.3 zu diesem Zeitpunkt in Entwicklung war und bereits 0-RTT-Handshakes enthielt).

Etwa ein Jahr später, im Jahr 2016, wurde ein neuer Satz von I-Ds eingereicht:

• draft-hamilton-quic-transport-protocol-00

• draft-thomson-quic-tls-00

• draft-iyengar-quic-loss-recovery-00

• draft-shade-quic-http2-mapping-00

Hier steckt eine weitere Ursache für Verwechslungen im Zusammenhang mit HTTP und QUIC: draft-shade-quic-http2-mapping-00 trägt den Titel „HTTP/2 Semantics Using The QUIC Transport Protocol“ („HTTP/2-Semantik mit dem QUIC-Transportprotokoll“) und beschreibt sich selbst als „Mapping der HTTP/2-Semantik über QUIC“. Dies ist jedoch eine irreführende Bezeichnung. Bei HTTP/2 ging es darum, die Syntax zu ändern und gleichzeitig die Semantik zu erhalten. Außerdem war „HTTP/2-über-gQUIC“ aus den oben bereits genannten Gründen auch nie eine genaue Beschreibung der Syntax. Behalten Sie das im Kopf.

Diese IETF-Version von QUIC sollte ein völlig neues Transportprotokoll werden. Das ist ein großes Unterfangen, und bevor sich die IETF kopfüber in solche Verpflichtungen stürzt, misst sie gerne das tatsächliche Interesse ihrer Mitglieder. Zu diesem Zweck wurde auf dem IETF-Meeting 96 in Berlin im Jahr 2016 ein formelles Birds of a Feather-Meeting abgehalten. Ich hatte das Glück, persönlich an der Sitzung teilzunehmen, und die Folien werden ihr nicht gerecht. An dem Meeting nahmen Hunderte von Menschen teil, wie das Foto von Adam Roach zeigt. Am Ende der Sitzung wurde ein Konsens erzielt: QUIC würde von der IETF angenommen und standardisiert.

Der erste IETF QUIC-I-D zum Mapping von HTTP mit QUIC, draft-ietf-quic-http-00, folgte dem Ronseal-Ansatz und vereinfachte seinen Namen in „HTTP-über-QUIC“. Leider wurde die Arbeit nicht vollständig durchgeführt und es gab im Text viele Stellen, an denen noch der Begriff HTTP/2 verwendet wurde. Mike Bishop, der neue Editor des I-D, erkannte dies und begann, die Fehlbezeichnung HTTP/2 zu korrigieren. Im Entwurf 01 wurde die Beschreibung in „Mapping von HTTP-Semantik über QUIC“ geändert.

Im Laufe der Zeit und der Versionen nahm die Verwendung des Begriffs „HTTP/2“ ab und die Fälle wurden zu bloßen Verweisen auf Teile von RFC 7540. Zwei Jahre später, im Oktober 2018, ist der I-D nun bei Version 16. Auch wenn HTTP-über-QUIC Ähnlichkeit mit HTTP/2 aufweist, ist es letztlich eine unabhängige, nicht rückwärtskompatible HTTP-Syntax. Für diejenigen, die die IETF-Entwicklung nicht sehr genau verfolgen (was für einen sehr großen Prozentsatz der Erdbevölkerung gilt), ist dieser Unterschied jedoch nicht im Dokumentnamen enthalten. Einer der Hauptpunkte der Standardisierung ist die Unterstützung von Kommunikation und Interoperabilität. Doch eine einfache Sache wie das Benennen trägt viel dazu bei, dass Verwirrung in der Community entsteht.

Erinnern Sie sich daran, dass 2012 gesagt wurde, dass „HTTP/2.0 nur bedeutet, dass das Übertragungsformat nicht mit dem von HTTP/1.x kompatibel ist“. Die IETF griff diesen Gedanken auf. Nach langer Überlegung im Vorfeld und während des IETF 103 wurde Konsens darüber erzielt, „HTTP-über-QUIC“ in HTTP/3 umzubenennen. Die Welt ist jetzt ein besserer Ort, und wir können zu wichtigeren Debatten übergehen.

Manchmal können Dokumententitel für Verwirrung sorgen. Die derzeitigen HTTP-Dokumente, die Syntax und Semantik beschreiben, sind:

• RFC 7230 – Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (Nachrichtensyntax und Routing)

• RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (Semantik und Inhalte)

Man kann zu viel in diese Namen hineinlesen und glauben, dass grundlegende HTTP-Semantik spezifisch für Versionen von HTTP, z. B. HTTP/1.1, ist. Dabei handelt es sich jedoch um eine unbeabsichtigte Nebenwirkung des HTTP-Stammbaums. Die gute Nachricht ist, dass die HTTPbis-Arbeitsgruppe versucht, sich dem zu stellen. Einige mutige Mitglieder sind mit einer weiteren Runde der Dokumentenrevision beschäftigt, wie Roy Fielding es ausdrückte, „Auf ein Neues!“. Diese Arbeit ist im Moment im Gange und wird als HTTP-Core-Aktivität bezeichnet (Sie haben davon vielleicht auch unter den Namen HTTPtre oder HTTPter gehört; es ist schwierig, Dinge zu benennen). Dadurch werden die sechs Entwürfe auf drei reduziert:

• HTTP Semantics (draft-ietf-httpbis-semantics)

• HTTP Caching (draft-ietf-httpbis-caching)

• HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)

Unter dieser neuen Struktur wird deutlicher, dass HTTP/2 und HTTP/3 Syntaxdefinitionen für die gemeinsame HTTP-Semantik sind. Das bedeutet nicht, dass sie keine eigenen Funktionen jenseits der Syntax haben, aber es sollte helfen, die zukünftige Diskussion zu lenken.

Dieser Blogbeitrag hat einen oberflächlichen Blick auf den Standardisierungsprozess für HTTP in der IETF in den letzten drei Jahrzehnten geworfen. Ohne auf allzu viele technische Details einzugehen, habe ich versucht zu erklären, wie wir zu HTTP/3 gekommen sind. Wenn Sie die guten Teile in der Mitte übersprungen haben und nach einem Einzeiler suchen, dann ist es der hier: HTTP/3 ist nur eine neue HTTP-Syntax, die auf IETF QUIC, einem UDP-basierten, sicheren Transport mit Multiplexing, funktioniert. Es gibt viele interessante technische Bereiche, die man weiter erörtern könnte, aber das wird zu einem anderen Zeitpunkt geschehen müssen.

Im Laufe dieses Blogbeitrags haben wir wichtige Kapitel in der Entwicklung von HTTP und TLS untersucht, dies aber isoliert. Wir beenden den Beitrag, indem wir sie alle zusammen in die vollständige Zeitleiste des sicheren Webs ziehen, die unten präsentiert wird. Dadurch können Sie die detaillierte Historie nach Belieben selbst untersuchen. Und für die Superspürhunde: Versäumen Sie nicht, sich die vollständige Version mit den Entwurfnummern anzusehen.