Discussion :

[Djug]

Google veut doubler la vitesse du web


Google vient d’annoncer un nouveau projet pour l’amélioration du protocole http le protocole standard du web depuis 1996.

Ce nouveau projet baptisé SPDY (prononcé SPeeDY) est censé d’améliorer la vitesse du web en améliorant le protocole http par une couche supérieure.

Comme le protocole http se base principalement sur la communication par l’envoi et la réception des paquets, SPDY vient justement pour optimiser ces communications et de minimiser le temps de latence sur les serveurs.

Selon l’équipe Chromium qui travaille sur le projet SPDY, des tests dans des conditions de laboratoire ont montré que SPDY permet de charger les pages web 55% plus rapidement.

Source :
L’annonce sur le blog de l’équipe Chromium.


voir aussi :
le livre blanc du projet SPDY.

le code source du projet SPDY.

Qu’en pensez-vous ?

[jmini]

Il me semble avoir lu que le véritable problème du web sera a terme de reposer sur les paquets IP (et sur TCP/IP)

[shkyo]

...

Google vient d’annoncer un nouveau projet pour l’amélioration du protocole http le protocole standard du web depuis 1996.

Ce nouveau projet baptisé SPDY (prononcé SPeeDY) est censé d’améliorer la vitesse du web en améliorant le protocole http par une couche supérieure.
...

C'est pour mieux le contrôler et pouvoir injecter encore plus de pub... ??

Blague à part (quoique...), je pense comme jmini, à priori, les problèmes se situent plus au niveau couches réseau inférieures et de l'infrastructure plutôt que de l'http proprement dit...

[publicStaticVoidMain]

Comme le protocole http se base principalement sur la communication par l’envoi et la réception des paquets,

C'est écrit ou ca ?????
Dans quel RFC ????

[henolivier]

Google vient d’annoncer un nouveau projet

Encore ?

[longbeach]

Google veut ceci, Google fait cela, faut arrêter de prendre cette entreprise pour la reine des entreprises en matière d'innovation.

[shkyo]

Google veut ceci, Google fait cela, faut arrêter de prendre cette entreprise pour la reine des entreprises en matière d'innovation.

+1 !!! C'est clair, leurs managers doivent avoir leur intéressement annuel indexé sur le nombre de projets qu'ils lancent...

Mais d'ailleurs au fait, ils les terminent tous ? Ou ne disparaissent-ils pas dans le fin fond des entrailles du web ?

[tomlev]

C'est écrit ou ca ?????
Dans quel RFC ????

ben HTTP repose sur TCP, donc oui, tu échanges des paquets...

[marcel_kobain]

Augmenter de 50% la vitesse de chargement d'une page, cela ne double pas sa vitesse de chargement .... (mais seulement de 1.5 ...)
Sur quoi il se base pour dire qu'ils comptent doubler la vitesse du web ?

[Patriarch24]

