HTTP / 3: Vom Stamm zum Tipp

Ursprünglicher Autor: Lucas Pardue
  • Übersetzung
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 Webs 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 möglicherweise aus dem Nichts zu stammen. Dennoch können wir seinen Ursprung anhand der Versuchsgeschichte und der Entwicklung der Webprotokolle, insbesondere des QUIC-Transportprotokolls, nachvollziehen.

Wenn Sie mit QUIC nicht vertraut sind, haben meine Cloudflare-Kollegen verschiedene Aspekte ausführlich behandelt: Lesen Sie beispielsweise Artikel über die tatsächlichen Mängel des modernen HTTP und Einzelheiten zum Transportschichtprotokoll . Wir haben diese und andere Materialien auf cloudflare-quic.com gesammelt . Und wenn Sie daran interessiert sind, schauen Sie sich 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 ( draft-ietf-quic-http-17 ) offiziell genehmigt . Es wurde Ende Oktober 2018 vorgeschlagen und auf der IETF 103-Tagung im November in Bangkok ein Konsens erzielt.

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

In diesem Artikel werden wir uns den Verlauf einiger früherer 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 sich ein vollständiges Bild machen 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 wir uns auf HTTP konzentrieren, sollten wir daran erinnern, dass es zwei Protokolle namens QUIC gibt. Wie bereits erläutert , wird gQUIC normalerweise als Abkürzung für Google QUIC (Quellprotokoll) und QUIC als von gQUIC abweichende IETF-Version verwendet.

Seit Anfang der 90er Jahre haben sich die Bedürfnisse des Internets verändert. Wir haben neue Versionen von HTTP und eine neue Sicherheitsstufe in Form des TLS-Protokolls (Transport Layer Security). In diesem Artikel behandeln wir nur TLS, 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 und zeitlich überlappend entwickelten. Wenn Sie versuchen, alle Punkte in fast 30 Jahren der Geschichte des Internets zu verbinden, können Sie nicht ohne Visualisierung auskommen. Also habe ich diesen Zeitplan erstellt: Cloudflare Secure Web Timeline. (Anmerkung: Technisch gesehen ist dies ein Cladogramm , obwohl die Leute mit dem Wort „Graph“ besser vertraut sind). Aus Gründen der Schönheit ließ ich einige Informationen fallen und konzentrierte mich nur auf erfolgreiche Zweige im IETF-Raum. 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 wichtige Punkte 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. Aus diesem Grund beginnen wir mit einem kurzen Überblick über das Thema, bevor wir zum eigentlichen Zeitplan zurückkehren. Wenn Sie bereits mit der IETF vertraut sind, können Sie den nächsten Abschnitt überspringen.

Arten von Internet-Standards


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

Die ersten Definitionen der HTTP- und SSL-Protokolle wurden außerhalb der IETF veröffentlicht: Sie sind in der Grafik rot markiert . Aber die weit verbreitete Verwendung hat sie de facto zu Standards gemacht.

Irgendwann beschlossen sie, diese Protokolle zu formalisieren (einige Gründe werden unten beschrieben). Internetstandards werden in der Regel in der IETF definiert, die sich an dem informellen Prinzip „Beispielhafter Konsens und aktueller Code“ orientiert, das auf realen Anwendungen im Internet basiert. Dies unterscheidet sich von einem Reinraumansatz, wenn jemand versucht, ideale Protokolle im luftleeren Raum zu entwickeln.

IETF-Standards werden allgemein als RFCs bezeichnet. Es ist schwierig , kurz zu erklären, so dass ich den Artikel empfehlen „Wie die RFC» lesen von der Arbeitsgruppe Mitvorsitzender Mark Nottingham QUIC. Eine Arbeitsgruppe oder WG ist im Wesentlichen nur eine Mailingliste.

Jedes Jahr finden drei Treffen für persönliche Treffen von Mitgliedern aller Arbeitsgruppen statt, wenn sie dies wünschen. Die Agenda für diese Wochen kann sehr voll sein, es ist nicht genug Zeit für eine eingehende Diskussion technischer Fragen. Einige ziehen es daher vor, mehr Halbzeitsitzungen zwischen den IETF-Generalversammlungen auszurichten. QUIC Arbeitsgruppe mehr Zwischentreffen im Jahr 2017 statt, um die vollständige Liste ist auf der zur Verfügung stehende Seite der Sitzungen .

