Successfully reported this slideshow.

Http SessionLess : Pourquoi, comment ?

0

Share

Upcoming SlideShare
SdE 9 - Threads
SdE 9 - Threads
Loading in …3
×
1 of 10
1 of 10

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Http SessionLess : Pourquoi, comment ?

  1. 1. SessionLess : Pourquoi et Comment ? Guillaume Wallet Thomas Recloux
  2. 2. HTTP : Rappels ● HTTP est un protocole applicatif basé sur TCP ● Fonctionne en mode requête / réponse ● HTTP est un protocole déconnecté : chaque couple requête / réponse est indépendant ○ Pas de notion native de session.
  3. 3. HTTP Rappels ○ Chaque requête est associée à un verbe d'action ■ GET, POST, PUT, DELETE, .... ■ ○ Et à l'URL de la ressource associée ■ Chaque requête et réponse sont couplées à des entêtes ■ Négociation de contenu ■ Encoding ■ Taille ■ Cache ■ ...
  4. 4. HTTP et Session HTTP n'intègre pas de notion de session .... mais nos applications oui. Comment : Lors du premier accès à une application, le serveur g un ID de session, associe un espace mémoire à cet ID et fournit l'ID sous forme de Cookie au client. Cette session est bien pratique pour ● Faire du cache ● Stocker l'état de la conversation entre le navigateur et le serveur
  5. 5. HTTP et Session ● Ex : Recherche d'un article ○ GET /search.do -> affichage du champs de recherche ○ POST /search.do -> résultat de la recherche ○ GET /search-result?idx=1 -> Affichage du premier résultat de la recherche
  6. 6. HTTP & Session Les inconvénients de la session ● L'espace mémoire est localisé sur un serveur ○ Difficulté de gérer cet espace mémoire dans le temps (fourre tout) ○ Nécessité de dimensionner l'infrastructure de production en conséquence ■ Combien d'utilisateurs en pic, quelle taille de session par utilisateur ○ Au bout de combien de temps purger cet espace mémoire ?
  7. 7. HTTP & Session ● Répartition de charge / haute disponibilité ○ Mes requêtes doivent être redirigées vers le même serveur ■ Impact sur les composants de répartition de charge ○ Et si mon serveur tombe ? ■ Option 1 : Je suis redirigé vers un nouveau serveur qui ne connait pas ma session -> Plouf ■ Option 2 : je suis redirigé vers un autre serveur qui connait ma session mais doit encaisser beaucoup de requêtes supplémentaires -> Plouf aussi ● Scalabilité : Si je rajoute une machine, les sessions existentes ne pourront pas en profiter. ● Mise à jour : Les objets en session sont liés à une version de l'application => complexité de déploiement d'une nouvelle version
  8. 8. Mais comment faire sans session ? ● Rôle : faire du cache ○ Utiliser .... des solutions de cache :) ■ Au sein de l'application : ehCache, osCache ■ Dans des systèmes dédiés : memcache, terracota, ... ○ Ne pas faire de cache : faire confiance à l'infrastructure (OS, Base, ...) ● Rôle : stocker l'état de la conversation ○ Avoir un minimum d'état conversationnel .... ■ Penser bookmark ■ URL significatives autosuffisantes
  9. 9. Mais comment faire sans session ? ● Ex : ○ GET /search -> affichage du champs de recherche ○ GET /search?txt=shoes -> résultat de la recherche ○ GET /catalog/shoes/453-black-shoes-women -> Affichage du premier résultat de la recherche
  10. 10. Serveur sans état ○ Stocker l'état ailleurs ■ Sur le client ■ Applis Ajax avec une seule page : Stocker l'état sous forme d'objets JavaScript (GWT) ■ Autres clients riches : Flex , ... ■ Capacités de stockage HTML5 (LocalStorage, ....) ■ Dans la base de données ■ (Retour de la vengeance du cache) ■ Faire transiter ces données à chaque requête / réponse ■ Champs cachés ■ Cookies

×