Encore une annonce Googlesque. Ils vont accélérer le web, après avoir inventé le navigateur tip top cool qui déchire, sans parler du reste (le meilleur langage de programmation, l'offre Cloud la meilleure, etc etc).
Ils lancent plein de nouveaux projets, quelle activité ! C'est dingue, le nombre de posts dans la rubrique actualité qui commence par "Google a fait". Bientôt, on pourra remplacer notre "Jacques a dit" par un "Google a fait".

[NoobX]

google annonce pas mal de nouveauté en ce moment.

Vraisemblablement ca n'est que le début ....

Les fondations du libre vont avoir a a faire a un sérieux concurrent ....

[nouknouk]

Google veut ceci, Google fait cela, faut arrêter de prendre cette entreprise pour la reine des entreprises en matière d'innovation.

Certes, mais d'un autre côté qui peut vouloir leur reprocher d'avoir une grosse R&D qui essaie moultes trucs ?

D'autant que dans ce cas précis -et comme dit dans la news- la techno a vocation à être totalement open source ?

On ne peut pas vraiment me qualifier de 'fanboy Google', mais je préfère mille fois (*) une boite qui cherche à se développer et 'maintenir son rang' en investissant pour rester à la pointe de l'innovation plutôt qu'une boite qui se repose sur ses lauriers et fait simplement tout pour garder son petit monopole.

Certes, 90% ira sûrement droit à la poubelle après moins d'un an. Mais n'est-ce pas là justement le principe de la recherche : chercher énormément et trouver peu ?


(*) on peut préférer mille fois un Google mais on ne peut pas préférer mille fois mille ... non ... on peut préférer mille fois mille Google ... non ... on peut préférer mille fois un Google mais on ne peut pas préférer mille Google une fois.

[batataw]

Certes, mais d'un autre côté qui peut vouloir leur reprocher d'avoir une grosse R&D qui essaie moultes trucs ?

D'autant que dans ce cas précis -et comme dit dans la news- la techno a vocation à être totalement open source ?

On ne peut pas vraiment me qualifier de 'fanboy Google', mais je préfère mille fois (*) une boite qui cherche à se développer et 'maintenir son rang' en investissant pour rester à la pointe de l'innovation plutôt qu'une boite qui se repose sur ses lauriers et fait simplement tout pour garder son petit monopole.

Certes, 90% ira sûrement droit à la poubelle après moins d'un an. Mais n'est-ce pas là justement le principe de la recherche : chercher énormément et trouver peu ?


(*) on peut préférer mille fois un Google mais on ne peut pas préférer mille fois mille ... non ... on peut préférer mille fois mille Google ... non ... on peut préférer mille fois un Google mais on ne peut pas préférer mille Google une fois.

+1

[nicorama]

Certes, mais d'un autre côté qui peut vouloir leur reprocher d'avoir une grosse R&D qui essaie moultes trucs ?


Certes, 90% ira sûrement droit à la poubelle après moins d'un an. Mais n'est-ce pas là justement le principe de la recherche : chercher énormément et trouver peu ?

D'autant que, à part à la limite pour Google Wave, Google ne fait ps des pataques. Une annonce, et puis voilou. C'est vraiment de la recherche digne de ce nom.

En l'occurrence, il me semble qu'il s'agisse plus de faire progresser TCP/IP plutôt que Http, non ? Il parait que ce n'est pas superflu, mais ca va être chaud à faire passer !

[nouknouk]

En l'occurrence, il me semble qu'il s'agisse plus de faire progresser TCP/IP plutôt que Http, non ? Il parait que ce n'est pas superflu, mais ca va être chaud à faire passer !

Non, le protocole se situe au niveau de la couche applicative et reste transporté par TCP.

C'est une condition sine-qua-non pour espérer qu'un jour la technologie soit adoptée, car si c'était un remplaçant de TCP, ça voudrait dire qu'il faudrait mettre à jour ou remplacer l'ensemble du matériel réseau de la planète !

[Boulovale]

Je ne suis pas un expert en protocoles mais je pense qu'attaquer des protocoles de couches basses comme TCP ou encore IP n'est pas une bonne idée si l'on souhaite un jour faire adopter un nouveau protocole de communication.

Certes TCP et ses accusés de réception sont un frein énorme à la vitesse mais si ce protocole a été largement adopté parce qu'il apporte cette vérification qui nous assure de recevoir tous les paquets que nous attendons. Cependant à l'heure actuelle le débit n'est plus réellement un problème. Ce qui pose problème, et je pense que des personnes plus expertes en réseau pourront le confirmer, c'est latence, autrement "le temps de connexion".

Je ne sais pas si HTTP est l'unique cause de cette latence en tout cas les résultats publiés de SPDY semblent montrer que c'est une bonne piste pour améliorer ceci.

Je me perds un peu par contre : certains articles parlent d'une surcouche d'HTTP, d'autres parlent d'un remplacement (ce qui me parait ambitieux même pour Google).

En ce qui concerne cette initiative de Google, je ne me prononcerai pas vraiment, n'étant pas assez objectif je pense... je rejoins tout de même les personnes qui sont pour la R&D. Si toutes les boîtes en faisait autant nous n'aurions surement plus le temps de poster nos opinions...

[publicStaticVoidMain]

Comme le protocole http se base principalement sur la communication par l’envoi et la réception des paquets,

ben HTTP repose sur TCP, donc oui, tu échanges des paquets...

Si c'est comme ça que tu le comprends, pas gen problem.

Apres avoir jeté un coup d'oeil rapide sur leur site, je commence à comprendre ce qu'ils veulent faire. En gros, réduire les en-tetes HTTP inutiles et faire en sorte que l'on puisse faire plusieurs requetes en // dans une meme connection.
Ce qui apportera des améliorations à HTTP

[deadalnix]

Pour revenir à ces histoires de protocole :

Oui IP demande de la puissance de calcul car il faut calculer un routage pour chaque paquets (ceci dit, en IPv6, ça en demanderait moins). Mais ce n'est pas un problème, car on peut encapsuler le paquet IP dans divers protocoles de niveau 2, et ce sont eux qui font vraiment le travail. MPLS par exemple est une bonne solution à ce problème.

Par contre, TCP lui est vicié. En effet, TCP se base sur des envoies de paquets et le personne qui reçoit le paquet valide qu'elle les a bien reçus (ACK). Le problème, c'est que plus les débits montent, et plus les machines passent du temps à ne rien faire en attendant les ACK, le ping n'augmentant pas dans les même proportions que le débit (et est de plus limité physiquement par la vitesse de la lumière, alors que le débit ne l'est pas).

