Entrem a les capes superiors del model OSI, i ho fem per la més peculiar de les set: la capa 5 o capa de sessió. És peculiar perquè, a diferència de les quatre que ja has recorregut, no trobaràs "el protocol de capa 5" en cap captura de trànsit: gairebé cap protocol real no la implementa com a peça separada. I tanmateix, els problemes que aquesta capa descriu —qui parla ara, per on anàvem, com reprenem el que s'ha interromput— existeixen en tota comunicació real, i algun tros de programari els resol sempre. Entendre la capa de sessió et dona dues coses: el vocabulari per reconèixer aquests problemes allà on apareguin (i apareixen cada dia: sessions caducades, baixades que es reprenen, videotrucades que es recuperen després d'un tall), i l'explicació de per què el mapa OSI i el territori del programari real no coincideixen a les capes altes.

1. La funció de la capa de sessió dins del model
2. Servei 1: establir, gestionar i tancar sessions
3. Servei 2: control del diàleg
4. Servei 3: punts de sincronització i recuperació
5. Per què gairebé cap protocol no la implementa per separat
6. On viu avui el concepte: tres exemples a Meridiano

Primer, distingim dues paraules que s'assemblen perillosament:

• Una connexió (capa 4) és un canal de transport entre dos processos: el tub TCP entre el navegador de la Marta i el port 443 del servidor.
• Una sessió (capa 5) és un diàleg amb context i continuïtat: "la conversa de la Marta amb la intranet, autenticada com a Marta, amb el seu cistell de gestions a mitges, des que entra fins que surti".

La diferència es veu en preguntar-se: si el tub es trenca i se n'obre un altre, segueix viva la conversa? Amb només capa 4, no: cada connexió nova comença de zero. La capa de sessió és la que OSI defineix perquè la resposta sigui sí: la seva funció és donar a la comunicació una vida més llarga i més rica que la de les connexions que la transporten.

El contracte OSI de la capa 5:

