Les versions nocturnes de Firefox ont ajouté le support de HTTP/3.

Dans versions nocturnes Firefox, qui fera partie de la version 72 prévue pour le 7 janvier, ajouté la prise en charge du protocole HTTP/3. Par défaut, HTTP/3 est désactivé et nécessite l'activation de l'option « network.http.http3.enabled » dans about:config.

La prise en charge de HTTP/3 dans Firefox est basée sur un projet développé par Mozilla neqo, fournissant une implémentation pour le client et le serveur du protocole QUIC. Le code des composants pour la prise en charge de HTTP/3 et QUIC est écrit en Rust.
Dans le logiciel client, la prise en charge expérimentale de HTTP/3 est déjà ajouté présente dans Chrome et curl, et pour les serveurs, elle est disponible sous la forme du module pour nginx et un serveur de test basé sur la bibliothèque quiche (implémentation QUIC et HTTP/3 en Rust développée par Cloudflare). Pour vérifier le fonctionnement des clients HTTP/3, plusieurs sites de test ont été lancés, dont la majorité ne s'ouvre pas encore correctement dans Firefox (HTTP/3 est en phase de brouillon de spécification et n'est pas encore finalisé). Dans les versions nocturnes de Firefox, qui feront partie de la version 72 prévue pour le 7 janvier.

Rappelons que HTTP/3 standardise l'utilisation du protocole QUIC en tant que transport pour HTTP/2. Le protocole QUIC (Quick UDP Internet Connections) est développé par Google depuis 2013 comme une alternative à la combinaison TCP+TLS pour le Web, résolvant les problèmes de latence dans l'établissement et l'accord des connexions TCP et éliminant les retards dus aux pertes de paquets pendant le transfert de données. QUIC représente une couche au-dessus du protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des méthodes de cryptage équivalentes à TLS/SSL.

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 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 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