Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

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

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.

2 commentaires
Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 08/10/20 à 12:45:36

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.

Avatar de OB Abonné
Avatar de OBOB- 08/10/20 à 13:23:26
127.0.0.1

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.

Il n'est plus possible de commenter cette actualité.