Mozilla a annoncé son intention de commencer à adopter progressivement HTTP/3 et QUIC avec la sortie de Firefox 88, prévue pour le 19 avril (la sortie était initialement prévue pour le 20 avril, mais, à en juger par le calendrier, elle sera décalée d'un jour). . La prise en charge HTTP/3 ne sera initialement activée que pour un petit pourcentage d'utilisateurs et, sauf problème inattendu, sera déployée pour tout le monde d'ici la fin mai. Dans les builds nocturnes et les versions bêta, HTTP/3 a été activé par défaut fin mars.
Rappelons que l'implémentation de HTTP/3 dans Firefox est basée sur le projet neqo développé par Mozilla, qui fournit une implémentation client et serveur pour le protocole QUIC. Le code du composant pour la prise en charge HTTP/3 et QUIC est écrit en Rust. Pour contrôler si HTTP/3 est activé, about:config fournit l'option « network.http.http3.enabled ». Depuis le logiciel client, une prise en charge expérimentale de HTTP/3 a également été ajoutée à Chrome et curl, et pour les serveurs, elle est disponible dans nginx, ainsi que sous la forme d'un module nginx et d'un serveur de test de Cloudflare. Côté site web, le support HTTP/3 est déjà assuré sur les serveurs de Google et Facebook.
Le protocole HTTP/3 est encore au stade de projet de spécification et n'a pas encore été entièrement standardisé par l'IETF. HTTP/3 nécessite la prise en charge client et serveur pour la même version du projet de norme QUIC et HTTP/3, qui est spécifiée dans l'en-tête Alt-Svc (Firefox prend en charge les projets de spécifications 27 à 32).
HTTP/3 définit l'utilisation du protocole QUIC comme transport pour HTTP/2. 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 de longs délais d'installation et de négociation des connexions en TCP et éliminant les retards en cas de perte de paquets lors du transfert de données. transfert. 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, l'une pour HTTP/3 et la seconde supportée par Google (Chrome supporte les deux options).
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