¿Qué es SESSION en chino?

1. El término sesión

En mi experiencia, el grado de abuso de la palabra sesión probablemente sea superado solo por transacción. Lo que es más interesante es que transacción y sesión se utilizan en. ciertos contextos El significado es el mismo.

Sesión suele traducirse como conversación en chino. Su significado original se refiere a una serie de acciones/mensajes que tienen un principio y un final. Por ejemplo, al realizar una llamada telefónica, la serie de procesos desde la elección. levantar el teléfono para marcar y colgar el teléfono se puede llamar Es una sesión. A veces podemos ver palabras como "Durante una sesión del navegador,..." La palabra sesión aquí se usa en su significado original, que se refiere al período desde la apertura hasta el cierre de una ventana del navegador①. Lo más confuso es la frase "el usuario (cliente) durante una sesión", que puede referirse a una serie de acciones del usuario (generalmente una serie de acciones relacionadas con un propósito específico, como desde iniciar sesión hasta comprar bienes). El proceso de compra en línea desde el pago hasta el cierre de sesión a veces se denomina transacción). Sin embargo, a veces puede referirse simplemente a una conexión o puede referirse al significado ①. La diferencia solo se puede inferir del contexto ②.

Sin embargo, cuando la palabra sesión se asocia con un protocolo de red, a menudo implica dos significados: "orientado a la conexión" y/o "mantenimiento del estado". "Orientado a la conexión" se refiere a la comunicación. , ambas partes primero deben establecer un canal de comunicación, como hacer una llamada telefónica. La comunicación no puede comenzar hasta que la otra parte responda el teléfono. Por el contrario, cuando envía una carta, no puede confirmar si la dirección de la otra parte es correcta cuando la envía. la carta, el canal de comunicación puede no estar establecido, pero para el remitente la comunicación ya ha comenzado. "Mantener el estado" significa que la parte que se comunica puede asociar una serie de mensajes para que los mensajes puedan depender unos de otros. Por ejemplo, un camarero puede reconocer a un antiguo cliente que vuelve y recordar que el cliente le debía un dólar a la tienda la última vez. . Ejemplos de esta categoría incluyen "una sesión TCP" o "una sesión POP3" ③.

En la era del intenso desarrollo de los servidores web, la semántica de sesión en el contexto del desarrollo web se ha ampliado. Su significado se refiere a una clase utilizada para mantener el estado entre el cliente y el servidor. . A veces, la sesión también se utiliza para referirse a la estructura de almacenamiento de esta solución, como "Guardar xxx en la sesión"⑤. Dado que varios lenguajes utilizados para el desarrollo web brindan soporte para esta solución hasta cierto punto, sesión también se usa para referirse a la solución de ese lenguaje en el contexto de un lenguaje específico, como suele ser el javax.servlet proporcionado en Java. es equivalente al signo principal de la tienda, como Procter & Gamble. También puede especificar una máquina específica en un dominio, como www.google.com o froogle.google.com. Puede usar Rejoice para hacerlo.

La ruta es la ruta URL que sigue al nombre de dominio, como / o /foo, etc., que se puede comparar con un determinado contador de Rejoice.

La ruta y el dominio juntos constituyen el alcance de la cookie.

Si no se establece el tiempo de caducidad, significa que la vida útil de esta cookie es durante la sesión del navegador. Mientras la ventana del navegador esté cerrada, la cookie desaparecerá. Este tipo de cookie que dura mientras dura la sesión del navegador se denomina cookie de sesión. Las cookies de sesión generalmente no se almacenan en el disco duro sino en la memoria. Por supuesto, este comportamiento no está especificado en la especificación. Si se establece un tiempo de vencimiento, el navegador guardará las cookies en el disco duro. Si cierra y abre el navegador nuevamente, estas cookies seguirán siendo válidas hasta que se exceda el tiempo de vencimiento establecido.

Las cookies almacenadas en el disco duro se pueden compartir entre diferentes procesos del navegador, como dos ventanas de IE. Cada navegador tiene diferentes métodos de procesamiento de las cookies almacenadas en la memoria.

Para IE, la ventana abierta presionando Ctrl-N (o desde el menú Archivo) en una ventana abierta se puede compartir con la ventana original, pero un proceso de IE recién abierto que utiliza otros métodos no puede compartir la ventana ya abierta. Mozilla Firefox 0.8, todos los procesos y pestañas pueden compartir la misma cookie. En términos generales, la ventana abierta con window.open de javascript compartirá la cookie de memoria con la ventana original. El manejo de las cookies de sesión por parte del navegador, que sólo reconoce la cookie pero no a la persona, a menudo causa grandes problemas a los desarrolladores de aplicaciones web que utilizan el mecanismo de sesión.

El siguiente es un ejemplo de cómo Google configura un encabezado de respuesta de cookie

HTTP/1.1 302 Found

Ubicación: /intl/zh-CN/

