Das HTTP-Anwendungsschichtprotokoll liegt dem Internet zugrunde. Es begann sein Leben 1991 als HTTP / 0.9 und wurde 1999 zu HTTP / 1.1, das vom Internet Engineering Council (IETF) standardisiert wurde.

HTTP / 1.1 hat lange Zeit alle zufrieden gestellt, aber die wachsenden Anforderungen des Web erforderten ein Upgrade - und 2015 wurde HTTP / 2 eingeführt. Die Geschichte endete nicht dort: Erst kürzlich kündigte die IETF eine neue Version von HTTP / 3 an. Für einige war dies eine Überraschung und sorgte für einige Verwirrung. Wenn Sie die IETF nicht überwachen, scheint HTTP / 3 aus dem Nichts zu stammen. Trotzdem können wir seinen Ursprung anhand der Versuchsgeschichte und der Entwicklung der Webprotokolle, insbesondere des QUIC-Transportprotokolls, verfolgen.

Wenn Sie mit QUIC nicht vertraut sind, haben meine Cloudflare-Kollegen verschiedene Aspekte ausführlich behandelt: Lesen Sie beispielsweise Artikel zu den tatsächlichen Fehlern des modernen HTTP und Details zum Transportschichtprotokoll . Wir haben diese und andere Materialien bei cloudflare-quic.com gesammelt . Und wenn Sie interessiert sind, schauen Sie sich unbedingt die Quiche an : Es ist unsere eigene Implementierung von QUIC, geschrieben in Rust mit Open Source Code.

HTTP / 3 - Übersetzung des QUIC-Transportprotokolls für die Anwendungsschicht. Der Name HTTP / 3 wurde erst kürzlich in der 17. Version des Entwurfs ( Entwurf-ietf-quic-http-17 ) offiziell genehmigt. Es wurde Ende Oktober 2018 vorgeschlagen und auf dem IETF 103-Treffen im November in Bangkok ein Konsens erzielt.

Zuvor war HTTP / 3 von QUIC als HTTP bekannt, und zuvor - von gQUIC als HTTP / 2 und noch früher - von gQUIC als SPDY. Unter dem Strich ist HTTP / 3 jedoch nur die neue HTTP-Syntax, die auf dem IETF QUIC-Protokoll ausgeführt wird, einem gemultiplexten und sicheren Transport, der auf UDP basiert.

In diesem Artikel werden wir uns die Geschichte einiger der vorherigen HTTP / 3-Namen ansehen und die Motivation für die Änderung des Nachnamens vorstellen. Kommen wir zurück zu den ersten Tagen von HTTP und allem, was in dieser Zeit passiert ist. Wenn Sie das vollständige Bild erhalten möchten, können Sie sofort zum Ende des Artikels gehen oder diese sehr detaillierte Version von SVG öffnen.


HTTP / 3-Schicht-Kuchen

Einrichtung

Bevor Sie sich auf HTTP konzentrieren, sollten Sie daran erinnern, dass es zwei Protokolle gibt, die als QUIC bezeichnet werden. Wie bereits erläutert , wird gQUIC normalerweise als Abkürzung für Google QUIC (Quellprotokoll) und QUIC als IETF-Version verwendet, die sich von gQUIC unterscheidet.

Seit Anfang der 90er Jahre haben sich die Bedürfnisse des Internets geändert. Wir haben neue Versionen von HTTP und eine neue Sicherheitsstufe in Form des TLS-Protokolls (Transport Layer Security). In diesem Artikel werden nur TLS behandelt, und in anderen Artikeln unseres Blogs können Sie das Thema genauer untersuchen.

Die Geschichte von HTTP und TLS kann nicht mit einer einfachen Liste von Daten ausgedrückt werden, da sich einige Zweige parallel entwickelten und zeitlich überlappten. Wenn Sie versuchen, alle Punkte in fast 30 Jahren Geschichte des Internets miteinander zu verbinden, können Sie nicht auf Visualisierung verzichten. Also habe ich diesen Zeitplan erstellt: Cloudflare Secure Web Timeline. (Hinweis: Technisch gesehen ist dies ein Cladogramm , obwohl die Leute mit dem Wort „Grafik“ besser vertraut sind.)



Der Schönheit halber habe ich einige Informationen gelöscht und mich nur auf erfolgreiche Niederlassungen im IETF-Bereich konzentriert. Beispielsweise werden die Bemühungen der HTTP-NG-Arbeitsgruppe des W3-Konsortiums sowie einige exotische Technologien, deren Aussprache die Autoren noch zu erklären versuchen, hier nicht gezeigt: HMURR (ausgesprochen "hummer") und WAKA (ausgesprochen "wah-kah").