Diese Treffen bieten die Gelegenheit, sich mit Experten anderer Organisationen wie dem Internet Architecture Board (IAB) oder der Internet Technology Research Group (IRTF) zu treffen . In den letzten Jahren hat am Wochenende vor dem IETF-Treffen traditionell der IETF-Hackathon stattgefunden. Hier wird realer Code entwickelt und vor allem Kompatibilitätstests bestanden. Dies hilft, Probleme in den Spezifikationen zu finden, die direkt auf dem Meeting 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-Internet-Entwurfs (ID), der zur Überprüfung eingereicht wird. In dem Fall, dass die Spezifikation bereits veröffentlicht wurde, wird das Vorbereiten einer ID zu einer einfachen Neuformatierung. Die Nutzungsdauer der ID beträgt 6 Monate ab dem Datum der Veröffentlichung. Um aktiv zu bleiben, 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.

Im Cladogram werden Entwürfe in Lila angezeigt. 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 wird, heißt der Entwurf draft-ietf- {workgroup} - {topic} - {version} . IDs können verzweigt, zusammengeführt oder ausgeblendet werden. Die Version beginnt um 00 und wird mit jedem neuen Projekt um eins erhöht. Beispielsweise erhält der vierte Entwurf die Versionsnummer 03. Bei jeder Änderung der Namens-ID wird die 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 zu einem Konsens führt und das endgültige Dokument den Test besteht, erhalten wir einen RFC. Zu diesem Zeitpunkt ändert sich der Name erneut. Jeder RFC ist eine eindeutige Nummer, beispielsweise zugewiesen 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 komplett ersetzen oder ergänzen.

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

Nachfolgend finden Sie ein Beispiel für die Entwicklung des RFC 1945- Standards , d. H. HTTP / 1.0.


Geschichte von RFC 1945 im IETF Datatracker Interface

Interessanterweise stellte ich im Verlauf meiner Arbeit fest, dass die obige Visualisierung nicht korrekt ist. Aus irgendeinem Grund fehlt draft-ietf-http-v10-spec-05 . Da die ID 6 Monate alt ist, ist sie wahrscheinlich vor der Annahme des RFC abgelaufen, obwohl der Entwurf in Wirklichkeit bis August 1996 aktiv war.

Cladogram-Studie


Nach einer kurzen theoretischen Einführung können wir beginnen, das Kladogramm 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 befinden sich jedoch alle in der Vollversion .

HTTP erschien 1991 als HTTP / 0.9-Protokoll, und 1994 wurde ein Entwurf für ein 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 übernommen .



Noch vor Abschluss der Arbeiten an HTTP / 1.0 wurde jedoch ein separates HTTP / 1.1-Projekt gestartet. EntwurfsversionDer Entwurf-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 vollständig widerspiegelt - eine erfolglose Störung des Visualisierungstools. Ich habe versucht, solche Probleme so weit wie möglich zu minimieren.

Mitte 1997 begann eine Überarbeitung von HTTP / 1.1 als Draft-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 herauskam und SSL 3.0 im November 1996 herauskam. Interessanterweise ist SSL 3.0 in RFC 6101 genehmigt , das erst im August 2011 veröffentlicht wurde. Es befindet sich im historischen Teil. Laut IETF wurde es erstellt, "um Ideen zu dokumentieren, die berücksichtigt und verworfen wurden, oder Protokolle, die bereits vorhanden waren, als beschlossen wurde, sie zu dokumentieren." In diesem Fall brauchte ich ein IETF-Dokument, das SSL 3.0 beschreibt, um es überall als kanonischen Link zu verwenden.

Wir sind mehr daran interessiert, wie SSL Ingenieure zur Entwicklung von TLS inspiriert hat, was mit einem Entwurf des ietf-tls-protocol-00 begannim November 1996. Es durchlief 6 Entwurfsversionen und wurde  Anfang 1999 als RFC 2246 - TLS 1.0 veröffentlicht.

