Sesión (informática)
En informática, particularmente en redes, una sesión es un intercambio de información interactiva semipermanente, también conocido como diálogo, una conversación o un encuentro, entre dos o más dispositivos de comunicación, o entre un ordenador y usuario. Una sesión se establece en un cierto momento y se finaliza poco después. Una sesión de comunicación establecida puede implicar más de un mensaje en cada dirección. Una sesión es típicamente, pero no siempre, con estado, significando que al menos una de las partes comunicantes necesita salvar información sobre el historial de sesión para ser capaz de comunicarse, o sin estado, donde la comunicación consta de peticiones independientes con respuestas.
Una sesión establecida es el requisito básico para realizar una comunicación orientada a conexión. También es el paso básico para transmisión en modos de comunicación sin conexión. Sin embargo, cualquier transmisión unidireccional no define una sesión.[1]
El transporte de comunicación puede ser implementado 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.
- Ejemplos de capa de la aplicación:
- Sesiones HTTP, los cuales dejan asociar información con visitantes individuales
- Una sesión de login remoto mediante telnet
- Ejemplo de capa de sesión:
- Un Protocolo de Iniciación de la Sesión (VOIP) en el que se basa una llamada de teléfono de Internet
- Ejemplo de capa de transporte:
- Una sesión TCP, la cual es sinónimo a un circuito virtual TCP, una conexión TCP, o un socket TCP establecido.
En el caso de protocolos de transporte que no implementan una capa de sesión formal (p. ej., UDP) o donde las sesiones en la capa de aplicación son generalmente de un tiempo de vida muy corto (p. ej., HTTP), las sesiones se mantienen mediante un programa de más alto nivel que utiliza un método de intercambio de información definido. Por ejemplo, un intercambio de HTTP entre un navegador y un anfitrión remoto pueden incluir una cookie HTTP que identifica el estado, como una única sesión ID, información sobre las preferencias o nivel de autorización del usuario.
HTTP/1.0 fue ideado para permitir una única petición y respuesta durante una sesión Web/HTTP. La versión del protocolo HTTP/1.1 mejoró esto con la Interfaz de Puerta Común (CGI), haciendo más fácil de mantener la sesión web con cookies HTTP y soporte de carga de archivos.
La mayoría de las sesiones cliente-servidor están mantenidas por la capa de transporte - una conexión única para una única sesión. Aun así, 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 requiere una ID de sesión. La ID de sesión está embebida en los enlaces de las etiquetas <A HREF> o <FORM> de las páginas web dinámicas para que pueda ser enviada de vuelta al CGI. El CGI utiliza la ID de sesión para asegurar la continuidad entre las fases de transacción. Una ventaja de una conexión por fase es que trabaja bien sobre conexiones de bajo ancho de banda (módem).
Implementación de software
Las sesiones TCP, normalmente, son implementadas por software mediante el uso de procesos y/o hilos, donde un proceso nuevo o el hilo se crea cuando el ordenador establece o se une a una sesión. Las sesiones HTTP son normalmente no se implementan usando un hilo por sesión sino una base de datos con información sobre el estado de cada sesión. La ventaja con hilos o procesos múltiples es una menor complejidad del software, ya que cada hilo es una instancia con su propio historial y variables encapsuladas. La desventaja es un elevado consumo de recursos de sistema, y que la sesión puede ser interrumpida si el sistema se reinicia.
Cuando un cliente se conecta a cualquier servidor en un grupo de servidores, aparece un problema de consistencia cuando los servidores tienen que mantener el estado de una sesión. El cliente tiene que ser dirigido al mismo servidor durante la vida de la sesión, o los servidores tienen que transmitir la información de la sesión a través de un sistema de archivos compartido o base de datos. De lo contrario, el cliente puede reconectarse a un servidor diferente de aquel con el que inició la sesión y causará problemas cuando el servidor nuevo no tenga acceso al estado almacenado en el servidor anterior.
Sesiones web de lado del servidor
Las sesiones de lado del servidor son manejables y eficientes pero pueden llegar a ser difíciles de manejar conjuntamente con sistemas de balanceo de carga/alta disponibilidad. No es utilizable en absoluto en sistemas embebidos sin soporte de almacenamiento. El problema de balanceo de carga puede solucionarse utilizando almacenamiento compartido o forzando la conexión del cliente a un mismo servidor del cluster, a pesar de que esto puede comprometer la eficiencia del sistema y la distribución de carga.
Un método para utilizar sesiones de lado del servidor en sistemas sin almacenamiento es reservar una porción de RAM para almacenamiento de la información de sesión. Este método es aplicable para servidores con un número limitado de clientes (p. ej. router o punto de acceso con acceso infrecuente o no permitido a más de un cliente a la vez)...
Sesiones web de lado del cliente
Las sesiones web de lado del cliente utilizan cookies y técnicas de cifrado para mantener el estado de la sesión sin almacenar la información en e servidor. Cuando se muestra una página web dinámica, el servidor envía la información del estado actual al cliente (navegador de web) mediante una cookie. El cliente guarda la cookie en memoria o en disco. Con cada petición sucesiva, el cliente envía la cookie de vuelta al servidor, y el servidor utiliza la información para "recordar" el estado de la aplicación para aquel cliente concreto y generar una respuesta apropiada.
Este mecanismo puede trabajar bien en algunos contextos; aun así, el dato almacenado en el cliente es vulnerable a ediciones por parte del usuario o por el software que tiene acceso al ordenador del cliente. Para utilizar sesiones de lado del cliente donde se requiere confidencialidad e integridad se debe garantizar:
- Confidencialidad: Nada aparte del servidor tendría que ser capaz de interpretar la información de sesión.
- Integridad de dato: Nada aparte del servidor tendría que manipular la información de sesión (accidentalmente o maliciosamente).
- Autenticidad: Nada aparte del servidor tendría que ser capaz de iniciar sesiones válidas.
Para cumplir esto, el servidor ha de cifrar la información de la sesión antes de enviarlo al cliente y evitar la modificación de tal información mediante cifrado.
Transmitir de vuelta el estado con cada petición sólo es práctico cuando el tamaño de la cookie es pequeño. En esencia, las sesiones de lado del cliente consumen un ancho de banda extra en cada petición web. Además, los navegadores web limitan el número y tamaño de las cookies que se pueden almacenar por sitio web. Para mejorar la eficiencia, el servidor puede comprimir la información antes de crear la cookie, descomprimiéndolo más tarde, cuando la cookie regresa del cliente.
Token de sesión HTTP
Un token de sesión es un identificador único que está generado y enviado desde un servidor a un cliente para identificar la sesión de interacción actual. El cliente envía el token como una cookie HTTP y/o lo envía como parámetro en GET o POST. La razón para utilizar tokens de sesión es que el cliente sólo tiene que manejar el identificador—toda la información de sesión está almacenada en el servidor (normalmente en una base de datos, al cual el cliente no tiene acceso directo) enlazada a aquel identificador. Ejemplos de los nombres que algunos lenguajes de programación utilizan cuándo se nombra su cookie HTTP son: JSESSIONID (JSP),PHPSESSID (PHP), CGISESSID (CGI), y ASPSESSIONID (ASP).
Administración de sesión
En la interacción de ordenador-humano, la administración de sesión es el proceso de mantener la pista de la actividad de un usuario a través de sesiones de interacción con el sistema de ordenador.
Entre las tareas de administración de sesión típicas en un entorno de escritorio se incluye mantener la pista de las aplicaciones abiertas y qué documentos tiene abiertos cada aplicación, de modo que se pueda restaurar el mismo estado cuando el usuario sale y se reconecta posteriormente. Para un sitio web, la administración de sesión podría implicar requerir al usuario reconectarse si la sesión expira (p.ej., pasa un plazo máximo seguro sin actividad del usuario). Se utiliza también para almacenar información en el servidor entre peticiones HTTP.
Administrador de sesión de escritorio
Un administrador de sesión de escritorio es un programa que puede guardar y restaurar sesiones de escritorio. Una sesión de escritorio es todas las ventanas que se están ejecutando y su contenido actual. La administración de sesión en sistemas Linux la proporciona el administrador de sesión X. En sistemas de Microsoft Windows, no se incluye ningún administrador de sesión, pero puede ser proporcionado por aplicaciones de terceros como twinsplay.
La administración de sesión es particularmente útil en un navegador web donde un usuario puede guardar todas las páginas abiertas y configuraciones y restaurarlas posteriormente. Para ayudar a la recuperación de un fallo del sistema o de una aplicación, las páginas y su configuración pueden restaurarse en la siguiente ejecución. Google Chrome, Mozilla Firefox, Explorador de Internet, OmniWeb y ópera son ejemplos de navegadores web con soporte de administración de sesión. La administración de sesión se controla a menudo mediante cookies.
Administración de sesión del servidor web
El protocolo HTTP no tiene estado: un ordenador cliente que ejecuta un navegador web tiene que establecer una conexión TCP nueva con cada petición GET o POST. El servidor web, por lo tanto, no puede confiar en una conexión TCP establecida para más que una única operación GET o POST. La administración de sesión es la técnica que utiliza el desarrollador web para dar soporte de estado de sesión HTTP a una sesión sin estado. Por ejemplo, una vez que un usuario ha sido autenticado en el servidor web, la próxima petición HTTP del usuario (GET o POST) no debería necesitar una nueva solicitud de usuario y contraseña.
En situaciones donde múltiples servidores web tienen que compartir el estado de sesión (típico en un entorno de clusters) la información de sesión tiene que ser compartida entre los nodos del grupo que está corriendo el software del servidor web. Métodos para compartir estado de sesión entre los nodos en un grupo incluyen: multicasting de la información de sesión a los nodos miembro, compartiendo la información de sesión con un nodo que utiliza memoria compartida distribuida o virtualización de memoria, compartiendo información de sesión entre los nodos que utilizan sockets de red, almacenando información de sesión en un sistema de archivo compartido como el sistema de archivo de red o el sistema de archivo global, o almacenando la información de sesión fuera del grupo en una base de datos.
Si información de sesión está considerada como dato transitorio o volátil, se puede utilizar culquier método para almacenarla.
En una arquitectura orientada a servicios, los mensajes SOAP construidos con lenguaje de marcado extensibe (XML) pueden usarse para crear sesiones.
Administración de sesión en SMS
El SMS usa un protocolo sin estado, al igual que HTTP. El SMS llegó a ser inter operable a través de redes rivales en 1999, aumentando su uso como una forma de comunicación gobal. Varias empresas se interesaron en utilizar el canal de SMS para propósitos comerciales.[2] Los servicios iniciales no requerían administración de sesión ya que por entonces eran sólo comunicaciones de un solo sentido (por ejemplo, en 2000, el primer servicio de notificación móvil se entregó vía SMS en Finlandia). Hoy, estas aplicaciones se las conoce como mensajería de aplicación a cliente y es distinto de la mensajería cliente a cliente. El desarrollo de aplicaciones de empresa requería administración de sesión, pero como el SMS es un protocolo sin estado definido por el estándar GSM, las implementaciones tempranas estuvieron controladas en el lado del cliente en el cual, los usuarios introducían órdenes e identificadores de servicio manualmente.[3] En 2001, un inventor finlandés, Jukka Salonen, introdujo una forma de mantener el estado de sesiones asíncronas desde el servidor de un operador independiente con un método denominado Matriz de Diálogo Dinámica (DDM).[4] Controlando las sesiones de un servidor remoto elimina la complejidad para el usuario final y habilita soluciones a escala más sencillas de manera que es compatible con teléfonos móviles existentes hasta el momento. Controlando sesiones de lado del servidor también permitió una autentificación de usuario mejorada, eliminando la necesidad de transmitir información sensible sobre redes inalámbricas inseguras. Finnair fue la primera aerolínea en utilizar el sistema DDM y un método para control de autentificación móvil en sus vuelos.[5]
Véase también
Referencias
- Sessionless-oriented protocol and session-oriented protocol
- CTIA InterCarrier Messaging Guidelines, Version 1.0 http://www.ctia.org/business_resources/wic/index.cfm/AID/12056http://files.cti (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). a.org/pdf/Inter-Carrier_SMS_Guidelines_V3.1_As_Adopted_May_2012-final.pdf
- GSM Doc 28/85 "Services and Facilities to be provided in the GSM System" rev2, June 1985
- US 7406429 “Booking method and system” Aug 21, 2001.
- “Making More of SMS, much more” High Tech Finland. 2009 http://www.hightech.fi/direct.aspx?area=htf&prm1=794&prm2=article el 13 de julio de 2015 en Wayback Machine.
Enlaces externos
- Métodos de seguimiento de sesión