En informática y redes en particular, una sesión es un enlace bidireccional delimitado por el tiempo, una capa práctica (relativamente alta) en el protocolo TCP/IP que permite la expresión interactiva y el intercambio de información entre dos o más dispositivos o extremos de comunicación, ya sean computadoras, sistemas automatizados o usuarios activos en vivo (ver sesión de inicio de sesión ). Una sesión se establece en un punto determinado en el tiempo y luego se "desconecta" (se pone fin) en algún momento posterior. Una sesión de comunicación establecida puede implicar más de un mensaje en cada dirección. Una sesión suele ser con estado , lo que significa que al menos una de las partes que se comunican necesita mantener información de estado actual y guardar información sobre el historial de la sesión para poder comunicarse, a diferencia de la comunicación sin estado , donde la comunicación consiste en solicitudes independientes con respuestas.
Una sesión establecida es el requisito básico para realizar una comunicación orientada a conexión . Una sesión también es el paso básico para transmitir en modos de comunicación sin conexión . Sin embargo, cualquier transmisión unidireccional no define una sesión. [1]
El transporte de comunicaciones puede implementarse como parte de protocolos y servicios en la capa de aplicación , en la capa de sesión o en la capa de transporte en el modelo OSI .
En el caso de protocolos de transporte que no implementan una capa de sesión formal (por ejemplo, UDP ) o donde las sesiones en la capa de aplicación son generalmente de muy corta duración (por ejemplo, HTTP), las sesiones son mantenidas por un programa de nivel superior utilizando un método definido en los datos que se intercambian. Por ejemplo, un intercambio HTTP entre un navegador y un host remoto puede incluir una cookie HTTP que identifica el estado, como un ID de sesión único , información sobre las preferencias del usuario o el nivel de autorización.
Se pensaba que HTTP/1.0 solo permitía una única solicitud y respuesta durante una sesión Web/HTTP. La versión de protocolo HTTP/1.1 mejoró esto al completar la Interfaz de Puerta de Enlace Común (CGI), lo que facilitó el mantenimiento de la sesión Web y admitió cookies HTTP y cargas de archivos.
La mayoría de las sesiones cliente-servidor se mantienen mediante la capa de transporte (una única conexión para una única sesión). Sin embargo, cada fase de transacción de una sesión Web/HTTP crea una conexión independiente. Para mantener la continuidad de la sesión entre fases, se necesita un identificador de sesión . El identificador de sesión se incluye en los enlaces <A HREF> o <FORM> de las páginas web dinámicas para que se transmita de nuevo a la CGI. A continuación, la CGI utiliza el identificador de sesión para garantizar la continuidad de la sesión entre fases de transacción. Una ventaja de una conexión por fase es que funciona bien en conexiones de bajo ancho de banda (módem).
Las sesiones TCP se implementan normalmente en software mediante procesos secundarios y/o multihilo , donde se crea un nuevo proceso o hilo cuando el equipo establece o se une a una sesión. Las sesiones HTTP no se implementan normalmente utilizando un hilo por sesión, sino mediante una base de datos con información sobre el estado de cada sesión. La ventaja de tener múltiples procesos o hilos es la complejidad relajada del software, ya que cada hilo es una instancia con su propio historial y variables encapsuladas. La desventaja es una gran sobrecarga en términos de recursos del sistema y que la sesión puede interrumpirse si se reinicia el sistema.
Cuando un cliente puede conectarse a cualquier servidor de un grupo de servidores, surge un problema especial a la hora de mantener la coherencia cuando los servidores deben mantener el estado de la sesión. El cliente debe ser dirigido al mismo servidor durante la sesión o los servidores deben transmitir información de la sesión del lado del servidor a través de un sistema de archivos o una base de datos compartidos. De lo contrario, el cliente puede volver a conectarse a un servidor diferente al que utilizó para iniciar la sesión, lo que causará problemas cuando el nuevo servidor no tenga acceso al estado almacenado del antiguo.
Las sesiones del lado del servidor son prácticas y eficientes, pero pueden resultar difíciles de manejar junto con sistemas de alta disponibilidad y equilibrio de carga, y no se pueden utilizar en absoluto en algunos sistemas integrados sin almacenamiento. El problema del equilibrio de carga se puede resolver utilizando almacenamiento compartido o aplicando un emparejamiento forzado entre cada cliente y un único servidor del clúster, aunque esto puede comprometer la eficiencia del sistema y la distribución de la carga.
Un método para utilizar sesiones del lado del servidor en sistemas sin almacenamiento masivo es reservar una parte de la RAM para el almacenamiento de datos de sesión. Este método es aplicable a servidores con una cantidad limitada de clientes (por ejemplo, enrutadores o puntos de acceso con acceso poco frecuente o no permitido a más de un cliente a la vez).
Las sesiones del lado del cliente utilizan cookies y técnicas criptográficas para mantener el estado sin almacenar tantos datos en el servidor. Al presentar una página web dinámica, el servidor envía los datos del estado actual al cliente (navegador web) en forma de cookie. El cliente guarda la cookie en la memoria o en el disco. Con cada solicitud sucesiva, el cliente envía la cookie de vuelta al servidor, y el servidor utiliza los datos para "recordar" el estado de la aplicación para ese cliente específico y generar una respuesta adecuada.
Este mecanismo puede funcionar bien en algunos contextos; sin embargo, los datos almacenados en el cliente son vulnerables a la manipulación por parte del usuario o del software que tenga acceso al equipo cliente. Para utilizar sesiones del lado del cliente en las que se requiere confidencialidad e integridad, se debe garantizar lo siguiente:
Para lograr esto, el servidor debe cifrar los datos de la sesión antes de enviarlos al cliente, y se debe evitar la modificación de dicha información por parte de terceros mediante medios criptográficos.
La transmisión de estado de ida y vuelta con cada solicitud solo es práctica cuando el tamaño de la cookie es pequeño. En esencia, las sesiones del lado del cliente intercambian espacio en el disco del servidor por el ancho de banda adicional que requerirá cada solicitud web. Además, los navegadores web limitan la cantidad y el tamaño de las cookies que puede almacenar un sitio web. Para mejorar la eficiencia y permitir más datos de sesión, el servidor puede comprimir los datos antes de crear la cookie y descomprimirlos más tarde cuando el cliente devuelve la cookie.
Un token de sesión es un identificador único que se genera y envía desde un servidor a un cliente para identificar la sesión de interacción actual. El cliente generalmente almacena y envía el token como una cookie HTTP y/o lo envía como un parámetro en consultas GET o POST. La razón para usar tokens de sesión es que el cliente solo tiene que manejar el identificador: todos los datos de la sesión se almacenan en el servidor (generalmente en una base de datos , a la que el cliente no tiene acceso directo) vinculados a ese identificador. Algunos ejemplos de los nombres que algunos lenguajes de programación usan al nombrar su cookie HTTP incluyen JSESSIONID ( JSP ), PHPSESSID ( PHP ), CGISESSID ( CGI ) y ASPSESSIONID ( ASP ).
En la interacción hombre-computadora , la gestión de sesiones es el proceso de realizar un seguimiento de la actividad de un usuario a lo largo de las sesiones de interacción con el sistema informático .
Las tareas típicas de administración de sesiones en un entorno de escritorio incluyen el seguimiento de las aplicaciones que están abiertas y los documentos que cada aplicación ha abierto, de modo que se pueda restaurar el mismo estado cuando el usuario cierre sesión e inicie sesión más tarde. En el caso de un sitio web, la administración de sesiones puede implicar solicitar al usuario que vuelva a iniciar sesión si la sesión ha expirado (es decir, ha transcurrido un cierto límite de tiempo sin actividad del usuario). También se utiliza para almacenar información en el lado del servidor entre solicitudes HTTP.
Un administrador de sesiones de escritorio es un programa que puede guardar y restaurar sesiones de escritorio. Una sesión de escritorio son todas las ventanas que se están ejecutando actualmente y su contenido actual. La administración de sesiones en sistemas basados en Linux la proporciona el administrador de sesiones X. En los sistemas Microsoft Windows , la administración de sesiones la proporciona el subsistema del administrador de sesiones (smss.exe); la funcionalidad de la sesión de usuario se puede ampliar con aplicaciones de terceros como twinsplay.
La gestión de sesiones es especialmente útil en un navegador web donde un usuario puede guardar todas las páginas y configuraciones abiertas y restaurarlas en una fecha posterior o en una computadora diferente (ver portabilidad de datos ).
Para ayudar a recuperarse de un fallo del sistema o de una aplicación, las páginas y configuraciones también se pueden restaurar en la próxima ejecución. Google Chrome , Mozilla Firefox , Internet Explorer , OmniWeb y Opera son ejemplos de navegadores web que admiten la administración de sesiones. La administración de sesiones se suele gestionar mediante la aplicación de cookies .
El protocolo de transferencia de hipertexto (HTTP) no tiene estado. La gestión de sesiones es la técnica que utiliza el desarrollador web para que el protocolo HTTP sin estado admita el estado de la sesión. Por ejemplo, una vez que un usuario se ha autenticado en el servidor web, la siguiente solicitud HTTP del usuario (GET o POST) no debería hacer que el servidor web vuelva a solicitar la cuenta y la contraseña del usuario. Para obtener una explicación de los métodos utilizados para lograr esto, consulte Cookie HTTP e ID de sesión.
En situaciones en las que varios servidores web deben compartir el conocimiento del estado de la sesión (como es habitual en un entorno de clúster ), la información de la sesión debe compartirse entre los nodos del clúster que ejecutan el software del servidor web. Los métodos para compartir el estado de la sesión entre los nodos de un clúster incluyen: la multidifusión de la información de la sesión a los nodos miembros (consulte JGroups para ver un ejemplo de esta técnica), compartir la información de la sesión con un nodo asociado mediante memoria compartida distribuida o virtualización de memoria , compartir la información de la sesión entre nodos mediante sockets de red, almacenar la información de la sesión en un sistema de archivos compartido, como un sistema de archivos distribuido o un sistema de archivos global , o almacenar la información de la sesión fuera del clúster en una base de datos .
Si la información de la sesión se considera transitoria, datos volátiles que no son necesarios para el no repudio de transacciones y no contienen datos que estén sujetos a auditoría de cumplimiento (en los EE. UU., por ejemplo, consulte la Ley de Portabilidad y Responsabilidad de Seguros Médicos y la Ley Sarbanes-Oxley para ver ejemplos de dos leyes que requieren auditoría de cumplimiento), entonces se puede utilizar cualquier método de almacenamiento de información de la sesión. Sin embargo, si la información de la sesión está sujeta a cumplimiento de auditoría, se debe considerar el método utilizado para el almacenamiento, la replicación y la agrupación de la sesión.
En una arquitectura orientada a servicios , las aplicaciones de consumo pueden utilizar el Protocolo simple de acceso a objetos o mensajes SOAP construidos con lenguaje de marcado extensible ( XML ) para hacer que los servidores web creen sesiones.
Así como HTTP es un protocolo sin estado , también lo es SMS . A medida que SMS se volvió interoperable entre redes rivales en 1999, [2] y la mensajería de texto comenzó su ascenso para convertirse en una forma de comunicación global ubicua, [3] varias empresas se interesaron en usar el canal SMS para fines comerciales. Los servicios iniciales no requerían administración de sesiones ya que eran solo comunicaciones unidireccionales (por ejemplo, en 2000, el primer servicio de noticias móvil se entregó a través de SMS en Finlandia ). Hoy, estas aplicaciones se conocen como mensajería de aplicación a par (A2P) a diferencia de la mensajería de par a par (P2P) . El desarrollo de aplicaciones empresariales interactivas requirió administración de sesiones, pero debido a que SMS es un protocolo sin estado según lo definen los estándares GSM, [4] las primeras implementaciones se controlaban del lado del cliente haciendo que los usuarios finales ingresaran comandos e identificadores de servicio manualmente.