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, 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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de SylvainPV SylvainPV
http://www.developpez.com
Expert Confirmé Sénior
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é ?
Avatar de Washmid Washmid
http://www.developpez.com
Membre actif
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.
Avatar de Paul TOTH Paul TOTH
http://www.developpez.com
Expert Confirmé Sénior
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 ?
Avatar de Enerian Enerian
http://www.developpez.com
Membre émérite
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.
Avatar de Paul TOTH Paul TOTH
http://www.developpez.com
Expert Confirmé Sénior
le 24/06/2013 17:32
après une lecture en diagonale du PDF je retiens:
- compression, et ce n'est pas une option, car quand c'est une option, ce n'est pas utilisé ou il faut une première requête pour savoir si ça l'est.
- l'idée de pouvoir mixer les flux (aussi bien les requêtes que les réponses) c'est pour permettre d'optimiser le temps d'activation du réseau et donc la durée de vie des batteries. Pas besoin d'attendre la réponse à la première requête pour lancer le suivante, on minimise la fenêtre d'utilisation du réseau en réduisant les temps de latence dans le protocole.
Avatar de SylvainPV SylvainPV
http://www.developpez.com
Expert Confirmé Sénior
le 24/06/2013 19:10
Okay donc par exemple, si un document HTML contient 3 stylesheets et 4 scripts, on serait capable de charger ces 7 éléments en une seule requête HTTP multiplexée. C'est bien ça ? Dans tous les cas les scripts devraient être exécutés dans leur ordre de déclaration, donc ça ne devrait rien changer.
Avatar de gangsoleil gangsoleil
http://www.developpez.com
Modérateur
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.
Avatar de Stéphane le calme Stéphane le calme
http://www.developpez.com
Chroniqueur Actualités
le 31/07/2013 5:48
Microsoft présente le premier prototype du serveur HTTP 2.0
basé sur Katana Server

Mise à jour du 31/07/13

Microsoft a rendu public un prototype du serveur HTTP 2.0 basé sur la version 4 de Katana Server, la pile web open source basée sur C#. Ce prototype devrait supporter la compression d'en-tête, le multiplexage de flux ainsi que ALPN (Application Layer Protocol Negotiation), le mécanisme de mise à jour de HTTP et les connexions directes HTTP 2.0.

Ce prototype est le premier d'une série d'expérimentations de l'implémentation de HTTP 2.0. « Nous travaillons sur les propositions dans le code (…) nous sommes susceptibles d'avoir plusieurs prototypes qui affineront progressivement l'approche que nous avons adoptée » explique Mark Nottingham, président de l'IETF HTTPBIS.

L'idée est d'améliorer les performances en supportant le multiplexage et en réduisant le temps de latence de la couche application.

Pour permettre à la communauté de tester cette implémentation de HTTP 2.0, deux adresses ont été identifiées. Il s'agit de http://http2katanatest.cloudapp.net:8080/ et https://http2katanatest.cloudapp.net:8443/. Ces liens tests sont donnés uniquement pour répondre aux navigateurs HTTP 2.0 et ne sont donc pas censés être accessibles après un évènement « clic ».

Télécharger le code sur GitHub.

Source : Microsoft Open Technologies

Et vous ?

Avez-vous déjà essayé Katana Server ? Qu'en pensez-vous ?
Avatar de Gecko Gecko
http://www.developpez.com
Membre chevronné
le 31/07/2013 11:19
Citation Envoyé par Stéphane le calme  Voir le message
Il faut aussi noter que bien que SPDY n'autorise que les connexions chiffrées, pour HTTP 2.0 elles seront facultatives

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...
Avatar de Firwen Firwen
http://www.developpez.com
Membre Expert
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.
Offres d'emploi IT
Chef de Projet ERP H/F
CDI
Otteo - Picardie - Beauvais
Parue le 11/10/2014
Ingénieur Logiciel Embarqué H/F
CDI
Sogeti HT - Région SSE - Midi Pyrénées - toulouse (31000)
Parue le 24/09/2014
Analyste Programmeur h/f
CDI
Kobaltt - Pays de la Loire - La Roche sur Yon (85000)
Parue le 16/10/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula