HTTP/3 : Des origines à nos jours

HTTP est le protocole d'application sur lequel repose le Web. Il a vu le jour en 1991 sous le nom de protocole HTTP/0.9 et, en 1999, a évolué vers HTTP/1.1, qui a été normalisé par l'IETF (Internet Engineering Task Force). HTTP/1.1 a longtemps suffi, mais l'évolution constante des besoins du Web a nécessité la mise en place d'un protocole mieux adapté, et HTTP/2 est apparu en 2015. On a annoncé dernièrement que l'IETF avait l'intention de publier une nouvelle version dénommée HTTP/3. Cela a surpris certaines personnes et a semé un peu la confusion. Si vous ne suivez pas de près les travaux de l'IETF, HTTP/3 peut vous sembler sorti de nulle part. Cependant, nous pouvons retracer ses origines en suivant une succession d'expériences et l'évolution des protocoles Web, en particulier le protocole de transport QUIC.

Si vous ne connaissez pas QUIC, sachez que mes collègues en ont abordé tous les aspects de manière tout à fait remarquable. L’article de John décrit certains des désagréments inhérents au HTTP d'aujourd'hui, celui d'Alessandro se penche sur toutes les questions liées à la couche de transport, et celui de Nick décrit comment effectuer certains tests. Nous les avons rassemblés avec d'autres publications sur https://cloudflare-quic.com. Si cela vous tente, vous pouvez aussi jeter un coup d'œil à quiche, notre propre application open source du protocole QUIC écrit en Rust.

HTTP/3 est l'application qui fait la liaison avec la couche de transport QUIC. Ce nom a été officialisé dans la récente mouture 17 (projet-ietf-quic-http-17), présentée fin octobre 2018, qui a fait l'objet de discussions et d'un large consensus lors de la 103e réunion de l'IETF en novembre à Bangkok. HTTP/3 s'appelait auparavant HTTP over QUIC, qui se nommait lui-même auparavant HTTP/2 over QUIC. Avant cela, nous avions HTTP/2 over gQUIC et, bien avant, SPDY over gQUIC. Le fait est cependant que HTTP/3 n'est qu'une nouvelle syntaxe HTTP qui fonctionne sur IETF QUIC, un transport multiplexé et sécurisé basé sur UDP.

Dans cet article, nous allons nous pencher sur l'histoire de certains des noms précédents de HTTP/3 et vous expliquer pourquoi le nom a changé dernièrement. Nous remonterons aux débuts du HTTP et parlerons de tout le travail qui a été accompli depuis. Si vous voulez vous faire une idée plus globale de la situation, vous pouvez passer directement à la fin de l'article ou ouvrir cette version SVG très détaillée.

Un millefeuille HTTP/3

Juste avant de nous intéresser au HTTP, il convient de rappeler qu'il existe deux protocoles qui ont pour nom QUIC. Comme nous l’avons déjà expliqué, gQUIC sert habituellement à identifier Google QUIC (le protocole original), et QUIC sert généralement à représenter la version en cours de développement de l'IETF qui diffère du protocole gQUIC.

Depuis ses débuts dans les années 90, les besoins du Web ont changé. Nous avons connu de nouvelles versions de HTTP et ajouté plus de sécurité pour les utilisateurs avec le système Transport Layer Security (TLS). Nous ne reviendrons pas ici sur TLS, mais vous pourrez consulter nos autres articles de blog si vous souhaitez en savoir plus à ce sujet.

Afin de mieux vous raconter l'histoire de HTTP et TLS, j'ai commencé à rassembler des informations sur les spécifications et les dates clés du protocole. Ces informations sont généralement présentées sous forme de liste de points indiquant des titres de documents, classés par date. Cependant, il existe des principes de hiérarchisation, chacun se chevauchant dans le temps, et une simple liste ne peut exprimer la complexité réelle des relations. Avec HTTP, des travaux parallèles ont été menés pour remanier les définitions des protocoles de base afin d'en faciliter la consommation, étendre le protocole à de nouvelles utilisations et redéfinir la manière dont le protocole échange les données sur Internet pour optimiser les performances. Lorsque vous tentez de faire le lien entre les étapes de près de 30 ans d'histoire d’Internet à travers différents domaines ramifiés, vous devez les représenter visuellement. C’est donc ce que j’ai fait avec la « Chronologie Cloudflare du Web sécurisé ». (N.B. : techniquement, il s'agit d'un cladogramme, mais le terme « chronologie » est plus répandu.)

