Le comité IETF (Internet Engineering Task Force), qui travaille sur le développement des protocoles et de l'architecture d'internet, a achevé la rédaction de la RFC pour le protocole QUIC et a publié les spécifications associées sous les identifiants RFC 8999 (propriétés du protocole indépendantes de la version), RFC 9000 (transport sur UDP), RFC 9001 (cryptage TLS pour le canal de communication QUIC) et RFC 9002 (gestion de la congestion et détermination de la perte de paquets lors de la transmission des données).
Les RFC ont obtenu le statut de « norme proposée », après quoi le travail commencera pour donner aux RFC le statut de norme ébauche (Draft Standard), ce qui signifie en fait une stabilisation complète du protocole et la prise en compte de toutes les remarques exprimées. Le protocole HTTP/3, qui définit l'utilisation du protocole QUIC comme transport pour HTTP/2, est encore au stade de spécification ébauche, mais il sera bientôt standardisé de manière définitive au sein de l'IETF.
On s'attend à ce que la normalisation de QUIC favorise une adoption plus large de ce protocole, ainsi que le développement d'extensions basées sur celui-ci, telles que WebTransport (technologie pour l'envoi et la réception de données entre le navigateur et serveur) et MASQUE (technologie de proxy qui étend les capacités de SOCKS et HTTP CONNECT, utilisant HTTPS au-dessus de QUIC comme transport).
Rappelons que le protocole QUIC (Quick UDP Internet Connections), développé par Google depuis 2013 comme alternative à la combinaison TCP+TLS pour le Web, s'attaque aux problèmes de latence dans l'établissement et la négociation des connexions dans TCP et élimine les retards lors de la perte de paquets pendant la transmission des données. QUIC est une superposition du protocole UDP, supportant le multiplexage de plusieurs connexions et fournissant des méthodes de cryptage équivalentes à TLS/SSL. Au cours de l'élaboration de la norme au sein de l'IETF, des modifications ont été apportées au protocole, donnant naissance à deux branches existant parallèlement, l'une pour HTTP/3, et l'autre soutenue par Google (Chrome prend en charge les deux versions, tandis que Firefox prend en charge la version IETF).
Fonctionnalités principales de 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 ;
- Capacité à é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 à garantir des délais minimaux entre l'envoi de la requête et la réception de la réponse (RTT, Round Trip Time);
- L'utilisation d'un numéro de séquence différent lors de la retransmission d'un paquet, ce qui permet d'éviter les ambiguïtés lors de l'identification 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 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 ;
- 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.
- Un gain significatif de performance et de bande passante par rapport à TCP. Pour les services vidéo tels que YouTube, l'utilisation de QUIC a montré une réduction de 30 % des opérations de rebuffering lors de la visionnage de vidéos.
Source : opennet.ru
