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 2013-06-24 11:36:21, par Stéphane le calme, Chroniqueur Actualités
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 ?
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 ?
-
gangsoleilModérateurUne 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.le 25/06/2013 à 9:32
-
FirwenMembre expérimenté
Envoyé par Gecko
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.le 31/07/2013 à 13:15 -
gangsoleilModérateurPour 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...le 27/05/2014 à 16:08 -
thelvinModérateurBen 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.le 27/05/2014 à 16:52 -
SylvainPVRédacteur/ModérateurTout 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.le 27/05/2014 à 15:39 -
gangsoleilModérateurSi 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".
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.le 02/06/2014 à 13:44 -
SylvainPVRédacteur/ModérateurJe 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é ?le 24/06/2013 à 14:03
-
WashmidMembre avertiSi 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.le 24/06/2013 à 14:26 -
Paul TOTHExpert éminent séniorle 24/06/2013 à 14:29
-
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.le 24/06/2013 à 14:51