J'ai pris quelques libertés en choisissant de me focaliser sur les branches à succès de l'IETF. Je n'ai notamment pas montré les travaux du groupe de travail HTTP-NG du W3C, ni certaines idées un peu extravagantes au nom parfois imprononçable :  HMURR (prononcer « hammer ») et WAKA.

Dans les chapitres suivants, je suivrai cette chronologie pour vous raconter les étapes décisives de l'histoire du protocole HTTP. Pour tirer le meilleur parti de cet article, il faut comprendre en quoi la normalisation est bénéfique et comment l'IETF l'aborde. Nous commencerons donc par un très bref exposé sur ce sujet avant de revenir à la chronologie elle-même. N'hésitez pas à sauter le chapitre suivant si vous connaissez déjà l'IETF.

En règle générale, les normes définissent des termes de référence communs, un champ d'application, des contraintes, des possibilités d'application et d'autres principes. Il existe beaucoup de variantes et formats de normes, ces normes pouvant être informelles (c'est-à-dire de facto) ou formelles (convenues/publiées par un organisme de réglementation tel que l'IETF, l'ISO ou le MPEG). Les normes sont utilisées dans de nombreux domaines. Il existe même une norme britannique officielle régissant la fabrication du thé (BS 6008).

Les premières définitions de protocole HTTP et SSL publiées en dehors de l'IETF sont marquées en rouge sur la Chronologie du Web sécurisé. L'adoption de ces protocoles par les clients et les serveurs en a fait des normes de facto.

Il a été décidé à un moment donné de structurer ces protocoles (certaines des raisons à cela sont décrites dans un paragraphe ultérieur). Les normes relatives à Internet sont définies au sein de l'IETF, qui se fonde sur le principe informel du « consensus approximatif et du code fonctionnel ». Cette approche s'appuie sur une expérience de développement et de déploiement d'applications sur Internet. Elle diffère de celle qui consiste à essayer de développer des protocoles parfaits en partant de rien.

Les normes Internet de l'IETF sont connues sous le nom de RFC. Il est difficile de les expliquer, alors je vous recommande de lire l’article sur la lecture d’une RFC rédigé par le coprésident du groupe de travail QUIC, Mark Nottingham. Un groupe de travail, ou GT, est en quelque sorte une simple liste de diffusion.

Chaque année, l'IETF tient trois réunions qui permettent à tous les groupes de travail de se réunir en personne s'ils le souhaitent. Le programme de ces semaines peut être très chargé, le temps disponible pour discuter en profondeur de domaines hautement techniques étant limité. Pour y remédier, certains groupes de travail choisissent de tenir également des réunions intermédiaires au cours des mois situés entre les réunions générales de l'IETF. Cela peut aider à ne pas freiner le processus d'élaboration des exigences. Le groupe de travail QUIC a tenu plusieurs réunions transitoires depuis 2017, dont la liste complète est disponible sur leur page des réunions.

Ces réunions de l'IETF permettent également à d'autres groupes de personnes liés à l'IETF de se rencontrer, comme l’Internet Architecture Board ou l’Internet Research Task Force. Ces dernières années, un hackathon de l'IETF avait lieu le week-end précédant la réunion de l'IETF. Cela donne l'occasion à la communauté de développer du code fonctionnel et, surtout, d'effectuer des tests d'interopérabilité en étant dans la même pièce que les autres. Cela permet de repérer les aspects des cahiers des charges pouvant être discutés dans les jours suivants.

Dans le cadre de cet article, il est important de comprendre que les RFC ne naissent pas du jour au lendemain. Au contraire, elles suivent un processus qui commence habituellement par une ébauche de l'IETF («Internet Draft», ou I-D) dont l'adoption est discutée. Si une spécification a déjà été publiée, la préparation d'une I-D peut se réduire à un simple remaniement rédactionnel. Les I-D ont une durée de vie de 6 mois à compter de la date de publication. Pour qu'elles restent actives, de nouvelles versions doivent être publiées. Dans la pratique, le dépassement du délai n'a que peu de conséquences et cela se produit fréquemment. Les documents demeurent hébergés sur le site Web de l'IETF, à la disposition de tous ceux qui veulent les lire.

