Discussion :

[Bruno]

HTTP/3 est rapide, et c'est un atout majeur pour les performances du web,
Google.com serait entièrement servi en HTTP/3 pour les navigateurs modernes

Les équipes de recherche ont travaillé en étroite collaboration pour faire passer HTTP/3 et QUIC de normes naissantes à des technologies largement adoptées pour améliorer le Web. HTTP/3 est la troisième version du protocole HTTP (Hypertext Transfer Protocol), anciennement HTTP over-QUIC. QUIC (Quick UDP Internet Connections) a été initialement développé par Google et est le successeur de HTTP/2. Des entreprises comme Google et Facebook utilisent déjà QUIC pour accélérer le Web.

La première version officielle de HTTP (Hypertext Transfer Protocol 1.0) a été finalisée en 1996. Certains problèmes pratiques et certaines parties de la norme nécessitant une mise à jour, HTTP/1.1 a été publié un an plus tard, en 1997. Cependant, HTTP/1.0 ne prend pas suffisamment en compte les effets des proxies hiérarchiques, de la mise en cache, du besoin de connexions persistantes et des hôtes virtuels. En outre, la prolifération d'applications incomplètement implémentées se réclamant de HTTP/1.0 a nécessité un changement de version du protocole afin que deux applications communicantes puissent déterminer les véritables capacités de l'autre.

Il faudra attendre encore 18 ans avant qu'une nouvelle version de HTTP ne soit publiée. En 2015, et avec beaucoup de fanfare, la RFC 7540 a normalisé HTTP/2 comme la prochaine version majeure du protocole. HTTP/2 a apporté de sérieuses améliorations avec des téléchargements non bloquants, des pipelines et les serveurs push qui ont aidé à surmonter certaines limitations du protocole TCP sous-jacent. Cela a permis de réduire au minimum le nombre de cycles de requêtes-réponses.

Multiplexage avec Hypertext Transfer Protocol

HTTP/2

Le multiplexage était le principal argument de vente de HTTP/2. Il a résolu les problèmes de blocage de tête de ligne au niveau des applications en adoptant un format binaire sur le fil qui permet le téléchargement multiplexé de fichiers. En d'autres termes, un client peut demander les 10 fichiers en même temps et les télécharger tous en parallèle sur une seule connexion TCP. Malheureusement, HTTP/2 souffre toujours d'un problème de blocage en tête de ligne, juste une couche plus bas. Le TCP lui-même devient le maillon faible de la chaîne. Tout flux de données qui perd un paquet doit attendre que ce paquet soit retransmis pour continuer.

Cependant, 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é provoque un blocage de toutes les transactions actives, que la transaction ait été ou non directement touchée par le paquet perdu. En fait, dans les environnements à forte perte de paquets, HTTP/1.1 est plus performant grâce aux multiples connexions TCP parallèles ouvertes par le navigateur.

HTTP/3 et QUIC

Entrez dans le monde de HTTP/3. La principale différence entre HTTP/2 et HTTP/3 est le protocole de transport qu'ils utilisent. Au lieu de TCP, HTTP/3 utilise un nouveau protocole appelé QUIC. QUIC est un protocole de transport général destiné à résoudre les problèmes de blocage de tête de ligne que HTTP/2 rencontre avec TCP. Il permet de créer une série de flux à état (similaire à TCP) sur UDP.

Le protocole de transport QUIC intègre le multiplexage de flux et le contrôle de 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.

Analyse comparative de HTTP/3

Pour voir la différence de performance de HTTP/3, Request metrics met en place un test de benchmarking. Request Metrics est un outil de suivi des performances des sites Web, simplifié pour les petites équipes.

Le HTML

Afin de se rapprocher le plus possible de l'utilisation réelle, la configuration du test de Request Metrics a consisté en trois scénarios : un petit site, un site à fort contenu (beaucoup d'images et un peu de JS) et une application à page unique (avec beaucoup de JS).

• Petit site
  
  • 10 fichiers JS de 2kb à 100kb
  • 10 images de 1 kb à 50 kb
  • Taille totale de la charge utile 600kb, 20 ressources bloquantes au total
  
  
• Site à fort contenu
  
  • 50 fichiers JS de 2 kb à 1 mb
  • 55 images d'une taille comprise entre 1 kb et 1 mb.
  • Taille totale de la charge utile : 10 Mo, 105 ressources au total
  
  
• Application à page unique
  
  • 85 fichiers JS de 2 kb à 1 mb
  • 30 images dont la taille varie de 1 kb à 50 kb.
  • Taille totale de la charge utile 15MB, 115 ressources au total
  
  

Pour le test, le navigateur a été automatisé pour demander la même page 20 fois de suite, en attendant 3 secondes après le chargement de la page pour lancer la demande suivante. La connexion Internet était de 200 Mbps. Aucune autre application n'était en cours d'exécution sur l'ordinateur au moment où les données ont été capturées. Voici les temps de réponse pour HTTP/2 par rapport à HTTP/3 lors de la visite de trois sites différents depuis le centre de données de New York :

HTTP/3 est :

• 200 ms plus rapide pour le petit site
• 325 ms plus rapide pour le site de contenu
• 300 ms plus rapide pour l'application à page unique

Le test de référence HTTP/1.1 a également été inclus afin de montrer à quel point HTTP/2 et HTTP/3 sont plus rapides, pour le site à fort contenu, les temps sont si lents qu'ils ne tiennent même pas entièrement sur le graphique.

