Entramos en las capas superiores del modelo OSI, y lo hacemos por la más peculiar de las siete: la capa 5 o capa de sesión. Es peculiar porque, a diferencia de las cuatro que ya has recorrido, no vas a encontrar "el protocolo de capa 5" en ninguna captura de tráfico: casi ningún protocolo real la implementa como pieza separada. Y sin embargo, los problemas que esta capa describe —quién habla ahora, por dónde íbamos, cómo retomamos lo interrumpido— existen en toda comunicación real, y algún trozo de software los resuelve siempre. Entender la capa de sesión te da dos cosas: el vocabulario para reconocer esos problemas allá donde aparezcan (y aparecen a diario: sesiones caducadas, descargas que se reanudan, videollamadas que se recuperan tras un corte), y la explicación de por qué el mapa OSI y el territorio del software real no coinciden en las capas altas.

1. La función de la capa de sesión dentro del modelo
2. Servicio 1: establecer, gestionar y cerrar sesiones
3. Servicio 2: control del diálogo
4. Servicio 3: puntos de sincronización y recuperación
5. Por qué casi ningún protocolo la implementa por separado
6. Dónde vive hoy el concepto: tres ejemplos en Meridiano

Primero, distingamos dos palabras que se parecen peligrosamente:

• Una conexión (capa 4) es un canal de transporte entre dos procesos: el tubo TCP entre el navegador de Marta y el puerto 443 del servidor.
• Una sesión (capa 5) es un diálogo con contexto y continuidad: "la conversación de Marta con la intranet, autenticada como Marta, con su carrito de gestiones a medias, desde que entró hasta que salga".

La diferencia se ve al preguntarse: si el tubo se rompe y se abre otro, ¿sigue viva la conversación? Con solo capa 4, no: cada conexión nueva empieza de cero. La capa de sesión es la que OSI define para que la respuesta sea sí: su función es dar a la comunicación una vida más larga y más rica que la de las conexiones que la transportan.

El contrato OSI de la capa 5:

• Qué recibe de arriba (capa 6): datos de aplicaciones que quieren mantener diálogos organizados y con memoria.
• Qué servicio ofrece: abrir, mantener, sincronizar y cerrar sesiones; organizar los turnos del diálogo; y marcar puntos de control para reanudar tras un fallo.
• Qué usa de abajo (capa 4): conexiones de transporte entre procesos — que pueden ser varias, sucesivas o simultáneas, al servicio de una misma sesión.
• Su PDU: datos (como en todas las capas superiores; a partir de aquí ya no hay cabeceras con direcciones propias).

El ciclo de vida de una sesión tiene tres fases, y en cada una hay decisiones que alguien debe tomar:

1. Establecimiento: los dos extremos acuerdan iniciar el diálogo y fijan su contexto: quiénes son (aquí suele engancharse la autenticación), qué reglas usarán, qué identificador tendrá la sesión.
2. Mantenimiento: mientras dura, la sesión conserva el estado (quién es el usuario, qué se ha hecho ya) y vigila que el interlocutor sigue ahí — los "latidos" o keepalives periódicos, y los cierres por inactividad, son gestión de sesión pura.
3. Cierre: ordenado (ambos acuerdan terminar y liberan recursos) o abrupto (uno desaparece y el otro debe detectarlo y limpiar).

Fíjate en que nada de esto lo hace la capa 4 por sí sola: TCP abre y cierra conexiones, pero no sabe quién es Marta, ni recuerda nada entre una conexión y la siguiente, ni decide cuándo un diálogo "ha caducado". Ese estado con significado es la aportación de la capa 5.

Segundo servicio: organizar los turnos. OSI distingue los diálogos:

• Full-duplex: ambos extremos pueden hablar a la vez (una llamada telefónica normal).
• Half-duplex: se habla por turnos, y hace falta gestionar "el testigo" de quién tiene la palabra (un walkie-talkie: "cambio").

Aunque el término suene antiguo, el problema es actual: en una videollamada, el software decide de quién es el audio dominante y silencia ecos; en un sistema de reservas, cuando dos usuarios editan el mismo recurso, alguien gestiona quién tiene "el turno" de escritura para que no se pisen. Cada vez que un software coordina a quién le toca, está resolviendo el problema que OSI llamó control del diálogo.

El servicio más valioso y el más fácil de reconocer hoy. La idea: en un intercambio largo, insertar puntos de sincronización — marcas de "hasta aquí, confirmado y a salvo" — de modo que, si algo falla a mitad, no se reinicie desde cero sino desde la última marca.

