Google Chrome passera du protocole SPDY à HTTP/2 d'ici quelques semaines

Google Chrome passera du protocole SPDY à HTTP/2 d’ici quelques semaines

Va donc, va donc chez Speedy... SPDY !

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

10/02/2015 4 minutes
63

Google Chrome passera du protocole SPDY à HTTP/2 d'ici quelques semaines

C’est officiel, Google annonce que pour les prochaines versions de Chrome il abandonnera son protocole web (expérimental) SPDY au profit du HTTP/2. Le changement n’est pourtant pas si grand puisque le successeur du HTTP est fondé sur le protocole de Google. Il est d'ailleurs censé être standardisé ce mois-ci.

Ce n’est qu’un au revoir... L’équipe de développement de Chromium a annoncé lundi sur son blog officiel l’abandon du protocole expérimental SPDY, qui sera remplacé par le successeur officiel du HTTP : le HTTP/2. Le but de ce dernier est de combler les manques du vénérable HTTP/1.1, standardisé en 1999, et notamment d’améliorer la vitesse, la sécurité des connexions et en finir avec le modèle d’une connexion par requête HTTP. Il est censé être standardisé ce mois de février par l’Internet Engineering Task Force (IETF), qui édicte les standards du Net.

HTTP/2 : le remplaçant du HTTP, basé sur le SPDY de Google

« Certaines fonctions-clé comme le multiplexage [le passage de plusieurs requêtes HTTP par une connexion unique], la priorisation [des éléments dans une page web] et la négociation du protocole sont des évolutions du travail effectué sur un protocole ouvert, mais non-standard, SPDY » expliquent les ingénieurs de Google. La future version officielle du protocole Web est une suite directe des travaux du groupe californien.

Google prévoit de déployer le support de HTTP/2 dans Chrome 40 (qui est actuellement en version stable) dans les prochaines semaines. Le protocole SPDY, lui, sera supprimé début 2016... soit cinq ans après son introduction dans Chrome 6, lancé fin 2010. Le groupe de Mountain View recommande logiquement aux développeurs qui ont déjà implémenté SPDY de l’abandonner au profit de HTTP/2. La version actuelle du protocole HTTP risque, elle, de rester de nombreuses années dans nos navigateurs, le temps que l’ensemble du Web s’adapte. Pour rappel, la préversion de HTTP/2 a été implémentée dans Firefox 34 en décembre et dans Internet Explorer 12, au sein de la Technical Preview de Windows 10.

Un meilleur protocole, pas exempt de controverses

Concrètement, HTTP/2 doit amener le multiplexage, qui agrège les requêtes HTTP en une seule connexion, ce qui évite d’en ouvrir une pour chaque requête de contenu. Les serveurs pourront également directement pousser des données vers le client, sans requête du navigateur. Une fonction également disponible dans les web apps HTML5, avec les Websockets. Le futur protocole apporte également la compression des entêtes HTTP et d’autres optimisations. En 2012, Google estimait SPDY 23 % plus rapide que le HTTP classique sur réseaux mobiles.

Surtout, le protocole apporte le chiffrement des connexions par défaut (via TLS). Une fonction sur laquelle beaucoup d’attention s’est focalisée depuis les révélations d’Edward Snowden sur la surveillance du Net par la NSA. Au 1er février, HTTP/2 était déjà utilisé « dans 5 % du trafic global » selon des chiffres de Google obtenus par Daniel Stenberg, ingénieur réseau chez Mozilla. Dans ce document, il propose d'ailleurs une analyse détaillée du HTTP/2.

Des critiques s’élèvent tout de même contre le choix de SPDY comme base de HTTP/2, rapporte The Register. Un des points de discorde est ce fameux chiffrement par défaut, qui serait appliqué à l’ensemble des connexions, même quand il serait inutile, voire illégal. Des contributeurs aux travaux sur le protocole, au sein du W3C, songeraient à corriger certains problèmes du futur HTTP/2 dans la version suivante, HTTP/3. Une mouture qui ne serait donc pas mise en circulation avant de nombreuses années.

HTTP/2HTTP/2
Crédits : Daniel Stenberg (licence: CC by 4.0)

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

