Connexion
Abonnez-vous

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

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

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

Le 10 février 2015 à 13h14

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)

Commentaires (63)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

“va donc viens donc chez Speedy… SPDY !”



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

votre avatar

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.

votre avatar







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.


votre avatar







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


votre avatar

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

votre avatar

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

votre avatar

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;

votre avatar

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;

votre avatar

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 ?

votre avatar

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 !

votre avatar

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.

votre avatar

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;

votre avatar

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.

votre avatar







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.


votre avatar







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=" />)


votre avatar

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

votre avatar

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

votre avatar

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



youtube.com YouTube

votre avatar

A quel moment le chiffrement devient illégale ?

votre avatar

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

votre avatar



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

votre avatar
votre avatar

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

votre avatar

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)

votre avatar

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

votre avatar







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


votre avatar







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;


votre avatar

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.

votre avatar

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

votre avatar







patos a écrit :









Strimy a écrit :





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


votre avatar

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

votre avatar

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.

votre avatar







darkbeast a écrit :



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





<img data-src=" />


votre avatar

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=" />

votre avatar







Malesendou a écrit :



A quel moment le chiffrement devient illégale ?







dans un ou deux ans


votre avatar

&nbsp;







Alucard63 a écrit :



<img data-src=" />





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


votre avatar

Tu as des exemples de trucs “plus moderne” ?

votre avatar







Malesendou a écrit :



A quel moment le chiffrement devient illégale ?





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


votre avatar

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 ;)

votre avatar







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=" />


votre avatar







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=" />


votre avatar







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=" />


votre avatar

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

votre avatar

Si, plus ou moinscode.google.com Google

votre avatar







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=" />


votre avatar







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;—)


votre avatar

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


votre avatar









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.


votre avatar

.

votre avatar

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

votre avatar

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 …

votre avatar

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

votre avatar

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=" />

votre avatar

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



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

votre avatar

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

votre avatar







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)


votre avatar







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=" />


votre avatar

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

votre avatar







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.


votre avatar

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

votre avatar







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…


votre avatar







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.



votre avatar







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;



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

Fermer