Le navigateur ne fait pas à la fois client et serveur, il initie une connexion TCP vers le serveur sur laquelle on ouvre des flux bidirectionnels, le serveur comme le client peut donc envoyer des données. Par rapport au modèle du HTTP qui est du style
- Le client envoie une requête
- Le serveur répond
- Le client envoie une requête
- Le serveur répond
- etc.
En SPDY, le client lit sur la socket en permanence pour que le serveur puisse également être à l'initiative de certaines requête, comme dit plus haut pour éviter d'avoir à poller des changements d'état.
Une connexion en HTTP est directement liée à la connexion TCP sous-jacente, en SPDY, la connexion HTTP se traduit plutôt par l'ouverture d'un flux sur la connexion TCP. Par exemple si j'ai en permanence 3 onglets ouverts sur https://linuxfr.org/myhttps://linuxfr.org/journal et https://linuxfr.org/forums il me faut 3 connexion http (voir une par fichier si je ne fait pas de keep-alive qui n'est pas obligatoire), avec SPDY, j'ouvre une connexion TCP sur laquelle j'ouvre 3 flux SPDY.
[^] # Re: Push
Posté par Étienne . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 5.
- Le client envoie une requête
- Le serveur répond
- Le client envoie une requête
- Le serveur répond
- etc.
En SPDY, le client lit sur la socket en permanence pour que le serveur puisse également être à l'initiative de certaines requête, comme dit plus haut pour éviter d'avoir à poller des changements d'état.
Une connexion en HTTP est directement liée à la connexion TCP sous-jacente, en SPDY, la connexion HTTP se traduit plutôt par l'ouverture d'un flux sur la connexion TCP. Par exemple si j'ai en permanence 3 onglets ouverts sur https://linuxfr.org/my https://linuxfr.org/journal et https://linuxfr.org/forums il me faut 3 connexion http (voir une par fichier si je ne fait pas de keep-alive qui n'est pas obligatoire), avec SPDY, j'ouvre une connexion TCP sur laquelle j'ouvre 3 flux SPDY.
Étienne