In den folgenden Abschnitten werden wir dieses Cladogramm durchgehen und einige Wendepunkte in der Geschichte von HTTP betrachten. Ich hoffe, dies hilft zu verstehen, warum Standardisierung für alle von Vorteil ist und wie die IETF dieses Problem angeht. Daher beginnen wir mit einem sehr kurzen Überblick über das Thema, bevor wir zum Zeitplan selbst zurückkehren. Wenn Sie bereits mit der IETF vertraut sind, können Sie den nächsten Abschnitt überspringen.

Arten von Internet-Standard

In der Regel definieren Standards allgemeine Kompetenz, Umfang, Einschränkungen, Anwendbarkeit und andere Überlegungen. Standards gibt es in vielen Formen und Größen. Sie können informell (De-facto-Standard) oder formell (von einer Organisation zur Festlegung von Standards wie IETF, ISO oder MPEG vereinbart / veröffentlicht) sein. Standards werden in vielen Bereichen verwendet, es gibt sogar einen formalen britischen Standard für die Herstellung von Tee - BS 6008.

Die ersten HTTP- und SSL-Protokolldefinitionen wurden außerhalb der IETF veröffentlicht: Sie sind im Diagramm mit roten Linien markiert. Die weit verbreitete Verwendung hat sie jedoch zu De-facto-Standards gemacht.

Irgendwann beschlossen sie, diese Protokolle zu formalisieren (einige Gründe werden unten beschrieben). Internetstandards werden normalerweise in der IETF definiert, die sich an dem inoffiziellen Prinzip des „beispielhaften Konsenses und des aktuellen Codes“ orientiert, das auf realen Anwendungen im Internet basiert. Dies unterscheidet sich vom Reinraumansatz, wenn jemand versucht, ideale Protokolle im luftleeren Raum zu entwickeln.

IETF-Standards werden allgemein als RFCs bezeichnet. Es ist schwer kurz zu erklären, daher empfehle ich den Artikel "Wie man RFC liest" vom Co-Vorsitzenden der QUIC-Arbeitsgruppe Mark Nottingham. Eine Arbeitsgruppe oder Arbeitsgruppe ist im Wesentlichen nur eine Mailingliste.

Jedes Jahr gibt es drei Treffen für persönliche Treffen von Mitgliedern aller Arbeitsgruppen, wenn sie dies wünschen. Die Tagesordnung für diese Wochen kann sehr voll sein, es bleibt nicht genügend Zeit für eine eingehende Diskussion technischer Fragen. Einige ziehen es daher vor, mehr mittelfristige Sitzungen zwischen den IETF-Hauptversammlungen abzuhalten. Die QUIC-Arbeitsgruppe hat seit 2017 mehrere Zwischensitzungen abgehalten. Die vollständige Liste finden Sie auf der Seite mit den Sitzungen .

Diese Treffen bieten die Möglichkeit, Experten aus anderen Organisationen wie dem Internet Architecture Council (IAB) oder der Internet Technology Research Group (IRTF) zu treffen. In den letzten Jahren hat das Wochenende vor der IETF traditionell den IETF-Hackathon abgehalten. Hier wird echter Code entwickelt, der vor allem Kompatibilitätstests besteht. Dies hilft, Probleme in den Spezifikationen zu finden, die direkt in der Besprechung besprochen werden können.

Es ist wichtig zu verstehen, dass RFCs nicht aus dem Nichts entstehen. Sie durchlaufen einen ganzen Prozess. Es beginnt normalerweise mit einem Entwurf eines IETF-Internetentwurfs (ID), der zur Überprüfung eingereicht wird. In dem Fall, in dem die Spezifikation bereits veröffentlicht wurde, wird die Erstellung einer ID zu einer einfachen Neuformatierung. Die Lebensdauer der ID beträgt 6 Monate ab dem Datum der Veröffentlichung. Um es aktiv zu halten, müssen Sie neue Versionen veröffentlichen. In der Praxis ist es in Ordnung, dass die ID abläuft. Das passiert ziemlich oft. Dokumente werden weiterhin auf der IETF-Website gespeichert und stehen allen offen.

Auf dem Cladogramm werden Entwürfe in lila dargestellt . Jeder hat seinen eigenen Namen im Format Entwurf- {Autor} - {Arbeitsgruppe} - {Thema} - {Version} . Das WG-Feld ist optional, es kann auf eine zukünftige IETF-Arbeitsgruppe verweisen und sich manchmal ändern. Wenn die ID von der IETF genehmigt oder direkt in der IETF initiiert wurde, heißt der Entwurf Draft-Ietf- {Arbeitsgruppe} - {Thema} - {Version} . IDs können verzweigt, zusammengeführt oder ausgeblendet werden. Die Version beginnt bei 00 und erhöht sich mit jedem neuen Projekt um eins. Beispielsweise erhält der vierte Entwurf die Versionsnummer 03. Jedes Mal, wenn der ID-Name geändert wird, wird seine Version auf 00 zurückgesetzt.

