Google Chrome passera du protocole SPDY à HTTP/2 d’ici quelques semaines
Va donc, va donc chez Speedy... SPDY !
Le 10 février 2015 à 13h14
4 min
Internet
Internet
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.
Crédits : Daniel Stenberg (licence: CC by 4.0)
Google Chrome passera du protocole SPDY à HTTP/2 d’ici quelques semaines
-
HTTP/2 : le remplaçant du HTTP, basé sur le SPDY de Google
-
Un meilleur protocole, pas exempt de controverses
Commentaires (63)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/02/2015 à 13h15
“va donc viens donc chez Speedy… SPDY !”
" />
Le 10/02/2015 à 16h51
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.
Le 10/02/2015 à 17h21
Le 10/02/2015 à 18h26
Le 10/02/2015 à 18h33
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) ?
Le 10/02/2015 à 18h41
Ils vont “prioriser” quoi? Les pubs je suppose?
Le 10/02/2015 à 18h50
Les trolls IPv6 sur les slides…
Ils sont marrants chez Google, ce n’est pas sur la même couche du modèle OSI…
Le 10/02/2015 à 18h53
Hello
(je suis pour le full https :) ).
coté client, c’est effectivement pas grand chose (quelques ms a l’initialisation de la connexion…)
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). 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.
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 => il faut impérativement un certificat signé par une autorité de confiance sinon la connexion ne se fait pas. (norme précise qu’il est interdit au navigateur de bypasser cela)
==> Tu as un certificat autosigné : refusé
==> Tu as un certificat révoqué / expiré : refusé
Le 10/02/2015 à 19h29
Chrome " />
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 ?
Le 10/02/2015 à 19h35
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 !
Le 10/02/2015 à 20h26
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.
Le 11/02/2015 à 07h53
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 encore de beaux jours devant 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 " />
Le 11/02/2015 à 08h19
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.
Le 11/02/2015 à 14h24
Le 11/02/2015 à 15h01
Le 10/02/2015 à 13h20
Et au niveau des serveurs, ça se passe comment ? Apache le supporte déjà ?
Le 10/02/2015 à 13h21
xhamster et youporn sont compatibles ? (95% de mon surf)
Le 10/02/2015 à 13h22
Va falloir penser à revoir ses classiques avant de commenter :o
YouTube
Le 10/02/2015 à 13h23
A quel moment le chiffrement devient illégale ?
Le 10/02/2015 à 13h23
Aïe ma mémoire me fait déjà défaut, c’est pas bon pour la suite ça " />
Le 10/02/2015 à 13h26
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 " />), ça risque de ne pas être souvent exploité.
Le 10/02/2015 à 13h26
hein ?
Le 10/02/2015 à 13h27
“Les serveurs pourront également directement pousser des données vers le client, sans requête du navigateur”
Du coup je comprend pas trop, ça sera une espece d’AJAX directement “de base” ?
Le 10/02/2015 à 13h27
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)
Le 10/02/2015 à 13h28
Selon les législations nationales, ça peut le devenir. Ils ont des idées très innovantes au Royaume-Uni par exemple. ^^
Le 10/02/2015 à 13h33
Le 10/02/2015 à 13h33
Le 10/02/2015 à 13h35
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.
Le 10/02/2015 à 13h40
Plus qu’à attendre Debian 9 pour avoir ça sur mon serveur " />
Le 10/02/2015 à 13h41
Le 10/02/2015 à 13h43
Concrètement, pour un site qui veut passer à ce protocole, que doit-il changer ? Le serveur web suffit ou alors il faut faire plus ?
Le 10/02/2015 à 14h04
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.
Le 10/02/2015 à 14h14
Le 10/02/2015 à 14h14
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. " />
Le 10/02/2015 à 14h15
Le 10/02/2015 à 14h18
Le 10/02/2015 à 14h20
Tu as des exemples de trucs “plus moderne” ?
Le 10/02/2015 à 14h22
Le 10/02/2015 à 14h27
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 ;)
Le 10/02/2015 à 14h31
Le 10/02/2015 à 14h32
Le 10/02/2015 à 14h33
Le 10/02/2015 à 14h34
Non c’est juste que le protocole supporte le push. Un peu comme les websockets.
Le 10/02/2015 à 14h35
Si, plus ou moins Google
Le 10/02/2015 à 14h35
Le 10/02/2015 à 14h40
Le 10/02/2015 à 14h43
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
Le 10/02/2015 à 14h54
Le 10/02/2015 à 15h28
.
Le 10/02/2015 à 15h29
Un web optimisé pour les services Google. Bizarrement personne ne parle de neutralité ici.
Le 10/02/2015 à 15h32
Oui je sais, mais dans la news ils disent que le travail est basé sur spdy., et sur la faq httpd2, ils disent:
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 …
Le 10/02/2015 à 15h34
Heu en quoi c’est optimisé pour les services google ? Et en quoi ça viole la neutralité ?
Le 10/02/2015 à 15h38
Yup. SPDY sert de base. Maintenant, HTTP/2 contiendra des différences (l’avantage de discuter à plusieurs) " />.
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é.
" />
Le 10/02/2015 à 15h38
“la priorisation [des éléments dans une page web] ”
Miam, on aura donc toujours la pub qui arrivera d’abord.
Le 10/02/2015 à 15h45
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….
Le 10/02/2015 à 16h04
Le 10/02/2015 à 16h05
Le 10/02/2015 à 16h09
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é.
Le 10/02/2015 à 16h17
Le 10/02/2015 à 16h21
Ya un équivalent au about:networking, de Firefox, sous Chrome/Opera ?
Le 10/02/2015 à 16h25
Le 10/02/2015 à 16h31
Le 10/02/2015 à 16h43