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.
Server push est un mode d'interaction introduit dans HTTP/2 qui permet à un serveur de pousser un échange de demande-réponse vers un client en attendant que ce dernier fasse la demande indiquée. Ce mode permet de compenser l'utilisation du réseau par un gain de latence potentiel. Plusieurs trames HTTP/3 sont utilisées pour gérer le push serveur, comme PUSH_PROMISE, MAX_PUSH_ID et CANCEL_PUSH.
Comme dans HTTP/2, les champs de demande et de réponse sont compressés pour la transmission. Comme HPACK ([HPACK]) repose sur la transmission dans l'ordre des sections de champs compressés (une garantie non fournie par QUIC), HTTP/3 remplace HPACK par QPACK. QPACK utilise des flux unidirectionnels distincts pour modifier et suivre l'état de la table de champs, tandis que les sections de champs codées font référence à l'état de la table sans la modifier.
Configuration et gestion des connexions
Découverte d'un point d'extrémité HTTP/3
Le protocole HTTP repose sur la notion de réponse faisant autorité : une réponse qui a été déterminée comme étant la réponse la plus appropriée pour cette requête, compte tenu de l'état de la ressource cible au moment de l'émission du message de réponse par (ou à la demande de) le serveur d'origine identifié dans l'URI cible.
Le schéma « https » associe l'autorité à la possession d'un certificat que le client considère comme digne de confiance pour l'hôte identifié par le composant d'autorité de l'URI. À la réception d'un certificat de serveur dans la poignée de main TLS, le client doit vérifier que le certificat est une correspondance acceptable pour le serveur d'origine de l'URI. Si le certificat ne peut pas être vérifié en ce qui concerne le serveur d'origine de l'URI, le client ne doit pas considérer que le serveur fait autorité pour cette origine.
Un client peut tenter d'accéder à une ressource avec un URI « https » en résolvant l'identificateur d'hôte en une adresse IP, en établissant une connexion QUIC à cette adresse sur le port indiqué (y compris la validation du certificat du serveur), et en envoyant un message de demande HTTP/3 ciblant l'URI au serveur sur cette connexion sécurisée. À moins qu'un autre mécanisme ne soit utilisé pour sélectionner HTTP/3, le jeton « h3 » est utilisé dans l'extension ALPN (Application-Layer Protocol Negotiation) pendant l’établissement d'une liaison TLS.
Les problèmes de connectivité (par exemple, le blocage d'UDP) peuvent entraîner l'échec de l'établissement d'une connexion QUIC ; dans ce cas, les clients devraient essayer d'utiliser des versions de HTTP basées sur TCP. Les serveurs peuvent servir HTTP/3 sur n'importe quel port UDP ; une annonce de service alternatif inclut toujours un port explicite, et les URI contiennent soit un port explicite, soit un port par défaut associé au schéma.
Établissement de la connexion
HTTP/3 s'appuie sur la version 1 de QUIC comme transport sous-jacent. La version 1 QUIC utilise TLS version 1.3 ou supérieure comme protocole d’établissement d'une liaison. Les clients HTTP/3 DOIVENT prendre en charge un mécanisme permettant d'indiquer l'hôte cible au serveur pendant la poignée de main TLS. Si le serveur est identifié par un nom de domaine ([DNS-TERMS]), les clients DOIVENT envoyer l'extension TLS SNI (Server Name Indication ; [RFC6066]), sauf si un autre mécanisme est utilisé pour indiquer l'hôte cible.
Les connexions QUIC sont établies comme décrit dans [QUIC-TRANSPORT]. Pendant l'établissement de la connexion, la prise en charge de HTTP/3 est indiquée par la sélection du jeton ALPN "h3" dans la poignée de main TLS. La prise en charge d'autres protocoles de la couche application PEUT être proposée dans la même liaison.
Alors que les options de niveau connexion relatives au protocole QUIC de base sont définies dans la poignée de main cryptographique initiale, les paramètres spécifiques à HTTP/3 sont transmis dans la trame SETTINGS. Après l'établissement de la connexion QUIC, une trame SETTINGS DOIT être envoyée par chaque point d'extrémité comme trame initiale de leur flux de contrôle HTTP respectif.
Réutilisation des connexions
Les connexions HTTP/3 sont persistantes sur plusieurs requêtes. Pour des performances optimales, il est prévu que les clients ne ferment les connexions que lorsqu'il est déterminé qu'aucune autre communication avec un serveur n'est nécessaire (par exemple, lorsqu'un utilisateur quitte une page Web particulière) ou lorsque le serveur ferme la connexion.
Une fois qu'une connexion à un point d'extrémité du serveur existe, cette connexion peut être réutilisée pour des demandes comportant plusieurs composants d'autorité URI différents. Pour utiliser une connexion existante pour une nouvelle origine, les clients doivent valider le certificat présenté par le serveur pour le nouveau serveur d'origine. Cela implique que les clients devront conserver le certificat du serveur et toute information supplémentaire nécessaire pour vérifier ce certificat ; les clients qui ne le font pas ne pourront pas réutiliser la connexion pour d'autres origines.
Si le certificat n'est pas acceptable en ce qui concerne la nouvelle origine pour une raison quelconque, la connexion ne doit pas être réutilisée et une nouvelle connexion doit être établie pour la nouvelle origine. Si la raison pour laquelle le certificat ne peut être vérifié peut s'appliquer à d'autres origines déjà associées à la connexion, le client devrait revalider le certificat du serveur pour ces origines. Par exemple, si la validation d'un certificat échoue parce que le certificat a expiré ou a été révoqué, cela peut être utilisé pour invalider toutes les autres origines pour lesquelles ce certificat a été utilisé pour établir l'autorité.
Les clients ne doivent pas ouvrir plus d'une connexion HTTP/3 vers une adresse IP et un port UDP donnés, l'adresse IP et le port pouvant être dérivés d'un URI, d'un service alternatif sélectionné ([ALTSVC]), d'un proxy configuré ou de la résolution de nom de l'un de ces éléments. Un client peut ouvrir plusieurs connexions HTTP/3 à la même adresse IP et au même port UDP en utilisant différentes configurations de transport ou TLS, mais DOIT éviter de créer plusieurs connexions avec la même configuration.
Les administrateurs systèmes sont encouragés à maintenir les connexions HTTP/3 ouvertes aussi longtemps que possible, mais sont autorisés à mettre fin aux connexions inactives si nécessaire. Lorsque l'un des points d'extrémité choisit de fermer la connexion HTTP/3, le point d'extrémité qui y met fin DEVRAIT d'abord envoyer une trame GOAWAY afin que les deux points d'extrémité puissent déterminer de manière fiable si les trames précédemment envoyées ont été traitées et achever ou terminer gracieusement toute tâche restante nécessaire.
Source : RFC Editor
Et vous ?
Que pensez-vous du protocole http/3 ? Quel commentaire faites-vous de l'adoption de ce protocole par l'IETF comme norme ? À votre avis, était-ce nécessaire d'adopter une nouvelle norme ?Voir aussi :
Vous avez entendu parler de HTTPS. Découvrez maintenant HTTPA : des services Web dans des environnements de confiance, avec Intel SGX, un outil qui fournit le chiffrement en mémoire Les dispositifs IoT grand public apparaissent sur les réseaux d'entreprises, ce qui pourrait conduire à de graves incidents de cybersécurité, selon Palo Alto Networks Internet : quels sont les inconvénients de l'utilisation de HTTPS ? Une étude décèle cinq faiblesses du protocole L'interception HTTPS du Kazakhstan cible déjà des domaines comme ceux de Facebook, Twitter et Google, soulevant des craintes chez les chercheurs 
