Chrome a ajouté un support expérimental pour le protocole HTTP/3

Assemblages expérimentaux Chrome Canary ajouté prise en charge du protocole HTTP/3, qui implémente une couche pour exécuter HTTP sur le protocole QUIC. Le protocole QUIC a été ajouté au navigateur il y a cinq ans et est depuis utilisé pour optimiser les services de Google. Cependant, la variante de QUIC utilisée dans Chrome différait sur certains points de celle de spécifications l'IETF, mais les implémentations sont désormais synchronisées.

HTTP/3 standardise l'utilisation de QUIC comme transport pour HTTP/2. Pour activer HTTP/3 et la variante QUIC de la version 23 de l'ébauche des spécifications de l'IETF, il faut lancer Chrome avec les options « —enable-quic —quic-version=h3-23 », après quoi l'ouverture d'un site de test quic.rocks:4433 en mode d'inspection réseau dans les outils pour développeurs affichera l'activité HTTP/3 comme « http/2+quic/99 ».

Rappelons que le protocole QUIC (Quick UDP Internet Connections) est développé depuis 2013 par Google comme une alternative à la combinaison TCP+TLS pour le Web, résolvant les problèmes liés aux temps de connexion élevés et à la négociation dans TCP, et éliminant les retards lors de la perte de paquets pendant la transmission des données. QUIC est une surcouche sur le protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des méthodes de chiffrement équivalentes à TLS/SSL. Ce protocole est déjà intégré dans l'infrastructure serveur de Google, fait partie de Chrome, est prévu pour être activé dans Firefox et est largement utilisé pour traiter les demandes des clients sur les serveurs de Google.

Principales caractéristiques QUIC :

• Haute sécurité, similaire à TLS (en substance, QUIC permet d'utiliser TLS sur UDP) ;
• Contrôle de l'intégrité du flux, empêchant la perte de paquets ;
• Possibilité d'établir une connexion instantanément (0-RTT, dans environ 75% des cas les données peuvent être transmises immédiatement après l'envoi du paquet d'établissement de connexion) et de garantir des délais minimaux entre l'envoi de la demande et la réception de la réponse (RTT, Round Trip Time) ;
• Non-utilisation lors de la retransmission d'un paquet du même numéro de séquence, permettant d'éviter toute ambiguïté lors de la détermination des paquets reçus et d'éliminer les délais d'attente ;
• La perte d'un paquet n'affecte que la livraison du flux qui lui est associé et ne bloque pas la livraison des données dans les flux simultanément transmis via la connexion actuelle ;
• Les mécanismes de correction d'erreurs réduisent les délais dus à la retransmission des paquets perdus. L'utilisation de codes spécifiques de correction d'erreurs au niveau du paquet permet de réduire les situations nécessitant la retransmission des données d'un paquet perdu.
• Les frontières cryptographiques des blocs sont alignées sur les frontières des paquets QUIC, ce qui réduit l'impact des pertes de paquets sur le décodage du contenu des paquets suivants.
• Absence de problèmes de blocage de la queue TCP.
• Support de l'identifiant de connexion, permettant de réduire le temps d'établissement d'une reconnexion pour les clients mobiles.
• Capacité à se connecter à des mécanismes avancés de contrôle de congestion.
• Utilisation de techniques de prévision de bande passante dans chaque direction pour garantir une intensité d'envoi optimale des paquets, empêchant un glissement vers un état de congestion, où des pertes de paquets sont observées.
• Une augmentation remarquable de performance et de bande passante par rapport à TCP. Pour les services vidéo tels que YouTube, l'application de QUIC a montré une réduction de 30% des opérations de re-buffering lors du visionnage de vidéos.

Source : opennet.ru