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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Conception Web Discussion :

HTTP/3 est rapide, et c'est un atout majeur pour les performances du web


Sujet :

Conception Web

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    mai 2019
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2019
    Messages : 557
    Points : 8 878
    Points
    8 878
    Par défaut HTTP/3 est rapide, et c'est un atout majeur pour les performances du web
    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.

    Nom : http3coolB.png
Affichages : 19298
Taille : 44,5 Ko

    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 :

    Nom : Http3.jpg
Affichages : 3678
Taille : 26,5 Ko

    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.

    Nom : http3B1.png
Affichages : 3936
Taille : 91,5 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Homme Profil pro
    Consultant Ingenierie mécanique
    Inscrit en
    mars 2006
    Messages
    1 303
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant Ingenierie mécanique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2006
    Messages : 1 303
    Points : 3 007
    Points
    3 007
    Par défaut
    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

  3. #3
    Membre averti

    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2013
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : novembre 2013
    Messages : 207
    Points : 391
    Points
    391
    Billets dans le blog
    2
    Par défaut Inutile de déployer des technos 'rapides' pour arriver à une utilisabilité inférieure au Minitel
    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.

  4. #4
    Membre actif
    Homme Profil pro
    Développeur
    Inscrit en
    décembre 2008
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : décembre 2008
    Messages : 101
    Points : 255
    Points
    255
    Par défaut
    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.

Discussions similaires

  1. Réponses: 8
    Dernier message: 02/10/2021, 01h50
  2. Réponses: 59
    Dernier message: 07/04/2011, 10h32
  3. [CKEditor] [Sécurité] Est-ce un outil pour les membres ou pour l'admin ?
    Par Jonathan.b dans le forum Bibliothèques & Frameworks
    Réponses: 1
    Dernier message: 02/03/2010, 21h59
  4. fieldset est-il fortement conseille pour les formulaires ?
    Par keaton7 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 4
    Dernier message: 14/04/2009, 21h08
  5. Réponses: 3
    Dernier message: 21/01/2009, 23h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo