Última parada del recorregut: la capa 7 o capa d'aplicació, el cim del model OSI. És la capa on la xarxa deixa de ser un mecanisme de transport i es converteix en una cosa útil per a les persones: pàgines que s'obren, correus que arriben, fitxers que es comparteixen. També és la capa pitjor entesa, començant pel seu nom: la capa d'aplicació no són les aplicacions — el navegador de la Marta no "és capa 7" — sinó els serveis i protocols de xarxa que les aplicacions fan servir per comunicar-se. En aquesta lliçó precisarem aquesta distinció, entendrem què vol dir exactament que HTTP, DNS o SMTP (vells coneguts del mòdul 2) siguin "protocols de capa 7", veurem com les capes 5-6-7 conviuen foses dins del programari real fent servir el navegador de la Marta com a exemple integrador, i tancarem el mòdul amb la vista completa del model ja recorregut — llesta per comparar-la, al mòdul que ve, amb la pila que de debò governa Internet.

1. La funció de la capa d'aplicació dins del model
2. Què vol dir que HTTP, DNS o SMTP siguin "capa 7"
3. API i serveis de xarxa des de la perspectiva OSI
4. Les capes 5-7 juntes al programari real: el navegador de la Marta
5. El diagnòstic al cim: problemes de capa 7
6. El model complet: taula-resum de les 7 capes

El contracte OSI de la capa 7 és especial, perquè és el final de l'escala:

• Què rep de dalt: ja no hi ha capa superior — a dalt hi ha els processos d'usuari (el navegador, el client de correu, l'aplicació d'escriptori). La capa 7 és la seva interfície amb la xarxa: el conjunt de serveis que un programa invoca quan necessita comunicar-se.
• Quin servei ofereix: serveis de xarxa amb semàntica útil per als programes: "porta aquest document", "resol aquest nom", "lliura aquest missatge a aquesta bústia", "transfereix aquest fitxer".
• Què fa servir de baix (capa 6): dades ja representades de manera comuna (codificades, serialitzades, xifrades si escau), viatjant per un diàleg viu (5) i un transport entre processos (4).
• La seva PDU: dades.

La distinció crucial, dita sense embuts: l'aplicació fa servir la capa d'aplicació, no la constitueix. El navegador de la Marta fa moltíssimes coses que no són xarxa — dibuixar la pàgina, gestionar pestanyes, recordar marcadors —; només quan necessita alguna cosa d'un altre equip parla un protocol de capa 7 (HTTP, o DNS per resoldre el nom). De la mateixa manera, el full de càlcul amb què l'Ana edita un fitxer del servidor no és capa 7, però el protocol de fitxers en xarxa amb què l'obre i el desa, sí. La capa 7 és la finestreta de serveis de xarxa; el programa és el client de la finestreta.

Al mòdul 2 (02-05) vas estudiar HTTP, DNS, SMTP, FTP/SFTP i DHCP com a protocols concrets. Ara podem dir amb precisió OSI què comparteixen per merèixer l'etiqueta "capa 7". Un protocol és de capa d'aplicació quan compleix això:

1. El seu vocabulari parla l'idioma del problema, no el de la xarxa. Les capçaleres de capes 2-4 parlen de MAC, IP, ports, seqüències — mecànica de transport. HTTP parla de documents, mètodes i codis d'estat; SMTP parla de remitents, destinataris i bústies; DNS parla de noms i registres. Cadascun modela un problema humà concret.
2. Defineix el diàleg entre un programa client i un programa servidor: què es pot demanar, com es respon, què vol dir cada error. El GET i el 404 d'HTTP, o el DORA de DHCP, són gramàtica de capa 7.
3. Delega tota la resta cap avall. HTTP no sap encaminar, ni retransmetre, ni xifrar: demana un transport fiable (capa 4), viatja xifrat si hi ha TLS (5-6) i no mira mai una IP de ruta. Aquesta delegació neta és el model de capes funcionant.

Vist així, la taula de protocols de 02-05 adquireix la seva lectura definitiva: cada protocol d'aplicació és un servei especialitzat de la finestreta de capa 7, i tots comparteixen la mateixa infraestructura de les capes 1-6:

Mereix un apunt el cas curiós de DHCP i DNS: són capa 7 per estructura (diàleg client-servidor amb vocabulari propi), però el seu propòsit és donar servei a les capes de baix — DHCP configura adreces de capa 3, DNS tradueix noms a adreces de capa 3. Són l'"administració interna" de la xarxa construïda, amb tota naturalitat, com a serveis d'aplicació. Que això sigui possible —fer servir el cim de la pila per gestionar els seus fonaments— és una elegància del disseny en capes.

Si treballes en desenvolupament, cloud o devops, el teu contacte diari amb la capa 7 té un nom concret: API. Una API web (aquells serveis que responen JSON que vas veure a la lliçó anterior) és, en termes OSI, capa d'aplicació en estat pur: un contracte client-servidor, muntat sobre HTTP, el vocabulari del qual modela un domini de negoci.