HTTP/2 : le remplaçant du HTTP, basé sur le SPDY de Google

Un meilleur protocole, pas exempt de controverses

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (63)


“va donc viens donc chez Speedy… SPDY !”



&nbsp;&nbsp;<img data-src=" />


Et au niveau des serveurs, ça se passe comment ? Apache le supporte déjà ?


xhamster et youporn sont compatibles ? (95% de mon surf)


Va falloir penser à revoir ses classiques avant de commenter :o



https://www.youtube.com/watch?v=Pt2wTMR9Fi0


A quel moment le chiffrement devient illégale ?


Aïe ma mémoire me fait déjà défaut, c’est pas bon pour la suite ça&nbsp;<img data-src=" />




Les serveurs pourront également directement pousser des données vers le client, sans requête du navigateur.



Quand on voit le nombre de “Low ID” sous eMule (pour ceux qui l’utilisent encore <img data-src=" />), ça risque de ne pas être souvent exploité.


“Les serveurs pourront également directement pousser des données vers le client, sans requête du navigateur”&nbsp;



&nbsp;Du coup je comprend pas trop, ça sera une espece d’AJAX directement “de base” ?


Le soucis surtout c’est que le chiffrement par défaut, c’est l’obligation d’allouer des ressources (donc de l’argent) a un encodage / décodage inutile dans l’essentiel des cas (sans valeur ajouté, si le contenu est publique)


Selon les législations nationales, ça peut le devenir. Ils ont des idées très innovantes au Royaume-Uni par exemple. ^^








vampire7 a écrit :



Quand on voit le nombre de “Low ID” sous eMule (pour ceux qui l’utilisent encore <img data-src=" />), ça risque de ne pas être souvent exploité.





Ca n’a juste rien à voir. Le client ouvre une connexion permanente et latente à travers laquelle le serveur peut envoyer des données sans que le client les attende expressément.&nbsp; Ca reste une connexion Client -&gt; Serveur.

Le protocole qui s’en rapproche est la variante IDLE de l’IMAP (tout comme Activesync Server d’ailleurs).









Northernlights a écrit :



Le soucis surtout c’est que le chiffrement par défaut, c’est l’obligation d’allouer des ressources (donc de l’argent) a un encodage / décodage inutile dans l’essentiel des cas (sans valeur ajouté, si le contenu est publique)





J’avais lu un article de google qui indiquait que le chiffrement de tous le trafic ne représente qu’une surcharge assez infime finalement. J’essaye de retrouver le lien.&nbsp;



&nbsp;Pour moi c’est une bonne chose, parce que aujourd’hui si on veut chiffrer les échanges entre son site et le client, il faut installer un certificat https et si il n’est pas signé par une autorité de confiance (ce qui est payant) et bien l’utilisateur pense qu’il est sûr un site pas du tout sécurisé, alors qu’il l’ai plus qu’un site non chiffré.&nbsp;



Donc là c’est bien, on à une solution standard, gratuite et transparente pour l’utilisateur afin de sécurisé un peu les échanges.&nbsp;



Et au final je pense que le % de donnée qui contiennent uniquement des données publique n’est pas si important que ça. La plupart des sites même avec des infos publiques (comme wikipedia) on un système de login qui fait qu’une partie des données n’est plus publique.&nbsp;



C’est pas vraiment l’idée que tu as en tête.

Classiquement, ton navigateur commence par demander la page web, la parse, et fait diverses requêtes pour récupérer les images/css/scripts/…

Ici, ton navigateur va demander la page web, et le serveur va directement te donner la page, ainsi que les ressources associées.





Concrètement, HTTP/2 doit amener le multiplexage, qui agrège les requêtes HTTP en une seule connexion, ce qui évite d’en ouvrir une pour chaque requête de contenu.



Le fait d’utiliser une seule connexion est largement déjà possible. C’est le principe du keep-alive qui conserve la même connexion TCP pour effectuer les différentes requêtes. Ce qui change avec HTTP2, c’est qu’une requête sur une connexion n’est pas bloquante pour les requêtes suivantes. Si on imagine qu’on fait une requête vers un serveur en utilisant une connexion A sur une ressource R1 et que celle-ci prends 10 secondes à être traitée, on peut envoyer 25 requêtes sur la même connexion A mais vers d’autres ressources, il faudra que le serveur réponde en premier lieu la ressource R1 avant de répondre aux autres.

C’est ce que change HTTP2 puisque l’ordre de réponse est independant de l’ordre des requêtes.


Plus qu’à attendre Debian 9 pour avoir ça sur mon serveur <img data-src=" />








patos a écrit :









Strimy a écrit :





Ok, merci pour les éclaircissements. <img data-src=" />



Concrètement, pour un site qui veut passer à ce protocole, que doit-il changer ? Le serveur web suffit ou alors il faut faire plus ?


Concrètement niveau hébergement il te faut installer un serveur parlant le http2.



Celui qui commence à prendre pas mal d’importance est nghttp2.



J’espère fortement qu’apache ne tentera pas d’adopter http2. C’est enfin l’occasion de passer à un truc plus moderne. Marre de ses vieilleries.








darkbeast a écrit :



xhamster et youporn sont compatibles ? (95% de mon surf)





<img data-src=" />



Apache non, nginx et lighttpd non plus. Prévu dans IIS pour Win 10. Tant que le RFC n’est pas publié, ça ne sert pas à grand chose d’en proposer le support. <img data-src=" />








Malesendou a écrit :



A quel moment le chiffrement devient illégale ?







dans un ou deux ans



&nbsp;







Alucard63 a écrit :



<img data-src=" />





hé tu te moques pas de ma misère affective <img data-src=" />



Tu as des exemples de trucs “plus moderne” ?








Malesendou a écrit :



A quel moment le chiffrement devient illégale ?





Au moment ou tu vis en Corée du Nord. <img data-src=" />



Avec l’IoT, HTTP/1 n’est pas près de trépasser!

Mieux vaut ça que faire comme Apple sur le respect de la norme 4G ;)








Lordtoniok a écrit :



Concrètement niveau hébergement il te faut installer un serveur parlant le http2.



Celui qui commence à prendre pas mal d’importance est nghttp2.



J’espère fortement qu’apache ne tentera pas d’adopter http2. C’est enfin l’occasion de passer à un truc plus moderne. Marre de ses vieilleries.



T’as raison. Apache étant le serveur le plus utilisé du monde, ils ne vont rien faire et attendre de crever tranquillement. <img data-src=" />









Obidoub a écrit :



Plus qu’à attendre Debian 9 pour avoir ça sur mon serveur <img data-src=" />





Rhooo elle est méchante celle-là.<img data-src=" />









John Shaft a écrit :



Apache non, nginx et lighttpd non plus. Prévu dans IIS pour Win 10. Tant que le RFC n’est pas publié, ça ne sert pas à grand chose d’en proposer le support. <img data-src=" />





J’utilise Monkey<img data-src=" />

Mais je sais pas si il est supporté.<img data-src=" />



Non c’est juste que le protocole supporte le push. Un peu comme les websockets.








skan a écrit :



Avec l’IoT, HTTP/1 n’est pas près de trépasser!

Mieux vaut ça que faire comme Apple sur le respect de la norme 4G ;)