L’augmentation de la vitesse est encore plus prononcée lorsque de plus grandes distances sur le réseau sont en jeu. HTTP/3 est :

• 600 ms plus rapide pour le petit site
• 1200 ms plus rapide pour le site de contenu
• 1000 ms plus rapide pour l'application à page unique

Pourquoi HTTP/3 est-il tellement plus rapide ?

Un véritable multiplexage

Le multiplexage sur HTTP/3 signifie qu'il n'y a pas de blocage de tête de ligne sur la pile. Lorsqu’un utilisateur demande des ressources à partir d'une zone géographique plus éloignée, le risque de perte de paquets et la nécessité pour TCP de retransmettre ces paquets sont beaucoup plus élevés.

HTTP/3 prend en charge les connexions O-RTT QUIC, qui réduisent le nombre d'allers-retours nécessaires pour établir une connexion TLS sécurisée avec le serveur. La fonction 0-RTT de QUIC permet à un client d'envoyer des données avant la fin de la prise de contact. Cela est possible en réutilisant les paramètres négociés lors d'une connexion précédente. Pour ce faire, le client doit se souvenir des paramètres critiques et fournir au serveur un ticket de session TLS qui lui permet de récupérer les mêmes informations.

Bien que le protocole soit actuellement à l'état de projet, il existe de nombreuses implémentations. NGINX disposerait d'un support expérimental et travaille à l'élaboration d'une version officielle de HTTP/3 dans un avenir proche. Les grands acteurs technologiques comme Google et Facebook diffusent déjà leur trafic via HTTP/3. Google.com est entièrement servi en HTTP/3 pour les navigateurs modernes. Pour les personnes qui restent coincées dans l'écosystème Windows, Windows Server 2022 devrait prendre en charge HTTP/3, avec quelques étapes plutôt ésotériques nécessaires pour l'activer.

Source : Request metrics

Et vous ?

Que pensez-vous du protocole http/3 ?

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

[Aiekick]

ca changera rien a la lourdeur du web, il vont utiliser le regain de puissance pour plus de tracking et de pubs... au bout du compte on en sera au meme stade

[JP CASSOU]

Tous les gains en termes de rapidité (débits Internet, latence) sont complètement absorbés par l'accroissement de la lourdeur des pages Web.
On se retrouve bien souvent devant un site dont l'utilisabilité est inférieure au service Minitel qu'il a remplacé.

En mai 2012, j'ai fait deux opérations d'achat de billet de train, respectivement sur le site Web et le service Minitel.

A votre avis, quelle a été la procédure la plus rapide ?

Site sncf.com: 7 minutes pour finaliser l'achat

Service Minitel 36 15 SNCF: Process terminé en 3 minutes.

Au travail, notre connexion Internet est complètement moisie (connexion fibre partagée par 200 agents), et internet est parfaitement inutilisable.

[barmic]

ca changera rien a la lourdeur du web, il vont utiliser le regain de puissance pour plus de tracking et de pubs... au bout du compte on en sera au meme stade

Ceux qui voudront être plus efficace le seront. Si tu regarde quick (le protocole qui est en dessous de http3) tu verra qu'il est très intéressant. J'attends avec impatience sont utilisation pour ssh (gestion des perte de connexion, multiplexage très intéressant pour utiliser le shell et faire du transfert de fichiers en même temps par exemple).

Tous les gains en termes de rapidité (débits Internet, latence) sont complètement absorbés par l'accroissement de la lourdeur des pages Web.
On se retrouve bien souvent devant un site dont l'utilisabilité est inférieure au service Minitel qu'il a remplacé.

J'en doute. Rien que pour lister les possibilités 25 lignes * 40 colonnes c'est pas très pratique surtout quand la plupart des écrans mettent plusieurs secondes pour s'afficher ligne par ligne.

En mai 2012, j'ai fait deux opérations d'achat de billet de train, respectivement sur le site Web et le service Minitel.

Il y a 10 ans donc.

A votre avis, quelle a été la procédure la plus rapide ?

Celle avec la quelle tu étais le plus à l'aise ?

Site sncf.com: 7 minutes pour finaliser l'achat

Service Minitel 36 15 SNCF: Process terminé en 3 minutes.

Pas le 3623 qui était 8 fois plus rapide ?
Bon le service est payant à la minute oups.
Bon l'achat te demande de donner ton numéro de carte (TLS ? Ah ah ! X25 se base sur "ben faut faire confiance au réseau")

Au travail, notre connexion Internet est complètement moisie (connexion fibre partagée par 200 agents), et internet est parfaitement inutilisable.

Et le minitel vous demanderais d'avoir 200 lignes distinctes...

Le minitel c'est rigolo. C'est un élément important de l'histoire des réseaux, mais c'est dommage de laisser la nostalgie nous convaincre que tout était mieux avant.

[Bruno]

HTTP/3 devient enfin une norme, il apporte un trafic plus rapide et plus de chiffrement,
avec prise en charge des connexions Internet rapides UDP (QUIC) révélées par Google

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

[redcurve]

On l'utilise depuis notre passage à dotnet 6, on a testé des scénarios type grpc/quic

[smarties]

Je viens de regardé et c'est supporté sur Firefox et activé par défaut à priori.

Il faut maintenant que je regarde si c'est simple à mettre en place avec nginx...