Es ist wichtig zu beachten, dass jeder seinen Entwurf bei der IETF einreichen kann: Sie können nicht als Standards betrachtet werden. Wenn der Standardisierungsprozess jedoch einen Konsens erreicht und das endgültige Dokument den Test besteht, erhalten wir einen RFC. Zu diesem Zeitpunkt ändert sich der Name erneut. Jeder RFC erhält eine eindeutige Nummer, z. B. RFC 7230 . Dokumente mit diesem Status werden als blaue Linien angezeigt.

RFC darf nicht geändert werden. Das heißt, Änderungen am RFC erfordern die Annahme eines Dokuments mit einer neuen Nummer. Änderungen sind nur zur Korrektur von redaktionellen oder technischen Fehlern oder zur einfachen Layoutoptimierung zulässig. Neue RFCs können die alten vollständig ersetzen oder ergänzen.

Alle IETF-Dokumente sind unter http://tools.ietf.org öffentlich verfügbar. Persönlich erscheint es mir etwas bequemer als der IETF-Datatracker , da dort der Dokumentpfad von ID zu RFC visuell angezeigt wird.

Das folgende Beispiel zeigt die Entwicklung des RFC 1945- Standards, d. H. HTTP / 1.0.


Geschichte des RFC 1945 an der IETF Datatracker-Schnittstelle

Interessanterweise stellte ich im Laufe der Arbeit fest, dass die obige Visualisierung falsch ist. Aus irgendeinem Grund fehlt der Entwurf-ietf-http-v10-spec-05 . Da der Ausweis 6 Monate alt ist, ist er wahrscheinlich vor der Annahme des RFC abgelaufen, obwohl der Entwurf in Wirklichkeit bis August 1996 aktiv war.

Ein Cladogramm studieren

Nach einer kurzen theoretischen Einführung können wir beginnen, das Cladogramm zu studieren. Dieser Abschnitt enthält einige Auszüge mit den wichtigsten Teilen. Jeder Punkt gibt das Datum an, an dem das Dokument oder die Funktion bereitgestellt wurde. Aus Gründen der Übersichtlichkeit wurden in IETF-Dokumenten die Projektnummern weggelassen, sie sind jedoch alle in der Vollversion .

HTTP erschien 1991 als HTTP / 0.9-Protokoll, und 1994 wurde Draft-Fielding-http-spec-00 veröffentlicht. Bald wurde es von der IETF akzeptiert, wodurch sich der Name in Draft-ietf-http-v10-spec-00 änderte. Nach sechs Ausgaben des Entwurfs wurde 1996 der RFC 1945- Standard HTTP / 1.0 verabschiedet.



Noch vor Abschluss der Arbeiten an HTTP / 1.0 wurde jedoch ein separates HTTP / 1.1-Projekt gestartet. Der Entwurf des Entwurfs-ietf-http-v11-spec-00 wurde im November 1995 veröffentlicht und 1997 offiziell als RFC 2068 angenommen. Das scharfe Auge wird bemerken, dass das Cladogramm diese Abfolge von Ereignissen nicht ganz widerspiegelt - ein erfolgloser Fehler des Visualisierungstools. Ich habe versucht, solche Probleme nach Möglichkeit zu minimieren.

Mitte 1997 begann eine Überarbeitung von HTTP / 1.1 als Entwurf-ietf-http-v11-spec-rev-00 . Es endete 1999 mit der Veröffentlichung von RFC 2616 . Bis 2007 war in der IETF-HTTP-Welt alles ruhig. Wir kommen etwas später darauf zurück.

SSL- und TLS-Verlauf

Wir wenden uns der SSL-Flugbahn zu. Wir sehen, dass die SSL 2.0-Spezifikation um 1995 und SSL 3.0 im November 1996 veröffentlicht wurde. Interessanterweise ist SSL 3.0 in RFC 6101 zugelassen , das erst im August 2011 erschien. Es befindet sich im historischen Teil. Laut IETF wurde es erstellt, "um Ideen zu dokumentieren, die berücksichtigt und verworfen wurden, oder um Protokolle, die bereits existierten, als beschlossen wurde, sie zu dokumentieren". In diesem Fall benötigte ich ein IETF-Dokument, das SSL 3.0 beschreibt, um es überall als kanonische Verbindung verwenden zu können.