<img data-src=" />









nicolasdinunno a écrit :



“Les serveurs pourront également directement pousser des données vers le client, sans requête du navigateur”&nbsp;



&nbsp;Du coup je comprend pas trop, ça sera une espece d’AJAX directement “de base” ?





AJAX c’est asynchrone, mais c’est une demande du client vers le serveur. Ce serait plutôt du long polling.



Grosso modo le client initie une connexion au serveur, et celui-ci s’en sert pour envoyer des données quand il le souhaite.



en AJAX,

-&nbsp;serveur, y’a du nouveau ? &nbsp;(—&gt;)




  • nan (&lt;—)



  • et maintenant ? (—&gt;)

  • nan (&lt;—)



  • et là ? (—&gt;)

  • ouaip, vlà ton nouveau flux. (&lt;—)



    &nbsp;

    avec du server push, ce serait plutôt :

    -serveur, prévient moi quand y’a du nouveau… (—&gt;)





  • et vlà ton nouveau flux (&lt;—)



Oué, là c’est SPDY, truc fait en interne chez Google.



Là on parle d’un standard Internet proposé par l’IETF. Tant que les discussions ne sont pas terminées et le brouillon validé, je ne vois pas l’intérêt de proposer le support aux admins sys (hormis sur une machine de test) : il suffit d’un terme qui change dans le RFC (mettons un “MAY” qui devient un “MUST”) pour que tout le code soit à revoir