¿Te suena? Es exactamente lo que hace tu navegador cuando una descarga interrumpida se reanuda donde iba, o lo que hacen las herramientas de copia de seguridad de Meridiano cuando la sincronización nocturna con Bilbao se corta y al reconectar continúa por el fichero donde se quedó. El mecanismo concreto varía (marcas de posición, peticiones de rangos, listas de bloques ya confirmados), pero el concepto es el punto de sincronización de la capa 5, tal cual lo definió OSI hace cuarenta años.

Y ahora, la pregunta clave de la lección: si estos servicios son tan útiles, ¿por qué no existe "el protocolo de sesión" corriendo en el servidor de Meridiano?

La razón es histórica y práctica a la vez. El modelo OSI se diseñó antes y al margen de los protocolos que finalmente triunfaron. En la pila real de Internet, los servicios de sesión resultaron necesitarse de formas muy distintas según la aplicación — la sesión de una videollamada no se parece en nada a la de una web —, así que nadie construyó una capa genérica: cada pieza de software incorporó los servicios de sesión que necesitaba, a su manera. El resultado es que la capa 5 no desapareció: se disolvió en tres lugares:

Consecuencia para ti como profesional: "capa de sesión" no es una cosa que configurar, sino una categoría de problemas — identidad mantenida, continuidad, turnos, reanudación. Cuando uno de esos problemas falla, saber que "esto es un asunto de capa 5" te dice dónde mirar: no en la red (capas 1-4, que pueden estar perfectas), sino en el software que gestione esa sesión concreta.

La reunión de los lunes entre Ana y Jon es un festival de capa 5. Antes de que fluya ni un segundo de vídeo, el software de videollamada establece la sesión: quiénes participan, qué capacidades tiene cada uno, identificadores de la llamada. Durante la reunión, la sesión se mantiene con latidos periódicos, y el control de diálogo gestiona el audio dominante. Y lo mejor: si la VPN parpadea diez segundos, la llamada no "muere" — las conexiones de transporte se rompen y se recrean, pero la sesión de la llamada sobrevive y el vídeo vuelve solo. Esa reconexión transparente es la distinción conexión/sesión hecha experiencia de usuario: murió la capa 4; la capa 5 (implementada por la aplicación) siguió viva.

Cuando el administrador de Meridiano abre SSH contra el servidor .10, se ve el ciclo completo en miniatura: establecimiento con autenticación (la identidad queda ligada a la sesión), mantenimiento con estado (el directorio actual, las variables del entorno remoto: el servidor recuerda dónde está el administrador entre comando y comando), keepalives que detectan si el otro extremo desapareció, y cierre ordenado con exit, que libera los recursos de ambos lados. SSH integra sus servicios de sesión dentro del propio protocolo: capa 5 disuelta en la aplicación, funcionando de libro.

El caso más cotidiano y el más instructivo, porque aquí la capa 5 se reconstruye sobre un protocolo que no la tiene: HTTP es sin estado — cada petición llega al servidor huérfana, sin memoria de las anteriores (lo viste en 02-05). Entonces, ¿cómo sabe la intranet que la petición número 40 sigue siendo de Marta? Porque al autenticarse, el servidor le entregó un identificador de sesión en una cookie (o un token), y el navegador lo reenvía en cada petición; el servidor mantiene asociado a ese identificador el contexto de Marta. Eso es, conceptualmente, una capa de sesión artesanal construida a nivel de aplicación. Y sus averías son las incidencias de capa 5 más frecuentes que atenderás: "la intranet me ha echado" (sesión caducada por inactividad), "me pide la contraseña a cada rato" (las cookies no persisten), "en mi portátil estoy dentro y en el fijo no" (la sesión vive en cada navegador, no "en la red"). En todas ellas, ping, DNS y TCP están perfectos: ninguna herramienta de capas 1-4 verá nada raro, porque el problema vive en el estado del diálogo.

• Confundir sesión con conexión. La conexión es el tubo (capa 4); la sesión es la conversación con memoria (capa 5). Una sesión puede sobrevivir a muchas conexiones (la videollamada tras el parpadeo de la VPN) y una conexión puede transportar sesiones de varios usuarios.
• Buscar la capa 5 como un componente configurable. No existe "el servicio de sesión" del sistema: son funciones repartidas entre TLS, los protocolos de aplicación y el código de cada aplicación. Se diagnostica en el software, no en la red.
• Culpar a la red de problemas de sesión. "Me expulsa de la intranet cada 10 minutos" con ping y DNS perfectos no es un problema de red: es una política de caducidad de sesión o unas cookies que no persisten. Reconocer la capa te ahorra perseguir fantasmas por las capas 1-4.
• Creer que como OSI "se equivocó" con esta capa, no vale la pena estudiarla. Al contrario: los conceptos (establecimiento, estado, turnos, sincronización, reanudación) aparecen en cada sistema distribuido moderno. Lo que no cuajó fue implementarla como pieza separada; el vocabulario es de uso diario.
• Consejo: cuando algo "se desconecta" o "expulsa" a un usuario, pregunta primero: ¿qué murió, la conexión o la sesión? ¿Y quién gestiona esa sesión: TLS, el protocolo o la aplicación? Esas dos preguntas dirigen el diagnóstico al lugar correcto.

