L'IETF (Internet Engineering Task Force), responsable du développement des protocoles et de l'architecture Internet, a achevé la formation d'une RFC pour le protocole HTTP/3.0 et publié les spécifications associées sous les identifiants RFC 9114 (protocole) et RFC 9204 ( Technologie de compression d'en-tête QPACK pour HTTP/3) . La spécification HTTP/3.0 a reçu le statut de « Proposed Standard », après quoi les travaux commenceront pour donner à la RFC le statut de projet de norme (Draft Standard), ce qui signifie en réalité une stabilisation complète du protocole et la prise en compte de tous les commentaires formulés. Parallèlement, des versions mises à jour des spécifications des protocoles HTTP/1.1 (RFC 9112) et HTTP/2.0 (RFC 9113) ont é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 mise en cache HTTP. (RFC9111).
Le protocole HTTP/3 définit l'utilisation du protocole QUIC (Quick UDP Internet Connections) comme transport pour HTTP/2. 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. Le protocole a été créé en 2013 par Google comme alternative à la combinaison TCP+TLS pour le Web, résolvant les problèmes liés aux longs temps d'établissement de connexion et de négociation dans TCP et éliminant les retards en cas de perte de paquets lors du transfert de données.
Actuellement, la prise en charge de QUIC et HTTP/3.0 est déjà implémentée dans tous les navigateurs Web populaires (dans Chrome, Firefox et Edge, la prise en charge de HTTP/3 est activée par défaut, et dans Safari, elle nécessite le paramètre « Avancé > Fonctionnalités expérimentales > HTTP/3 » à activer). Côté serveur, des implémentations HTTP/3 sont disponibles pour nginx (dans une branche distincte et sous la forme d'un module distinct), Caddy, IIS et LiteSpeed. La prise en charge HTTP/3 est également fournie par le réseau de diffusion de contenu Cloudflare.
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.
Parmi les changements dans la spécification HTTP/1.1, on peut noter l'interdiction de l'utilisation isolée du caractère retour chariot (CR) en dehors du corps du contenu, c'est-à-dire Dans les éléments de protocole, le caractère CR ne peut être utilisé qu'en conjonction avec le caractère de saut de ligne (CRLF). L'algorithme de présentation des requêtes fragmentées a été amélioré pour simplifier la séparation des champs et des sections attachés avec des en-têtes. Ajout de recommandations pour gérer le contenu ambigu afin de bloquer les attaques « HTTP Request Smuggling », qui nous permettent de nous insérer dans le contenu des requêtes des autres utilisateurs dans le flux entre le frontend et le backend.
La mise à jour de la spécification HTTP/2.0 définit explicitement la prise en charge de TLS 1.3. Le schéma de priorisation et les champs d'en-tête associés sont obsolètes. Le mécanisme inutilisé de mise à jour de la connexion avec HTTP/1.1 a été déclaré obsolète. Les exigences de vérification des noms et des valeurs des champs ont été réduites. Certains types de trames et paramètres précédemment réservés sont proposés à l'utilisation. Les champs d'en-tête interdits liés à la connexion sont définis plus précisément.
Source: opennet.ru