In den Jahren 1995-1999 wurden zum Schutz von HTTP-Verbindungen im Internet SSL und TLS verwendet. Dies hat als De-facto-Standard hervorragend funktioniert. Erst im Januar 1998 mit der Veröffentlichung eines Entwurf draft-ietf-tls-https-00 begann HTTPS formalen Standardisierungsprozess. Die Arbeiten wurden im Mai 2000 mit der Veröffentlichung von RFC 2616  - HTTP over TLS abgeschlossen.

TLS wurde 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 als draft-ietf-tls-tls13-00 veröffentlicht wirdim April 2014 und nach 28 Entwürfen bestätigt als RFC 8446  - TLS 1.3 im August 2018.

Internet-Standardisierungsprozess


Nach einem kurzen Kennenlernen des Cladogramms hoffe ich, dass es besser geworden ist, die Funktionsweise der IETF zu verstehen. 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. Anhand der erhaltenen Informationen können Sie Probleme identifizieren oder das Protokoll verbessern. Die Veröffentlichung der Arbeit hilft, das Experiment zu erläutern, die Meinung eines größeren Kreises von Fachleuten zu treffen oder Hilfe von anderen Interpreten zu erhalten. Wenn andere Teilnehmer diese Arbeit frühzeitig akzeptieren, wird sie zum De-facto-Standard, und letztendlich gibt es genug Schwung für die offizielle Normung.

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, weil er normalerweise Stabilität bietet. Eine seriöse Organisation wie die IETF, die die Interessen und Erfahrungen vieler Teilnehmer widerspiegelt, übernimmt die Führung. Es ist jedoch zu beachten, dass nicht alle formalen Standards erfolgreich sind.

Der Prozess der Erstellung eines Standards ist fast so wichtig wie der Standard selbst. Die anfängliche Idee zu verarbeiten, eine Einladung, Menschen mit weiterem Wissen, Erfahrung und Anwendungsfällen zu diskutieren - 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 einen eigenen Prozess, der sich auf ihr Tätigkeitsfeld und die Teilnehmer konzentriert. Alle Details der Funktionsweise der IETF zu erklären, würde den Rahmen dieses Artikels sprengen. Wenn Sie interessiert sind, ist die Seite Wie wir arbeiten ein guter Ausgangspunkt .auf der IETF-Website. Wie immer ist der beste Weg, es herauszufinden, selbst teilzunehmen. Genug, um der Mailingliste oder Diskussion im entsprechenden GitHub-Repository beizutreten.

Cloudflare-Arbeitscode


Cloudflare ist stolz darauf, eines der ersten Unternehmen zu sein, das 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 .

Indem Sie echten Code ausführen, können Sie nachvollziehen, wie gut das Protokoll in der Praxis funktioniert. Wir kombinieren Expertenwissen mit experimentellen Informationen, um den Code zu verbessern, und melden Probleme oder Verbesserungen, wo dies sinnvoll ist, an eine Arbeitsgruppe, 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 sicherheitsgerichtete Protokolle, z. B. CloudflareSSLv3 standardmäßig deaktiviert wegen der Verwundbarkeit POODLE. In anderen Fällen werden die Protokolle durch technisch fortschrittlichere Protokolle ersetzt: Beispielsweise 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 der Realität hat die jahrelange aktive Nutzung des Protokolls jedoch Erfahrung gebracht und verborgene Probleme von RFC 2616 aufgedeckt, einschließlich einiger Kompatibilitätsprobleme. Darüber hinaus wurde das Protokoll um weitere RFCs wie 2817 und 2818 erweitert. Daher wurde 2007 beschlossen, Aktivitäten zur Verbesserung der HTTP-Spezifikation aufzunehmen. 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 das Refactoring von RFC 2616 in HTTPbis begonnen. Es enthält Fehlerbehebungen und die Implementierung einiger Aspekte aus anderen Spezifikationen, die gleichzeitig veröffentlicht werden. Es wurde beschlossen, das Dokument in Teile zu unterteilen. Infolgedessen wurden im Dezember 2007 sechs Entwürfe veröffentlicht:

  • Draft-IETF-httpbis-p1-Messaging
  • Draft-IETF-httpbis-p2-Semantik
  • draft-ietf-httpbis-p4-conditional
  • Draft-IETF-httpbis-p5-Bereich
  • draft-ietf-httpbis-p6-cache
  • draft-ietf-httpbis-p7-auth



