Google veut remplacer http: par spdy://
- Auteur de la discussion GUITEL
- Date de début
WRInaute occasionnel
Re: [Google] http: remplacer par spdy://
Merci Guitel pour l'information, c'est un article intéressant.
Merci Guitel pour l'information, c'est un article intéressant.
WRInaute passionné
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...
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...
@ 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.
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.
BadProcESs a dit:
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 a dit:
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.
WRInaute impliqué
+1 mais je laisse la discussion aux spécialistes.
@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
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
aladdin a dit:
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.
WRInaute accro
Petite question
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 ?
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).Marie-Aude a dit:Petite question
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 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.
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 serveursalva a dit:
et ce protocole risque d'être plus gourmand en ressources pour le serveur,...
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
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
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:
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:
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.Leonick a dit:
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).
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:
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:
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:
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:
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.
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.
Discussions similaires
