- bcp plus de socketa à allouer du coté serveur
Je pense le contraire, ne serait-ce que parce que tu rajoute une sémantique en disant quels sont les flux qui ont besoin de rester ouverts (le flush où il y a du PUSH) et quels sont ceux qui peuvent être fermés. Le problème actuel du keep-alive (et la raison pour laquelle il est désactivé sur un bon nombre de serveur), c'est qu'on ne sait jamais si une connexion doit rester ouverte ou pas, donc tout ce qu'on peut faire c'est avoir un temps d'inactivité au bout duquel on coupe la connexion. En permettant de cibler les flux qui doivent rester ouverts, tu peux déjà fermer toutes les connexions sur lesquels il n'y a pas de flux en PUSH. D'autre part, tu multiplexe ta connexion pour y faire passer plusieurs flux et par là même tu diminue ton nombre de connexions. Si on prend l'exemple de linuxfr :
Un utilisateur qui ouvre la page d'accueil et la page des journaux
En SPDY
On va ouvrir une seule connexion avec 2 flux, pas besoin de PUSH, on peut fermer la connexion après le chargement des 2 pages
avec du HTTP en Keep-Alive
On ouvre 2 connexions qui restent ouvertes jusqu'à expiration du timeout.
Un utilisateur qui ouvre la page d'accueil et la tribune
En SPDY
Il ouvre une connexion avec 2 flux dont l'un en PUSH. Lorsque les 2 pages sont chargées, la connexion reste ouverte car il reste un fluxh en PUSH. L'utilisateur n'a pas besoin de solliciter le serveur toute les quelques secondes, le serveur peut envoyer des données seulement lorsqu'un nouveau message arrive.
En HTTP avec du Keep-Alive
On ouvre 2 connexions, la première se ferme à expiration du timeout, tandis que l'autre reste ouverte mais le client doit en plus solliciter le serveur toutes les quelques secondes pour récupérer les nouveaux message.
Je pense que globalement, avec un protocole qui permet de caractériser les flux, le serveur peut faire des choix plus éclairés que de simplement attendre la fin d'un timeout, et par là même mieux gérer ses connexions et ses ressources.
Quand au problème sur les autres outils, il a bien fallut développer des framework pour faire de l'Ajax depuis quelques années, et on n'a que l'embarras du choix, je ne pense pas qu'il faudra très longtemps si ce protocole (ou un similaire) débarque, pour voir apparaître de nombreuses solutions techniques.
[^] # Re: Le vrai probleme:
Posté par Étienne . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.
Je pense le contraire, ne serait-ce que parce que tu rajoute une sémantique en disant quels sont les flux qui ont besoin de rester ouverts (le flush où il y a du PUSH) et quels sont ceux qui peuvent être fermés. Le problème actuel du keep-alive (et la raison pour laquelle il est désactivé sur un bon nombre de serveur), c'est qu'on ne sait jamais si une connexion doit rester ouverte ou pas, donc tout ce qu'on peut faire c'est avoir un temps d'inactivité au bout duquel on coupe la connexion. En permettant de cibler les flux qui doivent rester ouverts, tu peux déjà fermer toutes les connexions sur lesquels il n'y a pas de flux en PUSH. D'autre part, tu multiplexe ta connexion pour y faire passer plusieurs flux et par là même tu diminue ton nombre de connexions. Si on prend l'exemple de linuxfr :
Un utilisateur qui ouvre la page d'accueil et la page des journaux
En SPDY
On va ouvrir une seule connexion avec 2 flux, pas besoin de PUSH, on peut fermer la connexion après le chargement des 2 pages
avec du HTTP en Keep-Alive
On ouvre 2 connexions qui restent ouvertes jusqu'à expiration du timeout.
Un utilisateur qui ouvre la page d'accueil et la tribune
En SPDY
Il ouvre une connexion avec 2 flux dont l'un en PUSH. Lorsque les 2 pages sont chargées, la connexion reste ouverte car il reste un fluxh en PUSH. L'utilisateur n'a pas besoin de solliciter le serveur toute les quelques secondes, le serveur peut envoyer des données seulement lorsqu'un nouveau message arrive.
En HTTP avec du Keep-Alive
On ouvre 2 connexions, la première se ferme à expiration du timeout, tandis que l'autre reste ouverte mais le client doit en plus solliciter le serveur toutes les quelques secondes pour récupérer les nouveaux message.
Je pense que globalement, avec un protocole qui permet de caractériser les flux, le serveur peut faire des choix plus éclairés que de simplement attendre la fin d'un timeout, et par là même mieux gérer ses connexions et ses ressources.
Quand au problème sur les autres outils, il a bien fallut développer des framework pour faire de l'Ajax depuis quelques années, et on n'a que l'embarras du choix, je ne pense pas qu'il faudra très longtemps si ce protocole (ou un similaire) débarque, pour voir apparaître de nombreuses solutions techniques.