Connexion
Abonnez-vous

Chrome : Google commence le déploiement de HTTP/3 et du QUIC de l’IETF

Chrome : Google commence le déploiement de HTTP/3 et du QUIC de l’IETF

Le 08 octobre 2020 à 07h50

QUIC (Quick UDP Internet Connections) est à la base un protocole créé par Google en 2013, avec l’objectif de proposer une couche de transport performante pour les applications web – en communiquant par UDP plutôt que par TCP – et de réduire la latence.

En 2015, Google a présenté ses travaux à l’IETF, qui a fini par récupérer la gouvernance du projet. Depuis, Chrome embarque toujours la version Google du protocole, mais pas celle de l’IETF. La situation évolue désormais.

Google explique dans un billet de blog que la version IETF dépasse maintenant de manière « significative » les performances de la sienne, permettant notamment de réduire la latence de plus de 2 %. En conséquence donnée comme exemple, le temps de rechargement du buffer sous YouTube diminue de 9 %.

L’éditeur annonce que 25 % des utilisateurs de le version stable de Chrome bénéficient désormais du « nouveau » QUIC, ainsi que du HTTP/3 qui l’accompagne. Le déploiement s’étalera durant quelques mois, pendant lesquels Google continuera de surveiller les performances générales.

Plusieurs éléments sont à noter toutefois. IETF QUIC n’est pas un standard finalisé. La version implémentée est le 29e brouillon. Deux autres sont sortis depuis, mais Google assure qu’ils n’induisent aucune cassure.

D’autre part, Chrome ne prend pas en charge le 0-RTT (Zero Round Trip Time Resumption) de QUIC pour l’instant. Il devrait arriver dans les prochains mois. La technique permet de reprendre immédiatement une connexion récemment fermée, par exemple lorsque l’on revient sur un site visité un peu plus tôt.

Le 08 octobre 2020 à 07h50

Commentaires (2)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Le web suit de plus en plus un modèle diffuseur/récepteur… une sorte de web mono-directionnel “serveur–>client(s)”. C’est d’autant plus vrai pour les services de brodcast.



Logique de vouloir s’affranchir de TCP qui est un flux bi-directionnel pensé pour le dialogue entre serveur et client. Il y a plein d’avantages à utiliser un protocole comme UDP dans ce cas.

votre avatar

je sais pas…. Est-ce que , par exemple, QUICC et HTTP/3 serait utilisable dans le contexte d’ActivityPub ?



Pour moi , le vrai souci est que TCP est bien supporté par énormément de couches logicielles, allant des petits objets IoT jusqu’aux gros serveurs, et en passant par les box, routeurs, … avec toute les bidouilles style NAT, statefull firewall,…
UDP aussi, mais comme il n’y a pas d’état, le suivi des connections est plus souvent effectué via un timer, parfois très petit



Pour moi je conçois QUICC comme un protocole TCP fortement enrichi, qui est placé au dessus de UDP “par commodité” et parceque beaucoup de CPE (box grand public ou pro) n’implémentent que TCP et UDP , à l’exclusion de tous les autres protocoles (j’ai vu des problèmes avec GRE, IPIP, STCP,…).



A mon avis c’est là où vont se situer les problèmes.

Chrome : Google commence le déploiement de HTTP/3 et du QUIC de l’IETF

Fermer