El papel de la sesión
La sesión aquí mencionada se refiere a la sesión que se genera cuando el usuario navega por el sitio web. Dado que el protocolo http es apátrida, el servidor necesita asociar esta sesión con el usuario para que pueda saber qué usuario envió cada solicitud para realizar el correspondiente procesamiento y retroalimentación.
El principio de sesión
La esencia de la sesión es fácil de entender. Se puede considerar como un mapa. Puede colocar varios objetos en ella, como el usuario que inició sesión, los productos que el usuario agrega al carrito de compras y una serie de cosas relacionado con el usuario actualmente conectado. También se puede entender que la administración se mantiene a través de un mapa, la clave es session_id y el valor es session. Cuando cada navegador accede al servidor, el servidor generará un session_id único para indicarle al navegador y almacenarlo en la cookie, para que el navegador se inicie la próxima vez. La solicitud llevará este session_id para que el servidor pueda identificar al usuario que actualmente está iniciando la solicitud.
Gestión de sesión en un entorno de servidor único
En un entorno de servidor web independiente, no necesitamos prestar demasiada atención a la administración y el mantenimiento de la sesión, porque el servidor ya tiene su propia solución predeterminada, solo necesitamos obtener la sesión del servidor directamente a través de las clases relevantes.
Como se puede ver en la figura, hay un administrador de sesiones (SessionManager) dentro del servidor, cuya función principal es administrar la sesión y analizar la solicitud y poner la sesión en el hilo de la solicitud actual.
Con el aumento de las solicitudes del sistema, un solo servidor no puede satisfacer completamente las necesidades de los servicios existentes. Por lo tanto, es un resultado inevitable que los servidores se muevan hacia los clústeres. Una de las preguntas que ha surgido es ¿cómo administrar las sesiones?
Manejo de sesiones en un clúster de servidores
1. Solicitud de reenvío dirigido
Un balanceador de carga como Ngnix generalmente se usa en un clúster. Si se usa un mecanismo de operación por turnos para distribuir solicitudes, puede hacer que las dos solicitudes enviadas por el mismo usuario se distribuyan a diferentes máquinas, lo que hace que la sesión sea El llamado reenvío dirigido por solicitud es uno. La solicitud del usuario siempre se asignará a un solo servidor web, por lo que se puede garantizar el problema de sincronización de la sesión, pero este método tiene dos inconvenientes principales: 1. El efecto de El equilibrio de carga es difícil de reflejar y es fácil causar distribución de solicitudes. La desigualdad conduce a una presión excesiva en algunos servidores; 2. Si un servidor deja de funcionar, todas las sesiones asignadas a este usuario dejarán de ser válidas.
2. Sincronización de distribución de sesiones
El principio de este esquema es que cuando un servidor crea o modifica una sesión, transmite automáticamente a otros servidores. Este esquema solo es adecuado para clústeres de servidores pequeños. Si el número de clústeres es grande, las tormentas de clústeres pueden causar una seria degradación del rendimiento del servidor. !
3. Almacenamiento público
La solución anterior es mantener la sesión en la memoria del servidor local. La solución más elegante es almacenarla directamente en una ubicación pública, como en Redis o en una base de datos (no recomendado), reemplazando el SessionManager predeterminado del servidor. lograr el almacenamiento de sesiones en los servicios públicos. Hay muchas implementaciones de código específicas en github, que se pueden usar directamente después de la configuración básica.
4. Token
En cuanto al método de verificación de tokens, se utiliza principalmente en API de estilo restful. La función principal es verificar los permisos. He resumido los tokens y se pueden dividir aproximadamente en 3 tipos.
1 、 mac_token
Este tipo de token se utiliza generalmente para la autorización de API en redes inseguras.
El formato de los datos es el siguiente:
{
"user_id": 666666, // ID de usuario
"access_token": "2547TYSAs1zCsicMWpAA", // token 标识
"expires_at": "2017-12-12T10: 00: 00Z", // el tiempo de vencimiento de este token
"refresh_token:": "tGsg42OkF0XG5Qx2TlSGES", // para renovar
"mac_key": "adijq39jdlaska9asud", // la clave de hmac
"mac_algorithm", "hmac-sha-256" // nombre del algoritmo hmac
}
Encabezado http de autorización Antes de que el cliente envíe una solicitud de API que requiera autenticación de token mac, la información del token mac debe colocarse en Autorización en el encabezado HTTP
Autorización: MAC id = "2547TYSAs1zCsicMWpAA", nonce = "1418752425123: dj83hs9s", mac = "SLDJd4mg43cjQfElUs3Qub4L6xE ="
El algoritmo de cifrado específico puede ser definido por usted mismo. Por lo general, el enlace de solicitud, los parámetros, la marca de tiempo y otros datos se combinan y luego se cifran. Siempre que los resultados de cifrado del servidor y el cliente sean coherentes, se considerará legítimo token. El principio de procesamiento de la sesión es similar, se puede acceder a través de redis
2 、 token de portador
{
"user_id": 11232323, // ID de usuario
"access_token": "2YotnFZFEjr1zCsicMWpAA", // token 标识
"expires_at": "2014-12-12T10: 00: 00Z", // el tiempo de vencimiento de este token (vence en 30 días)
"refresh_token:": "tGzv3JOkF0XG5Qx2TlKWIA", // para renovar
}
El formato de transmisión específico es el siguiente:
Autorización: Portador "2YotnFZFEjr1zCsicMWpAA"
La diferencia con mac_token es que el token de portador es generalmente una llamada de API entre el servidor y el servidor, que es una transmisión confiable, por lo que el token no está encriptado.
3 、 JWT
La diferencia con el access_token que el servidor respondió anteriormente es que el JWT contiene cierta información del usuario, como la identificación del usuario, el nombre de usuario, etc. La ventaja de usar este token para la verificación del usuario es que puede obtener información básica sobre el usuario al analizar el token. La información no necesita consultar la base de datos, pero la desventaja es que aumenta la cantidad de datos transmitidos a través de la red. En realidad, no soy muy preciso al clasificar tokens como este. JWT se puede considerar como otro tipo de access_token. En el proceso de transmisión real, se pueden considerar solo dos tipos de mac o portador. Para un análisis más específico de jwt, Puede verificarlo en Google y tomarse un tiempo para mí. Escribiré prácticas específicas del proyecto de acuerdo con el método de verificación del token.
