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 2.0 serait bloqué par l'ajout de SPDY de Google
Un ingénieur de FreeBSD traite le projet de « fiasco » et demande son abandon pour HTTP 3.0

Le , par Hinault Romaric

43PARTAGES

5  0 
Le groupe de travail de l'IETF (Internet Engineering Task Force) sur la version 2.0 de la norme HTTP (Hypertext Transfer Protocol) fait face à une crise qui pourrait entrainer un retard de la publication de celle-ci.

Pour rappel, HTTP 2.0 est conçu pour permettre aux navigateurs de charger des pages Web plus rapidement. La sortie de la version finale de la norme serait prévue pour la fin de cette année. Marcos Nottingham, le responsable du projet a présenté vendredi dernier sa feuille de route pour la sortie de la norme.

Cependant, le groupe de travail ferait face un nombre important de défis, qui n’ont pas manqué de créer des tensions entre les participants aux projets. « Chaque changement que nous faisons et surtout toutes les fonctionnalités que nous avons ajoutées ont le potentiel de retarder le projet », explique Marcos Nottingham.

La principale difficulté à laquelle serait confronté le groupe de travail de HTTP 2.0 serait liée au protocole SPDY de Google. Il faut noter que la norme est basée sur SPDY.

Le protocole SPDY a été dévoilé par Google en 2009, avant d’être proposé en fin 2012 à l’IETF. SPDY réduit le temps de chargement des pages en utilisant moins de connexions TCP pour transporter le contenu. Le protocole multiplexe les requêtes HTTP en une seule connexion TLS. Ainsi, une requête n’aura plus besoin d’attendre dans le navigateur à cause des limites de connexion. Il a été adopté par les navigateurs majeurs, notamment Chrome, Firefox et Internet Explorer.

Dans un message sur la liste de diffusion du groupe de travail, Poul-Henning Kamp, un développeur FreeBSD, n’y va pas par quatre chemins et demande que le travail soit abandonné. Celui-ci pointe essentiellement les problèmes que représente l’intégration de SPDY.

Poul-Henning Kamp s’est emporté suite au message de Marcos Nottingham invitant à finaliser la norme, passant pour celui-ci comme un aveu d’échec. Il demande que le processus de normalisation de HTTP 2.0 soit abandonné au profit d’un nouveau projet pour HTTP 3.0, estimant que cela a été un « véritable fiasco ». Au passage, celui-ci a reçu un « -1 » de Mike Belshe, développeur de SPDY et ancien employé de Google.

Actuellement, plusieurs membres du groupe de travail de l’IETF sont sceptiques par rapport à une publication de HTTP 2.0 cette année. « Je ne vois pas un projet qui est loin d’être prêt pour le dernier appel finir cette année », a affirmé Greg Wilkins, un développeur logiciel dans la liste de diffusion du projet. « Il existe actuellement dans le groupe de travail une confusion de niveau sur des questions fondamentales qui ne permettrait pas d’aboutir à une spécification claire. »

« Passer le dernier appel dans l’état actuel de la spécification est une folie », a affirmé James Snell, un ingénieur chez IBM. Un commentaire qui a été approuvé par un autre ingénieur d’Apple.

Le groupe de travail sur HTTP 2.0 se réunira le mois prochain à New York pour examiner les progrès accomplis et l’avenir de ce futur standard pour le Web. Il pourrait finaliser HTTP 2.0 afin de passer à HTTP 3.0 sur une base plus saine.

Source : Liste de diffusion du projet

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

Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 27/05/2014 à 16:08
Pour les normes, tu as deux mondes qui s'opposent.

D'un cote, le monde à la télécom, dans lequel on definit d'abord les normes, et une fois qu'elles sont viables et definies et plus encore, on commence a les implementer.
D'un autre cote, le monde "web", dont le W3C est un bel exemple, dans lequel on definit les normes a partir de ce qu'un ou plusieurs constructeurs ont commence a implementer et a vendre, en essayant de menager la chevre et le chou, et aussi les limaces, le vendeur d'engrais et la pluie et le soleil et ....

Alors oui, les normes telecom, c'est chiant, c'est lourd, c'est tout ce qu'on veut, mais ca fonctionne du feu de dieu. Les normes web, ca donne l'USB 1.0, avec l'USB 1.1 sorti en catastrophe, et des portables avec USB 3.0 vendus avant meme que la norme ne soit finie.

Ce qui est navrant, c'est que jusqu'a present, l'IETF etait loin de ce modele web...
4  0 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 27/05/2014 à 16:52
Citation Envoyé par SylvainPV Voir le message
Tout foutre à la poubelle et repartir de la page blanche ? C'est peut-être nécessaire, mais ça témoigne d'un problème de communication et de méthode.
Ben oui, ils sont partis d'une spécification tierce, élaborée avec bon esprit et offerte avec bienveillance, mais faite en dehors des circuits habituels et de leur vérification rigoureuse, expérimentée et universelle.

S'ils décident de ne pas le faire la prochaine fois, il n'y a aucune raison que ça suive le même chemin.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 27/05/2014 à 15:39
Tout foutre à la poubelle et repartir de la page blanche ? C'est peut-être nécessaire, mais ça témoigne d'un problème de communication et de méthode. Si ces problèmes ne sont pas résolus, leur HTTP 3.0 suivra le même chemin. Les éditeurs préparent chacun leurs petits plats chez eux puis se réunissent autour d'une table et veulent faire tout avaler aux autres. Pas étonnant que ça finisse en indigestion, surtout avec un plat aussi lourd à digérer que SPDY.

