L'Internet Engineering Task Force (IETF), responsable du développement des protocoles et de l'architecture Internet, a finalisé la RFC pour le protocole QUIC et publié les spécifications associées sous les identifiants RFC 8999 (propriétés du protocole indépendantes de la version), RFC 9000 (propriétés du protocole de transport). sur UDP), RFC 9001 (cryptage TLS du canal de communication QUIC) et RFC 9002 (contrôle de congestion et détection de perte de paquets lors de la transmission de données).
Les RFC ont reçu le statut de « Proposed Standard », après quoi les travaux commenceront pour donner au RFC le statut de projet de norme (Draft Standard), ce qui signifie en fait une stabilisation complète du protocole et la prise en compte de tous les commentaires formulés. Le protocole HTTP/3, qui définit l'utilisation du protocole QUIC comme transport pour HTTP/2, est encore au stade de projet de spécification, mais il sera bientôt définitivement standardisé par l'IETF.
On s'attend à ce que la standardisation de QUIC donne une impulsion à une adoption plus large de ce protocole, ainsi qu'au développement d'extensions basées sur celui-ci, telles que WebTransport (une technologie d'envoi et de réception de données entre un navigateur et un serveur) et MASQUE. (une technologie de proxy de connexion qui étend les capacités de SOCKS et HTTP CONNECT et utilise HTTPS sur QUIC comme transport).
Rappelons que le protocole QUIC (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 liés aux longs délais d'établissement et de négociation des connexions en TCP et éliminant les retards lors de la connexion. les paquets sont perdus 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. Lors du développement de la norme IETF, des modifications ont été apportées au protocole, ce qui a conduit à l'émergence de deux branches parallèles, une pour HTTP/3 et la seconde supportée par Google (Chrome prend en charge les deux options et Firefox prend en charge la version IETF). .
Principales caractéristiques de QUIC :
- 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) ;
- Utiliser un numéro de séquence différent lors de la retransmission d'un paquet, ce qui évite toute ambiguïté dans l'identification des paquets reçus et élimine 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 ;
- Augmentation significative des performances et du débit par rapport au 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