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 
Envoyé par Aiekick
