Discussion :

[Stéphane le calme]

Le protocole HTTP-over-QUIC change de nom et devient officiellement HTTP / 3,
pour éviter la confusion avec QUIC, le protocole de transport

Le protocole appelé HTTP-over-QUIC depuis un certain temps a maintenant changé de nom et devient officiellement HTTP / 3. Cette décision a été prise après un processus déclenché par une suggestion de Mark Nottingham, un développeur d’infrastructure Web influent qui est l’un des auteurs des spécifications Atom et WS-I Basic Profile, l’auteur de RFC 4229: Enregistrements d’en-tête HTTP, et président du groupe de travail HTTPBIS de l’IETF et du service d’adressage Web W3C.

En effet, le 28 octobre, il a publié ceci dans un billet de blog :

Vous vous souviendrez peut-être que nous avions précédemment parlé de renommer nos produits livrables afin de clarifier leur relation avec les documents de base (parfois dénommés "gQUIC vs iQUIC").

Après de nombreuses discussions avec diverses personnes, il semble évident que l'appel de notre simple produit livrable «QUIC» fera toujours l’affaire, car la variante de Google disparaître si nous réussissons, et il n'y a toujours pas de bonne alternative. [...]

Au cours de ces discussions, une préoccupation connexe a été identifiée; la confusion entre QUIC, le protocole de transport et QUIC, la liaison HTTP. D'autres personnes et moi avons vu un certain nombre de personnes qui ne participaient pas étroitement à ce travail, confondant les deux, même si elles sont maintenant séparées.

Pour remédier à cela, j'aimerais suggérer que, après coordination avec le groupe de travail HTTP, nous renommions notre document HTTP en "HTTP / 3" et que nous utilisions le jeton ALPN final "h3". Cela l'identifie clairement comme une autre liaison de la sémantique HTTP au protocole - tout comme HTTP / 2 - pour que les gens comprennent sa séparation de QUIC.

Dans le cadre de cette discussion, je suggérerais que nous formalisions le fait que sa maintenance (ainsi que celle de QPACK) soit transmise au groupe de travail HTTP une fois que nous l'avons publié.

J'ai parlé de cela avec un certain nombre de personnes. Les seules préoccupations que j'ai entendues jusqu'à présent sont les suivantes:

a) Ce QUIC n'est pas encore prouvé. C'est vrai, mais le nom ne sera pas formalisé ou utilisé sur le réseau jusqu'à la publication de la RFC, nous avons donc beaucoup de temps pour reculer. Même dans ce cas, s'il échoue sur le marché, nous pouvons toujours passer à HTTP / 4 un jour, s'il le faut.

b) Faire des discussions pour donner un nom est une distraction de notre travail technique. Je suis d'accord avec la préoccupation dans son ensemble, mais nous avons la responsabilité de communiquer clairement avec les développeurs et les utilisateurs externes. J'aimerais donc avoir une discussion * limitée * à ce sujet.

Evolution

Après le protocole SPDY, permettant d’accélérer le Web en compressant les requêtes d’une page Web, Google s’est lancé dans l’expérimentation d’un nouveau protocole dont l’objectif était d’offrir, comme le précédent, une vitesse de chargement des pages optimisée.

Ce n’est qu’en fin juin 2013 que le numéro un de la recherche en ligne a dévoilé une première préversion du protocole expérimental Quick UDP Internet Connections (QUIC), dans la dernière version de son navigateur sur le canal Canary.

QUIC avait pour objectif de faire évoluer le protocole TCP en tirant parti des avantages qu’offre UDP. Le protocole reposait alors sur un multiplexage de flux au dessus d’UDP, pour permettre des transmissions fiables en mode connecté, avec une rapidité comparable à UDP.

En avril 2015, Google a annoncé son intention de proposé à l’IETF (Internet Engineering Task Force, un groupe international qui participe à l’élaboration des standards Internet) son protocole réseau QUIC.

