En informática y redes en particular, una sesión es un enlace bidireccional delimitado en 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 momento determinado y luego se "derriba" (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 tener estado , lo que significa que al menos una de las partes que se comunican necesita mantener información del 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 pensó que HTTP/1.0 solo permitía una única solicitud y respuesta durante una sesión web/HTTP. La versión del protocolo HTTP/1.1 mejoró esto al completar la Interfaz de puerta de enlace común (CGI), lo que facilita el mantenimiento de la sesión web y admite cookies HTTP y cargas de archivos.
La mayoría de las sesiones cliente-servidor son mantenidas por 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 separada. Mantener la continuidad de la sesión entre fases requiere una ID de sesión . El ID de sesión está incrustado en los enlaces <A HREF> o <FORM> de las páginas web dinámicas para que se devuelva al CGI. Luego, CGI utiliza el ID de sesión para garantizar la continuidad de la sesión entre las fases de la 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 generalmente se implementan en software que utiliza procesos secundarios y/o subprocesos múltiples , donde se crea un nuevo proceso o subproceso cuando la computadora establece o se une a una sesión. Las sesiones HTTP normalmente no se implementan 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 múltiples procesos o subprocesos es la complejidad relajada del software, ya que cada subproceso 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 en un grupo de servidores, se encuentra un problema especial para 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 inició la sesión, lo que causará problemas cuando el nuevo servidor no tenga acceso al estado almacenado del anterior.
Las sesiones del lado del servidor son útiles y eficientes, pero pueden resultar difíciles de manejar junto con sistemas de equilibrio de carga/alta disponibilidad 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 emparejamiento forzado entre cada cliente y un único servidor en el 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 almacenar los datos de la sesión. Este método es aplicable a servidores con un número limitado de clientes (por ejemplo, enrutador o punto 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 regreso al servidor, y el servidor usa 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 tiene acceso a la computadora del cliente. Para utilizar sesiones del lado del cliente donde se requiere confidencialidad e integridad, se debe garantizar lo siguiente:
Para lograr esto, el servidor necesita cifrar los datos de la sesión antes de enviarlos al cliente, y se debe evitar que cualquier otra parte modifique dicha información mediante medios criptográficos.
Transmitir el estado de un lado a otro con cada solicitud solo es práctico 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 la 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 normalmente almacena y envía el token como una cookie HTTP y/o lo envía como 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) vinculada a ese identificador. Ejemplos de los nombres que utilizan algunos lenguajes de programación al nombrar su cookie HTTP incluyen JSESSIONID ( JSP ), PHPSESSID ( PHP ), CGISESSID ( CGI ) y ASPSESSIONID ( ASP ).
En la interacción persona-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 realizar un seguimiento de qué aplicaciones están abiertas y qué documentos ha abierto cada aplicación, de modo que se pueda restaurar el mismo estado cuando el usuario cierre la sesión y vuelva a iniciarla más tarde. Para un sitio web, la gestión de sesiones puede implicar que el usuario 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 gestión de sesiones en sistemas basados en Linux la proporciona el administrador de sesiones X. En los sistemas Microsoft Windows , la gestión de sesiones la proporciona el subsistema de administrador de sesiones (smss.exe); La funcionalidad de la sesión de usuario puede ampliarse mediante aplicaciones de terceros como twinsplay.
La gestión de sesiones es particularmente ú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 (consulte portabilidad de datos ).
Para ayudar a recuperarse de una falla del sistema o de una aplicación, las páginas y configuraciones también se pueden restaurar en la siguiente ejecución. Google Chrome , Mozilla Firefox , Internet Explorer , OmniWeb y Opera son ejemplos de navegadores web que admiten la gestión de sesiones. La gestión de sesiones suele realizarse 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 utilizada por el desarrollador web para hacer que el protocolo HTTP sin estado admita el estado de 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 solicite nuevamente la cuenta y la contraseña del usuario. Para obtener una descripció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 conocimientos sobre el estado de la sesión (como es típico en un entorno de clúster ), la información de la sesión se debe compartir 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 nodos en un clúster incluyen: transmitir información de la sesión a nodos miembros (consulte JGroups para ver un ejemplo de esta técnica), compartir información de la sesión con un nodo asociado mediante memoria compartida distribuida o virtualización de memoria , compartir información de la sesión entre nodos utilizando sockets de red, almacenar 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 que no contienen datos sujetos a auditoría de cumplimiento (en los EE. UU., por ejemplo, consulte la Ley de Responsabilidad y Portabilidad del Seguro Médico y la Ley Sarbanes-Oxley). Busque ejemplos de dos leyes que requieran una auditoría de cumplimiento), entonces se puede utilizar cualquier método para almacenar información de la sesión. Sin embargo, si la información de la sesión está sujeta al cumplimiento de la auditoría, se debe considerar el método utilizado para el almacenamiento, la replicación y la agrupación en clústeres de la sesión.
En una arquitectura orientada a servicios , las aplicaciones de consumo pueden utilizar mensajes de protocolo simple de acceso a objetos o mensajes SOAP construidos con mensajes de 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 los SMS se volvieron interoperables entre redes rivales en 1999, [2] y los mensajes de texto comenzaron su ascenso hasta convertirse en una forma de comunicación global ubicua, [3] varias empresas se interesaron en utilizar el canal SMS con fines comerciales. Los servicios iniciales no requerían gestión de sesiones ya que eran sólo comunicaciones unidireccionales (por ejemplo, en 2000, el primer servicio de noticias móvil se entregó a través de SMS en Finlandia ). Hoy en día, estas aplicaciones se conocen como mensajería de aplicación a igual (A2P) , a diferencia de la mensajería de igual a igual (P2P) . El desarrollo de aplicaciones empresariales interactivas requería gestió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 desde el lado del cliente haciendo que los usuarios finales ingresaran comandos e identificadores de servicio manualmente.