Vers les versions expérimentales prise en charge du protocole HTTP/3, qui implémente un module complémentaire pour permettre à HTTP de fonctionner sur le protocole QUIC. Le protocole QUIC lui-même a été ajouté au navigateur il y a cinq ans et est depuis utilisé pour optimiser le travail avec les services Google. Dans le même temps, la version QUIC de Google utilisée dans Chrome différait sur certains détails de la version de IETF, mais maintenant les implémentations sont synchronisées.
HTTP/3 standardise l'utilisation de QUIC comme transport pour HTTP/2. Pour activer les options HTTP/3 et QUIC à partir de Les spécifications IETF imposent que Chrome soit lancé avec les options "-enable-quic -quic-version=h3-23" puis à l'ouverture du site de test En mode d'inspection du réseau dans les outils de développement, l'activité HTTP/3 sera affichée sous la forme « http/2+quic/99 ».
Rappelons que le protocole (Quick UDP Internet Connections) a été développé par Google depuis 2013 comme alternative à la combinaison TCP+TLS pour le Web, résolvant les problèmes de longs temps de configuration et de négociation des connexions TCP et éliminant les retards en cas de perte de paquets lors du transfert de données. QUIC est une extension du protocole UDP qui prend en charge le multiplexage de plusieurs connexions et fournit des méthodes de cryptage équivalentes à TLS/SSL. Le protocole en question est déjà intégré à l'infrastructure du serveur Google et fait partie de Chrome. pour inclusion dans Firefox et est activement utilisé pour répondre aux demandes des clients sur les serveurs de Google.
principal RAPIDE :
- Haute sécurité similaire à TLS (essentiellement QUIC offre la possibilité d'utiliser TLS sur UDP) ;
- Contrôle de l'intégrité du flux, empêchant la perte de paquets ;
- La possibilité d'établir instantanément une connexion (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 fournir des délais minimes entre l'envoi d'une demande et la réception d'une réponse (RTT, Round Trip Time) ;
- Ne pas utiliser le même numéro de séquence lors de la retransmission d'un paquet, ce qui évite toute ambiguïté dans l'identification des paquets reçus et supprime les délais d'attente ;
- La perte d'un paquet affecte uniquement la livraison du flux qui lui est associé et n'arrête pas la livraison des données dans les flux parallèles transmis via la connexion en cours ;
- Fonctionnalités de correction d'erreurs qui minimisent les retards dus à la retransmission des paquets perdus. Utilisation de codes de correction d'erreurs spéciaux au niveau des paquets pour réduire les situations nécessitant une retransmission de données par paquets perdues.
- Les limites des blocs cryptographiques sont alignées sur les limites des paquets QUIC, ce qui réduit l'impact des pertes de paquets sur le décodage du contenu des paquets suivants ;
- Aucun problème avec le blocage de la file d'attente TCP ;
- Prise en charge de l'identifiant de connexion, qui réduit le temps nécessaire pour établir une reconnexion pour les clients mobiles ;
- Possibilité de connecter des mécanismes avancés de contrôle de la congestion des connexions ;
- Utilise des techniques de prévision du débit par direction pour garantir que les paquets sont envoyés à des débits optimaux, les empêchant ainsi d'être encombrés et de provoquer une perte de paquets ;
- Perceptible performances et débit par rapport à TCP. Pour les services vidéo tels que YouTube, il a été démontré que QUIC réduit de 30 % les opérations de rebuffering lors du visionnage de vidéos.
Source: opennet.ru