Le protocole HTTP/3.0 a obtenu le statut de norme proposée

Le comité IETF (Internet Engineering Task Force), chargé de l'élaboration des protocoles et de l'architecture d'Internet, a finalisé la création de la RFC pour le protocole HTTP/3.0 et a publié les spécifications associées sous les identifiants RFC 9114 (protocole) et RFC 9204 (technologie de compression des en-têtes QPACK pour HTTP/3). La spécification HTTP/3.0 a obtenu le statut de « Norme proposée », après quoi le travail pour accorder à la RFC le statut de norme de brouillon (Draft Standard) débutera, ce qui signifie en fait la stabilisation complète du protocole et la prise en compte de toutes les remarques formulées. Des versions mises à jour des spécifications pour les protocoles HTTP/1.1 (RFC 9112) et HTTP/2.0 (RFC 9113) ont également été publiées, ainsi que des documents définissant la sémantique des requêtes HTTP (RFC 9110) et les en-têtes de contrôle de cache HTTP (RFC 9111).

Le protocole HTTP/3 définit l'utilisation du protocole QUIC (Quick UDP Internet Connections) comme transport pour HTTP/2. QUIC représente une surcouche au protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des méthodes de chiffrement équivalentes à TLS/SSL. Le protocole a été créé en 2013 par Google comme alternative à la combinaison TCP+TLS pour le web, résolvant les problèmes de temps d'établissement et de négociation des connexions dans TCP et éliminant les retards causés par la perte de paquets lors de la transmission de données.

À l'heure actuelle, le support de QUIC et HTTP/3.0 est déjà implémenté dans tous les navigateurs web populaires (dans Chrome, Firefox et Edge, le support de HTTP/3 est activé par défaut, tandis que dans Safari, il nécessite l'activation de l'option « Avancé > Fonctionnalités expérimentales > HTTP/3 »). Du côté serveur, des implémentations de HTTP/3 sont disponibles pour nginx (dans une branche séparée et sous forme de module distinct), Caddy, IIS et LiteSpeed. Le support de HTTP/3 est également assuré par le réseau de distribution de contenu Cloudflare.

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.

Parmi les changements dans la spécification HTTP/1.1, on peut noter l'interdiction de l'utilisation isolée du symbole de retour chariot (CR) en dehors du corps du contenu, c'est-à-dire que dans les éléments du protocole, le symbole CR ne peut être utilisé qu'en combinaison avec le symbole de saut de ligne (CRLF). L'algorithme de composition des requêtes chunkées a été amélioré pour simplifier la séparation des champs joints et de la section des en-têtes. Des recommandations ont été ajoutées pour le traitement de contenus ambiguës afin de bloquer les attaques de type « HTTP Request Smuggling », permettant de s'immiscer dans le contenu des requêtes d'autres utilisateurs dans le flux entre le frontend et le backend.

La mise à jour de la spécification HTTP/2.0 définit clairement le support de TLS 1.3. Le schéma de définition des priorités et les champs associés dans les en-têtes ont été relégués dans la catégorie obsolète. Le mécanisme de mise à jour des connexions de HTTP/1.1, qui n'a pas été largement adopté, a été déclaré obsolète. Les exigences relatives à la vérification des noms de champs et des valeurs ont été réduites. Certains types de trames et paramètres auparavant réservés sont proposés pour une utilisation. Les champs d'en-tête interdits liés à la connexion ont été définis plus précisément.

Source : opennet.ru