L'activation du support HTTP/3 dans Firefox est prévue pour fin mai.

La société Mozilla a annoncé son intention de commencer l'activation progressive des protocoles HTTP/3 et QUIC dans la version 88 de Firefox, prévue pour le 19 avril (initialement, la sortie était prévue pour le 20 avril, mais, selon le calendrier, elle a été décalée d'un jour). Au départ, le support d'HTTP/3 sera activé uniquement pour un petit pourcentage d'utilisateurs et, si aucun problème inattendu ne survient, sera étendu à tous d'ici la fin mai. Dans les versions nocturnes et bêtas, HTTP/3 a été activé par défaut fin mars.

Rappelons que l'implémentation d'HTTP/3 dans Firefox est basée sur le projet neqo en cours de développement par Mozilla, qui fournit une implémentation du client et de serveurs pour le protocole QUIC. Le code des composants pour le support d'HTTP/3 et QUIC est écrit en Rust. Pour gérer l'activation d'HTTP/3 dans about:config, une option "network.http.http3.enabled" est disponible. Un support expérimental d'HTTP/3 a également été ajouté dans Chrome et curl, et pour serveurs est disponible dans nginx, ainsi que sous forme de module nginx et de serveur de test de la société Cloudflare. Du côté des sites, le support d'HTTP/3 est déjà assuré sur les serveurs de Google et Facebook.

Le protocole HTTP/3 est encore en phase de spécification préliminaire et n'est pas encore standardisé au sein de l'IETF. Pour utiliser HTTP/3, il est nécessaire que le client et le serveur supportent la même version de la spécification préliminaire de QUIC et HTTP/3, qui est indiquée dans l'en-tête Alt-Svc (Firefox supporte les ébauches de spécifications de 27 à 32).

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 une alternative à la combinaison TCP+TLS pour le Web, solution qui résout les problèmes de temps d'établissement et de négociation de connexions dans TCP et élimine les retards dus à la perte de paquets lors de la transmission de données. QUIC constitue une couche au-dessus du protocole UDP, prenant en charge le multiplexage de plusieurs connexions et offrant des méthodes de cryptage équivalentes à celles de TLS/SSL. Au cours du développement de la norme dans l'IETF, des modifications ont été apportées au protocole, ce qui a conduit à l'émergence de deux branches coexistantes, l'une pour HTTP/3 et l'autre soutenue par Google (Chrome supporte les deux variantes).

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