Wir sind mehr daran interessiert, wie SSL Ingenieure zur Entwicklung von TLS inspirierte, das mit einem Entwurf des Entwurfs-ietf-tls-Protokoll-00 im November 1996 begann. Es durchlief 6 Entwurfsversionen und wurde Anfang 1999 als RFC 2246 - TLS 1.0 veröffentlicht.

In den Jahren 1995-1999 wurden SSL und TLS zum Schutz von HTTP-Verbindungen im Internet verwendet. Dies funktionierte als De-facto-Standard hervorragend. Erst im Januar 1998 begann die offizielle Standardisierung von HTTPS mit der Veröffentlichung eines Entwurfsentwurfs-ietf-tls-https-00 . Die Arbeiten wurden im Mai 2000 mit der Veröffentlichung von RFC 2616 - HTTP über TLS abgeschlossen.

TLS hat sich von 2000 bis 2007 mit der Einführung von TLS 1.1 und 1.2 weiterentwickelt. Dann gab es eine siebenjährige Pause, bevor mit der Arbeit an der nächsten Version des TLS-Protokolls begonnen wurde, das im April 2014 als Entwurf-ietf-tls-tls13-00 veröffentlicht und nach 28 Entwürfen im August 2018 als RFC 8446 - TLS 1.3 genehmigt wird.

Internet-Standardisierungsprozess

Nach einer kurzen Bekanntschaft mit dem Cladogramm hoffe ich, dass es besser wurde zu verstehen, wie die IETF funktioniert. Bei der Erstellung von Standards entwickeln Forscher oder Ingenieure experimentelle Protokolle für bestimmte Anwendungsfälle. Auf verschiedenen Ebenen experimentieren sie mit öffentlichen oder privaten Protokollen. Mit den erhaltenen Informationen können Sie Probleme identifizieren oder das Protokoll verbessern. Die Veröffentlichung der Arbeit hilft, das Experiment zu erklären, die Meinung eines größeren Kreises von Spezialisten zu treffen oder Hilfe von anderen Darstellern zu finden. Wenn andere Teilnehmer diese Arbeit frühzeitig akzeptieren, wird sie zum De-facto-Standard, und letztendlich wird es genügend Dynamik für die offizielle Standardisierung geben.

Der offizielle Status des Protokolls ist ein wichtiger Faktor für Organisationen, die darüber nachdenken, es zu verwenden. Der formale Standardisierungsprozess macht den De-facto-Standard attraktiver, da er normalerweise Stabilität bietet. Eine seriöse Organisation wie die IETF, die die Interessen und Erfahrungen vieler Teilnehmer widerspiegelt, übernimmt die Führung und Führung. Es ist jedoch zu beachten, dass nicht alle formalen Standards erfolgreich sind.

Der Prozess der Erstellung eines Standards ist fast genauso wichtig wie der Standard selbst. Die Verarbeitung der ursprünglichen Idee, eine Einladung zur Diskussion von Personen mit umfassenderem Wissen, Erfahrung und Anwendungsfällen - all dies trägt dazu bei, etwas Nützlicheres für ein breites Publikum zu schaffen. Der Standardisierungsprozess ist jedoch nicht immer einfach. Es gibt Fallstricke und Hindernisse. Manchmal dauert ein Prozess so lange, dass das Ergebnis nicht mehr relevant ist.

Jede Organisation, die Standards definiert, hat normalerweise ihren eigenen Prozess, der sich auf ihr Tätigkeitsfeld und ihre Teilnehmer konzentriert. Alle Details der Funktionsweise der IETF zu erläutern, geht weit über den Rahmen dieses Artikels hinaus. Wenn Sie interessiert sind, ist die Seite "Wie wir arbeiten" auf der IETF-Website ein guter Ausgangspunkt. Wie immer ist der beste Weg, es herauszufinden, selbst teilzunehmen. Genug, um sich der Mailingliste oder Diskussion im entsprechenden GitHub-Repository anzuschließen.

Cloudflare-Arbeitscode

Cloudflare ist stolz darauf, einer der ersten zu sein, der neue Protokolle einführt, wie dies bei HTTP / 2 und anderen Technologien der Fall war. Wir testen auch experimentelle und noch nicht genehmigte Funktionen wie TLS 1.3 und SPDY .

Wenn Sie echten Code ausführen, können Sie besser verstehen, wie gut das Protokoll in der Praxis funktioniert. Wir kombinieren Expertenwissen mit experimentellen Informationen, um den Code zu verbessern und, wo es sinnvoll ist, Probleme oder Verbesserungen einer Arbeitsgruppe zu melden, die das Protokoll standardisiert.

