Plus de trois ans après sa première proposition, la troisième version majeure du protocole de transfert hypertexte, HTTP, a été adoptée comme norme par l'IETF (Internet Engineering Task Force).La sémantique HTTP est utilisée pour un large éventail de services sur Internet. Ces sémantiques ont été le plus souvent utilisées avec HTTP/1.1 et HTTP/2. HTTP/1.1 a été utilisé sur une variété de couches de transport et de session, tandis que HTTP/2 a été utilisé principalement avec TLS sur TCP. HTTP/3 supporte la même sémantique sur un nouveau protocole de transport : QUIC.
Comme souvent, l'adoption de HTTP/3 a devancé le processus officiel de normalisation. Bien qu'il n'ait été publié que cette semaine en tant que RFC 9114, HTTP/3 est déjà utilisé, ayant été progressivement mis en œuvre dans les principaux navigateurs depuis décembre 2019 (Apple Safari prend en charge le protocole, mais il est actuellement désactivé par défaut.)
Le principal changement apporté par HTTP/3 est sa prise en charge des connexions Internet rapides UDP (QUIC), que Google a révélée pour la première fois en 2013. Le protocole de transport QUIC possède plusieurs caractéristiques souhaitables dans un transport pour HTTP, telles que le multiplexage de flux, le contrôle de flux par flux et l'établissement de connexions à faible latence.
Comme l'explique la RFC 9114 : « Le protocole de transport QUIC possède plusieurs caractéristiques qui sont souhaitables dans un transport pour HTTP, comme le multiplexage de flux, le contrôle de flux par flux et l'établissement de connexions à faible latence. »
En plaçant le trafic web sur UDP au lieu du protocole de contrôle du transport (TCP), QUIC réduit la manipulation nécessaire pour établir une connexion, une caractéristique particulièrement importante sur les réseaux mobiles. QUIC suit également la pratique de longue date de l'IETF selon laquelle les nouvelles normes doivent chiffrer le trafic des utilisateurs autant que possible, un objectif de l'organisme depuis sa déclaration de 2014 selon laquelle « la surveillance omniprésente est une attaque ».
Versions antérieures de HTTP
HTTP/1.1 utilise des champs de texte délimités par des espaces blancs pour transmettre les messages HTTP. Bien que ces échanges soient lisibles par l'homme, l'utilisation d'espaces blancs pour le formatage des messages entraîne une complexité d'analyse et une tolérance excessive des variantes de comportement.
Comme HTTP/1.1 n'inclut pas de couche de multiplexage, plusieurs connexions TCP sont souvent utilisées pour traiter les demandes en parallèle. Cependant, cela a un impact négatif sur le contrôle de la congestion et l'efficacité du réseau, puisque TCP ne partage pas le contrôle de la congestion entre plusieurs connexions.
HTTP/2 a introduit une couche de structuration et de multiplexage binaire pour améliorer la latence sans modifier la couche transport. Toutefois, comme la nature parallèle du multiplexage de HTTP/2 n'est pas visible pour les mécanismes de récupération des pertes de TCP, un paquet perdu ou réordonné entraîne un blocage de toutes les transactions actives, que la transaction ait été ou non directement touchée par le paquet perdu.
Délégation à QUIC
Le protocole de transport QUIC intègre le multiplexage de flux et le contrôle de flux par flux, similaire à celui fourni par la couche de trame HTTP/2. En assurant la fiabilité au niveau du flux et le contrôle de la congestion sur l'ensemble de la connexion, QUIC a la capacité d'améliorer les performances de HTTP par rapport à un mappage TCP. QUIC intègre également TLS 1.3 ([TLS]) au niveau de la couche transport, offrant une confidentialité et une intégrité comparables à l'exécution de TLS sur TCP, avec la latence d'établissement de connexion améliorée de TCP Fast Open (TFO).
La RFC 9114 définit HTTP/3 : un mappage de la sémantique HTTP sur le protocole de transport QUIC, en s'inspirant largement de la conception de HTTP/2. HTTP/3 s'appuie sur QUIC pour assurer la protection de la confidentialité et de l'intégrité des données, l'authentification des pairs et la livraison fiable, dans l'ordre et par flux. Tout en déléguant les questions de durée de vie des flux et de contrôle des flux à QUIC, un framework binaire similaire au framework HTTP/2 est utilisé sur chaque flux. Certaines caractéristiques de HTTP/2 sont subsumées par QUIC, tandis que d'autres caractéristiques sont implémentées au sommet de QUIC.
Présentation du protocole HTTP/3
HTTP/3 fournit un transport pour la sémantique HTTP en utilisant le protocole de transport QUIC et une couche d'encadrement interne similaire à HTTP/2. Dès qu'un client sait qu'un serveur HTTP/3 existe à un certain point d'extrémité, il ouvre une connexion QUIC. QUIC assure la négociation du protocole, le multiplexage basé sur le flux et le contrôle du flux.
Au sein de chaque flux, l'unité de base de la communication HTTP/3 est une trame. Chaque type de trame a un objectif différent. Par exemple, les trames HEADERS et DATA constituent la base des demandes et des réponses HTTP. Les trames qui s'appliquent à l'ensemble de la connexion sont transportées sur un flux de contrôle dédié. Le multiplexage des demandes est effectué à l'aide de l'abstraction de flux QUIC. Chaque paire demande-réponse consomme un seul flux QUIC. Les flux sont indépendants les uns des autres, de sorte qu'un flux qui est bloqué ou subit une perte de paquets n'empêche pas la progression des autres flux.
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