• Què rep de dalt (capa 6): dades d'aplicacions que volen mantenir diàlegs organitzats i amb memòria.
• Quin servei ofereix: obrir, mantenir, sincronitzar i tancar sessions; organitzar els torns del diàleg; i marcar punts de control per reprendre després d'una fallada.
• Què fa servir de baix (capa 4): connexions de transport entre processos — que poden ser diverses, successives o simultànies, al servei d'una mateixa sessió.
• La seva PDU: dades (com a totes les capes superiors; a partir d'aquí ja no hi ha capçaleres amb adreces pròpies).

El cicle de vida d'una sessió té tres fases, i a cadascuna hi ha decisions que algú ha de prendre:

1. Establiment: els dos extrems acorden iniciar el diàleg i en fixen el context: qui són (aquí s'hi sol enganxar l'autenticació), quines regles faran servir, quin identificador tindrà la sessió.
2. Manteniment: mentre dura, la sessió conserva l'estat (qui és l'usuari, què s'ha fet ja) i vigila que l'interlocutor segueix allà — els "batecs" o keepalives periòdics, i els tancaments per inactivitat, són gestió de sessió pura.
3. Tancament: ordenat (tots dos acorden acabar i alliberen recursos) o abrupte (un desapareix i l'altre ho ha de detectar i netejar).

Fixa't que res d'això no ho fa la capa 4 tota sola: TCP obre i tanca connexions, però no sap qui és la Marta, ni recorda res entre una connexió i la següent, ni decideix quan un diàleg "ha caducat". Aquest estat amb significat és l'aportació de la capa 5.

Segon servei: organitzar els torns. OSI distingeix els diàlegs:

• Full-duplex: tots dos extrems poden parlar alhora (una trucada telefònica normal).
• Half-duplex: es parla per torns, i cal gestionar "el testimoni" de qui té la paraula (un walkie-talkie: "canvi").

Encara que el terme soni antic, el problema és actual: en una videotrucada, el programari decideix de qui és l'àudio dominant i silencia ecos; en un sistema de reserves, quan dos usuaris editen el mateix recurs, algú gestiona qui té "el torn" d'escriptura perquè no es trepitgin. Cada cop que un programari coordina a qui li toca, està resolent el problema que OSI va anomenar control del diàleg.

El servei més valuós i el més fàcil de reconèixer avui. La idea: en un intercanvi llarg, inserir punts de sincronització — marques de "fins aquí, confirmat i fora de perill" — de manera que, si alguna cosa falla a mitges, no es reiniciï des de zero sinó des de l'última marca.

Et sona? És exactament el que fa el teu navegador quan una baixada interrompuda es reprèn on anava, o el que fan les eines de còpia de seguretat de Meridiano quan la sincronització nocturna amb Bilbao es talla i en reconnectar continua pel fitxer on s'havia quedat. El mecanisme concret varia (marques de posició, peticions de rangs, llistes de blocs ja confirmats), però el concepte és el punt de sincronització de la capa 5, tal qual el va definir OSI fa quaranta anys.

I ara, la pregunta clau de la lliçó: si aquests serveis són tan útils, per què no existeix "el protocol de sessió" corrent al servidor de Meridiano?

La raó és històrica i pràctica alhora. El model OSI es va dissenyar abans i al marge dels protocols que finalment van triomfar. A la pila real d'Internet, els serveis de sessió van resultar necessitar-se de maneres molt diferents segons l'aplicació — la sessió d'una videotrucada no s'assembla en res a la d'una web —, així que ningú no va construir una capa genèrica: cada peça de programari va incorporar els serveis de sessió que necessitava, a la seva manera. El resultat és que la capa 5 no va desaparèixer: es va dissoldre en tres llocs:

Conseqüència per a tu com a professional: "capa de sessió" no és una cosa que es configura, sinó una categoria de problemes — identitat mantinguda, continuïtat, torns, represa. Quan un d'aquests problemes falla, saber que "això és un assumpte de capa 5" et diu on has de mirar: no a la xarxa (capes 1-4, que poden estar perfectes), sinó al programari que gestioni aquella sessió concreta.

La reunió dels dilluns entre l'Ana i en Jon és un festival de capa 5. Abans que flueixi ni un segon de vídeo, el programari de videotrucada estableix la sessió: qui hi participa, quines capacitats té cadascú, identificadors de la trucada. Durant la reunió, la sessió es manté amb batecs periòdics, i el control de diàleg gestiona l'àudio dominant. I el millor: si la VPN parpelleja deu segons, la trucada no "mor" — les connexions de transport es trenquen i es recreen, però la sessió de la trucada sobreviu i el vídeo torna sol. Aquesta reconnexió transparent és la distinció connexió/sessió feta experiència d'usuari: va morir la capa 4; la capa 5 (implementada per l'aplicació) va seguir viva.

Quan l'administrador de Meridiano obre SSH contra el servidor .10, es veu el cicle complet en miniatura: establiment amb autenticació (la identitat queda lligada a la sessió), manteniment amb estat (el directori actual, les variables de l'entorn remot: el servidor recorda on és l'administrador entre ordre i ordre), keepalives que detecten si l'altre extrem ha desaparegut, i tancament ordenat amb exit, que allibera els recursos de tots dos costats. SSH integra els seus serveis de sessió dins del mateix protocol: capa 5 dissolta a l'aplicació, funcionant de llibre.

El cas més quotidià i el més instructiu, perquè aquí la capa 5 es reconstrueix sobre un protocol que no la té: HTTP és sense estat — cada petició arriba al servidor òrfena, sense memòria de les anteriors (ho vas veure a 02-05). Llavors, com sap la intranet que la petició número 40 continua sent de la Marta? Perquè en autenticar-se, el servidor li va lliurar un identificador de sessió en una cookie (o un token), i el navegador el reenvia a cada petició; el servidor manté associat a aquest identificador el context de la Marta. Això és, conceptualment, una capa de sessió artesanal construïda a nivell d'aplicació. I les seves avaries són les incidències de capa 5 més freqüents que atendràs: "la intranet m'ha fet fora" (sessió caducada per inactivitat), "em demana la contrasenya cada dos per tres" (les cookies no persisteixen), "al meu portàtil soc dins i al fix no" (la sessió viu a cada navegador, no "a la xarxa"). En totes elles, ping, DNS i TCP estan perfectes: cap eina de capes 1-4 no hi veurà res d'estrany, perquè el problema viu a l'estat del diàleg.

• Confondre sessió amb connexió. La connexió és el tub (capa 4); la sessió és la conversa amb memòria (capa 5). Una sessió pot sobreviure a moltes connexions (la videotrucada després del parpelleig de la VPN) i una connexió pot transportar sessions de diversos usuaris.
• Buscar la capa 5 com un component configurable. No existeix "el servei de sessió" del sistema: són funcions repartides entre TLS, els protocols d'aplicació i el codi de cada aplicació. Es diagnostica al programari, no a la xarxa.
• Culpar la xarxa de problemes de sessió. "M'expulsa de la intranet cada 10 minuts" amb ping i DNS perfectes no és un problema de xarxa: és una política de caducitat de sessió o unes cookies que no persisteixen. Reconèixer la capa t'estalvia perseguir fantasmes per les capes 1-4.
• Creure que com que OSI "es va equivocar" amb aquesta capa, no val la pena estudiar-la. Al contrari: els conceptes (establiment, estat, torns, sincronització, represa) apareixen a cada sistema distribuït modern. El que no va quallar va ser implementar-la com a peça separada; el vocabulari és d'ús diari.
• Consell: quan alguna cosa "es desconnecta" o "expulsa" un usuari, pregunta primer: què va morir, la connexió o la sessió? I qui gestiona aquesta sessió: TLS, el protocol o l'aplicació? Aquestes dues preguntes dirigeixen el diagnòstic al lloc correcte.

Exercici 1. Classifica cada situació com a establiment/gestió/tancament de sessió, control de diàleg o punt de sincronització: (a) la còpia nocturna cap a Bilbao es talla i en reconnectar continua pel fitxer 412 de 900; (b) el programari de videotrucada dona preferència a l'àudio d'en Jon mentre presenta i atenua la resta; (c) la intranet expulsa la Marta després de 30 minuts sense activitat; (d) SSH demana usuari i clau abans d'acceptar cap ordre.

Exercici 2. Durant la reunió dels dilluns, la VPN entre seus cau vuit segons. La videotrucada es congela i es recupera sola; en canvi, la transferència d'un fitxer que en Jon tenia a mitges per una altra eina s'avorta i cal llançar-la de nou des de zero. Explica tots dos comportaments en termes de connexió (capa 4) i sessió (capa 5). Quin servei de capa 5 li falta a l'eina de transferència?

Exercici 3. La Marta truca al suport: "la intranet em demana la contrasenya contínuament, cada dos o tres clics". El ping al servidor és perfecte, el DNS resol i les pàgines carreguen ràpid. (a) Quines capes pots donar per bones? (b) On localitzes el problema i per què? (c) Dona dues causes plausibles coherents amb aquest diagnòstic.

Solució 1. (a) Punt de sincronització (represa des de l'última marca confirmada). (b) Control de diàleg (gestió de torns/paraula dominant). (c) Gestió/tancament de sessió (caducitat per inactivitat: política de manteniment de l'estat). (d) Establiment de sessió (l'autenticació lliga la identitat al diàleg abans de començar).

Solució 2. En tots dos casos les connexions de capa 4 van morir amb la caiguda de la VPN: això és inevitable i igual per a les dues aplicacions. La diferència és una capa més amunt: el programari de videotrucada manté una sessió independent de les seves connexions — en tornar la xarxa, restableix connexions noves i les reassocia a la sessió viva (identificadors de trucada, estat dels participants), i l'usuari només veu una congelació. L'eina de transferència no té aquest nivell: el seu "diàleg" és la seva connexió, i en morir aquesta, mor tot. Li falta el servei de punts de sincronització/represa: marques de progrés confirmat que permetessin reprendre per on anava en una connexió nova.

Solució 3. (a) Capes 1-4 correctes (ping, resolució, càrrega ràpida: xarxa i transport funcionen) — i el mateix servei web respon, així que tampoc no és el "port tancat" de la lliçó anterior. (b) A la gestió de sessió de l'aplicació (capa 5 conceptual): que demani la contrasenya cada dos per tres vol dir que el servidor no reconeix la Marta entre peticions — l'identificador de sessió no arriba, no persisteix o no s'accepta. (c) Causes plausibles: el navegador de la Marta bloqueja o esborra les cookies (mode privat, configuració o neteja agressiva), de manera que cada petició arriba sense identificador; o la caducitat de sessió del servidor està mal configurada (un temps de vida absurdament curt que fa expirar les sessions gairebé immediatament). Totes dues encaixen amb una xarxa impecable.

La capa de sessió defineix els serveis que converteixen connexions soltes en diàlegs amb memòria: establiment amb identitat, manteniment de l'estat, control de torns i punts de sincronització per reprendre sense començar de zero. La seva raresa és que a la pila real ningú no la implementa com a peça a part: es va dissoldre dins de TLS, de protocols com SSH i RPC, i del codi de les mateixes aplicacions — les cookies de la intranet de Meridiano són una capa 5 artesanal sobre un HTTP sense estat. Per a tu, és sobretot una categoria de diagnòstic: quan la xarxa està perfecta però l'usuari "es desconnecta", "caduca" o "no pot reprendre", el problema és de sessió i viu al programari. Ens queda una altra pregunta que les capes 1-5 no responen: les dades arriben senceres, en ordre i dins d'un diàleg viu... però en quin format arriben? Amb quina codificació, comprimides com, xifrades amb què? De la forma de les dades se n'ocupa la capa 6: la capa de presentació, propera lliçó.