Sessions collantes et NON collantes

255

Je veux connaître la différence entre les sessions collantes et non collantes. Ce que j'ai compris après avoir lu sur Internet:

Sticky : seul un objet de session unique sera là.

Session non collante : objet de session pour chaque nœud de serveur

session

— Sunny Gupta
source

Réponses:

612

Lorsque votre site Web est desservi par un seul serveur Web, pour chaque paire client-serveur, un objet de session est créé et reste dans la mémoire du serveur Web. Toutes les demandes du client vont à ce serveur Web et mettent à jour cet objet de session. Si certaines données doivent être stockées dans l'objet de session pendant la période d'interaction, elles sont stockées dans cet objet de session et y restent tant que la session existe.

Cependant, si votre site Web est servi par plusieurs serveurs Web qui se trouvent derrière un équilibreur de charge, l’équilibreur de charge décide vers quel serveur Web (physique) réel chaque requête doit aller. Par exemple, s'il y a 3 serveurs Web A, B et C derrière l'équilibreur de charge, il est possible que www.mywebsite.com/index.jsp soit servi à partir du serveur A, www.mywebsite.com/login.jsp soit servi à partir de le serveur B et www.mywebsite.com/accoutdetails.php sont servis depuis le serveur C.

Maintenant, si les demandes sont servies depuis (physiquement) 3 serveurs différents, chaque serveur a créé un objet de session pour vous et parce que ces objets de session reposent sur trois boîtes indépendantes, il n'y a aucun moyen direct de savoir ce qu'il y a dans l'objet de session de l'autre. Afin de synchroniser entre ces sessions de serveur, vous devrez peut-être écrire / lire les données de session dans une couche commune à tous, comme une base de données. Maintenant, écrire et lire des données vers / depuis une base de données pour ce cas d'utilisation peut ne pas être une bonne idée. Maintenant, voici le rôle de la session collante .

Si l'équilibreur de charge est invité à utiliser des sessions persistantes, toutes vos interactions se produiront avec le même serveur physique, même si d'autres serveurs sont présents. Ainsi, votre objet de session sera le même tout au long de votre interaction avec ce site Web.

Pour résumer, en cas de sessions collantes, toutes vos demandes seront dirigées vers le même serveur Web physique tandis qu'en cas d'équilibreur de charge non collant, vous pourrez choisir n'importe quel serveur Web pour répondre à vos demandes.

Par exemple, vous pouvez lire sur l'Elastic Load Balancer d'Amazon et les sessions persistantes ici: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

— TJ-
source

@ TJ- que se passera-t-il si un nœud n'est pas disponible?

— gstackoverflow

Dans la plupart des cas, la session sera perdue. En cas d' AWS ESB Si une instance échoue ou devient défectueuse, l'équilibreur de charge arrête la demande de routage vers cette instance, mais choisit à la place une nouvelle instance saine basée sur l'algorithme d'équilibrage de charge existant. L'équilibreur de charge traite la session comme étant désormais «bloquée» sur la nouvelle instance saine et continue de router les demandes vers cette instance même si l'instance défaillante revient.

— TJ-

Selon quelles informations le LoadBalancer rend-il une session HTTP collante? Surtout sur les connexions HTTPS, ce problème devient intéressant. Nourrissez-vous le LB avec la clé privée des serveurs Web, afin qu'il puisse rompre la connexion SSL et récupérer la session HTTP? Ou le LB utilise-t-il simplement l'adresse IP du client? Dans ce cas, qu'en est-il du serveur proxy où plusieurs clients utilisent la même adresse IP? Ou pire encore, les clients mobiles, où l'adresse IP change fréquemment? Ou existe-t-il encore une meilleure technique pour cela? Merci

— g000ze

Oui, vous avez absolument raison. Afin d'utiliser l'en-tête "x-forwarded-for" ou un cookie collant dans ce contexte, la terminaison SSL doit être utilisée et, par conséquent, la demande doit être déchiffrée au niveau du LB.

— TJ-

