Pourquoi les connexions persistantes HTTP ne permettent pas la gestion de session ? Voilà la question que je me posais ce matin (triste, hein ?).
Quelques raisons de pourquoi la persistance HTTP 1.1 n’est pas utilisée pour la gestion des sessions:
- Les “connections” HTTP utilisent pas mal de mémoire et réduisent les performances. Une connexion ouverte a un impact négatif sur les performances du serveur. Pour ces raisons la valeur du keep-alive est généralement très basse (5 à 15 secondes par défaut sur Apache), c’est pourquoi c’est totalement insufisant pour une gestion de session convenable.
- Il est formellement interdit à un mandataire 1.1 d'établir une connexion persistante avec un client 1.0 : une gestion des sessions est donc de toute façon nécessaire
- Le W3C a conduit en 1997 une étude sur les performances montrant que HTTP 1.1 avec connexions persistentes introduisait une latence supplémentaire d'un facteur 1.5
- Les techniques de gestions de sessions par cookies / sessionID utilisées sont matures et tout à fait satisfaisantes
- La gestion des sessions par des cookies permet une plus grande souplesse
En pratique, en faisant abstraction des performances, il est cependant possible de gérer les sessions grâce aux connexions persistantes HTTP 1.1.
Pour terminé, le protocole HTTP 1.1 n’est pas considéré comme un protocole “connecté” car la peristance des connexions ne correspond pas aux critères d’un protocole mode connecté (en mode connecté, les 2 ordinateurs établissent une liaison virtuelle avant le transfert effectif des données. Un message d'erreur est renvoyé si les informations ne sont pas correctement réceptionnée).
Pour info, un chouette résumé des différents moyen de gestion des sessions par la plupart des serveurs (en mode non connecté bien sûr).
Inscription à :
Publier les commentaires (Atom)
1 commentaire:
This is great info to know.
Enregistrer un commentaire