Arribem al cim de la pila TCP/IP: la capa d'aplicació, el territori on viuen els protocols que fan alguna cosa visible per a les persones — el web que obre la Marta, el correu que envia en Jon, la resolució de noms que passa sense que ningú la vegi. Els seus protagonistes ja els coneixes de 02-05 (HTTP, TLS, DNS, correu, SFTP, DHCP), així que no tornarem a disseccionar-los un per un. El que aporta aquesta lliçó és l'arquitectura: per què TCP/IP fica en una sola capa allò que OSI reparteix en tres, on és la frontera pràctica entre "la meva aplicació" i "la xarxa" (pista: a les biblioteques i l'API del sistema operatiu), i — el plat fort — el recorregut complet i ordenat d'una petició real, GET /api/proyectos a la intranet de Meridiano, des de la línia de codi fins al socket de la lliçó anterior. Tancarem amb una idea que sol passar desapercebuda: DNS i DHCP són aplicacions que serveixen la xarxa mateixa, i amb el panorama complet de ports dels serveis de Meridiano. És important perquè aquí és on el 90 % dels professionals TI treballa cada dia: per sobre del socket, però amb la necessitat d'entendre el que hi ha a sota.

1. Una capa que en val tres: la fusió de les OSI 5-7
2. Els protocols coneguts, situats a la pila TCP/IP
3. La frontera pràctica: biblioteques i API del SO
4. Anatomia d'una petició real: GET /api/proyectos, pas a pas
5. Serveis d'infraestructura: aplicacions que serveixen la xarxa
6. El panorama de ports de Meridiano

Al mòdul 3 vas dedicar tres lliçons a les capes altes d'OSI — sessió (03-06), presentació (03-07) i aplicació (03-08) — i a cadascuna vas arribar a la mateixa conclusió: les seves funcions existeixen, però al programari real no viuen en capes separades. TCP/IP simplement fa oficial aquesta realitat: per sobre del transport hi ha una sola capa d'aplicació, i cada protocol resol dins seu, com li convingui, les funcions de sessió i presentació que necessiti.

L'exemple canònic ja el vas treballar: HTTPS. En termes OSI, TLS fa coses de sessió (establir i reprendre sessions segures) i de presentació (xifrar, negociar formats), i HTTP fa coses d'aplicació... però també de sessió (cookies, keep-alive) i de presentació (Content-Type, compressió gzip). Intentar trossejar HTTPS en les capes 5-6-7 és un exercici de taxidèrmia; TCP/IP hi renuncia:

Per què és la decisió correcta per construir? Perquè les necessitats de sessió i presentació varien moltíssim entre aplicacions: DNS no necessita cap sessió; SSH necessita una sessió xifrada persistent amb multiplexatge propi; HTTP va passar del model "una connexió per petició" (HTTP/1.0) a multiplexar desenes de peticions per connexió (HTTP/2) sense que cap altra capa hagués de canviar. Estandarditzar aquestes funcions en capes fixes hauria estat una cotilla. La contrapartida: quan diagnostiques, el vocabulari fi d'OSI continua sent útil — "això falla a presentació" (un JSON mal codificat) és més precís que "això falla a aplicació". D'aquest doble ús en parlarem a fons a 04-06.

Col·loquem el catàleg de 02-05 al seu lloc, amb el seu transport i el seu port — els dos trets d'identitat d'un protocol d'aplicació en TCP/IP:

Dues observacions d'arquitecte:

• El port és l'adreça "social" del protocol. Que HTTPS sigui "el 443" és un conveni (els ports ben coneguts — well-known ports — de la IANA), no una llei física: la intranet de Meridiano podria escoltar al 8443 i funcionaria igual — però tots els clients ho haurien de saber. Els convenis existeixen per no haver d'avisar.
• I TLS? No té fila pròpia perquè no és una aplicació: és una capa de seguretat intermèdia que s'interposa entre el transport i el protocol d'aplicació que la faci servir (HTTPS = HTTP sobre TLS; IMAPS = IMAP sobre TLS). Al mapa de TCP/IP viu dins de la capa d'aplicació, enganxada al seu terra. És un dels casos frontera estrella de 04-06.

Aquí hi ha la idea més útil de la lliçó per a un desenvolupador: on acaba "el meu programa" i comença "la xarxa"? La resposta té forma d'escala d'abstraccions:

Lectures d'aquest dibuix:

• La capa d'aplicació s'executa en espai d'usuari. Tot el que hi ha per sobre de la línia de sockets és codi de programa i biblioteques; tot el de sota és el kernel (04-01). HTTP no és "al sistema operatiu": és a la biblioteca que el teu programa carrega.
• Cada esglaó t'estalvia els de sota. El programador de la intranet escriu una línia (http_get(...)) i les biblioteques fan la resta. Però quan alguna cosa falla, l'error pot néixer a qualsevol esglaó — i els missatges el delaten: NXDOMAIN (va fallar el resolutor), certificate verify failed (va fallar TLS), connection refused (va fallar el connect del socket, 04-04), 404 Not Found (tot el de sota va funcionar; va fallar la conversa HTTP).
• L'API de sockets és el punt de trobada universal. Tant li fa el llenguatge o la biblioteca: al final, tots acaben cridant connect, send i recv. Per això la lliçó 04-04 és la frontissa del mòdul.

Ajuntem totes les peces. El panell de projectes que la Marta té obert al navegador executa:

El que passa entre aquesta línia i el JSON a la pantalla, en ordre i amb la seva capa:

Pas 1 — Resolució de noms (aplicació: DNS). La biblioteca extreu el nom intranet.grupomeridiano.example i crida el resolutor del SO (getaddrinfo). Si el nom no és a la memòria cau, el resolutor envia una consulta DNS — un datagrama UDP al port 53 del servidor DNS configurat (a València, el mateix router .10.1 fa de DNS de la xarxa i respon amb el registre local). Resposta: 192.168.10.10. Detall fi: per fer aquesta consulta ja hi ha hagut xarxa per sota — un socket UDP, un paquet IP, una trama. La primera "aplicació" que treballa en tota petició web és DNS.

Pas 2 — Connexió (transport: TCP). Amb la IP a la mà, la biblioteca obre un socket i fa connect(192.168.10.10, 443): el three-way handshake de 02-04, tal com el vas veure des del codi a 04-04. El kernel de la Marta tria un port efímer d'origen (p. ex. 52814); al servidor, l'accept() de nginx recull la connexió. Estat: ESTABLISHED a tots dos costats. (Per sota, cada segment va viatjar en paquets IP decidits per la taula de rutes de 04-03 i en trames de la xarxa de 04-02 — però això ja ni ho mirem: les capes de sota funcionen i prou, que és exactament la seva feina.)

Pas 3 — Handshake TLS (aplicació: seguretat). Abans del primer byte d'HTTP, la biblioteca TLS negocia sobre la connexió acabada d'obrir: versions i xifratges, el servidor presenta el seu certificat de intranet.grupomeridiano.example, el client el valida (el signa una autoritat en què confio? el nom coincideix?) i tots dos acorden claus de sessió (02-05, ara al seu lloc exacte de la seqüència). Des d'aquí, tot el que passi pel socket va xifrat: qui capturi el trànsit veurà que la Marta parla amb la intranet, però no què diu.

Pas 4 — Petició i resposta (aplicació: HTTP). Per fi, la biblioteca escriu al canal xifrat:

El servidor respon 200 OK amb Content-Type: application/json i el cos — la llista de projectes. La biblioteca comprova el codi d'estat, descomprimeix si cal, i retorna les dades al codi de la Marta. En total: una línia de codi, quatre converses de xarxa (DNS, TCP, TLS, HTTP), i tota la pila dels mòduls anteriors treballant a sota sense ser vista.

Aquest guió de quatre passos és, a més, la teva llista de comprovació de diagnòstic per a qualsevol "no em carrega": resol el nom? → connecta el port? → valida el certificat? → què respon HTTP? Cada pregunta aïlla un esglaó de l'escala. Al mòdul 6 la convertirem en mètode amb eines.

Hi ha una categoria de protocols d'aplicació amb una peculiaritat filosòfica deliciosa: tècnicament viuen a la capa d'aplicació (corren en espai d'usuari, fan servir transport, tenen port), però el seu client no és una persona — és la xarxa mateixa. Sense ells, les capes de sota no arrenquen:

• DHCP (02-05): quan el portàtil de l'Ana s'uneix a la Wi-Fi de València, encara no té IP, ni màscara, ni gateway, ni servidor DNS. El DORA els hi dona... fent servir UDP i difusió, és a dir, fent servir la pila per configurar la pila. És una aplicació el producte de la qual és que les capes 2-3 dels altres funcionin. A Meridiano, el servidor DHCP corre al router .10.1 i reparteix el rang .10.100–.10.199 (els equips fixos, com el servidor .10.10 o la impressora, tenen IP estàtica o reserva).
• DNS (02-05): sense ell, Internet "funciona" però és inservible — ningú no navega per IP. Cada consulta DNS és una miniaplicació completa (socket UDP, datagrama, resposta) que s'executa abans que l'aplicació "de debò" pugui començar. A Meridiano, el router .10.1 resol els noms interns (intranet.grupomeridiano.example → 192.168.10.10) i reenvia la resta als DNS del proveïdor.
• NTP: sincronitza els rellotges. Sembla cosmètic fins que recordes el pas 3 de la petició: la validació de certificats TLS compara dates — un servidor amb el rellotge desajustat anys comença a rebutjar tots els certificats i "cau Internet" de la manera més desconcertant possible.

La moralitat arquitectònica: en TCP/IP no hi ha cap capa de "gestió" separada — la xarxa s'administra a si mateixa amb aplicacions normals i corrents. És el pragmatisme de 04-01 dut a l'extrem: si una cosa es pot resoldre amb un protocol d'aplicació sobre UDP, no inventis una capa nova.

Tanquem amb el mapa complet de serveis de l'empresa — la taula que l'Ana té (o hauria de tenir) enganxada a la paret, i que és alhora inventari, guia de diagnòstic i base per a les regles del tallafoc:

Fixa't com la taula condensa el mòdul sencer: cada fila és una aplicació (aquesta lliçó) sobre un transport i port (04-04), abastable gràcies a l'encaminament (04-03) sobre les interfícies de cada seu (04-02). Quatre capes, una fila per servei.

• Creure que "capa d'aplicació" = "la meva aplicació". La capa d'aplicació són els protocols (HTTP, DNS...); el teu programa és un usuari d'aquests protocols a través de biblioteques. El navegador no és HTTP: parla HTTP.
• Oblidar que DNS passa primer. Mitja humanitat diagnostica "no funciona el web" reiniciant el router quan la fallada era de resolució de noms. Primera pregunta sempre: resol el nom? (Al mòdul 6: nslookup/dig.)
• Situar TLS "al transport" perquè es diu Transport Layer Security. El nom enganya: TLS corre en espai d'usuari, sobre TCP, dins de la capa d'aplicació de TCP/IP. El matís complet, a 04-06.
• Assumir que el port defineix el protocol. El 443 sol ser HTTPS per conveni, però res no impedeix servir-hi una altra cosa (o HTTPS al 8443). Els ports són convenció, no comprovació — els tallafocs seriosos inspeccionen més enllà del número.
• Ignorar els serveis d'infraestructura en els diagnòstics. Si DHCP falla, "no funciona res" als portàtils però els equips amb IP fixa van bé; si DNS falla, "no funciona res per nom" però el ping a la IP va bé; si NTP es desajusta, TLS falla de maneres absurdes. Els tres patrons són or pur per aïllar problemes.
• Consell: interioritza el guió de 4 passos (DNS → TCP → TLS → HTTP) fins que sigui un reflex. És l'esquelet de qualsevol diagnòstic de servei web i l'estructura sobre la qual muntarem la metodologia del mòdul 6.

1. En Jon, des de Bilbao, obre https://intranet.grupomeridiano.example/api/proyectos i obté un error. L'Ana ho comprova des del PC d'en Jon: nslookup intranet.grupomeridiano.example respon 192.168.10.10; tot seguit, una connexió de prova al port 443 d'aquella IP es queda en timeout. (a) Quins passos del guió de 4 fases han funcionat i quin ha fallat? (b) A quina capa TCP/IP és el problema, probablement? (c) Quin element concret de la infraestructura de Meridiano és el primer sospitós?

2. Classifica aquests tres incidents segons quin servei d'infraestructura ha fallat, raonant pel patró de símptomes: (a) els portàtils de la sala de reunions de València no accedeixen a res, però el servidor .10.10 i la impressora funcionen amb normalitat per a la resta; (b) ningú no pot obrir la intranet per nom, però https://192.168.10.10 (acceptant l'avís del certificat) funciona; (c) des de fa una setmana, el servidor de fitxers rebutja totes les connexions HTTPS amb errors de "certificat no vàlid: encara no és vàlid", però només des d'alguns equips.

3. L'Ana vol endurir el tallafoc del router de València per al trànsit entrant des de la VPN (Bilbao → València): la sucursal només necessita fer servir la intranet, els fitxers compartits i que l'Ana pugui administrar per SSH. Fent servir la taula de ports de Meridiano, escriu la llista mínima de regles "permetre" (destinació, transport, port) i explica per què DNS i DHCP no necessiten regla en aquesta direcció.

1. (a) El pas 1 (DNS) funciona: el nom resol a la IP correcta. El pas 2 (connexió TCP) falla amb timeout: no s'arriba ni a TLS ni a HTTP. (b) Un timeout de connexió (03-05, 04-04) apunta que els SYN no arriben o no tornen: problema a la capa d'Internet (encaminament/abast) o un tallafoc que descarta — no és un problema de l'aplicació intranet (això donaria "connection refused" o un error HTTP). (c) El primer sospitós és el túnel VPN Bilbao–València: és el camí obligat d'en Jon cap a 192.168.10.10. Comprovació ràpida: ping 192.168.10.10 des de Bilbao i revisar l'estat del túnel als routers .20.1 i .10.1. (Que DNS respongués no exculpa la VPN si el resolutor de Bilbao té memòria cau o resol localment.)

2. (a) DHCP: afecta només els equips que demanen configuració dinàmica (portàtils que arriben a la sala), mentre que els d'IP fixa (servidor, impressora) continuen funcionant. Probablement el rang dinàmic exhaurit o el servei DHCP del router caigut. (b) DNS: el patró "per nom no, per IP sí" és la seva signatura inconfusible — la xarxa sencera funciona; només falta el traductor. (c) NTP (rellotge): "encara no és vàlid" significa que l'equip client creu ser en una data anterior a l'inici de validesa del certificat — rellotges desajustats en aquells equips concrets. Per això afecta "només alguns": cada màquina duu el seu propi rellotge malament.

3. Regles mínimes d'entrada des de la VPN: permetre TCP:443 cap a 192.168.10.10 (intranet HTTPS), permetre TCP:445 cap a 192.168.10.10 (SMB), permetre TCP:22 cap a 192.168.10.10 i 192.168.10.1 (SSH d'administració; idealment restringit a més a la IP de l'equip de l'Ana), i denegar la resta. DNS no necessita regla en aquesta direcció perquè els equips de Bilbao pregunten al seu DNS (el router .20.1 o el que tinguin configurat), no al de València — la consulta no creua el túnel cap al .10.1. DHCP tampoc: funciona per difusió dins de cada xarxa local (02-05) i les difusions no travessen ni routers ni túnels — Bilbao té el seu propi DHCP al .20.1.

La capa d'aplicació de TCP/IP és la fusió honesta de les OSI 5-7: cada protocol resol sessió i presentació a la seva manera, i la frontera real entre "programa" i "xarxa" no és en un diagrama sinó a l'API de sockets, amb les biblioteques (HTTP, TLS, resolutor) com a esglaons intermedis que estalvien feina — i com a sospitosos ordenats quan alguna cosa falla. Ja saps recórrer el guió complet d'una petició real (DNS → TCP → TLS → HTTP), reconèixer en DNS, DHCP i NTP les aplicacions que serveixen la xarxa mateixa, i llegir el mapa de ports de Meridiano com el que és: el mòdul 4 sencer comprimit en una taula. Amb les quatre capes ja recorregudes de baix a dalt, queda una última tasca abans de tancar el mòdul: posar els dos mapes — OSI i TCP/IP — l'un al costat de l'altre, decidir quan fer servir cadascun i desactivar les confusions clàssiques de frontera (on va ARP? i TLS?). Aquesta comparativa és la pròxima i última lliçó del mòdul.