Les I-D sont représentées sur la Chronologie du Web sécurisé par des lignes violettes. Chacune porte un nom unique qui se présente sous la forme draft-{nom de l'auteur}-{groupe de travail}-{sujet}-{version}. Le champ « groupe de travail » est facultatif ; il peut indiquer le groupe de travail de l'IETF qui va travailler sur le projet et des changements peuvent survenir. Si une I-D est adoptée par l'IETF, ou si l'I-D a été lancée directement au sein de l'IETF, le nom prend la forme draft-ietf-{groupe de travail}-{sujet)-{version}. Les I-D peuvent se développer, fusionner ou mourir. La version commence à 00 et augmente de 1 chaque fois qu'une nouvelle version est publiée. Par exemple, la 4ème version d'une I-D sera la version 03. Chaque fois qu'une I-D change de nom, elle revient à la version 00.

Il faut savoir que n'importe qui peut soumettre une I-D à l'IETF ; vous ne devez pas considérer ces documents comme des normes. Cependant, si le processus de normalisation IETF d'une I-D parvient à un consensus et que le document final passe l'examen, nous obtenons finalement une RFC. Le nom change encore une fois à ce stade. Chaque RFC se voit attribuer un numéro unique, par exemple RFC 7230. Celles-ci sont représentées sous forme de lignes bleues sur la Chronologie du Web sécurisé.

Les RFC sont des documents inaltérables. Cela signifie que les modifications apportées aux RFC nécessitent un tout nouveau matricule. Des modifications peuvent être apportées afin d'incorporer des corrections (suite à des erreurs éditoriales ou techniques ayant été trouvées et signalées) ou simplement pour remanier la présentation des spécifications. Les RFC peuvent remplacer les anciennes versions (remplacement complet), ou simplement les actualiser (modification substantielle).

Tous les documents de l'IETF peuvent être consultés sur http://tools.ietf.org. Pour ma part, je trouve le Datatracker de l'IETF un peu plus convivial, car il permet de visualiser la progression d'un document depuis l'I-D jusqu'à la RFC.

L'exemple ci-dessous montre le développement de la RFC 1945 - HTTP/1.0 et constitue une véritable source d'inspiration pour la Chronologie du Web sécurisé.

La RFC 1945 selon le Datatracker de l'IETF

Fait intéressant : au cours de mon travail, je me suis rendu compte que la représentation ci-dessus était inexacte. Je ne sais pas pourquoi, mais il manque draft-ietf-http-v10-spec-05. Étant donné que la durée de vie d'une I-D est de six mois, il semble qu'il y ait un délai avant qu'elle devienne une RFC, alors qu'en réalité le projet 05 était encore actif en août 1996.

Avec une petite idée de la façon dont les documents relatifs aux normes d'Internet sont élaborés, nous pouvons commencer à étudier la Chronologie du Web sécurisé. Dans cette partie, vous trouverez un certain nombre d'extraits de diagrammes qui montrent une grande partie de la chronologie. Chaque point représente la date à laquelle un document ou une fonctionnalité a été publié(e). Pour les documents de l'IETF, les numéros de version des projets sont omis par souci de clarté. Cependant, si vous voulez voir tous ces détails, nous vous invitons à consulter la chronologie complète.

HTTP a vu le jour en 1991 sous le nom de protocole HTTP/0.9 et, en 1994, l'I-D draft-fielding-http-spec-00 a été publiée. L'IETF l'a adoptée peu de temps après, et le nom a été changé en draft-ietf-http-v10-spec-00. L'I-D a connu 6 versions préliminaires avant d'être publiée sous le nom deRFC 1945 - HTTP/1.0 en 1996.

Cependant, avant même l'achèvement des travaux sur HTTP/1.0, HTTP/1.1 a fait l'objet de travaux distincts. L’I-D draft-ietf-http-v11-spec-00 a été publiée en novembre 1995 et a été officiellement publiée sous le nom de RFC 2068 en 1997. Les plus fins observateurs remarqueront que la Chronologie du Web sécurisé ne reflète pas tout à fait la chronologie des événements, ce qui est un effet secondaire malheureux de l'outil utilisé pour générer la représentation. J'ai essayé de limiter ces problèmes dans la mesure du possible.

On a commencé à réviser HTTP/1.1 mi-1997 avec la publication de draft-ietf-http-v11-spec-rev-00. Cette démarche s'est achevée en 1999 avec la publication de la RFC 2616. Le monde du HTTP est demeuré assez tranquille jusqu'en 2007. Nous y reviendrons tout à l'heure.

Basculement vers SSL. Nous pouvons voir que la norme SSL 2.0 a été publiée vers 1995, et que SSL 3.0 a été publiée en novembre 1996. Il est intéressant de noter que le protocole SSL 3.0 est décrit par la RFC 6101, qui a été publiée en août 2011. Cela peut être classé dans la catégorie Historique, qui « est habituellement destinée à répertorier les idées qui ont été examinées et rejetées, ou les protocoles qui étaient déjà en place quand il a été décidé de les recenser » selon l'IETF. Dans ce cas, il est avantageux de disposer d'un document de l'IETF décrivant SSL 3.0, car il peut être utilisé comme référence normative ailleurs.

Ce qui nous intéresse davantage, c'est la façon dont SSL a inspiré le développement de TLS, qui a vu le jour en novembre 1996 sous le nom de draft-ietf-tls-protocol-00. Ce document a connu 6 versions préliminaires et a été publié sous le nom de RFC 2246 - TLS 1.0 au début de l'année 1999.

Entre 1995 et 1999, les protocoles SSL et TLS ont été utilisés pour sécuriser les communications HTTP sur Internet. Ils ont très bien fonctionné en tant que normes de facto. Ce n'est qu'en janvier 1998 que le processus formel de normalisation du HTTPS a commencé avec la publication de l'I-D draft-ietf-tls-https-00. Ces travaux se sont achevés en mai 2000 avec la publication de la RFC 2616 - HTTP over TLS.

TLS a continué à évoluer entre 2000 et 2007, avec la normalisation de TLS 1.1 et 1.2. Il a fallu attendre 7 ans avant le début des travaux sur la version suivante de TLS, qui a été adoptée sous le nom de draft-ietf-tls-tls13-00 en avril 2014 et, après 28 projets, achevée sous le nom de RFC 8446 -TLS 1.3 en août 2018.

Après avoir jeté un bref coup d'œil à la chronologie, j'espère que vous pourrez vous faire une idée du fonctionnement de l'IETF. Le fait que des chercheurs ou des ingénieurs conçoivent des protocoles expérimentaux adaptés à leur domaine d'utilisation spécifique constitue une généralisation de la manière dont les normes Internet prennent forme. Ils testent les protocoles, tant en public qu'en privé, sur différents niveaux. Les données ainsi recueillies permettent d'identifier les points à améliorer ou les problèmes. Les travaux peuvent être publiés pour expliquer le déroulement des expériences, pour recueillir un plus grand nombre d'informations ou pour aider à trouver d'autres acteurs de mise en œuvre. L'adoption de ces premières mesures par d'autres acteurs peut en faire une norme de facto ; à terme, il se peut que la dynamique soit assez importante pour envisager une normalisation en bonne et due forme.

L'état de développement d'un protocole peut être un élément de prise de décision important pour les entreprises qui envisagent de le mettre en œuvre, de le déployer ou de l'utiliser d'une manière quelconque. Un processus de normalisation formel peut rendre une norme de facto plus attrayante parce qu'il contribue à sa stabilité. La gestion et les directives sont assurées par une organisation, telle que l'IETF, qui offre un large éventail d'expériences. Toutefois, il convient de souligner que toutes les normes formelles ne connaissent pas le même succès.

Le processus d'élaboration d'une norme définitive est presque aussi important que la norme elle-même. Le fait de prendre une idée de départ et de solliciter la participation de personnes ayant des connaissances, une expérience et des scénarios d'utilisation plus vastes peut aider à produire un projet qui profitera à un public plus large. Toutefois, le processus de normalisation n'est pas toujours chose aisée. Il comporte de nombreux pièges et obstacles. Le processus est parfois si long que le résultat obtenu est obsolète.

Chaque organisme normatif dispose généralement de son propre processus de normalisation adapté à son domaine de spécialité et à ses membres. Cet article n'a pas vocation à expliquer en détail le fonctionnement de l'IETF. La page relative à la manière de travailler de l’IETF constitue un excellent point de départ qui aborde de nombreux aspects de la question. Comme d'habitude, la meilleure façon de vous familiariser avec le sujet est d'effectuer vos propres recherches. Vous pouvez le faire en vous inscrivant tout simplement à une liste de diffusion ou en participant à une discussion sur un référentiel GitHub traitant de la question.

Cloudflare est fier d'être l'un des premiers à adopter des protocoles nouveaux et évolutifs. Depuis longtemps, nous adoptons de nouvelles normes de manière anticipée, comme HTTP/2. Nous testons également des fonctionnalités expérimentales ou à venir, telles que TLS 1.3 et SPDY.

En ce qui concerne le processus de normalisation de l'IETF, le déploiement de ce code fonctionnel sur des réseaux réels à travers un ensemble divers de sites Internet nous aide à comprendre comment le protocole fonctionnera dans la pratique. Nous conjuguons notre expertise existante à des informations expérimentales pour aider à améliorer le code fonctionnel et, lorsque cela est judicieux, à résoudre les problèmes de rétroaction ou à améliorer le groupe de travail chargé de la normalisation d'un protocole.

La priorité n'est pas seulement de tester des nouveautés. Une des qualités d'un innovateur est de savoir quand le moment est venu d'aller de l'avant et de mettre au placard les anciennes innovations. Parfois, il s'agit de protocoles axés sur la sécurité. Par exemple, Cloudflare a désactivé SSLv3 par défaut à cause de sa vulnérabilité POODLE. Dans d'autres cas, les protocoles sont dépassés par des protocoles plus évolués sur le plan technologique ; Cloudflare a désavoué SPDY en faveur de HTTP/2.

L'introduction et le retrait des protocoles concernés sont représentés sur la Chronologie du Web sécurisé sous la forme delignes oranges. Des lignes verticales pointillées permettent de relier les événements Cloudflare aux documents de l'IETF correspondants. Par exemple, Cloudflare a introduit la technologie TLS 1.3 en septembre 2016, et le document final, RFC 8446, a été publié presque deux ans plus tard, en août 2018.

HTTP/1.1 est un protocole qui a connu un grand succès et la chronologie montre que l'IETF n'a pas été très active après 1999. Cependant, le véritable constat est que des années d'utilisation active ont permis d'acquérir une expérience en matière de mise en œuvre qui a mis au jour des problèmes latents avec la RFC 2616, qui ont causé certains problèmes d'interopérabilité. De plus, le protocole a été complété par d'autres RFC telles que 2817 et 2818. Il a été décidé en 2007 de lancer un programme visant à améliorer les spécifications du protocole HTTP. Ce projet se nommait HTTPbis (« bis » est un mot latin signifiant « deux », « deux fois » ou « répétition ») et a pris la forme d'un nouveau groupe de travail. La charte originale décrit bien les problèmes visés.

En résumé, HTTPbis a décidé du remaniement de la RFC 2616. Elle devait contenir des corrections de ratés et intégrer certains aspects d'autres spécifications publiées entre-temps. Il fut décidé de scinder le document en plusieurs parties. Cela s'est traduit par la publication de 6 I-D en décembre 2007 :

• 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

Le diagramme montre comment ces travaux ont progressé au cours d'un long processus de rédaction de 7 ans, avec la publication de 27 versions préliminaires, avant la publication de la norme définitive. En juin 2014 paraît la série RFC 723x (x est compris entre 0 et 5). Le président du GT HTTPbis a marqué cette avancée en proclamant « RFC 2616 est morte ». Le message était clair : ces nouveaux documents rendaient obsolète l'ancienne versionRFC 2616.

Les choses ont continué d’évoluer en marge des travaux de l'IETF sur la série RFC 723x. On a continué d'améliorer, de développer et de tester le protocole HTTP sur Internet. Mentionnons entre autres Google, qui avait entamé des essais avec un logiciel du nom de SPDY (prononcer « speedy »). Ce protocole était censé améliorer la navigation sur le Web, ce qui constitue la principale raison d'être du protocole HTTP. Fin 2009, la v1 de SPDY fut annoncée, et elle fut rapidement suivie par la v2 en 2010.

Je ne m'attarderai pas sur les aspects techniques de SPDY. Cela fera un jour l’objet d’un article dédié. Le plus important est de retenir que SPDY a repris les principes de base du HTTP et modifié légèrement le format d'échange pour y apporter les améliorations nécessaires. Avec le recul, il est évident que HTTP a une sémantique et une syntaxe clairement définies. La sémantique décrit le concept des échanges de requêtes et de réponses : méthodes, codes de statut, champs d'en-tête (métadonnées) et corps (charge utile). La syntaxe décrit comment associer la sémantique aux octets du réseau.

HTTP/0.9, 1.0 et 1.1 partagent beaucoup de sémantique. Ils partagent également leur syntaxe sous forme de chaînes de caractères acheminées par des connexions TCP. SPDY a pris la sémantique HTTP/1.1 et a changé la syntaxe des chaînes de caractères en langage binaire. Le sujet est très intéressant, mais nous n'irons pas plus loin aujourd'hui.

Les expériences de Google avec SPDY ont montré qu'il était judicieux de modifier la syntaxe HTTP et de conserver la sémantique HTTP existante. Par exemple, le fait de conserver le format des URL pour utiliser https:// a évité de nombreux problèmes qui auraient pu avoir une incidence sur la diffusion.

Après avoir constaté certains des résultats positifs, l'IETF a décidé qu'il était temps de réfléchir à ce que pourrait être le protocole HTTP/2.0. Les présentations de la réunion HTTPbis qui s'est tenue pendant la 83e conférence de l'IETF en mars 2012 montrent les conditions, objectifs et mesures de réussite qui y ont été définis. En outre, il y est clairement indiqué que « HTTP/2.0 signifie seulement que le format de transmission n'est pas compatible avec celui de HTTP/1.x ».

Au cours de cette réunion, la communauté a été invitée à faire part de ses propositions. Voici quelques-unes des I-D proposées : draft-mbelshe-httpbis-spdy-00, draft-montenegro-httpbis-speed-mobility-00 et draft-tarreau-httpbis-network-friendly-00. Finalement, le projet SPDY a été adopté et, en novembre 2012, les travaux sur draft-ietf-httpbis-http2-00 ont commencé. Après 18 versions sur une période d'un peu plus de 2 ans, RFC 7540 - HTTP/2 a été publiée en 2015. Pendant cette période de définition de la norme, la syntaxe précise de HTTP/2 a divergé juste assez pour rendre HTTP/2 et SPDY incompatibles.

Au cours de cette période, l'IETF a consacré beaucoup de temps aux travaux liés au HTTP, le remaniement de HTTP/1.1 et la normalisation de HTTP/2 ayant eu lieu en parallèle. Cela contraste nettement avec les nombreuses années de calme au début des années 2000. Jetez un coup d'œil sur la chronologie complète pour bien mesurer la quantité de travail accompli.

Même si HTTP/2 était en cours de normalisation, l'utilisation et les tests de SPDY présentaient encore des avantages. Cloudflare a mis en place un support pour SPDY en août 2012 et ne l'a abandonné qu'en février 2018 lorsque nos statistiques ont montré que moins de 4 % des clients Web souhaitaient encore utiliser SPDY. Entre-temps, nous avons mis en place le support HTTP/2 en décembre 2015, peu de temps après la publication de la RFC, lorsque nous avons constaté que la plupart des clients Web pourraient en bénéficier.

Le support client Web des protocoles SPDY et HTTP/2 a préféré opter pour TLS, qui constitue une solution sécurisée. L'introduction du SSL universel en septembre 2014 a permis de faire en sorte que tous les sites Web inscrits sur Cloudflare puissent profiter de ces nouveaux protocoles dès leur lancement.

Google a continué à expérimenter entre 2012 et 2015 et a publié SPDY v3 et v3.1. Ils ont également commencé à travailler sur gQUIC (prononcé « Quick » à l'époque) et le premier cahier des charges public a été diffusé au début de l'année 2012.

Les premières versions de gQUIC utilisaient la forme SPDY v3 de la syntaxe HTTP. Ce choix était logique, car HTTP/2 n'était pas encore terminé. La syntaxe binaire SPDY a été compilée en paquets QUIC pouvant être envoyés sous forme de datagrammes UDP. Cela constituait une rupture par rapport au transport TCP sur lequel HTTP s'appuyait traditionnellement. Une fois rassemblés, voici à quoi ils ressemblaient :

Millefeuille SPDY over gQUIC

gQUIC a fait preuve d'astuce pour optimiser ses performances. Entre autres, il s'agissait de rompre les couches claires entre l'application et le transport. En pratique, cela signifiait que gQUIC ne prenait en charge que le protocole HTTP. À tel point que gQUIC, à l'époque appelé « QUIC » était considéré comme la nouvelle version à venir de HTTP. Malgré les changements constants apportés à QUIC au cours des dernières années, dont nous parlerons plus loin, tout le monde pense que QUIC est réduit à cette variante initiale de HTTP. Malheureusement, cela constitue souvent une source de confusion lors des discussions portant sur le protocole.

gQUIC a continué à expérimenter et est finalement passé à une syntaxe beaucoup plus proche de HTTP/2, tellement proche que la plupart des gens l'appelaient simplement « HTTP/2 over QUIC ». Cependant, en raison de contraintes techniques, il existait des différences très subtiles. Les en-têtes HTTP étaient par exemple numérotés et échangés. Il s'agit d'une différence minime, mais qui signifie en fait que HTTP/2 over gQUIC était incompatible avec le HTTP/2 de l'IETF.

De plus, il faut toujours tenir compte des éléments de sécurité des protocoles Internet. gQUIC a choisi de ne pas utiliser TLS pour la sécurisation des données. Au lieu de cela, Google a élaboré une nouvelle méthode appelée QUIC Crypto. Celle-ci comportait notamment une nouvelle méthode permettant d'accélérer les handshakes de sécurité. Un client ayant déjà établi une session sécurisée avec un serveur pouvait réutiliser les informations pour effectuer un handshake de type « zéro aller-retour », ou 0-RTT. 0-RTT a ensuite été intégré à TLS 1.3.

On y est presque.

Maintenant, vous devez être familiarisé(e) avec le fonctionnement de la normalisation, et gQUIC n’est pas si différent. L'intérêt suscité a été suffisamment important pour que les spécifications de Google soient rédigées au format I-D. En juin 2015, le projetdraft-tsvwg-quic-protocol-00, dont le nom en anglais pourrait se traduire par « QUIC : un canal de transport sûr et fiable basé sur UDP pour HTTP/2 », fut présenté. Souvenez-vous que j'ai dit plus tôt que la syntaxe était presque HTTP/2.

Google a annoncé qu’une Bar BoF se tiendrait lors de la 93e conférence de l’IETF à Prague. Les curieux qui se demandent ce qu'est une « Bar BoF » peuvent consulter la RFC 6771. Indice : BoF = Birds of a Feather (en français : « Qui se ressemble s’assemble »).

Cette collaboration avec l'IETF a montré, en résumé, que QUIC semblait offrir de nombreux avantages au niveau du transport et qu'il devrait être dissocié du HTTP. La séparation nette entre les couches devrait être réinstaurée. De plus, on a préféré revenir à un handshake basé sur TLS (ce qui était plutôt bien vu puisque TLS 1.3 était sur les rails à ce stade, et qu'il intégrait des handshakes 0-RTT).

Environ un an plus tard, en 2016, une nouvelle série d'I-D a été présentée :

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

• draft-thomson-quic-tls-00

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

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

C'est là qu'une autre source de confusion entre HTTP et QUIC entre en jeu. draft-shade-quic-http2-mapping-00, la « sémantique HTTP/2 utilisant le protocole de transport QUIC », se présente comme « une représentation de HTTP/2 sur une sémantique QUIC ». Toutefois, le titre est mal choisi. HTTP/2 visait à modifier la syntaxe tout en conservant la sémantique. De plus, « HTTP/2 over gQUIC » n'a jamais donné une description précise de la syntaxe, pour les raisons que j'ai soulignées précédemment... Gardez cela en tête.

Cette version de QUIC de l'IETF devait constituer un tout nouveau protocole de transport. Il s'agit d'une démarche de grande envergure et, avant de s'y lancer tête première, l'IETF préfère évaluer le degré de mobilisation réel de ses membres. À cette fin, une réunion officielle Birds of a Feather s’est tenue lors de la 96e conférence de l'IETF à Berlin en 2016. J’ai eu la chance d’y assister en personne et les diapositives ne reflètent pas sa teneur. Comme le montre la photo d'Adam Roach, des centaines de personnes y ont assisté. La réunion a débouché sur un consensus : QUIC sera adopté et normalisé à l'IETF.

La première I-D QUIC de l'IETF pour le mappage HTTP vers QUIC, draft-ietf-quic-http-00, adoptait la méthode Ronseal et simplifiait son nom en « HTTP over QUIC ». Malheureusement, le travail n'a pas été complètement achevé et le terme HTTP/2 a été utilisé à plusieurs reprises dans le texte. Mike Bishop, nouveau rédacteur en chef des I-D, s'en est rendu compte et a commencé à corriger l'erreur. Dans la version 01, la description a été changée en « mappage de la sémantique HTTP vers QUIC ».

Au fil du temps et des versions, le terme « HTTP/2 » fut de moins en moins utilisé et, lorsqu'il l'était, ce n'était que pour faire référence à certaines parties de la RFC 7540. Avançons de deux ans jusqu'en octobre 2018 : l'I-D en est maintenant à sa version 16. Bien que HTTP over QUIC présente des similitudes avec HTTP/2, il s'agit en définitive d'une syntaxe HTTP indépendante et non rétrocompatible. Cependant, pour ceux qui ne suivent pas de très près les évolutions de l'IETF (soit la majorité de la population mondiale), le nom du document ne reflète pas cette différence. L'un des principaux objectifs de la normalisation est de faciliter la communication et l'interopérabilité. Pourtant, aussi anodine soit-elle, une simple dénomination peut semer la confusion au sein de la communauté.

Rappelons ce qui a été dit en 2012 : « HTTP/2.0 signifie seulement que le format de communication n'est pas compatible avec celui de HTTP/1.x ». L'IETF a suivi ce principe. Après de longues délibérations avant et pendant la 103e conférence de l'IETF, les participants se sont mis d'accord pour rebaptiser « HTTP over QUIC » HTTP/3. Tout va donc mieux dans le meilleur des mondes et nous pouvons désormais aborder des sujets plus importants.

Les titres des documents peuvent parfois prêter à confusion. Les documents HTTP actuels suivants décrivent la syntaxe et la sémantique :

• RFC 7230 - Protocole de transfert hypertexte (HTTP/1.1) : syntaxe de message et routage

• RFC 7231 - Protocole de transfert hypertexte (HTTP/1.1) : sémantique et contenu

Il faut toutefois faire preuve de prudence et savoir que les principes fondamentaux de la sémantique HTTP sont propres aux versions de HTTP, c'est-à-dire HTTP/1.1. Cependant, il s'agit d'un effet secondaire non intentionnel de l'arbre généalogique HTTP. La bonne nouvelle, c'est que le groupe de travail HTTPbis se penche actuellement sur cette question. Certains membres courageux procèdent à une nouvelle révision des documents, comme l'a dit Roy Fielding : « Une fois de plus ! ». Ce travail est en cours en ce moment et est connu sous le nom d'activité « HTTP Core » (vous en avez peut-être entendu parler sous le nom de « HTTPtre » ou « HTTPter », le choix du nom est encore une fois difficile). Les six projets seront ainsi condensés et réduits à trois projets :

• Sémantique HTTP (draft-ietf-httpbis-semantics)

• Mise en cache HTTP (draft-ietf-httpbis-caching)

• Syntaxe des messages et routage HTTP/1.1 (draft-ietf-httpbis-messaging)

Avec cette nouvelle structure, il devient plus manifeste que HTTP/2 et HTTP/3 sont des définitions syntaxiques pour la sémantique HTTP commune. Cela ne signifie pas qu'ils ne possèdent pas leurs propres caractéristiques au-delà de la syntaxe, mais cela devrait aider à orienter les discussions vers l'avenir.

Cet article n'a abordé que superficiellement le processus de normalisation HTTP de l'IETF au cours des trois dernières décennies. Sans entrer dans les détails techniques, j'ai essayé d'expliquer comment nous en sommes arrivés à HTTP/3 aujourd'hui. Si vous avez sauté les passages les plus denses et qu'un résumé vous suffit, le voici : HTTP/3 n'est qu'une nouvelle syntaxe HTTP compatible avec IETF QUIC, un transport multiplexé et sécurisé basé sur UDP. De nombreux aspects techniques intéressants méritent une étude plus approfondie, mais cela attendra.

Dans cet article, nous avons traité des chapitres importants du développement du HTTP et du TLS, mais nous l'avons fait de manière isolée. Nous avons conclu en les rassemblant tous dans la Chronologie du Web sécurisé que vous trouverez ci-dessous. Vous pouvez vous en servir pour découvrir l'histoire en détail et à votre rythme. Les plus mordus peuvent consulter la version complète incluant les numéros des projets.

Mots-clés : IETF, QUIC, TLS, Sécurité