Et c’est ce qui s’est produit. Un groupe de travail QUIC de l'IETF a donc été constitué et s’est chargé de veiller à la normalisation de QUIC. Il faut préciser que lorsque ce travail de normalisation a débuté, le groupe a été scindé en deux : le transport et le HTTP. L'idée étant que ce protocole de transport peut également être utilisé pour transférer d'autres données et qu'il ne s'agit pas simplement d'une procédure explicite pour les protocoles HTTP ou de type HTTP. Mais le nom restait le même depuis toujours : QUIC.

Les membres de la communauté ont fait référence à ces différentes versions du protocole en utilisant des noms informels tels que iQUIC et gQUIC pour séparer les protocoles QUIC de l'IETF et de Google (car ils différaient beaucoup dans les détails). Le protocole qui envoie HTTP via "iQUIC" a longtemps été appelé "hq" (HTTP sur QUIC).

D'ailleurs Daniel Stenberg, développeur principal de Curl et employé par Mozilla, a avancé que :

Mike Bishop a fait peur à la réunion du groupe de travail QUIC à l'IETF 103 lorsqu'il a présenté cette diapositive avec ce que l'on pourrait presque prendre pour un logo

Le 7 novembre 2018, Dmitri de Litespeed a annoncé que Facebook et eux avaient réalisé avec succès la première interopérabilité jamais réalisé entre deux implémentations HTTP / 3. La présentation suivante de Mike Bihop lors de la session HTTPbis sur le sujet peut être vue ici (vidéo YouTube). Le consensus à la fin de cette réunion a déclaré que le nouveau nom est HTTP / 3!

Plus de confusion. HTTP / 3 est la nouvelle version HTTP à venir qui utilise QUIC pour le transport!

Sources : IETF, billet Daniel

Et vous ?

Que pensez-vous de cette décision ?

Voir aussi :

Google dévoile son nouveau protocole QUIC dans Chrome, qui combine le meilleur de TCP et UDP
Google projette de proposer son protocole QUIC à l'IETF, pour un internet plus rapide

[grunk]

On a mis presque 20 ans à passer de http 1.1 à http/2 et là tout d'un coup on se met à changer tous les 2 ans.
D'un coté c'est bien de travailler sur la performance , d'un autre j'ai bien peur qu'on se retrouve avec un eco système complètement fragmenté qui ne vas pas simplifier la vie des développeur

[Vulcania]

On a mis presque 20 ans à passer de http 1.1 à http/2 et là tout d'un coup on se met à changer tous les 2 ans.
D'un coté c'est bien de travailler sur la performance , d'un autre j'ai bien peur qu'on se retrouve avec un eco système complètement fragmenté qui ne vas pas simplifier la vie des développeur

Personnellement j'ai vu aucune différence de mon côté (dev web) entre http 1.1 et http 2, la plupart des outils de debug m'affichent les mêmes informations auquel je m'attend et http 2 est rétrocompatible avec les clients http 1.1.
J'ai plus peur pour les sysadmins avec les pares-feu et portails captif, ou encore nos fameuses boîtes noires qui vont pouvoir analyser correctement les infos seulement 3 ans plus tard et des centaines de milliers d'euros dépensés

[Invité]

Personnellement j'ai vu aucune différence de mon côté (dev web) entre http 1.1 et http 2, la plupart des outils de debug m'affichent les mêmes informations auquel je m'attend et http 2 est rétrocompatible avec les clients http 1.1.
J'ai plus peur pour les sysadmins avec les pares-feu et portails captif, ou encore nos fameuses boîtes noires qui vont pouvoir analyser correctement les infos seulement 3 ans plus tard et des centaines de milliers d'euros dépensés

En pratique le passage à HTTP/2 c'est surtout de la configuration et si ton serveur utilisait déjà HTTPs avec un algorithme de chiffrement moderne tu n'as presque rien à faire. Pour le dev la seule différence c'est que comme HTTP/2 envoi les fichiers en parallèle tu n'as plus un gros intérêt à grouper les fichiers à envoyer en un petit nombre.


Pour QUIC / HTTP/3 ça devrait filer un peu de taf aux sysadmins puisque la connexion passe de TCP à UDP mais pour le dev ça a l'air de ne rien changer du tout cette fois.