@ g000ze Lorsque je traite des applications qui ne sont pas servies directement sur Internet, je pense qu'il est courant d'activer TLS uniquement sur le serveur proxy le plus externe. (Un équilibreur de charge peut être considéré, peut-être de manière simpliste, comme un type spécial de serveur proxy, qui peut transmettre la demande à n'importe lequel de plusieurs serveurs.) Le trafic entre l'équilibreur de charge et les autres serveurs se produira sur un réseau local sécurisé. , et il n'est donc souvent pas nécessaire de le chiffrer, ou s'il doit être chiffré, un certificat auto-signé peut être suffisant (puisque le proxy peut être configuré pour lui faire confiance).

— jpmc26

106

J'ai fait une réponse avec plus de détails ici: https://stackoverflow.com/a/11045462/592477

Ou vous pouvez le lire ici ==>

Lorsque vous utilisez l'équilibrage de charge, cela signifie que vous disposez de plusieurs instances de tomcat et que vous devez diviser les charges.

Si vous utilisez la réplication de session sans session persistante: imaginez que vous n'avez qu'un seul utilisateur utilisant votre application Web et que vous disposez de 3 instances tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis l'équilibreur de charge enverra certaines de ces demandes à la première instance de tomcat et enverra certaines autres de ces demandes à la deuxième instance et d'autres à la troisième.
Si vous utilisez une session persistante sans réplication:Imaginez que vous n'ayez qu'un seul utilisateur utilisant votre application Web et que vous disposez de 3 instances de tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis l'équilibreur de charge enverra la première demande utilisateur à l'une des trois instances tomcat, et toutes les autres demandes envoyées par cet utilisateur au cours de sa session seront envoyées à la même instance tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez cette instance tomcat (instance tomcat qui est utilisée), l'équilibreur de charge envoie les demandes restantes à une autre instance tomcat qui est toujours en cours d'exécution, MAIS comme vous n'utilisez pas la réplication de session, l'instance tomcat qui reçoit les demandes restantes n'ont pas de copie de la session utilisateur, puis pour ce matou l'utilisateur commence une session: l'utilisateur perd sa session et est déconnecté de l'application web bien que l'application web soit toujours en cours d'exécution.
Si vous utilisez une session persistante AVEC réplication de session:Imaginez que vous n'ayez qu'un seul utilisateur utilisant votre application Web et que vous disposez de 3 instances de tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis l'équilibreur de charge enverra la première demande utilisateur à l'une des trois instances tomcat, et toutes les autres demandes envoyées par cet utilisateur au cours de sa session seront envoyées à la même instance tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez cette instance tomcat (instance tomcat qui est utilisée), l'équilibreur de charge envoie les demandes restantes à une autre instance tomcat qui est toujours en cours d'exécution, lorsque vous utilisez la réplication de session, l'instance tomcat qui reçoit les demandes restantes a une copie de la session utilisateur puis l'utilisateur continue sa session: l'utilisateur continue de parcourir votre application web sans être déconnecté, l'arrêt de l'instance tomcat n'a pas d'impact sur la navigation de l'utilisateur.

— Nico
source

Hmm .. en lisant ceci, je me demande: ne serait-il pas logique d'avoir une quatrième option: Non-Sticky AVEC la réplication de session? Ou autrement dit: quel est l'avantage d'avoir une session persistante si l'on réplique la session sur les différentes instances de toute façon? Je veux dire, si vous répliquez les sessions à travers les instances, vous pouvez également transmettre la demande à n'importe quel serveur, non? Qu'est-ce que je rate?

— dingalapadum

@dingalapadum vous avez raison, théoriquement, vous pouvez avoir une réplication de session sans session persistante. Mais dans le cas d'un grand cluster, c'est mauvais pour les performances du réseau. Ensuite, il existe certaines stratégies pour utiliser la réplication de session avec une session persistante comme celle-ci dans tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) consiste à mettre une session persistante et une seule réplique (un nœud ici appelé gestionnaire de sauvegarde qui conserve toute la réplication de session de nœud)

— Nico

Ensuite, la session persistante vous permet de n'avoir qu'une seule réplique de session, ce qui est préférable dans un grand cluster.

— Nico

Ah je vois - Si je comprends bien, vous voulez dire que la réplication de toutes les sessions sur l'ensemble du cluster inonderait le cluster en interne - je vois le problème. Oh, et maintenant, en examinant de plus près votre réponse, je viens de voir que c'est en fait le premier cas que vous décrivez ... "duh me" ..

— dingalapadum

@dingalapadum votre question est la bienvenue, elle permet d'améliorer la réponse

— Nico