Google a déjà commencé avec l'activation d'IETF QUIC et HTTP / 3 dans Chrome

Google a annoncé il y a quelques jours, il a déjà commencé avec le déploiement de HTTP / 3 et IETF QUIC dans Chrome et dans l'annonce, il déclare qu'il s'attend à ce que cette mise à jour apporte des améliorations de performances supplémentaires, notamment avec le support de QUIC.

QUIC est un nouveau protocole de transport réseau qui combine les fonctionnalités de TCP, TLS et plus encore. HTTP / 3 est la dernière version de HTTP, le protocole qui transporte la grande majorité du trafic Web. HTTP / 3 ne fonctionne que sur QUIC.

L'Internet Engineering Task Force, ou IETF, a introduit HTTP / 2 en 2015 et l'une des grandes améliorations qu'il a apportées est la prise en charge du multiplexage.

Cependant, il a utilisé TCP comme protocole de transport et les mécanismes de récupération de perte dans TCP, de sorte que les paquets perdus peuvent toujours entraîner un retard dans toutes les transactions actives.

En adoptant QUIC, HTTP / 3 peut encore améliorer le processus de transfert, puisque les paquets perdus dans ce cas n'affectent que les transactions directement affectées.

En fait, QUIC a été développé à l'origine par Google et annoncé pour la première fois en 2013. Depuis lors, le protocole a atteint sa majorité et est actuellement responsable du transport d'un tiers du trafic de Google.

Puis, en 2015, le développement de QUIC est passé entre les mains de l'IETF, l'organisme de normalisation chargé de maintenir les protocoles Internet. L'IETF a amélioré QUIC avec plusieurs changements. À ce jour, il existe deux protocoles similaires, mais différents, à savoir: Google QUIC et IETF QUIC.

Google a annoncé avoir toujours utilisé sa propre version de QUIC, mais que son équipe QUIC est également impliquée dans la mise en œuvre de la version propriétaire de l'IEFT. "Nous avons déployé des efforts considérables pour faire évoluer Google QUIC au cours des cinq dernières années afin de suivre les changements apportés par l'IETF, et la dernière version actuelle de Google QUIC présente de nombreuses similitudes avec IETF QUIC", lit-on dans l'article de blog. De Google, en plus, a précisé que certaines choses manquaient toujours.

À titre d'exemple, jusqu'à présent la plupart des utilisateurs de Chrome ne peuvent pas communiquer avec les serveurs IETF QUIC sans activer certaines options de ligne de commande. Également, Google a ajouté qu'il a maintenant constaté que IETF QUIC surpasse considérablement HTTP par rapport à TLS 1.3 par rapport à TCP.

En particulier, la société a déclaré que la latence des moteurs de recherche de Google était réduite de plus de 2%. Le temps de mise en mémoire tampon de YouTube a été réduit de plus de 9%. En outre, les performances des clients ont augmenté de plus de 3% sur les ordinateurs de bureau.

Sur les téléphones mobiles, la performance client a augmenté de plus de 7%. Ces raisons et d'autres expliquent le passage de Chrome à la version QUIC de l'IETF. «Nous sommes heureux d'annoncer que Chrome met en œuvre la prise en charge d'IETF QUIC (en particulier, la version pilote h3-29).

Aujourd'hui, environ 25% des utilisateurs de la version stable de Chrome utilisent h3-29, et nous prévoyons d'augmenter ce nombre dans les semaines à venir en continuant à surveiller les données de performances », a déclaré la société dans son article de blog.

"Chrome prendra en charge activement à la fois l'IETF QUIC h3-29 et la version Google QUIC (Q050) pour laisser le temps aux serveurs prenant en charge Q050 de passer à IETF QUIC", a-t-il ajouté. Chrome m85 ne prend pas encore en charge IETF QUIC 0-RTT et Google s'attend à ce que ces performances soient encore meilleures lorsqu'il publiera la prise en charge d'IETF QUIC 0-RTT dans les mois à venir. De plus, étant donné que les versions 30 et 31 d'IETF QUIC ne contiennent pas de modifications susceptibles de rompre la compatibilité, la société ne prévoit pas de modifier l'identifiant «over-the-wire».

Ceci signifie que continuera à suivre les changements dans la version IETF, mais le sera implémenté comme h3-29 / 0xff00001d.

Par conséquent, il recommande que les serveurs continuent à prendre en charge h3-29 jusqu'à ce que les RFC finales soient terminées s'ils souhaitent interagir avec Chrome. Cependant, si l'IETF apporte des modifications qui brisent la compatibilité dans un futur projet, Chrome annulera cette décision.

source: https://blog.chromium.org


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.