IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bruno

174PARTAGES

11  0 
,
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 18/12/2021 à 23:15
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
2  0 
Avatar de barmic
Membre actif https://www.developpez.com
Le 23/12/2021 à 14:32
Citation Envoyé par Aiekick Voir le message
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).

Citation Envoyé par JP CASSOU Voir le message
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.

Citation Envoyé par JP CASSOU Voir le message
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.

Citation Envoyé par JP CASSOU Voir le message
A votre avis, quelle a été la procédure la plus rapide ?
Celle avec la quelle tu étais le plus à l'aise ?

Citation Envoyé par JP CASSOU Voir le message
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"

Citation Envoyé par JP CASSOU Voir le message
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.
0  0 
Avatar de JP CASSOU
Membre averti https://www.developpez.com
Le 20/12/2021 à 10:15
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.
1  2