Das Diagramm zeigt, wie die Arbeit über einen langen siebenjährigen Entwicklungsprozess fortschritt. Vor der endgültigen Normung wurden 27 Entwürfe angenommen. Im Juni 2014 wurde die sogenannte RFC 723x-Serie veröffentlicht (wobei x zwischen 0 und 5 liegt). Vorsitzender der Arbeitsgruppe für HTTPbis sagte diese Leistung Ausdruck «RFC2616 tot“ . Wenn jemand es 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 finalisierte, blieb die Welt nicht stehen. Die Leute expandierten weiter und ergänzten HTTP. Unter ihnen sind Google-Ingenieure, die mit ihrem eigenen Protokoll namens SPDY (ausgesprochen "speedy") experimentierten. Sie gaben an, 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 die technischen Details von SPDY eingehen, aber es ist wichtig zu verstehen, dass SPDY die grundlegenden HTTP-Paradigmen übernommen und das Austauschformat für die 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 (Nutzdaten). Die Syntax beschreibt die Zuordnung der Semantik zu Bytes im Netzwerk.

HTTP / 0.9, 1.0 und 1.1 haben viele gemeinsame Semantiken. Sie verwenden außerdem die übliche 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 wir werden uns heute nicht mit diesem Kaninchenbau befassen.

Experimente mit SPDY haben gezeigt, dass eine Änderung der HTTP-Syntax wirklich Auswirkungen hat. Gleichzeitig ist es wichtig, die vorhandene Semantik beizubehalten. Durch das Speichern des URL-Formats zur Verwendung konnten beispielsweise https://viele Probleme vermieden werden, die sich auf die Implementierung von HTTPS auswirken könnten.

Nach einigen positiven Ergebnissen entschied die IETF, dass es an der Zeit sei, Optionen für HTTP / 2.0 in Betracht zu ziehen. Auf den Folien der HTTPbis-Sitzung während des IETF 83-Meetings im März 2012 sind die Anforderungen und Ziele aufgeführt, 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. Unter den eingereichten Entwürfen warendraft-mbelshe-httpbis-spdy-00 , draft-montenegro-httpbis-speed-mobility-00 und draft-tarreau-httpbis-network-friendly-00 . Am Ende wurde der SPDY-Entwurf angenommen, und im November 2012 begannen die Arbeiten an Draft-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 übernommen haben, zu einer sehr stressigen Zeit geworden. Dies steht in scharfem Kontrast zu den Jahren der Ruhe zu Beginn der 2000er Jahre. Schauen Sie sich unbedingt das vollständige Cladogram an, um die Menge der geleisteten Arbeit wirklich zu würdigen.

Trotz der Standardisierung von HTTP / 2 sind Experimente mit SPDY immer noch nützlich. Cloudflare führte die SPDY-Unterstützung im August 2012 ein und entfernte sie erst im Februar 2018, als unsere Statistiken zeigten, dass weniger als 4% der Web-Kunden dies beantragen. 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. Mit der Einführung von Universal SSL im September 2014 konnten wir garantieren, 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 verpackt, die in UDP-Datagrammen gesendet werden. Dies ist eine Abweichung vom TCP-Transport, auf den sich HTTP traditionell verlassen hat. Das ganze System sah so aus:


SPDY Layered Pie von gQUIC

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

gQUIC entwickelte sich weiter und wechselte schließlich zu einer Syntax, die HTTP / 2 sehr viel näher kommt. So nah, dass die meisten Leute anfingen, es "HTTP / 2 by 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, in der Praxis bedeutet dies jedoch, dass gQUIC HTTP / 2 nicht mit HTTP / 2 von der IETF kompatibel ist.