Das Testen von Innovationen ist nicht die einzige Priorität. Ein echter Innovator weiß immer, wann er Innovationen auf bessere Zeiten verschieben muss. Dies gilt manchmal für sicherheitsorientierte Protokolle: Beispielsweise hat Cloudflare SSLv3 aufgrund der POODLE-Sicherheitsanfälligkeit standardmäßig deaktiviert. In anderen Fällen werden die Protokolle durch technologisch fortgeschrittenere ersetzt: Zum Beispiel haben wir SPDY durch HTTP / 2 ersetzt .

Das Aktivieren und Deaktivieren von Protokollen in Cloudflare wird durch orangefarbene Linien dargestellt . Vertikale Orientierungspunkte helfen dabei, Cloudflare-Ereignisse mit verwandten IETF-Dokumenten zu korrelieren. Beispielsweise führte Cloudflare im September 2016 die TLS 1.3-Unterstützung ein, und der endgültige RFC 8446 wurde fast zwei Jahre später, im August 2018, veröffentlicht.

Refactoring: HTTPbis

HTTP / 1.1 ist ein sehr erfolgreiches Protokoll. Die Grafik zeigt keine besondere Aktivität der IETF nach 1999. In Wirklichkeit gab die jahrelange aktive Nutzung des Protokolls Erfahrung und enthüllte versteckte Probleme von RFC 2616, einschließlich einiger Kompatibilitätsprobleme. Darüber hinaus wurde das Protokoll um andere RFCs wie 2817 und 2818 erweitert. Infolgedessen wurde 2007 beschlossen, Aktivitäten zur Verbesserung der HTTP-Spezifikation zu starten. Es heißt HTTPbis (wobei "bis" vom lateinischen Wort "zwei", "zweimal" oder "wiederholen" kommt). Die ursprüngliche Charta der neuen Arbeitsgruppe beschreibt gut die Probleme, die sie zu lösen versuchte.

Im Allgemeinen hat HTTPbis begonnen, RFC 2616 umzugestalten. Es enthält Fehlerkorrekturen und die Implementierung einiger Aspekte aus anderen Spezifikationen, die gleichzeitig veröffentlicht werden. Es wurde beschlossen, das Dokument in Teile zu teilen. Infolgedessen wurden im Dezember 2007 sechs Entwürfe veröffentlicht:

• Draft-Ietf-httpbis-p1-Messaging
• Entwurf-ietf-httpbis-p2-Semantik
• Entwurf-ietf-httpbis-p4-bedingt
• Entwurf-ietf-httpbis-p5-Bereich
• Entwurf-ietf-httpbis-p6-Cache
• Entwurf-ietf-httpbis-p7-auth

Das Diagramm zeigt, wie die Arbeit in einem langen siebenjährigen Entwicklungsprozess fortgeschritten ist. Vor der endgültigen Normung wurden 27 Entwürfe angenommen. Im Juni 2014 wurde die sogenannte RFC 723x-Serie (wobei x zwischen 0 und 5 liegt) veröffentlicht. Der Vorsitzende der HTTPbis-Arbeitsgruppe bemerkte diesen Erfolg mit dem Satz „RFC2616 ist tot“. Wenn jemand nicht verstand, wurden die neuen Dokumente an das Archiv des alten RFC 2616 gesendet.

Was hat das mit HTTP / 3 zu tun?

Während die IETF den RFC 723x fertigstellte, stand die Welt nicht still. Die Menschen expandierten weiter und ergänzten HTTP. Unter ihnen sind Google-Ingenieure, die mit ihrem eigenen Protokoll namens SPDY (ausgesprochen „schnell“) zu experimentieren begannen. Sie sagten, dass dieses Protokoll das Laden von Webseiten beschleunigt, was ein wesentliches Merkmal von HTTP ist. Ende 2009 wurde die erste Version angekündigt und 2010 erschien SPDY v2 schnell.

Ich möchte nicht auf technische Details von SPDY eingehen, aber es ist wichtig zu verstehen, dass SPDY die grundlegenden HTTP-Paradigmen übernommen und das Austauschformat zur Optimierung geringfügig geändert hat. Rückblickend sehen wir, dass HTTP eine klare Unterscheidung zwischen Semantik und Syntax aufweist. Die Semantik beschreibt das Konzept des Austauschs von Anforderungen und Antworten, einschließlich Methoden, Statuscodes, Headerfeldern (Metadaten) und Körpern (nützliche Daten). Die Syntax beschreibt, wie Semantik Bytes im Netzwerk zugeordnet werden.

HTTP / 0.9, 1.0 und 1.1 haben viele gemeinsame Semantiken. Sie verwenden auch eine allgemeine Syntax in Form von Zeichenfolgen, die über TCP-Verbindungen gesendet werden. SPDY übernahm die Semantik von HTTP / 1.1 und änderte die Syntax in binär. Dies ist ein wirklich interessantes Thema, aber heute werden wir uns nicht mit diesem Kaninchenbau befassen.

