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]

Re: [Google] http: remplacer par spdy://

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 :mrgreen:

 

[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

 

[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é.... :roll: 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...

 

[NoGlob]

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.

Tu as mal compris ma phrase. Ce que je veux dire c'est que si Google lance un protocole il lancera avec une application pour l'exploiter et commencer le mouv.

 

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

Tu as mal compris ma phrase. Ce que je veux dire c'est que si Google lance un protocole il lancera avec une application pour l'exploiter et commencer le mouv.

l'application existe déjà c'est google chrome

 

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

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

 

[Marie-Aude]

Petite question

Les adresses en spdy:// pourraient alors fleurir rapidement sur les sites de Google et devenir une alternative intéressante au classique protocole HTTP.

Est ce que je comprends bien que cela pourrait être à la fois :
- une source potentielle de duplicate content dans nos sites ?
- une chance d'améliorer le ranking, si on rapproche de la fameuse interview de Matt Cuts où il parlait des temps de chargement d'un site, on pourrait imaginer que Google privilégieraient les sites avec des adresses speedées ?

 

[Leonick]

on pourrait imaginer que Google privilégieraient les sites avec des adresses speedées ?

de la même façon que gault et millau & MIchelin privilégient les fast food dans leur classement :mrgreen:

 

[salva]

Petite question

Les adresses en spdy:// pourraient alors fleurir rapidement sur les sites de Google et devenir une alternative intéressante au classique protocole HTTP.

Est ce que je comprends bien que cela pourrait être à la fois :
- une source potentielle de duplicate content dans nos sites ?
- une chance d'améliorer le ranking, si on rapproche de la fameuse interview de Matt Cuts où il parlait des temps de chargement d'un site, on pourrait imaginer que Google privilégieraient les sites avec des adresses speedées ?

- Si Google décide d'implémenter seul ce protocole, il ne peut le faire que sur son réseau propre (en interne donc pas de duplicate).

- Si la planète Web décidait ensuite de passer aussi sur ce même protocole, tous les sites web disposeraient du même gain de performance.

Le protocole http permet la communication/dialogue entre le client et le serveur.

 

[Leonick]

Si la planète Web décidait ensuite de passer aussi sur ce même protocole, tous les sites web disposeraient du même gain de performance.

pas vraiment, car cela dépendra de la façon de l'implémenter sur les serveurs, de la même façon que pour http on peut avoir apache, lighttpd, etc... qui ne répondent pas de la même façon et n'ont pas besoin des mêmes ressources serveur
et ce protocole risque d'être plus gourmand en ressources pour le serveur,...

 

[salva]

Je parle de généralité. Deux serveurs web se partagent le marché : apache et IIS de crocro

Part de marché en mars 2008 :
Apache 50,42%
Microsoft 35,33%
Google 6,08%
Lighttpd 0,90%
Sun 0,33%

Source

Plus d'info

Notez la part de marché que représente le réseau Google

 

[forummp3]

un protocole pour avoir un internet plus rapide? je le trouve rapide l'internet actuel.

ca me fait penser au lessive qui lavent plus blanc que blanc.

 

[salva]

un protocole pour avoir un internet plus rapide? je le trouve rapide l'internet actuel.

Pas d'accord

Les temps de latence entre la requête (PC) et la réponse du serveur peuvent et doivent être améliorés.

 

[Leonick]

le "problème" pour déterminer la représentativité des serveurs web est que, pour des raisons de sécurité, beaucoup de sites préfèrent masquer leur type de serveur.
Après, l'étude de zdnet parle de sites, donc un serveur mutualisé accueillant plusieurs centaines de sites est-il compté comme 1 serveur ou plusieurs centaines ?
quid des serveurs avec du ip failover ou en load balancing ?
quand à la PDM de google, si c'est compté via le nombre de sites, avec les sites blogger, ça en représente un paquet. Comme, en plus, ce sont eux qui gèrent ça, ils mettent toujours le nom du serveur web :wink:

 

[salva]

Tu as du lire en diagonale ou alors tu mélanges tout.

Sur un total de 182 millions de sites, le serveur de Google en fait tourner environ 10,5 millions dans le monde à la fin octobre, soit 411 000 de plus qu'en septembre, selon les statistiques de Netcraft, qui étudie les logiciels utilisés pour l'hébergement de pages web.

L'article parle du serveur Google comme on parlerait du serveur apache (pas des serveurs physiques).

Apache est utilisé pour 91,5 millions de sites, contre 62,8 millions pour Microsoft IIS. C'est toutefois Apache, et non Google, qui marque la plus forte progression en septembre, avec 463 000 sites supplémentaires.

 

[Leonick]

Tu as du lire en diagonale ou alors tu mélanges tout.

non, justement, parler en nombre de sites revient à accorder la même représentativité à monsite.blogger.com ou monsite.free.fr qu'à google.fr ou laredoute.fr :roll:

 

[salva]

Rien compris.

Sur un total de 182 millions de sites, le serveur de Google en fait tourner environ 10,5 millions dans le monde à la fin octobre, soit 411 000 de plus qu'en septembre, selon les statistiques de Netcraft, qui étudie les logiciels utilisés pour l'hébergement de pages web.

Netcraft :

Netcraft est une entreprise basée à Bath en Angleterre. Elle est spécialisée dans les technologies Internet.
Netcraft est surtout connue pour mener depuis 1995 des sondages automatisés d'Internet par nom de domaine à la recherche de serveurs HTTP, donc de sites web. Elle publie mensuellement ses résultats qui sont régulièrement repris par les médias informatiques, comme Slashdot. La méthodologie de Netcraft compte un serveur HTTP par site web trouvé. Cela fait que le même serveur HTTP est compté autant de fois qu'il héberge de sites. À l'inverse, un seul serveur HTTP est compté pour un site répartissant la charge sur plusieurs serveurs web.
Ces résultats permettent de connaître le nombre de sites web actifs sur Internet et donnent donc une mesure de la taille du World Wide Web. En outre, pour chaque site le serveur HTTP utilisé est détecté, ce qui permet d'étudier ce marché. Depuis plusieurs années, les résultats de Netcraft sont notamment suivis pour observer le succès des serveurs concurrents, spécialement le logiciel libre Apache et Internet Information Service de Microsoft.

 

[Leonick]

Rien compris.

La méthodologie de Netcraft compte un serveur HTTP par site web trouvé. Cela fait que le même serveur HTTP est compté autant de fois qu'il héberge de sites. À l'inverse, un seul serveur HTTP est compté pour un site répartissant la charge sur plusieurs serveurs web.

c'est bien ce que je disais, les chiffres n'ont qu'un intérêt très limité : accorder la même représentativité à un skyblog qu'à lci.fr :roll: autant de skyblog, autant de serveurs comptabilisés 8O

 

[salva]

c'est bien ce que je disais, les chiffres n'ont qu'un intérêt très limité : accorder la même représentativité à un skyblog qu'à lci.fr :roll: autant de skyblog, autant de serveurs comptabilisés 8O

Et ? Un nom de domaine reste un nom de domaine (donc un site web). Je ne vois vraiment pas ce qui te gêne.

Le plus intéressant est la synthèse de ceci (l'article de zdnet date d'1 an)...

La nature même du serveur web de Google est inconnue, l'entreprise indiquant seulement qu'il s'agit d'« une création maison basée sur Linux ». Le serveur web de Google héberge ses propres sites et applications web, dont la plate-forme Blogger et les Google Apps.

...et le titre du post.

 

[forummp3]

Rien compris.

La méthodologie de Netcraft compte un serveur HTTP par site web trouvé. Cela fait que le même serveur HTTP est compté autant de fois qu'il héberge de sites. À l'inverse, un seul serveur HTTP est compté pour un site répartissant la charge sur plusieurs serveurs web.

c'est bien ce que je disais, les chiffres n'ont qu'un intérêt très limité : accorder la même représentativité à un skyblog qu'à lci.fr :roll: autant de skyblog, autant de serveurs comptabilisés 8O

ils doivent aussi avoir les stats par ip de serveur aussi, c'est surement ce que tu voulais savoir, mais je sais pas s'ils ont mis ce genre de stats sur leur site.

D'un autre coté, derriere un site, il y a un webmaster, donc que ca soit lci ou monsite, la plupart du temps, il faut developper selon le serveur (htaccess par exemple), donc on peut dire qu'un serveur avec 1000 sites, ca fait 1000 utilisateurs d'apache par exemple (à ne pas confondre avec le nombre d'instalation).

 

[Leonick]

Et ? Un nom de domaine reste un nom de domaine (donc un site web)

un nom de domaine peut correspondre entre 0 et des millions de sites. Du genre les skyblog qui étaient 10 millions il y a 2 ans, donc encore plus maintenant

D'un autre coté, derriere un site, il y a un webmaster, donc que ca soit lci ou monsite, la plupart du temps, il faut developper selon le serveur (htaccess par exemple), donc on peut dire qu'un serveur avec 1000 sites, ca fait 1000 utilisateurs d'apache par exemple (à ne pas confondre avec le nombre d'instalation).