Mais changer un protocole comme TCP n'est pas facile. C'est pourquoi google propose dans l'un de ses solution d'utiliser un protocole tournant sur UDP, afin de rajouter certains fonctions fournies par TCP.

Enfin, HTTP est inadapté aux application en ligne. Il a diverses limitation qui sont gênantes et demande plein de ressources pour rien.

Les deux gros plus ici fournis par google sont pour moi la gestion native des proxy, qui n'a plus besoin d'être géré au niveau applicatif et la possibilité de push par le serveur.

En effet, les application actuelles sont obligées de faire du polling, ce qui demande beaucoup de ressources et est de plus moins efficace que si le serveur pouvait faire un push des données.

J'imagine rapidement l'effet d'une telle fonctionnalité sur les web messengers (comme gtalk) ou d'outils comme wave. Mais cela pourrait aussi être très profitable à twitter ou facebook.

[nouknouk]

Oui IP demande de la puissance de calcul car il faut calculer un routage pour chaque paquets (ceci dit, en IPv6, ça en demanderait moins). Mais ce n'est pas un problème, car on peut encapsuler le paquet IP dans divers protocoles de niveau 2, et ce sont eux qui font vraiment le travail. MPLS par exemple est une bonne solution à ce problème.

Oui et non: le routage devra également se faire en IPv6, autant qu'en IPv4.

La seule différence est qu'à priori l'énorme nombre d'adresses possible pour IPv6 devrait permettre de donner plus de possibilités pour hiérarchiser les plages d'adresses IP attribuées et donc réduire la complexité des tables de routage.

Ceci étant dit, même la (sur)complexité du routage actuel en IPv4 n'est depuis longtemps plus un souci, le hardware étant désormais largement capable de supporter d'énormes charges de flux.

Le MPLS dont tu parles (et qui, rappelons-le, et grosso modo uniquement utilisé dans les très gros liens du backbone internet) apportait des facilités de routage à l'origine ; mais désormais ceci étant un moindre problème du fait de l'augmentation des perfs du hardware, sa valeur ajoutée se situe plus dans les possibilités de gestion de la QoS que dans le routage.

Par contre, l'IPv6 sera au contraire plus complexe à router car de nouveaux concepts apparaissent avec la nouvelle version du protocole, notamment ceux axés sur la mobilité et le multicast routable sur le net.

Par contre, TCP lui est vicié. En effet, TCP se base sur des envoies de paquets et le personne qui reçoit le paquet valide qu'elle les a bien reçus (ACK). Le problème, c'est que plus les débits montent, et plus les machines passent du temps à ne rien faire en attendant les ACK, le ping n'augmentant pas dans les même proportions que le débit (et est de plus limité physiquement par la vitesse de la lumière, alors que le débit ne l'est pas).

Faux: le TCP c'est pas "j'ai envoyé un paquet, j'attends de recevoir l'ACK correspondant avant d'enovyer le suivant." TCP permet au contraire d'adapter le nombre d'ACK en fonction du débit et de la qualité du réseau intermédiaire (cf. la notion de 'fenêtre glissante' (sliding window) et donc de continuer à envoyer des données sans attendre l'ACK des données précédentes.

