IdentifiantMot de passe
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 !

Les tests d'interopérabilités sur HTTP 2.0 bientôt amorcés
La navigation internet sera plus rapide grâce au multiplexage

Le , par Stéphane le calme
24 commentaires

48PARTAGES

19  0 
Le web est susceptible de changer fondamentalement bientôt. L'IETF (Internet Engineering Task Force) prépare la version 2.0 du protocole HTTP, a expliqué Mark Nottingham qui dirige actuellement l'équipe d'IETF HTTPBIS.

Pour sa première ébauche, HTTP 2.0 s'appuiera sur SPDY, le protocole développé par Google. Le responsable de l'équipe de travail prévoit toutefois des changements significatifs. Parmi eux, un nouvel algorithme de compression d'en-tête. Il faut aussi noter que bien que SPDY n'autorise que les connexions chiffrées, pour HTTP 2.0 elles seront facultatives.

HTTP 2.0 ambitionne d'apporter le multiplexage comme l'explique Martin Thomson, employé Microsoft et éditeur de HTTP 2.0 au sein de l'IETF « HTTP 2.0 fournira le multiplexage pour vous permettre d'envoyer simultanément autant de requêtes que vous le souhaitez. ». Ainsi, les codes JavaScript, CSS et HTML en plus des images pourront être transmis en une seule fois via une connexion HTTP. Par conséquent, le temps de téléchargement des pages internet pourrait se voir accéléré.

Le revers de la médaille est que si le navigateur utilise toute la bande passante pour télécharger des images qui ne sont pas censées être visibles, l'affichage du site web pourrait s'en voir retardé. Pour y remédier, la priorisation des demandes pourrait être une solution ; les développeurs web n'auraient alors qu'à préciser l'ordre de téléchargement des contenus. Google est allé plus loin en expérimentant la hiérarchisation multidimensionnelle pour permettre au navigateur de changer les priorités en fonction de l'onglet actuellement visible.

Thomson, a spécifié que les tests d'interopérabilités seront amorcés dans six semaines environ et devraient s'achever au printemps 2014.

Source : IETF, spécification SPDY (au format PDF)

Et vous ?

Qu'en pensez-vous ?

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

24 commentaires
Commenter Signaler un problème
gangsoleil
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 25/06/2013 à 9:32
Une nouvelle version d'HTTP, c'est bien, mais tant que les connexions utiliseront TCP/IP sur ethernet, c'est a dire des paquets de 1500 octets tout compris avec une phase de slow-start (je t'envoie un paquet, j'attends de savoir si tu l'as recu avant de t'en envoyer deux autres, puis j'attends l'aquitement de ces deux pour t'en envoyer 4, et ainsi de suite), on ne gagera pas fondamentalement.
6  0 
Firwen
Avatar de Firwen
Membre expérimenté https://www.developpez.com
Le 31/07/2013 à 13:15
Citation Envoyé par Gecko
Bah voilà, la seule contrainte qui vise à protéger un minimum les flux est flinguée

Donc au final un hypothétique gain en perf mais question sécurité nada, vraiment nawak...
Ca serait aussi bien d’arrêter de dire n'importe quoi.
Si les protocoles en non-chiffrés ont été inventé c'est pas juste pour donner plus facilement tes "pokes" facebook à la NSA.

Le chiffrement a un cout, spécialement serveur side, et spécialement à grande échelle.

Définir HTTP 2.0 avec TLS on par défaut, aurait juste signifier un BAN irrévocable de celui-ci pour toutes les opérations de HPC, Fast-IO, Grid, Cloud storage, etc... dans toutes les situations où l'overhead causé par TLS apporte bien plus de problèmes que d'avantages.

Et je ne parle même pas du caching ou des Proxys.

Je suis un fervent défenseur de la protection de la vie privé, mais ce n'est pas une raison pour sortir des anneries pareilles.
5  1 
gangsoleil
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 
thelvin
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 
SylvainPV
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 
gangsoleil
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 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 24/06/2013 à 14:03
Citation Envoyé par Stéphane le calme Voir le message

Le revers de la médaille est que si le navigateur utilise toute la bande passante pour télécharger des images qui ne sont pas censées être visibles, l'affichage du site web pourrait s'en voir retardé. Pour y remédier, la priorisation des demandes pourrait être une solution ; les développeurs web n'auraient alors qu'à préciser l'ordre de téléchargement des contenus. Google est allé plus loin en expérimentant la hiérarchisation multidimensionnelle pour permettre au navigateur de changer les priorités en fonction de l'onglet actuellement visible.
Je ne comprends pas, c'est du ressort de la couche présentation au-dessus ça. Comment un changement du protocole HTTP pourrait changer le comportement du chargement de médias ? A cause du nombre max de requêtes en parallèle qui a été augmenté ?
0  0 
Washmid
Avatar de Washmid
Membre averti https://www.developpez.com
Le 24/06/2013 à 14:26
Si j'ai bien compris c'est grâce à une seule requête HTTP ayant une réponse contenant plusieurs médias qui se "suivent", pas via plusieurs réponses en parallèle.

L’intérêt est précisément de ne pas dépendre d'une modification non normalisée de la couche du dessus (aussi bien client que serveur) pour ce genre d'optimisation.
0  0 
Paul TOTH
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 24/06/2013 à 14:29
Citation Envoyé par Washmid Voir le message
Si j'ai bien compris c'est grâce à une seule requête HTTP ayant une réponse contenant plusieurs médias qui se "suivent", pas via plusieurs réponses en parallèle.

L’intérêt est précisément de ne pas dépendre d'une modification non normalisée de la couche du dessus (aussi bien client que serveur) pour ce genre d'optimisation.
ben ça c'est déjà le cas en HTTP/1.1 en connection keep-Alive non ?
0  0 
Avatar de
https://www.developpez.com
Le 24/06/2013 à 14:51
Je pense qu'on peut faire une analogie avec les flux d'un fichier multimedia. Par exemple, dans un fichier vidéo, on va avoir plusieurs flux : le flux vidéo, une piste audio en français, une piste audio en anglais, une piste de sous-titre, etc...
Au final, tous ces flux sont entrelacé pour ne former plus qu'un flux dans le fichier. Ils sont ensuite dés-entrelacés lors de la lecture, puis chaque flux est décodé et interprété.

Là pour moi c'est un peu pareil : les contenus JS/CSS/images sont entrelacés, transitent ensemble au sein d'une même réponse et sont dés-entrelacés lors de leur arrivés pour être ensuite interprétés/affichés.

C'est du moins comme ça que je le comprend.
0  0 
Commenter Signaler un problème