un skybloger est un webmaster :roll:

 

[salva]

Et ? Un nom de domaine reste un nom de domaine (donc un site web)

un nom de domaine peut correspondre entre 0 et des millions de sites. Du genre les skyblog qui étaient 10 millions il y a 2 ans, donc encore plus maintenant

Skyblog ou pas il lui faut un serveur web (apache, IIS, Google [dans un avenir proche ?],..) pour afficher ses pages.

 

[Leonick]

au fait, gg n'utilise que ses propres serveurs web pour tous ses services ?
question, comment comptabilise-t-on un site web qui utilise 5 ou 6 serveurs web différents ? on ne prend en compte que celui qui envoie la 1° page html ?
En plus, il faudra développer des navigateurs compatibles windows95, 98, etc... pour que ça ne soit pas un élément bloquant. :wink:

 

[salva]

question, comment comptabilise-t-on un site web qui utilise 5 ou 6 serveurs web différents ? on ne prend en compte que celui qui envoie la 1° page html ?

1 serveur web, c'est précisé dans l'article wiki sur Netcraft.

 

[Leonick]

alors youtube, il est considéré comme quoi, en tant que serveur, parce qu'il en utilise 7 ou 8 différents quand même, et pas que du gg inside ?

 

[aladdin]

pour revenir à l'histoire spdy:// et http:// je pense que si le protocole est bien foutu, il gardera une compatibilité avec http.
deux cas de figures :