Je pense que ça aiderait si toutes les spécifications du Web suivaient un modèle incrémental et non versionné. On est en train d'arrêter de versionner les specs HTML/CSS/JS : HTML5 est devenu HTML, les navigateurs implémentent déjà des bouts d'ES6 et d'ES7 sans qu'ES5 soit complètement supporté... On pourrait faire de même avec HTTP, de la détection de fonctionnalité plutôt que des normes versionnées. Cela permettrait une progression plus rapide et moins abrupte, tout en donnant davantage de pouvoir aux éditeurs pour choisir et faire évoluer les fonctionnalités qui leur sont chères. Pour reprendre ma métaphore, on sert les hors d'oeuvre, on voit ce qui part le plus vite et ce qui reste dans les assiettes, et on en déduit le menu à servir la prochaine fois.
2  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 02/06/2014 à 13:44
Citation Envoyé par SylvainPV Voir le message
Le W3C a un mode de fonctionnement très strict, certains de leurs documents de spécifications sont encore au stade de Candidate Recommendation alors que cela fait des années qu'on les utilise sur des sites grands publics.
Si c'est utilisé alors que la norme n'est pas finie, c'est qu'il y a un problème : une fois que quelque chose commence à être utilisé, ça n'est plus normalisable, et donc tu peux mettre ta norme à la poubelle, car tu ne pourras plus rien changer face à un géant du logiciel qui te dira "nous on fait comme ça, et si t'es pas content, c'est pareil".

Citation Envoyé par SylvainPV Voir le message
La spécification HTML5 n'est toujours pas finalisée, et pourtant on en parlait déjà fin 2007 ! Qu'est-ce que ça aurait été si personne n'avait fait de site en HTML5 tant que le W3C n'avait pas mis son tampon "Recommendation" ? Quand je vois comment a évolué le Web ces 7 dernières années, je suis plutôt content que le Web suive cette méthodologie pour l'évolution des normes. Quitte à ce qu'il y ait quelques incidents de parcours, au moins on avance et à grande vitesse.
Peut-être que la normalisation n'est pas adaptée au web dans ce cas. Mais je reviens a ce que je disais au dessus : normer quelque chose d'utilisé, c'est absolument inutile.
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 29/05/2014 à 5:11
Ce n'est pas un très beau tableau du W3C que tu donnes là gangsoleil. Le W3C a un mode de fonctionnement très strict, certains de leurs documents de spécifications sont encore au stade de Candidate Recommendation alors que cela fait des années qu'on les utilise sur des sites grands publics. Ce sont les éditeurs qui veulent accélérer le mouvement, c'est d'ailleurs pour ça que la WHATWG a été créé et c'est pour ça qu'ils se prennent le chou régulièrement. Je dirais que le W3C est encore un des rares acteurs du web qui ait gardé un pied dans cette méthodologie télécom. Et ça ne leur donne pas forcément une bonne image auprès de la communauté de développeurs web qui ont tendance à foncer tête baissée sur les nouveautés dès lors qu'elles sont implémentées sur les trois navigateurs majoritaires. Je me rappelle encore quand ils ont viré le WebSQL, moi qui avait un service en prod qui fonctionnait avec...

Alors certes, c'est un gage de maturité et de fiabilité, mais c'est loin d'être l'idéal pour le business et l'innovation. La spécification HTML5 n'est toujours pas finalisée, et pourtant on en parlait déjà fin 2007 ! Qu'est-ce que ça aurait été si personne n'avait fait de site en HTML5 tant que le W3C n'avait pas mis son tampon "Recommendation" ? Quand je vois comment a évolué le Web ces 7 dernières années, je suis plutôt content que le Web suive cette méthodologie pour l'évolution des normes. Quitte à ce qu'il y ait quelques incidents de parcours, au moins on avance et à grande vitesse.
0  0 
Avatar de singman
Membre actif https://www.developpez.com
Le 30/05/2014 à 9:35
La remarque du developpeur FreeBSD est juste stupide : passer directement à HTTP 3.0 parce qu'ils n'arrivent pas a se mettre d'accord sur SPDY sur HTTP 2.0 ? Et ça sera quoi la prochaine fois ? Il ne trouve pas le café a son gout et il voudra passer au HTTP 4.0 ?
SPDY existe déjà, a prouvé qu'il était utile et performant. L'intégrer dans HTTP 2.0 est difficile c'est certain, mais est ce qu'il faut pour autant abandonner et passer à autre chose ? Je ne pense pas.
0  0 
Avatar de pcdwarf
Membre éclairé https://www.developpez.com
Le 09/08/2014 à 2:02
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..."
0  0 
Avatar de
https://www.developpez.com
Le 03/12/2015 à 22:55
Magnifique résultat de notre serveur x1.82 !!!!
http://http2.httptwo.com/analysis/st...84fc9e12dc2703
0  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 11/08/2014 à 11:53
Citation Envoyé par pcdwarf Voir le message
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...
à 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 latence
0  1