Cette technique est essentielle pour optimiser la connexion en fonction de la QoS (débit max, taux de perte de paquets, ...) d'un lien qu'on ne peut de totue façon pas qualifier à priori dans un réseau 'best effort' comme le net.

C'est au contraire si on n'utilisait pas ce genre de technique de fenêtre glissante qu'on aurait énormément de soucis à se faire pour la congestion du réseau car les connexions seraient incapables par exemple de se dimensionner en fonction du débit disponible.

La seule contrainte de cette technique est qu'au tout début de la connexion, il y a un (petit !) délai pendant lequel la fenêtre est trop petite comparé à sa taille optimale. Mais -au dela de l'énorme avancée qu'a représenté HTTP 1.1 et les [ame="http://en.wikipedia.org/wiki/HTTP_persistent_connections"]persistent connexions[/ame])- certains mécanismes additionnels permettent d'ores et déjà de palier à ce genre de désagrément pour les connexions de courte durée (genre HTML) où on voudrait pouvoir transférer un maximum de données dès le départ (cf. google 'TCP slow start' / 'TCP fast start').

Mais changer un protocole comme TCP n'est pas facile. C'est pourquoi google propose dans l'un de ses solution d'utiliser un protocole tournant sur UDP, afin de rajouter certains fonctions fournies par TCP.

J'avais cru lire le contraire: que SPDY se basait au contraire toujours sur TCP et ajoutait sa couche au niveau applicatif.

EDIT: les liens donnés dans la news confirment l'utilisation d'un canal en TCP (chiffré par SSL de surcroît): "SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection. "

Enfin, HTTP est inadapté aux application en ligne. Il a diverses limitation qui sont gênantes et demande plein de ressources pour rien.

Oui, mais:

1/ le HTTP n'est pas censé être là pour faire du client 'semi lourd' avec connexion permanente (ie. du push) ; c'est détourner son utilisation première et ce n'est utile que pour une fraction de sites internet ; la plupart se contentant parfaitement du polling.

2/ Il existe d'autres solutions pour faire ce genre de choses :

- des solutions qui ont l'énorme avantage d'être déjà compatibles partout et capable de s'adapter en fonction des capacités du browser utilisé (cf. les 'Comet servers', comme l'Ajax Push Engine) : pour les browser qui le supportent, les serveurs Comet sont déjà capables de réduire le dialogue à une seule connexion TCP permanente (cf. the forever IFrame technique).

- des solutions optimales et encore plus flexibles mais nécessitant un plugin supplémentaire (typiquement une socket TCP 'native' via une applet Flash/Java/Silverlight).

J'imagine rapidement l'effet d'une telle fonctionnalité sur les web messengers (comme gtalk) ou d'outils comme wave. Mais cela pourrait aussi être très profitable à twitter ou facebook.

Moui, mais comme dit avant ce n'est pas utile pour la majorité des sites (qui se suffisent du polling) et pour le 'push', que ce soit avec une connexion TCP permanente via une applet ou avec une appli basée sur le paradigme du 'Comet server', ça fonctionne déjà très bien en l'état tout ça.

Pour moi, l'intérêt du 'one connexion' n'est certes pas nul, mais reste relativement limité du fait qu'il entre en concurrence avec des mécanismes compatibles avec les browsers actuels; surtout ça reste marginal comparé à l'avancée qu'a déjà amené HTTP 1.1.

L'intérêt de SPDY est plus à voir du côté du multiplexage de flux et de la gestion des priorités des données envoyées, mais perso j'ai un peu peur du surcroît de complexité côté serveur qu'une telle techno va engendrer.

[publicStaticVoidMain]

Par contre, l'IPv6 sera au contraire plus complexe à router car de nouveaux concepts apparaissent avec la nouvelle version du protocole, notamment ceux axés sur la mobilité et le multicast routable sur le net.

Je ne vois pas en quoi le routage IPv6 sera plus complexe étant donné que le nombre de champs ds l'entete Ipv6 est inférieur à celui d'ipV4.
Ipv6 a justement été créé pour faciliter le routage non?