- 1 - Quand on tape http:// ... le navigateur utilise le protocole http, quand on tape spdy:// il utilise speedy
- 2 - Quoi qu'on tape, le navigateur a un algo qui lui permet de determiner lequel des protocole serait le meilleur pour charger ses pages, et donc l'adresse changera automatiquement en spdy:// ou http:// de la même manière que certaines configs serveur permettent de rediriger automatiquement en http / https ou desservir des pages en gzipé / flat.

quoi qu'il en soit, l'idée d'un nouveau protocole reste intéressante... à moins que le spdy:// de google soit simplement un spy:// camouflé :lol:

 

[MrBark]

Ce qu'il faut voir aussi c'est :

Ils annoncent "Sur un lot de 25 sites web populaires, les pages se chargent jusqu’à 55 % plus rapidement"
mais quand on voit comment sont codés la plupart des gros sites web... (facebook doit etre le meilleur exemple)
on se dit que 90% des webmasters ne savent vraiment pas coder, et même au plus "haut" niveau.

Par ex la super fonction "de multiples images placées dans un unique fichier" n'a strictement aucun intérêt pour quelqu'un qui sait coder propre.
Car lorsqu'on a plusieurs images (en général il s'agit de boutons, cadres etc.) on les met en général déja dans une meme image puis on utilise le css pour les "choisir". Et lorsque c'est du gif, la palette est commune donc c'est encore plus efficace que d'en compacter plusieurs dans une seule requête...

Vraiment, je ne trouve pas qu'à notre époque le temps de chargement des pages soit un problème !!!
Le seul problème de débit que les gens rencontrent survient avec les vidéos/audio, et la, leur protocole ne changera strictement rien !

Ma conclusion: tout cela est bien bidon !
Il ne s'agit que d'un projet de monopole de plus par google, masqué par un soit disant gain de performance (que de toute facon personne ne verra puisqu'il à lieu à un niveau ou il est parfaitement inutile...)

PS: I LOVE HTTP
c'est un protocole magnifique, oser y toucher est un crime.