Sea un portero calificado y clasifique las notas de otras personas con alguna información, y descubra que el resumen es bastante correcto. Guarde su propio catálogo antes de reimprimir, ¡y me temo que algún día se informará como 404!

De hecho, he analizado muchas soluciones y he descubierto que la mayoría de las implementaciones que funcionan son el intercambio distribuido de sesiones a través del almacenamiento en caché. El ex autor resumió el esquema de intercambio de sesiones basado en pornografía y pitón.

Además, se agregarán varias implementaciones java de uso compartido distribuido de sesiones.

¿Qué son exactamente sesión, cookie y token?

Breve descripción

Leí muchos artículos sobre sesiones y cookies antes de escribirlos. Algunas personas dijeron que primero había una cookie y luego una sesión. Algunas personas dicen que primero hay una sesión y luego una cookie. No siento que lo haya dicho con mucha claridad, y hablo de ello en general. Espero que este artículo sea útil para todos
Nota: Este artículo requiere que los lectores tengan conocimientos básicos de cookies, sesión y token.

http es un protocolo sin estado

¿Qué es apátrida? Es decir, esta solicitud no tiene nada que ver con la solicitud anterior, no se conoce y no está relacionada. El beneficio de esta apatridia es la velocidad. La desventaja es que si queremos www.zhihu.com/login.htmly www.zhihu.com/index.htmlasociamos, debes utilizar algunos medios y herramientas

cookie 和 sesión

Debido a la naturaleza sin estado de http, para permitir que todas las páginas web bajo un determinado nombre de dominio compartan determinados datos, aparecen sesiones y cookies. El proceso para que el cliente acceda al servidor es el siguiente

Primero, el cliente enviará una solicitud http al servidor.
Una vez que el servidor acepta la solicitud del cliente, establece una sesión y envía una respuesta http al cliente.Este encabezado de respuesta contiene el encabezado Set-Cookie. Este encabezado contiene el sessionId. El formato de Set-Cookie es el siguiente, consulte la Explicación detallada de las cookies para obtener más detalles.
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
Para la segunda solicitud iniciada por el cliente, si el servidor da set-Cookie, el navegador agregará automáticamente la cookie al encabezado de la solicitud
El servidor recibe la solicitud, descompone la cookie, verifica la información y devuelve una respuesta al cliente después de que la verificación es exitosa.

Proceso de solicitud

Nota

La cookie es solo una de las formas de realizar la sesión. Aunque es el más utilizado, no es el único método. Hay otras formas de almacenar después de deshabilitar las cookies, como ingresar la URL
Hoy en día la mayoría son Session + Cookie, pero solo usan sesión sin cookie, o solo usan cookie sin sesión, en teoría se puede mantener el estado de la sesión. Sin embargo, en la práctica, por muchas razones, generalmente no se usa solo.
Con la sesión, solo necesita guardar una identificación en el lado del cliente, de hecho, se guarda una gran cantidad de datos en el lado del servidor. Si se utilizan todas las cookies, el cliente no tiene tanto espacio cuando la cantidad de datos es grande.
Si solo usa cookies y no sesiones, toda la información de la cuenta se almacena en el cliente. Una vez secuestrada, se filtrará toda la información. Y la cantidad de datos del cliente aumenta, la cantidad de datos transmitidos a través de la red también aumentará

resumen

En resumen, una sesión es como una tabla de archivos de información del usuario, que contiene la información de autenticación del usuario, el estado de inicio de sesión y otra información. Y la cookie es la contraseña del usuario.

simbólico

El token también se llama token.
El método de autenticación de token por uid + tiempo + signo [+ parámetro fijo] es similar a una firma de certificado temporal , y es un método de autenticación sin estado en el lado del servidor, que es muy adecuado para la API REST Sin estado significa que el servidor no guarda datos relacionados con la autenticación de identidad.

composición

uid: la identidad única del usuario
hora: la marca de tiempo de la hora actual
sign: Firma, comprimida en una cadena hexadecimal de longitud fija usando hash / encriptar para evitar empalmes maliciosos por parte de un tercero
Parámetros fijos (opcional): algunos parámetros fijos de uso común se agregan al token para evitar búsquedas repetidas en la base de datos

Tienda