Experimente mit SPDY haben gezeigt, dass das Ändern der HTTP-Syntax wirklich Wirkung bringt. Gleichzeitig ist es wichtig, die vorhandene Semantik beizubehalten. Durch das Speichern des URL-Formats für die Verwendung von https:// viele Probleme vermieden, die sich auf die Implementierung von HTTPS auswirken könnten.

Nachdem die IETF einige positive Ergebnisse gesehen hatte, entschied sie, dass es Zeit war, die Optionen für HTTP / 2.0 zu prüfen. Die Folien aus der HTTPbis-Sitzung während des IETF 83-Meetings im März 2012 zeigen die Anforderungen und Ziele, die die Entwickler für sich selbst festgelegt haben. Darin heißt es eindeutig: „HTTP / 2.0 bedeutet nur, dass das Transportprotokoll (Drahtformat) nicht mit HTTP / 1.x kompatibel ist.“



Während dieses Treffens wurde die Community eingeladen, ihre Ideen auszudrücken. Zu den eingereichten Entwürfen gehörten Draft-Mbelshe-httpbis-spdy-00 , Draft-Montenegro-httpbis-Speed-Mobility-00 und Draft-Tarreau-httpbis-Network-Friendly-00 . Am Ende wurde der Entwurf des SPDY angenommen, und im November 2012 begannen die Arbeiten am Entwurf-ietf-httpbis-http2-00 . Nach 18 Entwürfen erschien RFC 7540 - HTTP / 2 in etwas mehr als zwei Jahren. Bis 2015 war die HTTP / 2-Syntax genau genug, um HTTP / 2 und SPDY inkompatibel zu machen.

Diese Jahre sind für Arbeitsgruppen, die gleichzeitig HTTP / 1.1 überarbeitet und HTTP / 2 eingeführt haben, zu einer sehr stressigen Zeit geworden. Dies steht in scharfem Kontrast zu jahrelanger Ruhe in den frühen 2000er Jahren. Schauen Sie sich unbedingt das vollständige Cladogramm an, um den Arbeitsaufwand wirklich zu schätzen.

Trotz der Standardisierung von HTTP / 2 sind Experimente mit SPDY immer noch nützlich. Cloudflare führte den SPDY-Support im August 2012 ein und entfernte ihn erst im Februar 2018, als unsere Statistiken zeigten, dass weniger als 4% der Web-Clients ihn anfordern. In der Zwischenzeit, kurz nach der Veröffentlichung des RFC im Dezember 2015, haben wir die HTTP / 2-Unterstützung eingeführt, als die Analyse eine signifikante Unterstützung für Web-Clients ergab.

Die Protokolle SPDY und HTTP / 2 verwenden standardmäßig TLS. Durch die Einführung von universellem SSL im September 2014 konnten wir sicherstellen, dass alle Cloudflare-Benutzer die neuen Protokolle bei ihrer Einführung verwenden.

gQUIC

Google experimentierte weiter und veröffentlichte bis 2015 eine weitere Version von SPDY v3 und v3.1. Sie begannen auch mit der Arbeit am gQUIC-Protokoll, dessen erster Entwurf Anfang 2012 veröffentlicht wurde.

Frühere Versionen von gQUIC verwendeten die HTTP SPDY v3-Syntax. Diese Wahl war sinnvoll, da HTTP / 2 noch nicht genehmigt wurde. Die SPDY-Binärsyntax ist in QUIC-Paketen gepackt, die in UDP-Datagrammen gesendet werden. Dies ist eine Abkehr vom TCP-Transport, auf den sich HTTP traditionell verlassen hat. Das gesamte Montagesystem sah folgendermaßen aus:


SPDY Layered Pie von gQUIC

GQUIC verwendete Tricks, um die Leistung zu steigern. Eine davon besteht darin, die klare Linie zwischen der Anwendung und dem Transport zu verwischen. In der Praxis bedeutete dies, dass gQUIC nur HTTP unterstützt. Diese Verbindung war so stark, dass gQUIC, das zu dieser Zeit als QUIC bezeichnet wurde, als Kandidat für die nächste Version von HTTP angesehen wurde. Obwohl in Zukunft viele Änderungen an QUIC vorgenommen wurden, glauben viele Menschen bis heute, dass es nur HTTP unterstützt. Leider führt dies zu ständiger Verwirrung bei der Diskussion des Protokolls.