L'exemple de Meridiano: la intranet exposa una petita API interna. Quan l'aplicació d'escriptori de l'equip d'administració necessita la llista de projectes, fa una petició com:

Llegeix-ho amb ulleres OSI i hi veuràs tres pisos apilats dins de la mateixa capa d'aplicació i les seves veïnes:

• El contracte de l'API ("existeix /api/proyectos, accepta el filtre estado, retorna projectes") és pur domini: l'esglaó més alt de la capa 7.
• HTTP és el protocol de capa 7 que li presta la mecànica de petició-resposta.
• El JSON de la resposta és representació: capa 6. El token de sessió que autentica l'aplicació: capa 5 conceptual. I de la capa 4 cap avall, la infraestructura que ja domines.

La lliçó de fons: la frontera superior del model OSI és una bastida de contractes apilats — cada servei de xarxa modern es construeix muntant vocabularis sobre vocabularis (API sobre HTTP sobre TLS sobre TCP...), i el model et dona el llenguatge per assenyalar a quin pis és cada cosa. Quan un company digui "el balancejador és de capa 7", ja saps què vol dir: un equip que no es limita a repartir connexions (capa 4), sinó que entén HTTP i decideix llegint les seves capçaleres.

Tres lliçons seguides han acabat igual: "aquesta capa viu dins del programari". És el moment de veure-les totes juntes en l'exemple integrador del curs: què passa dins del navegador de la Marta en obrir la intranet. El navegador és un sol programa, però executa tot solet els papers de les capes 5, 6 i 7:

El diagrama explica la veritat completa sobre les capes altes del model:

• Nítides cap avall: la frontera entre el navegador i el sistema operatiu (entre la capa 5 i la 4) és real i tangible — el programa demana un socket i el SO hi posa TCP/IP. Per això les capes 1-4 tenen protocols, dispositius i eines tan identificables.
• Foses cap amunt: dins del navegador, els papers 5-6-7 no són mòduls separats sinó funcions entreteixides (TLS creua la 5 i la 6; HTTP i les seves llibreries toquen la 6 i la 7). Cap desenvolupador del navegador no va programar "la capa de sessió": va programar funcionalitats que, analitzades amb OSI, cauen en aquestes caselles.

I aquesta és la resposta definitiva a la pregunta que arrosseguem des de 03-01: per què el mòdul 2 va poder tractar les capes 5-7 com una sola "família d'aplicació" sense que passés res? Perquè al programari real estan foses — la separació en tres és analítica, no física. OSI les distingeix perquè són tres problemes diferents (mantenir diàlegs, acordar representacions, servir els programes), i distingir problemes és exactament per al que serveix un model de referència; però les solucions viuen juntes a cada aplicació. Mapa i territori, un cop més.

Completem l'escala de diagnòstic del mòdul. Un problema és "de capa 7" quan tota la infraestructura funciona — enllaç, IP, transport, sessió, format — i tot i així el servei respon malament en el seu propi vocabulari. La bona notícia: la capa 7 és l'única que t'explica els seus errors amb paraules:

Compara amb les capes de baix: un cable trencat no emet missatges, un paquet perdut mor en silenci, un port filtrat ni contesta. A la capa 7, en canvi, llegir l'error és la meitat del diagnòstic — un 403 i un 500 apunten a llocs completament diferents amb total claredat. Per això l'escala completa es recorre tan ràpid quan es domina: física → enllaç → xarxa → transport → sessió/presentació → i, si tot això està bé, deixa que la capa 7 t'ho expliqui amb els seus codis.

Recorregut acabat. Aquesta és la taula de la lliçó 03-01, però ja no com a promesa sinó com a repàs — cada fila és ara una lliçó que has treballat:

Guarda-la: és el resum del mòdul i la teva xuleta de diagnòstic per sempre.

• Dir que "el navegador és capa 7". El navegador és un procés d'usuari que fa servir protocols de capa 7 (i assumeix papers de la 5 i la 6). La capa 7 són els serveis i protocols, no els programes. La distinció sembla pedant fins que cal decidir si una fallada és del programa o del servei de xarxa.
• Tractar els codis d'error d'aplicació com a "fallades de xarxa". Un 404 o un 500 demostren que la xarxa funciona: la petició va arribar i va ser resposta. Escalar un 500 a l'equip de xarxes és el clàssic tiquet mal adreçat.
• Buscar fronteres físiques entre les capes 5, 6 i 7 al programari. No existeixen: són distincions analítiques. Fes-les servir per classificar problemes (diàleg? format? servei?), no per disseccionar programes.
• Oblidar que el DNS pot ser el culpable silenciós. És capa 7, però d'ell depèn que tota la resta comenci. "No funciona res per nom però sí per IP" és la signatura inconfusible d'un problema DNS.
• Consell: en un tiquet de suport, acostuma't a anotar la capa sospitosa i l'evidència ("capa 7: el servidor respon 500; capes 1-4 verificades amb ping i connexió al 443"). Converteix diagnòstics vagues en informes professionals.
• Consell: la taula-resum de dalt, memoritzada amb la columna de "l'essencial", val més que qualsevol mnemotècnia. Les sigles s'obliden; els problemes de cada capa, un cop entesos, no.