El token generalmente se almacena en localStorage, cookie o sessionStorage en el cliente. Generalmente almacenado en la base de datos del servidor.

proceso de autenticación de token

El proceso de autenticación del token es muy similar al de las cookies.

Una vez que el usuario inicia sesión, el servidor devuelve el token al cliente después de que se haya realizado correctamente.
El cliente recibe los datos y los guarda en el cliente.
El cliente vuelve a acceder al servidor y coloca el token en los encabezados.
El lado del servidor usa un filtro para verificar. Si la verificación es exitosa, se devolverán los datos solicitados y, si la verificación falla, se devolverá un código de error.

El token puede resistir csrf, la cookie + la sesión no

Si el usuario está iniciando sesión en la página web del banco, la página web no está protegida contra ataques csrf. El atacante puede inyectar una imagen, la imagen src es http://www.bank.com/api/transfer?count=1000&to=Tom. En el caso de sesión + cookie, el usuario ya ha transferido 1.000 yuanes a Tom cuando abre la página web. Porque una vez que se establece la sesión, la página del dominio actual y todas las páginas debajo de la ruta de la página comparten cookies. En el momento de la solicitud de img, el navegador agregará automáticamente la cookie al encabezado de la solicitud. Pero el token es diferente. Los desarrolladores agregan manualmente el token a la solicitud cada vez que inician una solicitud. Es decir, al abrir la página para solicitar img, no hay ningún token en el encabezado de la solicitud.

Sesión y token en caso distribuido

Ya sabemos que las sesiones tienen estado en todo momento, y generalmente se almacenan en la memoria del servidor o en el disco duro.Cuando el servidor está distribuido o agrupado, la sesión enfrentará problemas de equilibrio de carga.

En el caso del equilibrio de carga con varios servidores, es difícil confirmar si el usuario actual está conectado, porque varios servidores no comparten sesiones. Este problema también se puede resolver almacenando la sesión en un servidor, pero el efecto del equilibrio de carga no se puede lograr por completo.

El token no tiene estado y toda la información del usuario se almacena en la cadena del token.

El cliente inicia sesión y transfiere información al servidor. Después de recibirla, el servidor cifra la información del usuario (token) y la transmite al cliente. El cliente almacena el token en un contenedor como localStroage. El cliente pasa el token cada vez que visita y el servidor descifra el token para saber quién es el usuario. A través del cifrado y descifrado de la CPU, el servidor no necesita almacenar la sesión para ocupar espacio de almacenamiento, lo que resuelve el problema del equilibrio de carga de varios servidores. Este método se llama JWT (Json Web Token)

para resumir

La sesión se almacena en el servidor, que puede entenderse como una lista de estados con un símbolo de identificación único sessionId, que generalmente se almacena en una cookie. El servidor analiza el sessionId después de recibir la cookie y luego busca en la lista de sesiones para encontrar la sesión correspondiente. Confíe en las cookies
Una cookie es similar a un token, equipado con un sessionId, almacenado en el cliente, y el navegador generalmente lo agrega automáticamente.
Un token también es similar a un token. No tiene estado. La información del usuario se cifra en el token. Después de recibir el token, el servidor lo descifra para saber qué usuario es. El desarrollador debe agregarlo manualmente.
jwt es solo un esquema de autenticación entre dominios

Solución de sesión en clúster de equilibrio de carga

Prefacio

Después de usar el equilibrio de carga para un sitio web, un problema importante que debemos enfrentar es la forma de tratar las sesiones. Ya sea PHP, Python, Ruby o Java, siempre que se use el servidor para guardar la sesión, el problema de La sesión debe tenerse en cuenta al realizar el equilibrio de carga.

Compartir directorio:

¿Dónde está el problema? ¿Cómo lidiar con ello?
Persistencia de la sesión (caso: Nginx, Haproxy)
Replicación de sesión (caso: Tomcat)
Uso compartido de sesiones (caso: Memcached, Redis)

¿Dónde está el problema?

