HTTP/2 promet d’accélérer votre expérience web

Internet

Liste de tags

Aujourd’hui est un grand jour. La prochaine version majeure de HTTP, le protocole au cœur du Web qui est demeuré inchangé en 16 ans, a été officiellement finalisée.

En effet, l’actuelle norme qui vous permet de lire ces lignes n’a pas subi de révision majeure depuis 1999, au moment où la version 1.1 a été publiée.

HTTP/2 nécessitera beaucoup moins de connexions, ce qui devrait réduire considérablement la charge de travail actuellement imposée sur les serveurs et réseaux.

C’est Mark Nottingham, président du groupe de travail de HTTP de l’Internet Engineering Task Force (IETF), qui en a fait l’annonce aujourd’hui. La prochaine étape avant que HTTP/2 ne devienne une norme est de passer par le processus RFC de l’IETF afin d’en rédiger la version définitive.

Fondamentalement, le nouveau protocole emploie le même API que HTTP, mais permet aux développeurs d’exploiter une série de nouvelles fonctions. Au menu des bénéfices qu’apportera HTTP/2, il est question d’accélérer le chargement des pages, de maintenir plus longuement les connexions, d’accélérer la réception des éléments grâce au multiplexage des requêtes, et de permettre aux serveurs de distribuer les données par sa propre initiative (le concept du server push).

HTTP/2 nécessitera aussi beaucoup moins de connexions, ce qui devrait réduire considérablement la charge de travail actuellement imposée sur les serveurs et réseaux.

Cette nouvelle version de HTTP est basée sur le protocole SPDY de Google, aujourd’hui utilisé par certaines technologies pour gérer le trafic afin d’améliorer le temps de latence et la sécurité. Google a d’ailleurs récemment annoncé que le HTTP/2 sera bientôt implanté dans Chrome.

Les développeurs curieux d’essayer HTTP/2 avant tout le monde peuvent déjà le faire sous Firefox et Chrome, en téléchargeant des serveurs conçus pour effectuer leurs tests. Rendez-vous dans la FAQ de HTTP/2 afin de connaître la démarche à suivre.

  • Steve Rodrigue

    Pour écouter sur le sujet… Le dernier épisode du Security Now y est consacré: http://pca.st/p7yv

  • xfinity

    J’ai du mal à percevoir la réelle avancée que ce changement de protocole apportera.
    En effet, ici, je suis en haut débit (environ 100 Mb/s) ce qui m’apporte un confort de chargement de page sans réelle attente…

    Mais je ne suis pas un technophile. Ceci explique vraisemblablement mon incompréhension.

    • rodrigo89

      Bonjour,
      La loi sera inapplicable. En effet, il faudra definir ce qui est acceptable comme duree de vie. Pour une voiture, par exemple, que les constructeur produise pour 8 a 10 ans de vie minimum: 100.000km ou 100.000.000km? Le prix du vehicule sera multiplie par 1000. L’obsolescence et par definition, toujours programmee, en fonction de l’equilibre et l’interet economique. En effet, si un constructeur se met a faire des voitures pour 40 ans, l’entreprise ferme car ne dispose plus de marche de remplacement. Vous allez dire que les voitures (ou les autres produits) evoluent. C’est vrai, mais les technologies enbarquees dans 15 ans existent deja. Elles sont juste couteuse et seront mises en service un peu plus tard pour pousser le consommateur a changer; toujours une sorte d’obsolescence programmee. Si on applique cette regle a Apple, le constat sera le meme.

      • https://branchez-vous.com/ Laurent LaSalle

        Vous me rassurez, j’avais vraiment peur avant la publication de cet article que les commentaires dérapes sur un autre sujet complètement. #Voyons

        • xfinity

          #ironique !
          Je ne digresserai plus, promis !

    • omega

      La principale différence, c’est que si tu vas sur un site web et que tu demandes une page dont le poids est faible, remplis de petites images et de scripts de petites tailles, ton navigateur va passer plus de temps à demander les fichiers et attendre que le serveur commence à les envoyer.
      C’est sur, pour le consommateur final, la différence ne se verra pas sur des grosses vidéos, sur un serveur peu fréquenté ou si le serveur (et les routeurs intermédiaires, et quelques autres matériels) est boosté aux hormones. Par contre pour ceux qui gèrent des gros sites, ceux qui ont une connexion dont le ping est très long (temps que met une donnée pour faire l’allé retour) et les fournisseurs d’accès, ça va faire une grosse différence.

      A noter que pour les logiciels de type messagerie instantané et jeux en ligne il existe déjà un certain nombre de moyen d’obtenir le même résultat qu’avec l’http2 et ceux même en utilisant des serveurs à la norme http1.1. Mais c’est un autre débat.

      • Steve Rodrigue

        Beaucoup d’applications de communications directes utilisent UDP plutôt que TCP pour les flux en continu (streaming audio/vidéo). Sinon, les applications qui n’envoient que de petits messages n’ont pas à être optimisée en TCP pour bien performer. Par exemple, un tweet est contenu dans 1 paquets. Donc, même avec le handshaking TCP on ne comptera que 5-6 paquets dans tout l’échange.

        Sur le web, avec des pages qui contiennent des dizaines d’éléments, on multiplie le handshaking, le nombre de paquet est décuplé, etc…

    • https://branchez-vous.com/ Laurent LaSalle

      En fait, il s’agit essentiellement d’optimiser progressivement les serveurs et le réseau à l’échelle planétaire. Dans votre cas, même si vous payez pour du 100 Mbit/s, ce n’est que la vitesse maximale théorique à laquelle les données vous sont transmises. Avec le HTTP/2, vous serez susceptible d’atteindre cette vitesse plus souvent.

      • xfinity

        Effectivement je n’atteint jamais ce niveau, même si je m’en approche de façon régulière. Je suis raccordé à ce que nous appelons ici, de la fibre (fttb). Un abonnement su^érieur me eprmettrait d’atteindre du 200, et même depuis quelques semaines, du 800 !

    • Steve Rodrigue

      Pour bien comprendre, il faut vraiment comprendre comme le TCP fonctionne, comment les échanges de messages en HTTP fonctionnent…

      Prenez le temps d’écouter la baladodiffusion que j’ai mis en lien (voir mon autre commentaire). C’est en anglais, mais si vous avez un minimum de connaissance en réseautique/programmation, vous devriez comprendre tout les avantages et les « prouesses » de SPDY rebaptisé HTTP/2. C’est de l’excellent travail avec beaucoup de réflexion et des optimisations étonnantes!

      Et pour ce qui est du débit, même si vous avez un lien 100 mbps, il peut être très mal utilisé si les protocoles sont trop verbeux, si la « stack TCP » n’est pas bien optimisé ou configuré et aussi si on ajoute de la distance/latence entre les 2 ordinateurs qui se parlent… C’est un monde en soi!

      • xfinity

        Merci du lien.
        Mais je n’ai pas les connaissances techniques nécessaires.
        Qui plus est, en bon français, je ne maîtrise pas aussi bien la langue de Shakespeare aussi bien que vous, amis québécois !

  • Steve C

    Revoir le multiplexage , ce n’est pas peu dire …. ça serait le strict minimum … le multiplexage du HHTP/1.1 n’a de multiplex que le nom …..

  • Sara Houle

    Pssst… « qui vous permet de lire ces lignes… »

    Autrement, excellente vulgarisation! Merci!

  • arnaudzieba

    Merci pour l’info. Le plus intéressant là-dedans me semble être le multiplexage, ce qui va d’ailleurs chambouler un tant soit peu la programmation AJAX et dérivés.
    Même si c’est conceptuellement compliqué quoique théoriquement possible, y a-t-il quelque chose sur les sessions ? C’est en effet une couche OSI (une idée perdue quelque part dans les nuages numériques), pas TCP/IP.
    Et puis reste à savoir comment va se faire le passage vers cette nouvelle version, autrement que comme l’arlésienne de l’IPv6 (je parle des faits, pas des décisions) ou, soyons fous, de Perl 6 (tiens, encore un « 6″).
    Arnaud Ziéba

    • Marc Boivin

      Contrairement à l’IPv6 qui demande un changement fondamental des patterns de routages, nating et d’adressage, le HTTP2 peut être implémentée en auto-négociation avec le serveur web. Un ancien client serait servi du HTTP1.1 de manière transparente.

      Étant donnée que c’est le client qui initie la transaction c’est plus que viable comme solution.

      Pour le multiplexage, c’est fait pour être encapsulé dans la norme TCP/IP et non pas une tentative de redéfinir les couches OSI connexes.

      La couche AJAX est déjà pas mal abstraite aujourd’hui. l’impact du changement sera surement sur les requêtes asynchrone qui demanderont de valider si le stream est complété. Je le vois comme un avantage. De plus, les librairies pourront abstraire le changement pour le code legacy et seulement exposer aux applications modernes le concept de streaming.

      • arnaudzieba

        Merci Marc pour ces précisions et compléments.