HTTP 2.0 atteint le stade du « dernier appel »
La norme atteindra bientôt une version finale malgré les divergences
Le 2014-08-05 22:02:25, par Hinault Romaric, Responsable .NET
Le protocole HTTP 2.0 (Hypertext Transfer Protocol) s’approche d’une version finale. Le groupe de travail de l'IETF (Internet Engineering Task Force) sur la norme vient de lancer le dernier appel pour le projet, invitant les personnes intéressées par celui-ci à exprimer leurs préoccupations avant la publication d’une spécification définitive.
Les soumissions sont possibles jusqu’au 1er septembre et après, le projet entrera dans une phase de tests d’interopérabilité avant la publication d’une RFC pendant l’automne.
Avec l’évolution du Web, les sites Web sont passés de simples pages sans trop de contenu à de véritables plateformes utilisées pour la diffusion du contenu multimédia, des applications, etc. Le temps de réponse est devenu une préoccupation pour plusieurs éditeurs de contenu sur le Web.
HTTP 2.0 viendra remplacer le vieillissant HTTP 1 et aura pour mission d’accélérer le trafic Web sur internet en réduisant le temps de chargement des pages. HTTP 2.0 s’appuie en grande partie sur le protocole SPDY et permettra d’envoyer simultanément tous les éléments d’une page Web grâce au multiplexage. HTTP 2.0 utilise également HPACK, un système qui permet la compression des entêtes HTTP pour réduire le volume de données
Pour rappel, le protocole SPDY a été développé par Google et est déjà utilisé par les navigateurs populaires, notamment Chrome, Firefox et Internet Explorer. Il réduit le temps de chargement des pages en utilisant moins de connexions TCP pour transporter le contenu.
L’utilisation de SPDY avait créé plusieurs divergences au sein du groupe de travail de l'IETF. Poul-Henning Kamp, un développeur de FreeBSD, était allé jusqu’à demander que le processus de normalisation de HTTP 2.0 soit abandonné au profit d’un nouveau projet pour HTTP 3.0, estimant que celui-ci a été un « véritable fiasco ».
À la suite de la publication du message pour le dernier appel, Greg Wilkins principal développeur du serveur open source Jetty, a exprimé dans un billet de blog ses préoccupations par rapport à cette norme. « Il y a beaucoup d’aspects intéressants dans la norme proposée, mais j’ai quelques profondes réserves quant à certains aspects mauvais et laids du protocole », a écrit celui-ci.
Malgré les différences d’opinions, le projet suit son bout de chemin et sera bientôt une spécification finalisée.
Source : Message de l'IETF
Les soumissions sont possibles jusqu’au 1er septembre et après, le projet entrera dans une phase de tests d’interopérabilité avant la publication d’une RFC pendant l’automne.
Avec l’évolution du Web, les sites Web sont passés de simples pages sans trop de contenu à de véritables plateformes utilisées pour la diffusion du contenu multimédia, des applications, etc. Le temps de réponse est devenu une préoccupation pour plusieurs éditeurs de contenu sur le Web.
HTTP 2.0 viendra remplacer le vieillissant HTTP 1 et aura pour mission d’accélérer le trafic Web sur internet en réduisant le temps de chargement des pages. HTTP 2.0 s’appuie en grande partie sur le protocole SPDY et permettra d’envoyer simultanément tous les éléments d’une page Web grâce au multiplexage. HTTP 2.0 utilise également HPACK, un système qui permet la compression des entêtes HTTP pour réduire le volume de données
Pour rappel, le protocole SPDY a été développé par Google et est déjà utilisé par les navigateurs populaires, notamment Chrome, Firefox et Internet Explorer. Il réduit le temps de chargement des pages en utilisant moins de connexions TCP pour transporter le contenu.
L’utilisation de SPDY avait créé plusieurs divergences au sein du groupe de travail de l'IETF. Poul-Henning Kamp, un développeur de FreeBSD, était allé jusqu’à demander que le processus de normalisation de HTTP 2.0 soit abandonné au profit d’un nouveau projet pour HTTP 3.0, estimant que celui-ci a été un « véritable fiasco ».
À la suite de la publication du message pour le dernier appel, Greg Wilkins principal développeur du serveur open source Jetty, a exprimé dans un billet de blog ses préoccupations par rapport à cette norme. « Il y a beaucoup d’aspects intéressants dans la norme proposée, mais j’ai quelques profondes réserves quant à certains aspects mauvais et laids du protocole », a écrit celui-ci.
Malgré les différences d’opinions, le projet suit son bout de chemin et sera bientôt une spécification finalisée.
Source : Message de l'IETF
-
pcdwarfMembre éprouvéBon alors l'idée est intéressante, mais en pratique, selon mon expérience, SPDY c'est quand même un peu du vent.
Déjà tout serveur web qui se respecte a une fonction nommée keepalive qui permet de réutiliser la même socket pour plusieurs requêtes HTTP consécutives. (sans multiplexage)
Mais même avec un keepalive à off, les temps cumulés d'établissement des socket TCP sur une page, c'est quoi ? 50ms ?
A peu près rien devant le temps de calcul des serveurs et de transfert des data....
Remettre en cause un truc qui marche quand même divinement bien et surtout aisément compréhensible par n'importe qui pour au mieux gagner quelque chose comme 2% de perf, moi, ça me laisse très dubitatif...
De mon point de vue, ce qui est pénible, c'est surtout que les browsers ne font jamais que 2 connexions simultanées par serveur...
ça c'est vraiment un point limitant...
A une époque ça a eu un sens et qualque part ça peut toujours en avoir pour éviter de tabasser les serveurs des petits sites. Mais en ce qui me concerne, j'aimerai bien pouvoir dire aux browsers de mes clients "allez y les gars, faites donc 30 sockets simultanées, on gère..."le 09/08/2014 à 2:02 -
Magnifique résultat de notre serveur x1.82 !!!!
http://http2.httptwo.com/analysis/st...84fc9e12dc2703le 03/12/2015 à 22:55 -
TiranusKBXExpert confirméà ce que je sache les navigateurs modernes ouvres 6 à 8 connections simultanées parts pages mais il faut bien avant tout charger le code html avant de connaitre les autres ressources à charger et c'est ça qui donne un temps de latencele 11/08/2014 à 11:53