Le protocole HTTP-over-QUIC change de nom et devient officiellement HTTP / 3
Pour éviter la confusion avec QUIC, le protocole de transport
Le 2018-11-12 14:17:38, par Stéphane le calme, Chroniqueur Actualités
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 :
Envoyé par Mark Nottingham
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 :
Envoyé par Daniel Stenberg
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
En effet, le 28 octobre, il a publié ceci dans un billet de blog :
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 :
Et vous ?
Voir aussi :
-
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.le 12/11/2018 à 22:06 -
grunkModérateurOn 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éveloppeurle 12/11/2018 à 15:25 -
VulcaniaMembre éclairé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ésle 12/11/2018 à 16:44