Discussion :

[Stéphane le calme]

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

[SylvainPV]

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

[Washmid]

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.

[Paul TOTH]

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 ?

[Invité]

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.

[Paul TOTH]

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.

[SylvainPV]

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.

[gangsoleil]

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.

[Stéphane le calme]

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 ?

[Gecko]

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...

[Firwen]

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.

[Gecko]

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.

Tu m'a vu parler de la NSA? Je parle de la sécurité générale des usagers lambda qui ne savent pas faire la différence entre les flux classiques et chiffré.

Ensuite si je critique c'est parce qu'il serai temps que les choses tournent en faveur de la protection de ces utilisateurs au lieu d'uniquement s'axer sur le porte-feuille des sociétés.

Et si le TLS avait été actif par défaut HTTP 2.0 aurait certes été plus long à émerger mais certainement pas banni, les sociétés auraient cherchées à perfectionner le rendement de leur produits avant de le proposer et ça ça aurait pu faire naître de nouvelles techno plus performantes.

Pour moi une contrainte comme celle-ci n'a pas que des mauvais côté.

[pmithrandir]

POur que le HTTP2.0 soit mis en place, il faut que les acteurs du marché puisse s'y retrouver facilement.

En général, les sites ayant besoin de sécurité le sont. Pour les autres, on doit pour moi laisser la choix.

Rien que du coté du dev, un protocole chiffré qui demande de créer des certificat de sécurité, c'est fastidieux pour rien.
En interne, un intranet sans login / password, des pages statiques d'informations, etc... tout cela n'a pas besoin de sécurité, donc pourquoi perdre du temps a la mettre en place ?
Mettre en place des serveurs sans sécu est déjà bien assez fastidieux sans vouloir en ajouter pour rien.

[Hinault Romaric]

HTTP 2.0 serait bloqué par l’intégration de SPDY de Google
Un ingénieur de FreeBSD traite le projet de « fiasco »et demande son abandon au profit de HTTP 3.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

[singman]

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.

[pcdwarf]

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..."

[TiranusKBX]

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

[Hinault Romaric]

HTTP 2.0 : le développement du protocole finalisé
16 ans après la sortie de HTTP 1.1

Après moult tracasseries et reports, le nouveau protocole de transfert du Web HTTP 2.0 (Hypertext Transfer Protocol) a été approuvé de façon formelle par l’IESG (Internet Engineering Steering Group), un groupe de l’IETF (Internet Engineering Task Force), en charge de la validation des aspects techniques d’un projet en cours de normalisation.

L’information a été annoncée par Mark Nottingham, président du groupe de travail de l’IETF sur HTTP, dans un billet de blog. Par cette annonce, le projet franchit un cap important de son cycle de normalisation. En effet, il s’agit de la finalisation des travaux de développement de la prochaine génération du protocole Web.

Avant sa publication comme un standard finalisé, la spécification va encore passer par une dernière formalité : le processus de rédaction. Cette étape qui permettra de définir la documentation et les processus éditoriaux a été ouverte par le responsable du projet.

HTTP 2.0, viendra remplacer la dernière mise à jour du protocole HTTP 1.1, dont l’âge (la spécification avait été lancée en 1999) ne permet plus de répondre comme il se doit aux besoins du Web, qui est passé des simples pages sans trop de contenu à une véritable plateforme utilisée pour la diffusion du contenu multimédia, des applications, etc..

HTTP/2 promet de réduire le considérablement le temps de chargement des pages. Il repose en grande partie sur le protocole SPDY, développé par Google et soumis à l’IETF en 2012, dont l’atout principal est le multiplexage. En effet, 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.

HTTP 2.0 renforce également la sécurité. Le protocole supporte mieux le chiffrement (notamment le chiffrement avec TLS), ce qui permettra de rendre le Web plus sûr pour les internautes, tout en limitant l’espionnage de masse des organismes comme la NSA.

En ce qui concerne les développeurs, HTTP/2 repose sur les mêmes API que HTTP avec lesquels ils sont familiers. Mais, il propose cependant en bonus de nouvelles fonctionnalités que ceux-ci peuvent utiliser.

La normalisation de HTTP 2.0 ne s’est pas faite sans heurts entre les membres du groupe de travail de l’IETF, suite à des difficultés techniques rencontrées. Mark Nottingham avait appelé à une finalisation rapide du protocole, ce qui sonnait pour certains participants, comme un aveu d’échec, car plusieurs questions fondamentales n’avaient pas encore été résolues.

La reprise des fondamentaux de SPDY dans HTTP 2.0 a poussé Google a abandonné le support de son protocole dans son navigateur Chrome, qui prendra uniquement en charge le nouveau standard d’ici 2016.

Source : Billet de blog de Mark Nottingham

[Invité]

Magnifique résultat de notre serveur x1.82 !!!!
http://http2.httptwo.com/analysis/status/84fc9e12dc2703