Dans les versions nocturnes de Firefox, ainsi que dans la version bĂȘta, la prise en charge du protocole HTTP/3 est activĂ©e par dĂ©faut. Dans la branche stable, l'activation de HTTP/3 est prĂ©vue pour la sortie de Firefox 88, programmĂ©e pour le 20 avril. Dans Chrome, l'activation sĂ©lective de HTTP/3 a commencĂ© en octobre 2020.
La prise en charge de HTTP/3 dans Firefox repose sur le projet neqo développé par Mozilla, qui fournit une implémentation du client et de serveurs pour le protocole QUIC. Le code des composants pour la prise en charge de HTTP/3 et QUIC est écrit en Rust. Pour gérer l'activation de HTTP/3 dans about:config, une option « network.http.http3.enabled » est prévue. La prise en charge expérimentale de HTTP/3 a également été ajoutée dans le logiciel client Chrome et curl, et pour serveurs disponible dans nginx, ainsi qu'en tant que module nginx et serveur de test de la société Cloudflare. Plusieurs sites de test ont été lancés pour vérifier le fonctionnement des clients HTTP/3.
Le protocole HTTP/3 est encore à un stade de spécification préliminaire et n'est pas encore standardisé par l'IETF. HTTP/3 définit l'utilisation du protocole QUIC comme transport pour HTTP/2. Le protocole QUIC (Quick UDP Internet Connections) est développé par Google depuis 2013 comme alternative au couple TCP+TLS pour le Web, résolvant les problÚmes de temps de connexion et d'établissement au sein de TCP et éliminant les délais en cas de perte de paquets lors du transfert de données. QUIC est une superstructure au-dessus du protocole UDP, supportant le multiplexage de plusieurs connexions et fournissant des méthodes de chiffrement équivalentes à TLS/SSL. Au cours de l'élaboration de la norme par l'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 l'autre soutenue par Google (Chrome supportant les deux versions).
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 ;
- 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) ;
- 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.
- Une augmentation significative des performances et de la bande passante par rapport à TCP. Pour les services vidéo comme YouTube, l'utilisation de QUIC a montré une réduction des opérations de mise en mémoire tampon lors de la visionnage de vidéos de 30%.
Source : opennet.ru