Establecer cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8 expires=Sun, 17 de enero de 2038 19:14:07 GMT path=/; dominio =.google.com

Tipo de contenido: texto/html

Esto es parte del registro de comunicación HTTP capturado utilizando el software HTTP Sniffer HTTPLook

Examinar El servidor envía cookies automáticamente cuando vuelve a acceder a los recursos de Google.

Al usar Firefox, puede observar fácilmente el valor de las cookies existentes.

Al usar HTTPLook con Firefox, puede comprender fácilmente el principio de funcionamiento de las cookies.

IE también se puede configurar para que pregunte antes de aceptar cookies.

Este es un cuadro de diálogo que solicita aceptar cookies.

4. Comprender el mecanismo de sesión

El mecanismo de sesión es un mecanismo del lado del servidor. El servidor utiliza una estructura similar a una tabla hash (o puede usar una tabla hash) para guardar. información.

Cuando el programa necesita crear una sesión para la solicitud de un cliente, el servidor primero verifica si la solicitud del cliente ya contiene un identificador de sesión, llamado ID de sesión. Si ya contiene una ID de sesión, significa que hay una. La sesión se ha creado para este cliente antes, y el servidor recuperará esta sesión de acuerdo con la identificación de la sesión y la usará (si no se puede recuperar, puede crear una nueva. Si la solicitud del cliente no incluye la identificación de la sesión, creará una sesión para esta sesión de cliente y generará una identificación de sesión asociada con esta sesión. El valor de la identificación de sesión debe ser una cadena que no sea repetitiva ni fácil de encontrar patrones para falsificar. cliente en esta respuesta.

Se pueden utilizar cookies para guardar este ID de sesión, de modo que durante el proceso de interacción, el navegador pueda mostrar automáticamente esta identificación al servidor según las reglas. Generalmente, el nombre de esta cookie es similar a SEEESIONID. Por ejemplo, para la cookie generada por weblogic, JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764, su nombre es JSESSIONID.

Dado que las cookies se pueden deshabilitar artificialmente, debe haber otros mecanismos para pasar la identificación de la sesión al servidor cuando las cookies están deshabilitadas. Una tecnología utilizada con frecuencia se llama reescritura de URL, que consiste en agregar la identificación de la sesión directamente al final de la ruta URL. Hay dos formas de agregarla como información adicional a la ruta URL, en el formato /wls/. docs70/webapp/ weblogic_xml.html#1036869

6. Preguntas frecuentes sobre HttpSession

(En esta sección, el significado de sesión es una mezcla de ⑤ y ⑥)

1. La sesión es cuándo se crea

Un malentendido común es que la sesión se crea cuando un cliente accede a ella. Sin embargo, el hecho es que no se crea hasta que un programa del lado del servidor. llama a una declaración como HttpServletRequest.getSession(true). Tenga en cuenta que si JSP no usa explícitamente lt;@page session="false"gt para cerrar la sesión, el archivo JSP agregará automáticamente dicha declaración HttpSession session = HttpServletRequest.getSession (true) cuando se compila en un Servlet, este también es el origen del objeto de sesión oculto en JSP;

Dado que la sesión consume recursos de memoria, si no planea utilizar la sesión, debe cerrarla en todos los JSP.

2. ¿Cuándo se elimina la sesión?

Según la discusión anterior, la sesión se elimina en las siguientes circunstancias: a. El programa llama a HttpSession.invalidate(); La distancia desde la última colección El intervalo de tiempo entre los ID de sesión enviados al cliente excede la configuración del tiempo de espera de la sesión o c. El proceso del servidor se detiene (sesión no persistente)

3. sesión cuando el navegador está cerrado

Estrictamente hablando, esto no se puede hacer. Una forma de hacer un pequeño esfuerzo es utilizar el código javascript window.oncolose en todas las páginas del cliente para monitorear la acción de cierre del navegador y luego enviar una solicitud al servidor para eliminar la sesión. Pero todavía no hay nada que puedas hacer con los métodos no convencionales, como los fallos del navegador o la eliminación forzada de procesos.

4. ¿Cuál es el punto de tener un HttpSessionListener?

Puede crear un oyente de este tipo para monitorear los eventos de creación y destrucción de sesiones, de modo que pueda hacer algo en consecuencia cuando ocurra dicho evento. . trabajar. Tenga en cuenta que las acciones de creación y destrucción de la sesión activan al oyente, y no al revés. Los oyentes similares relacionados con HttpSession incluyen HttpSessionBindingListener, HttpSessionActivationListener y HttpSessionAttributeListener.

5. ¿Los objetos almacenados en la sesión tienen que ser serializables?

No es necesario. Se requiere que los objetos sean serializables solo para que la sesión pueda replicarse en el clúster o persistir o el servidor pueda intercambiar temporalmente la sesión fuera de la memoria cuando sea necesario. Colocar un objeto no serializable en una sesión de Weblogic Server generará una advertencia en la consola. En cierta versión de iPlanet que he usado, si hay objetos no serializables en la sesión, habrá una excepción cuando se destruya la sesión, lo cual es muy extraño.

6. Cómo abordar correctamente la posibilidad de que el cliente prohíba las cookies

Utilice la reescritura de URL para todas las URL, incluidos los hipervínculos, las acciones de formulario y las URL redirigidas; consulte [6] para obtener más información. métodos específicos

/wls/docs70/webapp/sessions.html#100770

7. ¿Se utilizará la misma sesión al abrir dos ventanas del navegador para acceder a sesiones diferentes

Consulte la discusión sobre cookies en la tercera sección. Para las sesiones, solo se reconoce la identificación, pero no la persona. Por lo tanto, diferentes navegadores, diferentes métodos de apertura de ventanas y diferentes métodos de almacenamiento de cookies tendrán diferentes efectos. a esta pregunta tiene implicaciones.

8. Cómo evitar la confusión de sesión causada por el usuario al abrir dos ventanas del navegador

Este problema es similar a evitar que el formulario se envíe varias veces. Se puede resolver configurando el. token del cliente. Es decir, el servidor genera una ID diferente y la devuelve al cliente cada vez, y la guarda en la sesión. Cuando el cliente envía el formulario, también debe devolver esta ID al servidor. El programa primero compara si la ID devuelta. es consistente con el valor guardado en la sesión. Si son inconsistentes, significa que esta operación ha sido enviada. Puede consultar la sección sobre el modelo de capa de presentación en "Patrones principales J2EE". Cabe señalar que para las ventanas abiertas usando javascript window.open, esta ID generalmente no se establece o se usa una ID separada, en caso de que no se pueda operar la ventana principal, se recomienda no realizar operaciones de modificación en la ventana abierta. window.open, para que no se requiera configuración.

9. ¿Por qué es necesario volver a llamar a session.setValue después de cambiar el valor de la sesión en Weblogic Server?

Esta acción es principalmente para solicitar el valor en la sesión de Weblogic Server. entorno del clúster. Se ha producido un cambio y es necesario copiar el nuevo valor de la sesión a otros procesos del servidor.

10. ¿Por qué falta la sesión?

Excluyendo el fallo normal de la sesión, la posibilidad del servidor en sí debería ser mínima. Aunque el autor está en la versión Solaris de iPlanet6SP1. con varios parches lo he encontrado antes; los complementos del navegador son menos probables y también he encontrado problemas causados ​​​​por el complemento 3721. En teoría, los firewalls o servidores proxy también pueden tener problemas con el procesamiento de cookies.

La mayoría de las razones de este problema son errores de programa. El más común es acceder a otra aplicación dentro de una aplicación. Discutimos este tema en la siguiente sección.

7. Compartir sesiones entre aplicaciones

A menudo ocurre que un proyecto grande se divide en varios proyectos pequeños para su desarrollo, para evitar interferir entre sí. Se requiere desarrollar un pequeño proyecto como una aplicación web separada, pero al final, de repente descubro que algunos proyectos pequeños necesitan compartir información, o quiero usar la sesión para implementar SSO (inicio de sesión único). guarde el inicio de sesión en la sesión Para obtener información del usuario, el requisito más natural es que las aplicaciones puedan acceder a las sesiones de las demás.

Sin embargo, según la especificación del Servlet, el alcance de la sesión debe limitarse a la aplicación actual y diferentes aplicaciones no pueden acceder a las sesiones de las demás. En realidad, cada servidor de aplicaciones cumple con esta especificación, pero los detalles de implementación pueden ser diferentes, por lo que los métodos para resolver el intercambio de sesiones entre aplicaciones también son diferentes.

Primero, echemos un vistazo a cómo Tomcat implementa el aislamiento de sesiones entre aplicaciones web. A juzgar por las rutas de cookies establecidas por Tomcat, establece diferentes rutas de cookies para diferentes aplicaciones. Esto es diferente. las aplicaciones son diferentes, por lo que incluso si se accede a diferentes aplicaciones en la misma ventana del navegador, los ID de sesión enviados al servidor pueden ser diferentes.

Con base en esta característica, podemos inferir que la estructura de memoria de la sesión en Tomcat es aproximadamente la siguiente.

El iPlanet que el autor ha utilizado antes también utiliza el mismo método. Se estima que no habrá mucha diferencia entre SunONE e iPlanet. Para este tipo de servidor, la solución es muy sencilla y no es difícil implementarla en la práctica. Permita que todas las aplicaciones compartan una ID de sesión o permita que las aplicaciones obtengan las ID de sesión de otras aplicaciones.

Existe una forma muy sencilla de compartir una identificación de sesión en iPlanet, que es establecer la ruta de la cookie de cada aplicación en / (en realidad debería ser /NASApp, para aplicaciones Se dice que su función es equivalente al de una raíz).

lt;infogt de sesión;

lt;pathgt;/NASApplt;/pathgt;

lt;/infogt de sesión