Para explicar desde el lado del usuario, cuando un usuario accede al servidor back-end A por el agente de equilibrio de carga por primera vez e inicia sesión, la información de inicio de sesión del usuario se retiene en el servidor A; cuando el usuario envía una solicitud nuevamente, puede ser afectado por la política de equilibrio de carga Representar a un servidor back-end diferente, como el servidor B. Dado que este servidor B no tiene la información de inicio de sesión del usuario, el usuario debe iniciar sesión nuevamente. Esto es insoportable para los usuarios. Por lo tanto, al implementar el equilibrio de carga, debemos considerar los problemas de sesión.

En el equilibrio de carga, para el procesamiento de sesiones, generalmente tenemos los siguientes métodos:

- Mantener sesión
- Replicación de sesiones
- Compartir sesión

1. Retención de sesiones

La retención de sesiones (retención de sesiones) es uno de los términos más comunes que vemos. A través de la retención de sesiones y el equilibrio de carga, cuando se realiza la distribución de solicitudes, se garantiza que cada cliente tendrá acceso fijo al mismo servidor de aplicaciones en el back-end. El esquema de persistencia de la sesión tiene implementaciones correspondientes en todo el equilibrio de carga. Y esto está en la capa de equilibrio de carga para resolver el problema de la sesión.

Nginx realiza la retención de sesión de equilibrio de carga

Para Nginx, puede elegir el método de retención de sesión para implementar el equilibrio de carga. El flujo ascendente de nginx actualmente admite 5 formas de distribución, de las cuales hay dos soluciones de sesión más comunes, ip_hash y url_hash. Nota: Este último no es un módulo oficial y requiere instalación adicional.

ip_hash （）

Cada solicitud se asigna según el resultado hash de la ip de acceso, de modo que cada visitante tenga un acceso fijo a un servidor back-end, logrando el método de retención de sesión.

Ejemplo:

upstream bakend {
   ip_hash;
   server192.168.0.11:80;
   server192.168.0.12:80;
 }

Haproxy realiza la retención de sesión de equilibrio de carga

Como un excelente software de proxy inverso y equilibrio de carga, Haproxy también proporciona una variedad de métodos para la retención de sesiones.Los dos más comúnmente utilizados se enumeran a continuación:

Hash de dirección de origen ( no se admite el equilibrio de carga )

Haroxy asigna la IP del usuario a un servidor real fijo después del cálculo hash (similar al comando ip hash de nginx)

配置指令:balancesource

Utilice cookies para la identificación ( obviamente, esta operación insegura no es confiable )

Es decir, Haproxy inserta una cookie en el navegador del usuario después de que el usuario visita por primera vez, y el navegador traerá esta cookie a Haproxy para que Haproxy la identifique la próxima vez que el usuario visite.

配置指令:cookie  SESSION_COOKIE  insert indirect nocache

El ejemplo de configuración es el siguiente:

cookie SERVERID insert indirect nocache
server web01 192.168.56.11:8080 check cookie web01
server web02 192.168.56.12:8080 check cookie web02

Desventajas de la retención de sesiones:

La retención de sesiones parece resolver el problema de sincronización de sesiones, pero trae algunos otros problemas:

Carga desequilibrada: debido al uso de la retención de sesión, está claro que no se puede garantizar el equilibrio de carga absoluto.
El problema no está completamente resuelto: si el servidor backend está inactivo, la sesión de este servidor se pierde y el usuario asignado a esta solicitud de servicio aún necesita iniciar sesión nuevamente.

2. Replicación de sesiones

Dado que nuestro objetivo es mantener la sesión del usuario en todos los servidores, ¿puede ser suficiente copiar la información de la sesión en cada servidor de aplicaciones a otros nodos del servidor? Esta es la segunda forma de lidiar con la sesión: la replicación de la sesión.

La replicación de sesión es compatible con Tomcat. Se basa en multidifusión IP (multidifusión) para completar la replicación de sesión. La replicación de sesión de Tomcat se divide en dos tipos:

Replicación de sesión global: use Delta Manager para replicar la información modificada en la sesión a todos los demás nodos del clúster.
Replicación no global: use Backup Manager para la replicación, replicará la sesión en un nodo de respaldo designado.

Sin embargo, no voy a explicar aquí la configuración de la replicación de sesiones de Tomcat. Si tiene algún requisito, puede consultar la documentación oficial de Tomcat, principalmente porque la replicación de sesiones no es adecuada para clústeres grandes. Según el caso práctico del autor en producción, se producirán varios problemas después de que el clúster exceda los 6 nodos, y no se recomienda para uso en producción (la sincronización puede causar demoras ) .