Last but not least sollten Sie immer die Sicherheitsaspekte von Internetprotokollen berücksichtigen. Und die gQUIC-Entwickler beschlossen, TLS zugunsten eines anderen Ansatzes aufzugeben, der sich QUIC Crypto nennt. Eine der interessanten Neuerungen ist eine neue Methode zur Beschleunigung von Handshakes. Nachdem eine sichere Sitzung mit dem Server eingerichtet wurde, kann der Client die Informationen wiederverwenden und die Nullzeit des Handshakes (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 tsvwg-quic-protocol-00 mit dem Titel „QUIC: Sicherer und zuverlässiger UDP-basierter Transport für HTTP / 2“ eingereicht . Vergessen Sie jedoch nicht, dass die Protokollsyntax letztendlich fast mit HTTP / 2 kompatibel ist.

Google gab bekannt, dass "BoF auf dem IETF 93-Treffen in Prag stattfinden wird". Wenn Sie sich für BoF interessieren, 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 bietet. Sie sollten dieses Protokoll von HTTP trennen und eine klare Trennung zwischen den Schichten wieder herstellen. Darüber hinaus haben sie sich für dieses Protokoll entschieden, 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 worden war).

Ungefähr ein Jahr später, im Jahr 2016, kamen neue Entwürfe heraus:


Hier kam die Verwirrung wieder auf: draft-shade-quic-http2-mapping-00 heißt "HTTP / 2-Semantik unter Verwendung des QUIC-Transportprotokolls" und beschreibt "HTTP / 2-Semantik-Mapping unter Verwendung von 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 beschriebenen Gründen noch 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. Dies ist ein ernstzunehmendes Unternehmen, weshalb die IETF versuchte, das Interesse ihrer Mitglieder an dem Projekt zu bewerten. Zu diesem Zweck wurde beim IETF 96 - Treffen in Berlin im Jahr 2016 eine BoF - Sitzung abgehalten ( Folien)) 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 übernommen und standardisiert.

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

Mit der Zeit und in neueren Versionen wurde der Begriff "HTTP / 2" allmählich seltener verwendet, wenn nötig, und es wurde lediglich auf RFC 7540 verwiesen . Zwei Jahre später, im Oktober 2018, wurde die siebzehnte Version des Entwurfs veröffentlicht (Nummer 16). Obwohl das HTTP-über-QUIC-Protokoll Ähnlichkeiten mit HTTP / 2 aufweist, handelt es sich im Wesentlichen um eine unabhängige und inkompatible HTTP-Syntax. Für Menschen, die die Arbeit der IETF nicht genau beobachten (und dies ist ein sehr großer Prozentsatz der Weltbevölkerung), spiegelt der Titel des Dokuments diesen Unterschied nicht wider. Eine der Hauptaufgaben der Normung ist die Förderung der Kommunikation und der Interoperabilität. Und eine so einfache Sache wie das Benennen ist die Hauptursache für Verwirrung in der Gemeinschaft geworden.

Denken Sie daran, was 2012 gesagt wurde: "HTTP / 2.0 bedeutet nur, dass das Format nicht mit HTTP / 1.x im Transport kompatibel ist." Die IETF hat diesen Präzedenzfall befolgt. Nach vielen Diskussionen vor und während der IETF 103-Konferenz bestand noch Konsens darüber, „HTTP over QUIC“ in HTTP / 3 umzubenennen.

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 diesen 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 im Moment im Gange und wird als HTTP-Core-Arbeit bezeichnet (Sie haben vielleicht unter den Namen HTTPtre oder HTTPter von dieser Arbeitsgruppe gehört: Auch hier ist alles mehrdeutig). Ihre Bemühungen werden es Ihnen ermöglichen, sechs Entwürfe auf drei zu 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 zusammen


In diesem Artikel wurde der HTTP-Standardisierungsprozess in der IETF in den letzten drei Jahrzehnten oberflächlich beschrieben. Ohne besonders auf die technischen Details einzugehen, versuchte ich zu erklären, wie wir nun zu HTTP / 3 kamen. Wenn Sie die Mitte verpasst und suchen in einem Satz, hier ist es: HTTP / 3 - es ist nur eine neue HTTP - Syntax, die auf der Grundlage des UDP auf der IETF QUIC, gemultiplext und sicheren Transport funktioniert . 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 Cladogram. Sie können es ruhig und gründlich in einer angenehmen Umgebung studieren. Und für Supersistener: Hier ist eine absolut vollständige Version inklusive Entwürfe .


Jetzt auch beliebt: