Si l'on doit récuperer 50 elements sur une page, imaginons le scénario :
# envoi de la requete de la page, tout a fait normal, avec une unique entete en plus :
GET /mapage HTTP/1.0
Speedy-Accept: Version; multiples_get, push, truc;
Le serveur repond :
200 OK
Speedy-Accept: multiples_get
// ici il envoie le contenu de la page /mapage et reste en attente
Ici, le client sait maintenant qu'il peut faire ses multiples requetes, toujours sur la meme connexion, entre temps il a chargé mapage et sait donc quelles ressources suplementaires il doit traiter.
On a donc une requete http classique pour la premiere page (dont le contenu de retour peut etre compressé), mais ensuite, en reutiliant la meme socket, on fait une operation pour recuperer les ressources necessaires)
Donc la requete de la page initiale est au meme prix qu'avant, mais les requetes suivantes (les images/styles/videos/...) de la page sont bien moins lourdes, puisque elles se font en une unique requete sur le meme canal.
Et comme cela, on peut dès demain avoir du speedy sur nos machines. C'est rétro compatible, mais si le serveur gere et le browser gere, on y gagne.
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par Guillaum (site web personnel) . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 5.
# envoi de la requete de la page, tout a fait normal, avec une unique entete en plus :
GET /mapage HTTP/1.0
Speedy-Accept: Version; multiples_get, push, truc;
Le serveur repond :
200 OK
Speedy-Accept: multiples_get
// ici il envoie le contenu de la page /mapage et reste en attente
Ici, le client sait maintenant qu'il peut faire ses multiples requetes, toujours sur la meme connexion, entre temps il a chargé mapage et sait donc quelles ressources suplementaires il doit traiter.
Speedy-Mget /mapage, image1, image2, image3, image4
Speedy-Priority: by-size
Et la le serveur envoie TOUT, compressé à mort.
On a donc une requete http classique pour la premiere page (dont le contenu de retour peut etre compressé), mais ensuite, en reutiliant la meme socket, on fait une operation pour recuperer les ressources necessaires)
Donc la requete de la page initiale est au meme prix qu'avant, mais les requetes suivantes (les images/styles/videos/...) de la page sont bien moins lourdes, puisque elles se font en une unique requete sur le meme canal.
Et comme cela, on peut dès demain avoir du speedy sur nos machines. C'est rétro compatible, mais si le serveur gere et le browser gere, on y gagne.