3. Compartir sesiones

Dado que la retención de sesiones y la replicación de sesiones no son perfectas, ¿por qué no colocamos la sesión en un lugar unificado, de modo que todos los nodos del clúster puedan acceder a la sesión en un solo lugar para resolver el problema?

¿Dónde se almacena la sesión ?

Para Session, debe usarse con frecuencia, aunque puede almacenarlo en una base de datos, en un entorno de producción real, recomendaría almacenarlo en datos KV distribuidos con un rendimiento más rápido, como Memcached y Redis.

Uso compartido de sesiones de configuración de PHP

Felicitaciones si está usando PHP, la configuración es muy simple. PHP puede almacenar Sesiones en Memcached o Redis a través de dos líneas de configuración, claro que hay que configurarlas previamente. Modificar php.ini:

session.save_handler = memcache
session.save_path = "tcp://192.168.56.11:11211"

Utilice Redis para almacenar la sesión

session.save_handler = redis
session.save_path ="tcp://localhost:6379"

Recordatorio: no olvide instalar los complementos de Memcache o Redis para PHP.

Tomcat configura el uso compartido de sesiones

Podemos usar MSM (Memcached Session Manager) para almacenar también la sesión en Memcache. La dirección de Github es la siguiente: https://github.com/magro/memcached-session-manager actualmente es compatible con Tomcat 6.x7.xy 8. x versión de.

Si desea utilizar Redis, también hay un código abierto disponible, pero desafortunadamente la versión de Tomcat 8.x no es compatible temporalmente: https://github.com/jcoleman/tomcat-redis-session-manager

Uso compartido de sesiones de configuración de Django

En Django, la sesión se administra a través de un middleware. Si desea utilizar Session en su aplicación, debe agregar'django.contrib.sessions.middleware.SessionMiddleware 'a la variable MIDDLEWARE_CLASSES en settings.py. El motor de sesión de Django puede almacenar la sesión en tres lugares: base de datos, caché y archivo.

Use la base de datos para guardar la sesión ( no eficiente )

Si desea utilizar las sesiones admitidas por la base de datos, debe agregar 'jango.contrib.sessions' a su configuración INSTALLED_APPS. Una vez completada la configuración, ejecute manage.py migrate para instalar una tabla de base de datos que guarde los datos de la sesión.

Usar caché para mantener la sesión

Para una sesión en caché simple:

Puede establecer SESSION_ENGINE en "django.contrib.sessions.backends.cache". En este punto, los datos de la sesión se almacenarán directamente en su caché. Sin embargo, es posible que los datos almacenados en caché no sean duraderos: si el caché se llena o el servidor de caché se reinicia, los datos almacenados en caché pueden limpiarse.

Para almacenar en caché los datos de forma persistente:

Puede establecer SESSION_ENGINE en "django.contrib.sessions.backends.cached_db". Su operación de escritura usa la caché, y cada escritura en la caché se escribirá nuevamente en la base de datos. Para una sesión de lectura, si los datos no están en la caché, se leen de la base de datos. El almacenamiento de ambas sesiones es muy rápido, pero el almacenamiento en caché simple es más rápido porque renuncia a la persistencia. En la mayoría de los casos, el backend cached_db es lo suficientemente rápido, pero si necesita exprimir el último punto de rendimiento y aceptar el riesgo de pérdida de datos de la sesión, puede usar la caché en lugar de cached_db

Usar archivo para guardar sesión

El uso de archivos para guardar sesiones ya no es nuestra discusión, porque es difícil de compartir, PHP también almacena las sesiones en el directorio / tmp por defecto.

Cookie, Session y Token
son la diferencia entre la verificación de cookie y token.
¿Por qué la cookie necesita sesión? ¿Es necesario
el diseño de CSRF Token?
Problemas y soluciones de cookies, token y sesión Soluciones de sesión en
clústeres de equilibrio de carga
Introducción a JWT
Json Web Tutorial introductorio de tokens

Comprender a fondo las soluciones de sesión, cookie, token y sesión en clústeres de equilibrio de carga