Ejercicio 1. Clasifica cada situación como establecimiento/gestión/cierre de sesión, control de diálogo o punto de sincronización: (a) la copia nocturna hacia Bilbao se corta y al reconectar continúa por el fichero 412 de 900; (b) el software de videollamada da preferencia al audio de Jon mientras presenta y atenúa el resto; (c) la intranet expulsa a Marta tras 30 minutos sin actividad; (d) SSH pide usuario y clave antes de aceptar ningún comando.

Ejercicio 2. Durante la reunión de los lunes, la VPN entre sedes cae ocho segundos. La videollamada se congela y se recupera sola; en cambio, la transferencia de un fichero que Jon tenía a medias por otra herramienta se aborta y hay que lanzarla de nuevo desde cero. Explica ambos comportamientos en términos de conexión (capa 4) y sesión (capa 5). ¿Qué servicio de capa 5 le falta a la herramienta de transferencia?

Ejercicio 3. Marta llama al soporte: "la intranet me pide la contraseña continuamente, cada dos o tres clics". El ping al servidor es perfecto, el DNS resuelve y las páginas cargan rápido. (a) ¿Qué capas puedes dar por buenas? (b) ¿Dónde localizas el problema y por qué? (c) Da dos causas plausibles coherentes con ese diagnóstico.

Solución 1. (a) Punto de sincronización (reanudación desde la última marca confirmada). (b) Control de diálogo (gestión de turnos/palabra dominante). (c) Gestión/cierre de sesión (caducidad por inactividad: política de mantenimiento del estado). (d) Establecimiento de sesión (la autenticación liga la identidad al diálogo antes de empezar).

Solución 2. En ambos casos las conexiones de capa 4 murieron con la caída de la VPN: eso es inevitable e igual para las dos aplicaciones. La diferencia está una capa más arriba: el software de videollamada mantiene una sesión independiente de sus conexiones — al volver la red, restablece conexiones nuevas y las reasocia a la sesión viva (identificadores de llamada, estado de los participantes), y el usuario solo ve una congelación. La herramienta de transferencia no tiene ese nivel: su "diálogo" es su conexión, y al morir esta, muere todo. Le falta el servicio de puntos de sincronización/reanudación: marcas de progreso confirmado que permitieran retomar por donde iba en una conexión nueva.

Solución 3. (a) Capas 1-4 correctas (ping, resolución, carga rápida: red y transporte funcionan) — y el propio servicio web responde, así que tampoco es el "puerto cerrado" de la lección anterior. (b) En la gestión de sesión de la aplicación (capa 5 conceptual): que pida la contraseña a cada rato significa que el servidor no reconoce a Marta entre peticiones — el identificador de sesión no llega, no persiste o no se acepta. (c) Causas plausibles: el navegador de Marta bloquea o borra las cookies (modo privado, configuración o limpieza agresiva), con lo que cada petición llega sin identificador; o la caducidad de sesión del servidor está mal configurada (un tiempo de vida absurdamente corto que expira las sesiones casi de inmediato). Ambas encajan con una red impecable.

La capa de sesión define los servicios que convierten conexiones sueltas en diálogos con memoria: establecimiento con identidad, mantenimiento del estado, control de turnos y puntos de sincronización para reanudar sin empezar de cero. Su rareza es que en la pila real nadie la implementa como pieza aparte: se disolvió dentro de TLS, de protocolos como SSH y RPC, y del código de las propias aplicaciones — las cookies de la intranet de Meridiano son una capa 5 artesanal sobre un HTTP sin estado. Para ti, es sobre todo una categoría de diagnóstico: cuando la red está perfecta pero el usuario "se desconecta", "caduca" o "no puede reanudar", el problema es de sesión y vive en el software. Nos queda otra pregunta que las capas 1-5 no responden: los datos llegan enteros, en orden y dentro de un diálogo vivo... pero ¿en qué formato llegan? ¿Con qué codificación, comprimidos cómo, cifrados con qué? De la forma de los datos se ocupa la capa 6: la capa de presentación, próxima lección.