Sesiones adhesivas y no adhesivas

255

Quiero saber la diferencia entre sesiones pegajosas y no pegajosas. Lo que entendí después de leer en internet:

Adhesivo : solo habrá un único objeto de sesión allí.

Sesión no fija : objeto de sesión para cada nodo del servidor

session

— Sunny Gupta
fuente

Respuestas:

612

Cuando su sitio web es atendido por un solo servidor web, para cada par cliente-servidor, se crea un objeto de sesión y permanece en la memoria del servidor web. Todas las solicitudes del cliente van a este servidor web y actualizan este objeto de sesión. Si algunos datos deben almacenarse en el objeto de sesión durante el período de interacción, se almacenan en este objeto de sesión y permanecen allí mientras exista la sesión.

Sin embargo, si su sitio web es atendido por varios servidores web que se encuentran detrás de un equilibrador de carga, el equilibrador de carga decide a qué servidor web (físico) real debe ir cada solicitud. Por ejemplo, si hay 3 servidores web A, B y C detrás del equilibrador de carga, es posible que www.mywebsite.com/index.jsp se sirva desde el servidor A, www.mywebsite.com/login.jsp se sirva desde el servidor B y www.mywebsite.com/accoutdetails.php se sirven desde el servidor C.

Ahora, si las solicitudes se atienden desde (físicamente) 3 servidores diferentes, cada servidor ha creado un objeto de sesión para usted y debido a que estos objetos de sesión se encuentran en tres cuadros independientes, no hay forma directa de que uno sepa qué hay en el objeto de sesión del otro. Para sincronizar entre estas sesiones del servidor, puede que tenga que escribir / leer los datos de la sesión en una capa que sea común a todos, como una base de datos. Ahora escribir y leer datos a / desde una base de datos para este caso de uso puede no ser una buena idea. Ahora, aquí viene el papel de la sesión fija .

Si se le indica al equilibrador de carga que use sesiones fijas, todas sus interacciones sucederán con el mismo servidor físico, aunque haya otros servidores presentes. Por lo tanto, su objeto de sesión será el mismo durante toda su interacción con este sitio web.

En resumen, en el caso de las Sesiones permanentes, todas sus solicitudes se dirigirán al mismo servidor web físico, mientras que en el caso de un equilibrador de carga no fijo, puede elegir cualquier servidor web para atender sus solicitudes.

Como ejemplo, puede leer sobre Elastic Load Balancer de Amazon y las sesiones adhesivas aquí: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

— TJ-
fuente

@ TJ: ¿qué sucederá si un nodo no está disponible?

— gstackoverflow

En la mayoría de los casos, la sesión se perderá. En el caso de AWS ESB Si una instancia falla o no es saludable, el equilibrador de carga detiene la solicitud de enrutamiento a esa instancia, en su lugar elige una nueva instancia saludable basada en el algoritmo de equilibrio de carga existente. El equilibrador de carga trata la sesión como ahora "pegada" a la nueva instancia en buen estado y continúa las solicitudes de enrutamiento a esa instancia, incluso si la instancia fallida regresa.

— TJ-

¿Según qué información hace LoadBalancer que una sesión HTTP sea pegajosa? Especialmente en las conexiones HTTPS, este problema se vuelve interesante. ¿Alimenta al LB con la clave privada de los servidores web, para que pueda romper la conexión SSL y recuperar la sesión HTTP? ¿O el LB simplemente hace uso de la dirección IP del cliente? En este caso, ¿qué pasa con el servidor proxy donde varios clientes usan la misma dirección IP? O peor aún, clientes móviles, donde la dirección IP cambia con frecuencia. ¿O hay incluso una mejor técnica para eso? Gracias

— g000ze 01 de

Si, usted esta absolutamente en lo correcto. Para utilizar el encabezado "x-forwards-for" o una cookie fija en este contexto, se debe utilizar la terminación SSL y, por lo tanto, la solicitud debe ser descifrada en el LB.

— TJ-

@ g000ze Cuando se trata de aplicaciones que no se sirven directamente a Internet, creo que es común habilitar TLS solo en el servidor proxy más externo. (Un equilibrador de carga puede considerarse, quizás de manera simplista, como un tipo especial de servidor proxy, que puede pasar la solicitud a cualquiera de varios servidores). El tráfico entre el equilibrador de carga y los otros servidores se producirá en una red local segura. y, por lo tanto, a menudo no es necesario cifrarlo, o si necesita cifrarse, un certificado autofirmado puede ser suficiente (ya que el proxy se puede configurar para confiar en él).

— jpmc26

106

He respondido con más detalles aquí: https://stackoverflow.com/a/11045462/592477

O puedes leerlo allí ==>

Cuando utiliza el equilibrio de carga, significa que tiene varias instancias de tomcat y necesita dividir las cargas.

Si está utilizando la replicación de sesión sin sesión fija: imagine que solo tiene un usuario usando su aplicación web y tiene 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego el equilibrador de carga enviará algunas de estas solicitudes a la primera instancia de tomcat, y enviará algunas de estas solicitudes a la segunda instancia y otras a la tercera.
Si está utilizando una sesión fija sin replicación:Imagina que solo tienes un usuario usando tu aplicación web y tienes 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego el equilibrador de carga enviará la primera solicitud de usuario a una de las tres instancias de tomcat, y todas las demás solicitudes que envíe este usuario durante su sesión se enviarán a la misma instancia de tomcat. Durante estas solicitudes, si cierra o reinicia esta instancia de tomcat (instancia de tomcat que se usa), el loadbalancer envía las solicitudes restantes a otra instancia de tomcat que aún se está ejecutando, PERO ya que no usa la replicación de sesión, la instancia de tomcat que recibe las solicitudes restantes no tienen una copia de la sesión del usuario, entonces para este tomcat el usuario comienza una sesión: el usuario pierde su sesión y se desconecta de la aplicación web aunque la aplicación web todavía se está ejecutando.
Si está utilizando una sesión fija CON replicación de sesión:Imagina que solo tienes un usuario usando tu aplicación web y tienes 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego el equilibrador de carga enviará la primera solicitud de usuario a una de las tres instancias de tomcat, y todas las demás solicitudes que envíe este usuario durante su sesión se enviarán a la misma instancia de tomcat. Durante estas solicitudes, si cierra o reinicia esta instancia de tomcat (instancia de tomcat que se usa), el loadbalancer envía las solicitudes restantes a otra instancia de tomcat que aún se está ejecutando, a medida que usa la replicación de sesión, la instancia tomcat que recibe las solicitudes restantes tiene una copia de la sesión del usuario y luego el usuario continúa con su sesión: el usuario continúa navegando por su aplicación web sin desconectarse, el cierre de la instancia de tomcat no afecta la navegación del usuario.

— Nico
fuente

Hmm ... leyendo esto, me pregunto: ¿no tendría sentido tener una cuarta opción: replicación de sesión no adherente CON? O dicho de otra manera: ¿cuál es la ventaja de tener una sesión fija si se replica la sesión a las diferentes instancias de todos modos? Quiero decir, si está replicando las sesiones en todas las instancias, también podría reenviar la solicitud a cualquier servidor, ¿verdad? ¿Qué me estoy perdiendo?

— dingalapadum

@dingalapadum tienes razón, teóricamente puedes tener una replicación de sesión sin una sesión fija. Pero en el caso de un clúster grande, es malo para el rendimiento de la red. Luego, hay algunas estrategias para usar la replicación de sesión con una sesión fija como esta en tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) es poner una sesión fija y solo una réplica (un nodo aquí llamado administrador de respaldo que mantiene todas las réplicas de sesión de nodo).

— Nico

Luego, la sesión fija le permite tener solo una réplica de sesión, lo que es mejor en un clúster grande.

— Nico

Ah, ya veo: si entiendo correctamente, quiere decir que replicar todas las sesiones en todo el clúster inundaría el clúster internamente. Veo el problema. Oh, y ahora echar un vistazo más de cerca a su respuesta, acabo de ver, que este es en realidad el primer caso que describes ... 'duh me' ..

— dingalapadum

@dingalapadum su pregunta es bienvenida, permite mejorar la respuesta

— Nico