récemment le IETF (Internet Engineering Task Force), qui développe les protocoles et l'architecture d'Internet, dévoilé les nouvelles qui finalisé la formation de la RFC pour le protocole HTTP/3.0 et publié les spécifications associées sous les identifiants RFC 9114 et RFC 9204.
La spécification HTTP/3.0 a reçu le statut de "Norme proposée", après quoi commenceront les travaux pour donner à la RFC le statut de projet de norme (Draft Standard), ce qui signifie en fait une stabilisation complète du protocole et la prise en compte de tous les commentaires formulés.
Protocole HTTP/3 définit l'utilisation du protocole QUIC (Connexions Internet UDP rapides) comme transport pour HTTP/2. QUIC est un plugin du protocole UDP qui prend en charge le multiplexage de plusieurs connexions et fournit des méthodes de chiffrement équivalentes à TLS/SSL.
Le protocole a été créé en 2013 par Google comme alternative à TCP + TLS pour le Web, résolvant le problème de la longue configuration de la connexion et du temps de négociation dans TCP et éliminant les retards dus à la perte de paquets pendant le 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 sites Web populaires. Côté serveur, des implémentations de HTTP/3 sont disponibles pour nginx (dans une branche séparée et en tant que module séparé), Caddy , IIS et LiteSpeed. HTTP/3 est également pris en charge par le réseau de diffusion de contenu de Cloudflare.
Principales caractéristiques de QUIC :
- Haute sécurité, similaire à TLS (en fait, QUIC offre la possibilité d'utiliser TLS sur UDP)
- Contrôle de l'intégrité de la transmission pour éviter la perte de paquets
- La possibilité d'établir une connexion instantanément et d'assurer des délais minimaux entre l'envoi d'une demande et la réception d'une réponse (RTT, aller-retour)
- Utilisez un numéro de séquence différent lors de la retransmission d'un paquet, ce qui vous permet d'éviter toute ambiguïté lors de la détermination des paquets reçus et de vous débarrasser des délais d'attente
- La perte d'un paquet affecte uniquement la livraison du flux qui lui est associé et n'interrompt pas la livraison des données dans les flux transmis en parallèle sur la connexion en cours
- Outils de correction d'erreurs qui minimisent les retards dus à la retransmission des paquets perdus. Utilisation de codes spéciaux de correction d'erreurs au niveau des paquets pour réduire les situations nécessitant la retransmission des données de paquets perdues.
- Les limites des blocs cryptographiques sont alignées sur les limites des paquets QUIC, ce qui réduit l'impact de la perte de paquets sur le décodage du contenu des paquets suivants
- Aucun problème de blocage de la file d'attente TCP
- Prise en charge de l'identification de la connexion pour réduire le temps de reconnexion des clients mobiles
- Possibilité de connecter des mécanismes avancés de contrôle de surcharge de connexion
- Utilisez des techniques de prévision de la bande passante dans chaque direction pour garantir des taux de transfert de paquets optimaux, en évitant les conditions de congestion où les paquets sont perdus.
- Performances et gains de performances notables sur TCP. Pour les services vidéo comme YouTube, il a été démontré que QUIC réduit les opérations de mise en mémoire tampon vidéo de 30 %.
De plus, également au même moment, 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 (RFC 9111).
Des changements dans la spécification HTTP/1.1, vous pouvez remarquer l'interdiction de l'utilisation séparée du caractère de retour chariot (CR) en dehors du corps avec le contenu, c'est-à-dire que dans les éléments de protocole, le caractère CR ne peut être utilisé qu'avec le caractère de nouvelle ligne (CRLF).
El l'algorithme de mise en page des requêtes fragmentées a été amélioré pour simplifier la séparation des champs joints et des sections avec des en-têtes. Ajout de directives pour la gestion du contenu ambigu afin de bloquer les attaques de classe "HTTP Request Smuggling" qui peuvent empiéter sur le contenu des demandes d'autres utilisateurs dans le flux entre le frontend et le backend.
Une mise à jour du cahier des charges HTTP/2.0 définit explicitement la prise en charge de TLS 1.3, schéma de priorisation obsolète et champs d'en-tête associés et mécanisme de mise à jour obsolète La connexion HTTP/1.1 est obsolète.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans la lien suivant