gQUIC entwickelte sich weiter und wechselte schließlich zu einer Syntax, die HTTP / 2 viel näher kam. So nah, dass die meisten Leute anfingen, es "HTTP / 2 von QUIC" zu nennen. Aufgrund technischer Einschränkungen traten jedoch einige sehr subtile Unterschiede auf. Ein Beispiel ist die Serialisierung und der Austausch von HTTP-Headern. Dies ist ein kleiner Unterschied, aber in der Praxis bedeutet dies, dass gQUIC HTTP / 2 nicht mit IETF HTTP / 2 kompatibel ist.

Zu guter Letzt sollten Sie immer die Sicherheitsaspekte von Internetprotokollen berücksichtigen. Und die Entwickler von gQUIC haben beschlossen, TLS zugunsten eines anderen Ansatzes namens QUIC Crypto aufzugeben. Eine der interessanten Neuerungen ist eine neue Methode zur Beschleunigung von Handshakes. Nach dem Einrichten einer sicheren Sitzung mit dem Server kann der Client die Informationen wiederverwenden und die Nullzeit des Handshakes, dh 0-RTT, festlegen. Dieser Trick wurde später in das TLS 1.3-Protokoll aufgenommen.

Kann ich endlich herausfinden, was HTTP / 3 ist?

Fast.

Jetzt verstehen wir, wie Standardisierung funktioniert. Die gQUIC-Betrachtung verlief also nach demselben Szenario. Im Juni 2015 wurde der erste Entwurf des Entwurfs-tsvwg-quic-protocol-00 mit dem Titel „QUIC: Sicherer und zuverlässiger UDP-basierter Transport für HTTP / 2“ vorgestellt. Vergessen Sie jedoch nicht, dass die Protokollsyntax am Ende fast mit HTTP / 2 kompatibel ist.

Google hat angekündigt, dass "BoF beim IETF 93-Treffen in Prag stattfinden wird". Wenn Sie daran interessiert sind, was BoF ist, lesen Sie bitte RFC 6771 . Kurz gesagt, BoF ( Birds of a Feather ) ist ein informelles Treffen auf einer Konferenz.



Als Ergebnis der Diskussion mit der IETF wurde entschieden, dass QUIC auf Transportebene viele Vorteile hat. Sie sollten dieses Protokoll von HTTP trennen und eine klare Trennung zwischen den Schichten wieder einführen. Darüber hinaus haben sie für dieses Protokoll beschlossen, den auf TLS basierenden Handshake zurückzugeben (was nicht so schlimm ist, da zu diesem Zeitpunkt bereits TLS 1.3 mit dem 0-RTT-Schema entwickelt wurde).

Ungefähr ein Jahr später, im Jahr 2016, wurde eine neue Reihe von Entwürfen veröffentlicht:

• Entwurf-Hamilton-Quic-Transport-Protokoll-00
• Draft-Thomson-Quic-Tls-00
• Draft-Iyengar-Quic-Loss-Recovery-00
• Draft-Shade-Quic-http2-Mapping-00

Hier kam die Verwirrung wieder auf: Draft-Shade-Quic-http2-Mapping-00 heißt „HTTP / 2-Semantik mit dem QUIC-Transportprotokoll“ und beschreibt „HTTP / 2-Semantic-Mapping über QUIC“. Dies ist jedoch der falsche Name. Die Essenz von HTTP / 2 besteht darin, die Syntax unter Beibehaltung der Semantik zu ändern. Darüber hinaus war „HTTP / 2 von gQUIC“ aus den zuvor genannten Gründen nie eine genaue Beschreibung der Syntax. Denken Sie daran, wenn Sie sich mit zukünftigen Ereignissen vertraut machen.

Diese Version von QUIC von IETF sollte ein völlig neues Transportprotokoll werden. Da es sich um ein ernstes Unternehmen handelt, hat die IETF versucht, das Interesse ihrer Mitglieder an dem Projekt zu bewerten. Zu diesem Zweck fand beim IETF 96-Treffen 2016 in Berlin eine BoF-Sitzung ( Folien ) statt. Ich hatte das Glück, persönlich an dem Treffen teilzunehmen, an dem Hunderte von Teilnehmern teilnahmen, wie das Foto von Adam Roach zeigt . Infolgedessen wurde ein Konsens erzielt: QUIC wird von der IETF verabschiedet und standardisiert.

Der erste Entwurf des IETF-QUIC- Entwurfs-ietf-quic-http-00 zur Übersetzung von HTTP in einen QUIC-Transport vereinfachte den Protokollnamen logisch in „HTTP über QUIC“ (HTTP über QUIC). Leider wurde die Arbeit nicht abgeschlossen, sodass im gesamten Unternehmen unterschiedliche HTTP / 2-Begriffe verwendet wurden. Mike Bishop, der neue Standard-Entwurfs-Repository-Editor, erkannte das Problem und begann, falsche HTTP / 2-Referenzen zu korrigieren. In der nächsten Version des Protokolls wurde die Beschreibung in "Zuordnung der HTTP-Semantik über QUIC" geändert.