Exercici 1. Classifica cada element com a procés d'usuari, protocol de capa 7, o funció de capes 5/6 dins del programari: (a) el client de correu que fa servir en Jon; (b) SMTP; (c) la deserialització del JSON de l'API de projectes; (d) la cookie de sessió de la intranet; (e) DNS; (f) el full de càlcul de l'Ana.

Exercici 2. L'aplicació d'escriptori d'administració falla en demanar GET /api/proyectos. Indica quina capa (aproximada) assenyala cadascun d'aquests resultats alternatius i què faries en cada cas: (a) la connexió al port 443 expira en silenci; (b) connecta, però respon 403 Forbidden; (c) connecta i respon 200 OK, però l'aplicació diu "format de resposta no vàlid"; (d) nslookup del nom de la intranet no resol, encara que amb la IP directa tot funciona.

Exercici 3. Com a tancament del mòdul: la Marta prem Envia en un formulari de la intranet i el navegador mostra un error. Sense més dades, escriu la seqüència de preguntes (una per capa o grup de capes, de baix a dalt) amb què acotaries el problema, i indica al costat de cadascuna l'evidència ràpida que la respon. (Autoavaluació: compara-la amb la solució; l'objectiu és que l'escala ja et surti de memòria.)

Solució 1. (a) Procés d'usuari (fa servir SMTP/IMAP, però ell no és capa 7). (b) Protocol de capa 7. (c) Funció de capa 6 dins del programari (representació). (d) Funció de capa 5 dins del programari (estat del diàleg). (e) Protocol de capa 7 (encara que serveixi la capa 3 traduint noms a IP). (f) Procés d'usuari (el protocol de fitxers en xarxa que faci servir per sota sí que seria capa 7).

Solució 2. (a) El silenci amb timeout apunta a capes 1-4: host caigut, ruta trencada o firewall que descarta — verificar amb ping i des d'una altra xarxa/equip (recordes el trio de 03-05? això és "m'ignoren"). (b) Capa 7, autorització: la infraestructura sencera funciona (la resposta ho demostra); revisar permisos/credencials de l'aplicació a la intranet. (c) Capa 6: transport i servei correctes, acord de representació trencat — comparar el JSON actual amb el que l'aplicació espera (el cas de la lliçó 03-07). (d) Capa 7, DNS: el servei funciona però el nom no resol — revisar el registre A d'intranet.grupomeridiano.example al DNS intern.

Solució 3. Seqüència raonable: (1) Capa 1: té xarxa el PC de la Marta? — icona de xarxa/LED d'enllaç. (2) Capes 2-3 local: assoleix la seva xarxa? — ping 192.168.10.1 (gateway). (3) Capa 3 extrem a extrem: assoleix el servidor? — ping 192.168.10.10. (4) Capa 7-DNS: resol el nom? — nslookup intranet.grupomeridiano.example. (5) Capa 4: accepta el port 443? — connecta, rebutja o ignora? (6) Capes 5-6: sessió vàlida i sense errors de certificat/format? — li demana login? avisa del certificat? (7) Capa 7: quin codi retorna el servidor en enviar el formulari? — un 4xx/5xx localitza la fallada en permisos, en la dada enviada o en el programari del servidor. Cada pas que passa en verd descarta tot l'anterior; el primer vermell delimita la capa i l'equip responsable.

La capa d'aplicació corona el model: és la finestreta on els programes demanen serveis de xarxa amb vocabularis que modelen problemes humans — documents (HTTP), noms (DNS), correu (SMTP), i a sobre seu les API que apilen contractes sobre contractes. Amb ella queda resposta la pregunta pendent des de 03-01: les capes 5, 6 i 7 són tres problemes diferents que OSI separa amb raó, però les solucions dels quals el programari real fon a cada aplicació, com el navegador de la Marta demostra paper a paper. I amb ella es tanca el recorregut complet: set capes, set lliçons, una taula-resum que és alhora mapa del mòdul i xuleta de diagnòstic per a tota la vida. Ara bé: al llarg del camí ho hem repetit — OSI és el mapa teòric, el llenguatge amb què la professió pensa i s'entén. Però el territori, la Internet real per la qual viatgen els paquets de Meridiano, es va construir amb una altra pila: més pragmàtica, de menys capes, nascuda dels protocols que ja domines — IP, TCP, UDP i companyia. Aquesta pila és el model TCP/IP, i a conèixer-la — primer per dins, capa a capa, i només al final cara a cara amb OSI — dediquem el mòdul 4, començant per la propera lliçó: Introducció al Model TCP/IP.