Ricard a écrit :



T’as raison. Apache étant le serveur le plus utilisé du monde, ils ne vont rien faire et attendre de crever tranquillement. <img data-src=" />





Ouai sauf que ce n’est plus le même protocole. C’est assez courant dans le monde opensource de lacher un soft et de repartir de 0 pour la suite. Il y aura surement du monde pour vouloir conserver l’historique histoire d’éviter de tout remettre en question mais c’est préjudiciable au final.



&nbsp;



atomusk a écrit :



Tu as des exemples de trucs “plus moderne” ?





Ouai en http on a quand même vu de nouveaux arrivants proposants des architectures amplement plus moderne genre nginx ou lighttpd. Personnelement je préferrait un petit nouveau plutôt que de se faire chier à hacker dans tous les sens un ancien pour tenter d’arriver tant bien que mal à parler http2 tout en conservant une architecture pensé à l’époque de la création du web.



.


Un web optimisé pour les services Google. Bizarrement personne ne parle de neutralité ici.


Oui je sais, mais dans la news ils disent que le travail est basé sur spdy., et sur la faq httpd2, ils disent:

&nbsp;

&nbsp;After a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers.

Donc je ne suis pas trop hors sujet …


Heu en quoi c’est optimisé pour les services google ? Et en quoi ça viole la neutralité ?


Yup. SPDY sert de base. Maintenant, HTTP/2 contiendra des différences (l’avantage de discuter à plusieurs) <img data-src=" />.



Du coup : ajouter un support à SPDY ne sert plus à rien maintenant (m’étonnerais que Google continue de dév le truc) et ajouter le support HTTP/2 est encore prématuré.



<img data-src=" />


“la priorisation [des éléments dans une page web] ”



Miam, on aura donc toujours la pub qui arrivera d’abord.


Ce sera du push (le serveur pousse l’information contrairement à ajax qui va tirer [GET] l’information), un peu comme les notifications des applis dans ton smartphone.

En gros tu ne demandes rien, c’est le serveur qui va notifier le client (en occurence le browser) qu’il y a une info qui arrive. En terme d’utilisation, c’est plus simple que de l’ajax (tu ne vas plus à la chasse aux données, c’est les données qui viennent à toi). Tu auras juste la fonction qui intercepte (en fait ta fonction s’abonne aux notifications) les infos pour les traiter….








AlbertSY a écrit :



Ce sera du push (le serveur pousse l’information contrairement à ajax qui va tirer [GET] l’information), un peu comme les notifications des applis dans ton smartphone.

En gros tu ne demandes rien, c’est le serveur qui va notifier le client (en occurence le browser) qu’il y a une info qui arrive. En terme d’utilisation, c’est plus simple que de l’ajax (tu ne vas plus à la chasse aux données, c’est les données qui viennent à toi). Tu auras juste la fonction qui intercepte (en fait ta fonction s’abonne aux notifications) les infos pour les traiter….





Et il fait comment le serveur pour savoir si le client est toujours sur la page? (vrai question)









Qruby a écrit :



Un web optimisé pour les services Google. Bizarrement personne ne parle de neutralité ici.





Ou alors tu n’as pas du tout compris le sujet et ton comm pue le gros troll …&nbsp;<img data-src=" />



Tu peux te baser sur la connexion TCP avec un mécanisme de heartbeat pour conserver la connexion active. (Ceci dit, j’en sais rien de comment c’est fait dans HTTP2)



Ceci dit, je n’ai pas l’impression que le Push du HTTP soit fait pour envoyer des notifications, mais uniquement pour pousser des ressources que le client n’a pas (encore) demandé.








ar7awn a écrit :



Et il fait comment le serveur pour savoir si le client est toujours sur la page? (vrai question)





