Pour l’IETF (Internet Engineering Task Force), il semble maintenant clair que HTTP-over-QUIC va devenir HTTP/3. Ce qui n’était qu’une fonction expérimentale de Google servira donc de base à la prochaine révision majeure du protocole HTTP.
QUIC, pour Quick UDP Internet Connections, se veut un remplaçant de TCP. Une nouvelle couche de transport supportant les connexions UDP multiplexées entre points, conçue pour réduire la latence et la bande passante nécessaire, ainsi bien sûr qu’une meilleure sécurité (données chiffrées par défaut).
Google réitère donc la genèse de HTTP/2, largement basé sur son protocole SPDY. Le passage de QUIC en spécification signifiera donc une adoption par les autres navigateurs. QUIC, bien que non finalisé, est cependant déjà implémenté dans Chromium et se retrouve ainsi dans les navigateurs l’utilisant, dont Opera.
On attend maintenant l’annonce officielle.
Commentaires (7)
#1
Ça n’est pas un peu précipité de mettre en place un successeur à HTTP/2 ? D’ailleurs, sait-on où ça en est avec le support de HTTP/2 dans les navigateurs et autres intermédiaires ?
#2
pour le support par les navigateurs : https://caniuse.com/#feat=http2
#3
Je pense pas, vu la disparité des maj des os mobiles, il vaut mieux le faire le plus rapidement possible pour que tout les nouveaux devices soient compatibles et puissent l’utiliser. Vu que c’est purement logiciel, pas de raison de se priver, http et http/2 restent utilisable et c’est transparent pour l’utilisateur
#4
#5
Quel sera le gain en terme de latence/bande passante ?
#6
si j’ai bien tout compris l’idée est de passer outre les contraintes inhérentes au TCP qui imposent par exmple plusieurs aller-retours au moment de l’établissement de connexion (cf. “TCP Three Way Handshake”) et une montée graduelle du débit (cf. “TCP slow start”).
L’idée générale est de baser le nouveau protocole au dessus d’UDP (qui n’impose quasiment rien, pas d’établissement de connexion, pas de fenêtre de congestion, etc…), quitte à reproduire une partie des fonctionnalités proposées par TCP (contrôle de l’intégrité des données, de congestion, etc…) mais dans une forme qui permet de booster un max le transfert dès le départ de la connexion (absence de x allers retours pour établir la connexion, absence de “TCP slow start”, etc…).
Amha, le gain le plus significatif devrait essentiellement se situer au niveau de la latence au moment de l’établissement de la connexion.
#7
C’est plus compliqué que ca: SPDY est devenu HTTP/2 mais le QUIC de Google n’est pas le QUIC de l’l’IETF.
L’IETF a séparé le QUIC de Google en 2 parties: la partie “qui remplace TCP” et la partie HTTP au dessus “de ce qui remplace TCP” devient HTTP/3 et au passage ce n’est plus compatible avec le QUIC de Google…