Im Laufe der Zeit und in neueren Versionen wurde der Begriff „HTTP / 2“ nach und nach weniger häufig verwendet, wenn nötig, und verwies lediglich auf RFC 7540 . Zwei Jahre später, im Oktober 2018, wurde die siebzehnte Fassung des Entwurfs (Nummer 16) veröffentlicht. Obwohl das HTTP-über-QUIC-Protokoll HTTP / 2 ähnelt, handelt es sich im Wesentlichen um eine unabhängige und inkompatible HTTP-Syntax. Für Menschen, die die Arbeit der IETF nicht genau überwachen (und dies ist ein sehr großer Prozentsatz der Weltbevölkerung), spiegelt der Titel des Dokuments diesen Unterschied jedoch nicht wider. Eine der Hauptaufgaben der Standardisierung ist die Förderung der Kommunikation und Interoperabilität. Und so einfach wie das Benennen ist die Hauptursache für Verwirrung in der Gemeinde geworden.

Erinnern Sie sich an das, was 2012 gesagt wurde: „HTTP / 2.0 bedeutet nur, dass das Format für den Transport nicht mit HTTP / 1.x kompatibel ist.“ Die IETF ist diesem Präzedenzfall gefolgt. Nach vielen Diskussionen vor und während der IETF 103-Konferenz wurde immer noch ein Konsens über die Umbenennung von „HTTP over QUIC“ in HTTP / 3 erzielt.

Die Welt ist besser geworden, und wir können zu wichtigeren Diskussionen übergehen.

RFC 7230 und 7231 stimmen jedoch nicht mit Ihrer Definition von Semantik und Syntax überein!

Manchmal können die Namen von Dokumenten verwirrend sein. Hier sind die HTTP-Dokumente, die Syntax und Semantik beschreiben:

• RFC 7230 - Hypertext Transfer Protocol (HTTP / 1.1): Nachrichtensyntax und Routing
• RFC 7231 - Hypertext Transfer Protocol (HTTP / 1.1): Semantik und Inhalt

Bei solchen Namen kann davon ausgegangen werden, dass die grundlegende Semantik von HTTP für eine bestimmte Version von HTTP, dh HTTP / 1.1, spezifisch ist. Dies ist jedoch ein zufälliger Nebeneffekt des HTTP-Stammbaums. Die gute Nachricht ist, dass die HTTPbis-Arbeitsgruppe versucht, das Problem zu lösen. Einige mutige WG-Mitglieder begannen eine weitere Runde der Überarbeitung des Dokuments. Diese Arbeit ist gerade im Gange und wird als HTTP-Kernarbeit bezeichnet (Sie haben möglicherweise von dieser Arbeitsgruppe unter den Namen HTTPtre oder HTTPter gehört: Auch hier ist alles nicht eindeutig). Mit ihren Bemühungen können Sie sechs Entwürfe auf drei komprimieren:

• HTTP-Semantik (Draft-Ietf-httpbis-Semantik)
• HTTP-Caching (Draft-Ietf-httpbis-Caching)
• HTTP / 1.1-Nachrichtensyntax und -Routing (Draft-Ietf-httpbis-Messaging)

Im Rahmen dieses neuen Frameworks wird deutlicher, dass HTTP / 2 und HTTP / 3 syntaktische Definitionen für die allgemeine Semantik von HTTP sind. Dies bedeutet nicht, dass sie keine eigenen Funktionen außerhalb der Syntax haben, dies sollte jedoch bei der weiteren Diskussion hilfreich sein.

Alles zusammenfügen

Dieser Artikel hat den HTTP-Standardisierungsprozess in der IETF in den letzten drei Jahrzehnten oberflächlich beschrieben. Ohne die technischen Details besonders zu berühren, versuchte ich zu erklären, wie wir jetzt zu HTTP / 3 kamen. Wenn Sie die Mitte verpasst haben und in einem Satz nach der Essenz gesucht haben, dann ist dies hier: HTTP / 3 ist nur eine neue HTTP-Syntax, die auf IETF QUIC funktioniert, einem multiplexierten und sicheren Transport, der auf UDP basiert . Es gibt viele interessante technische Nuancen, die Sie jedoch um ein anderes Mal verschieben müssen.

Wir haben die wichtigen Schritte bei der Entwicklung von HTTP und TLS untersucht, jedoch getrennt voneinander. Jetzt veröffentlichen wir am Ende des Artikels wieder das vollständige Cladogramm. Sie können es ruhig und sorgfältig in einer komfortablen Umgebung studieren. Und für Supersistener: Hier ist eine absolut vollständige Version, einschließlich Entwürfe .