C’est une bonne question. Pour moi, la gestion de la connection est faite au niveau TCP et non au niveau HTTP. Que la requete a été faite en GET ou en PUSH importe peu, dans les 2 cas il s’agit d’une connection TCP qui a été fermée au moment de la transaction.



Donc finalement, un serveur qui repond a un GET fait en TCP peut très bien avoir perdu sa connection avec son client. Pour moi, il devra gerer de la meme manière la perte de connection en PUSH qu’en GET.



Ya un équivalent au about:networking, de Firefox, sous Chrome/Opera ?








Lordtoniok a écrit :



Ouai sauf que ce n’est plus le même protocole. C’est assez courant dans le monde opensource de lacher un soft et de repartir de 0 pour la suite. Il y aura surement du monde pour vouloir conserver l’historique histoire d’éviter de tout remettre en question mais c’est préjudiciable au final.





Ouais mais on parle pas d’un petit soft à deux sous là… Apache, c’est des centaines de personnes derrière…









flagos_ a écrit :



C’est une bonne question. Pour moi, la gestion de la connection est faite au niveau TCP et non au niveau HTTP. Que la requete a été faite en GET ou en PUSH importe peu, dans les 2 cas il s’agit d’une connection TCP qui a été fermée au moment de la transaction.



Donc finalement, un serveur qui repond a un GET fait en TCP peut très bien avoir perdu sa connection avec son client. Pour moi, il devra gerer de la meme manière la perte de connection en PUSH qu’en GET.





<img data-src=" />





Strimy a écrit :



Tu peux te baser sur la connexion TCP avec un mécanisme de heartbeat pour conserver la connexion active. (Ceci dit, j’en sais rien de comment c’est fait dans HTTP2)



Ceci dit, je n’ai pas l’impression que le Push du HTTP soit fait pour envoyer des notifications, mais uniquement pour pousser des ressources que le client n’a pas (encore) demandé.







sans doutes car je ne vois pas quel serait l’avantage face a l’ajax pour le rechargement régulier d’une page, s’il faut pour cela checker régulièrement si le client est toujours besoin des ressources.










Lordtoniok a écrit :



Heu en quoi c’est optimisé pour les services google ? Et en quoi ça viole la neutralité ?





Alors, un début de réponse ici:

&nbsp;



kvasir a écrit :



“la priorisation [des éléments dans une page web] ”



Miam, on aura donc toujours la pub qui arrivera d’abord.





C’est déjà le cas à l’heure actuelle, mais c’est le genre de dérive que l’on pourra avoir.

&nbsp;





Glyphe a écrit :



Ou alors tu n’as pas du tout compris le sujet et ton comm pue le gros troll …&nbsp;<img data-src=" />&nbsp;




ouai mais c’est plus vraiment le même protocole. Non plus.

Au bout d’un moment il faut savoir lâcher prise et repartir d’une base saine.





La syntaxe de conf d’apache est d’un lourdingue… Mais bon je ne me fait pas d’illusion. Je sait qu’il suivra la marche et adoptera le protocole. Et malheureusement on continuera à subir ces tutos.








Lordtoniok a écrit :



ouai mais c’est plus vraiment le même protocole. Non plus.

Au bout d’un moment il faut savoir lâcher prise et repartir d’une base saine.





La syntaxe de conf d’apache est d’un lourdingue… Mais bon je ne me fait pas d’illusion. Je sait qu’il suivra la marche et adoptera le protocole. Et malheureusement on continuera à subir ces tutos.





Faut surtout penser aux millions de serveurs en prod qui utilisent Apache. Va y avoir de la mise à jour et de la maintenance à faire. Moi je vois ça comme une occasion de rajeunir un parc de serveurs obsolètes, bourrés de failles de sécurité etc… Ca devrait améliorer les choses.









nicolasdinunno a écrit :



&nbsp; Du coup je comprend pas trop, ça sera une espece d’AJAX directement “de base” ?





Euh non c’est carrément pas pareil. AJAX c’est du Javascript (pour simplifier), qui fait une requête asynchrone passant par le protocole HTTP, ce même protocole dont parle l’actu (en version 1 ou 2).



Mais du coup si c’est chiffré de base par TLS, c’est la fin des proxy filtrant le p0rn (via un mot clé dans l’url) ?


