Google veut remplacer http: par spdy://

[GUITEL]

Le protocole SPDY pourrait révolutionner le monde du web en réduisant de moitié le temps de chargement des pages.

source

[Ursu-Charlie]

Merci Guitel pour l'information, c'est un article intéressant.

[BadProcESs]

Pas trop pour, en tout cas, pas pour utilisation dites "standardisé".

En effet, confier la couche supérieur du protocole internet web à une entreprise privée, même si les sources sont au final opensource, ne me semble pas un bonne idée pour la neutralité des informations. Je ne sais pas encore comment cela fonctionne mais imaginons qu'après une adoption massive, Google décide par exemple de customiser les pages d'erreurs 404 comme le fît à une époque un fournisseur de DNS (je ne me rappelle plus de son nom) ?

Bref, "wait and see" comme on dit, mais cela ne me plait pas trop...

[GUITEL]

@ BadProcESs

Bien que je comprends le raisonnement.
Qui nous prouve à 100% que la neutralité des informations soit respectée avec le http ?

De plus, il est vrai que le temps de chargement avec le http devient de plus en plus contraignant, ça commence à saturer sérieusement.

[pcamliti]

A mon humble avis, si GG décide et impose, il faudra suivre comme pour Zindows qui a su imposer sa suprématie non ?
Il va falloir revoir nos URL alors ?

[aladdin]

En effet, confier la couche supérieur du protocole internet web à une entreprise privée, même si les sources sont au final opensource,

le terme "confier" n'a aucun sens là dedans, il s'agit de la mise en place d'un protocole ! et pas d'une application. si un jour ce protocole est standardisé (le chemin est très long) ... chaque entreprise pourra en faire sa propre implémentation ... y'aura alors une implémentation SPDY sur apache une autre sur IIS ou encore nginx ou lighthttpd ... bref rien de proprio là dedans.

sachant qu'avant la standardisation d'un tel protocole, les entreprises et les organisation discutent longement avant de décider une éventuelle adoption.

que ça soit google ou autre, il est vraiment temps d'implémenter un vrai protocole web : rapide, fiable et sécurisé ...
il serait bien interessant par exemple qu'un tel protocole puisse filtrer les spams à la source avant qu'ils transitent dans les réseaux puisque ces dernier occupent 70% de la BP de la plupart des réseaux web ....

[NoGlob]

Qui dit protocole, dit l'application qui va avec.
Si c'est comme pour chrome qui envoi tout plein d'infos à Google ... Là c'est la porte ouverte à plein de dérive comme BadProcESs le signale.

[aladdin]

Qui dit protocole, dit l'application qui va avec.

hein ? rien avoir !

http, ftp, smtp, ...etc ...etc tout ça c'est des protocole, et pourtant chaque entreprise ou groupe a le droit d'en faire sa propre implémentation ... faut pas mélanger.
un protocole ça n'a absolument rien avoir avec une application ... un protocole peut très bien exister sans être réellement implémenté, du moins pas en production.

[skyll]

un protocole ça n'a absolument rien avoir avec une application ... un protocole peut très bien exister sans être réellement implémenté, du moins pas en production.

+1 mais le truc sera de voir qui suit, et qui développe des outils utilisant ce protocole

[Bellegarde-webb]

+1 mais je laisse la discussion aux spécialistes.

[aladdin]

@skyll : si le protocole est adopté comme standard, forcement chaque acteur du web ou des réseaux vas très vite en faire une implémentation pour garder ses part de marché ... on retrouvera forcement du google mais aussi du cisco, du microsoft peut etre, de l'open source .... avec chacun sa couche compatible (qui respecte strictement le protocole) et une couche spécifique pour se démarquer des autres
dans tout les cas sa n'a absolument rien avoir avec un quelconque monopole ou un truc du genre. nombreux sont les protocoles proposé par des boites puis adopté, et au finale ce ne sont pas ceux qui ont proposé le protocole à la base qui en tire le plus de bénéfices ou de parts de marché.

un peu d'histoire :
le protocole SSH (oui oui c'est bien un protocole aussi) à la base a été créé par une société qui s'appelait SSH Communications Security, ensuite racheté par F-Secure (ça vous dit rien ? ) ... ensuite des chercheurs ont fait évoluer ce protocole vers une version 2 (SSH-2) qui est utilisé par la plupart des serveurs actuellement et qui est implémenté par tous les acteurs du marché que sa soit coté client ou serveur.
pour autant, F-Secure ne trace pas ce qui transite dans les tuyaux SSH :p

[pcamliti]

Bouh ! discussion pleine de passion ! Je pense qu'à ce niveau, je ne suis plus .... je vais survoler cela mais ne vais pas m'impliquer plus.

[hibou57]

[...] il serait bien interessant par exemple qu'un tel protocole puisse filtrer les spams à la source avant qu'ils transitent dans les réseaux puisque ces dernier occupent 70% de la BP de la plupart des réseaux web ....

70% : est-ce une manière imagée de parler du problème ou est-ce un ratio fondé par des mesures ?

[hibou57]

@skyll : si le protocole est adopté comme standard, forcement chaque acteur du web ou des réseaux vas très vite en faire une implémentation pour garder ses part de marché ... [...]

Réponse en trois points :

1) Pour garder ses parts de marché.... des parts de marchés qui ne sont pas justement pas rentables dans la plupart des cas (c.f. les grandes discussions depuis 6 mois autour de l'amortissement des investissements sur le web). Ça ne va peut-être pas se bousculer au portillon pour investir encore plus et aggraver encore les bilans comptables (sauf peut-être les société de poker en ligne, qui sont à peut prêt les seuls « services » pour lesquels les internautes ne soient pas choqués qu'ils puissent être payants). Je vois mal les sociétés du web se ruer sur, et investir dans un nouveau protocole, pour sauver des miettes de revenus publicitaires en baisse permanente.

2) Le « changer pour ce truc, c'est super méga mieux », inspire de plus en plus de saturation et d'indigestion, même chez les utilisateurs. Les décideurs sont déjà moins enclins à suivre que les utilisateurs chez qui la seule nouveauté représente un attrait, alors si même les utilisateurs saturent, c'est qu'il y a vraiment saturation. Ce point n°2 est un peu discutable, je le reconnais, mais il n'est pas hors de propos tout de même, et ça reste un « y en a assez de toujours devoir changer ci et ça ».

3) IPv6 lui aussi devait permettre plus de sécurité, de fiabilité et de rapidité. Alors pourquoi ne pas attendre tout d'abord l'arrivé effective de IPv6 ? Quand IPv6 sera concrètement là, on ne ressentira peut-être plus le besoin de passer de HTTP à autre chose. Et toujours au sujet de IPv6 : quand on voit la lenteur avec laquelle il s'introduit, je doute vraiment qu'un protocole remplaçant HTTP ne s'impose plus rapidement que IPv6, dont on entend parler depuis 1998 tout de même. Il y a urgence à passer à cette version de IP, par le force des choses (si je me souviens bien, les dernières adresses IPv4 auront été alloué en avril 2010, et sont d'ailleurs pour la plupart réservé à l'Afrique)n et pour ça traine, alors un successeur de HTTP sans bonne raison de migrer, je n'y crois pas.

[Leonick]

surtout que, visiblement, la charge serait transférée des réseaux sur les serveurs, donc avant d'investir dedans, il faudra voir si le surcout sera amorti par une bande passante moins importante utilisée par les serveurs, à voir...