Ils vont “prioriser” quoi? Les pubs je suppose?


Les trolls IPv6 sur les slides…



Ils sont marrants chez Google, ce n’est pas sur la même couche du modèle OSI…



&nbsp;


Hello



(je suis pour le full https :) ).&nbsp;

coté client, c’est effectivement pas grand chose (quelques&nbsp; ms&nbsp; a l’initialisation de la connexion…)

&nbsp;

&nbsp;Et oui, pour une grosse boite, tu as des boitier type F5 / redline avec compression matériel, profil http2 et cryptage materiel (supporte genre 20 000 initialisation de connection secure par seconde).&nbsp; la pas de soucis



Sur de “pauvre” serveur type apache, sur un serveur 8 core, tu n’atteindras une perf type 1000 connections /s et ton serveur sera a la ramasse.&nbsp;

&nbsp;

Clairement, je serais curieux de savoir comment est géré le https sur le site (je suppose que nextinpact a pas les moyens de se payer un F5) et de combien la surcharge CPU serait si le site passait en full https.



Sinon, je suppose que le HTTP2 s’appuiera aussi sur la norme STS =&gt; il faut impérativement un certificat signé par une autorité de confiance sinon la connexion ne se fait pas.&nbsp; (norme précise qu’il est interdit au navigateur de bypasser cela)

==&gt; Tu as un certificat autosigné&nbsp; : refusé

==&gt; Tu as un certificat révoqué / expiré : refusé



&nbsp;


Chrome&nbsp;<img data-src=" />

&nbsp;

Fidèle utilisateur depuis très longtemps… Il commence à m’insupporter.

spdy… ouais, cool. Et sinon y’a un autre navigateur sympa et (pas encore, puisque ça semble être la maladie de tous tôt ou tard) pachydermique ?


Salut



S’il s’agit juste de chiffrement matériel et de fonctionnalités basiques (et encore je suis méchant), tu peux te contenter d’un A10 qui fera largement le boulot et pour beaucoup beaucoup moins cher !


Re,



Oui, c’est aussi vrai. J’avoue ne pas connaitre le prix d’un A10 qui fait le minimum (ssl offloading+compression+load balancer) mais ca doit doit pouvoir se défendre dans beaucoup de cas.


Par contre il n’est à priori pas vraiment possible de faire passer du websocket sur une connexion HTTP/2 en raison de problèmes de multiplexage.



Et le push HTTP2 n’a pas vraiment le même usage et le même overhead que websocket (en gros c’est moins bien, vu que normalement ca ne sert pas à la même chose).



Donc Http1 a&nbsp;encore de beaux jours devant&nbsp;lui, au moins en complément de HTTP2 pour la partie temps réel. Même si perso je suis en train de tester des choses plus rigolotes <img data-src=" />&nbsp;


Pour ca il y a des solutions : le proxy s’occupe de la partie HTTPS entre lui et le site visité, il initie la connexion à la place du client. Il a donc accès à l’url (mot clé, catégoriseur) et bien entendu au contenu (filtrage par mot clé et scan antivirus possible du coup)

Ensuite il chiffre la connexion avec son propre certificat dont l’authorité de confiance est reconnu par le client (déploiement du certificat, ou achat de certificat d’une organisation reconnu) pour protéger le flux sur le LAN.








CryoGen a écrit :



Pour ca il y a des solutions : le proxy s’occupe de la partie HTTPS entre lui et le site visité, il initie la connexion à la place du client. Il a donc accès à l’url (mot clé, catégoriseur) et bien entendu au contenu (filtrage par mot clé et scan antivirus possible du coup)

Ensuite il chiffre la connexion avec son propre certificat dont l’authorité de confiance est reconnu par le client (déploiement du certificat, ou achat de certificat d’une organisation reconnu) pour protéger le flux sur le LAN.





muf, pas convaincu.

Mon navigateur risque de gueuler si je vais sur google en https et que le proxy me présente son certificat ssl.









simplix a écrit :



muf, pas convaincu.

Mon navigateur risque de gueuler si je vais sur google en https et que le proxy me présente son certificat ssl.







Non :) (oui j’ai un proxy comme çà <img data-src=" />)