Hem pujat tota la pila: l'enllaç de dades creua el segment local, IP uneix les xarxes, TCP i UDP lliuren a l'aplicació correcta amb les garanties justes. Tot aquest engranatge existeix per servir el darrer pis, l'únic que els usuaris veuen: els protocols d'aplicació, els «idiomes» concrets amb què els programes fan coses útils. Quan la Marta obre la intranet, quan el servidor de Bilbao rep un correu o quan un portàtil acabat d'encendre aconsegueix la seva adreça IP sense que ningú no configuri res, hi ha un protocol d'aplicació treballant. En aquesta lliçó recorrerem els imprescindibles: HTTP/HTTPS (la web), DNS (la guia telefònica d'Internet), els protocols de correu (SMTP, IMAP, POP3), la transferència de fitxers (FTP/SFTP) i DHCP (l'assignació automàtica d'adreces). Amb ella completem el catàleg de famílies del mòdul 2 i quedarem a punt per al pas següent: el mapa formal que les ordena totes.

1. La família d'aplicació: els protocols que veuen els programes
2. HTTP: el protocol de la web
3. HTTPS i TLS: la web amb sobre tancat
4. DNS: la guia telefònica d'Internet
5. Correu electrònic: SMTP, IMAP i POP3
6. Transferència de fitxers: FTP i SFTP
7. DHCP: adreces IP automàtiques
8. El quadre complet del mòdul

Un matís important abans de començar: protocol d'aplicació no és el mateix que aplicació (ho vam advertir a 02-01 i aquí es veu clar). Chrome, Firefox i curl són aplicacions diferents; HTTP és el protocol que les tres parlen. L'Outlook i el Thunderbird són programes; SMTP i IMAP són els seus idiomes. El protocol defineix els missatges; el programa, l'experiència.

Tots els protocols d'aquesta lliçó comparteixen tres trets:

• Es recolzen en el transport: cadascun va triar TCP o UDP segons les seves necessitats (la taula de la lliçó anterior pren vida avui), i cadascun té el seu port ben conegut.
• Gairebé tots segueixen el model client-servidor que vam definir a la lliçó 01-02: un servidor escolta al seu port; els clients inicien les peticions.
• Molts són llegibles: els seus missatges són text que un humà pot llegir, cosa que els fa ideals per aprendre (i per diagnosticar, com farem al mòdul 6).

HTTP (HyperText Transfer Protocol) és el protocol de petició-resposta sobre el qual funciona la web: el client (navegador) demana, el servidor respon, i cada intercanvi és independent. Els seus missatges són text pur amb una sintaxi claríssima. Quan la Marta obre la intranet de Meridiano, el seu navegador envia (sobre una connexió TCP al port corresponent) una cosa així:

• GET és el mètode: quina operació es demana.
• /informes/2026 és el recurs sol·licitat dins del servidor.
• Les línies següents són capçaleres amb metadades (a quin lloc es pregunta, quins formats accepta el client...). Una línia en blanc tanca la petició.

I el servidor respon:

La primera línia porta el codi d'estat, la semàntica del resultat. Els mètodes i codis essencials que tot professional ha de reconèixer:

Una regla mnemotècnica que val or en suport: els codis 4xx diuen «el problema és de la petició del client»; els 5xx, «el problema és del servidor». Un 404 després de canviar la intranet apunta a un enllaç vell; un 500, al fet que el servidor de la intranet necessita atenció.

HTTP viatja en text clar: qualsevol que pugui veure el trànsit (per exemple, en una Wi-Fi aliena) llegiria peticions i respostes senceres, contrasenyes incloses. HTTPS és exactament el mateix HTTP, però transportat dins d'un túnel xifrat anomenat TLS (Transport Layer Security), que s'estableix just després de la connexió TCP i abans de la primera petició. Conceptualment, TLS aporta tres garanties:

• Confidencialitat: el contingut va xifrat; un observador només veu bytes inintel·ligibles.
• Integritat: qualsevol manipulació pel camí es detecta.
• Autenticació: mitjançant un certificat digital, el servidor demostra ser qui diu que és (que intranet.grupomeridiano.example és de debò el servidor de Meridiano i no un impostor). És el que el navegador comprova quan mostra el cadenat — o l'avís vermell quan alguna cosa no quadra.

No entrarem en la criptografia (excedeix aquest curs); queda't amb el model mental: HTTPS = HTTP dins d'un sobre lacrat i signat, port 443 en lloc del 80. Avui és l'estàndard: la web pública de Meridiano i la seva intranet van totes dues per HTTPS, i un lloc en HTTP pla és un senyal d'alarma.

El fem servir sense anomenar-lo des de la lliçó 02-01: les persones fan servir noms (www.grupomeridiano.example) i la xarxa fa servir IP (203.0.113.80). El DNS (Domain Name System) és el sistema distribuït que tradueix els uns en les altres. Sense ell, Internet continuaria funcionant... però caldria saber-se les IP de memòria.

Quan el portàtil d'en Jon a Bilbao necessita resoldre un nom, pregunta (per UDP, port 53: consulta curta, resposta curta — el cas de llibre de la lliçó anterior) al seu servidor DNS configurat, anomenat resolver. I aquí hi ha l'elegància del sistema: si el resolver no coneix la resposta, l'esbrina recorrent la jerarquia de noms de dreta a esquerra:

Dos detalls que fan viable el sistema a escala planetària:

• Memòria cau a tots els nivells: cada resposta porta un temps de validesa (TTL, no confondre amb el TTL d'IP); el resolver —i el mateix sistema operatiu— la recorden i les consultes següents es responen a l'instant, sense repetir el recorregut.
• Delegació: ningú no té la llista completa; cada nivell només sap a qui preguntar pel següent. Meridiano administra únicament els noms del seu domini.

Les dades que guarda el DNS s'organitzen en registres de diversos tipus. Els quatre bàsics:

Tot això es pot consultar a mà amb nslookup, disponible a Windows i Linux:

Lectura: primer identifica a quin resolver està preguntant (el configurat a l'equip); «respuesta no autoritativa» vol dir que ha sortit de la memòria cau del resolver, no del servidor DNS del domini — perfectament normal. Es pot demanar un tipus concret de registre:

Quan «no va Internet» però el ping a una IP funciona, el culpable habitual és el DNS: els noms no es resolen encara que la xarxa estigui perfecta. nslookup és l'eina que separa els dos mons en segons; la reprendrem al mòdul 6.

El correu és el sistema federat més antic d'Internet i fa servir protocols diferents per enviar i per llegir — la font de confusió clàssica que deixarem clara:

• SMTP (Simple Mail Transfer Protocol): el protocol d'enviament i encaminament. El fa servir el teu programa de correu per lliurar el missatge al teu servidor, i els servidors entre si per fer-lo arribar al servidor del destinatari. És text llegible: MAIL FROM, RCPT TO, DATA...
• IMAP (Internet Message Access Protocol): el protocol de lectura modern. La bústia viu al servidor; el client la consulta i sincronitza. Llegeixes un correu al mòbil i apareix llegit al portàtil.
• POP3 (Post Office Protocol v3): el protocol de lectura clàssic: descarrega els missatges al dispositiu (típicament esborrant-los del servidor). Simple, però incòmode amb diversos dispositius; avui és minoritari davant d'IMAP.

El viatge d'un correu de la Marta ([email protected]) a un client extern ([email protected]):

Fixa't en el pas 2: el registre MX del DNS és la frontissa de tot el sistema — és la manera com els servidors de correu del món es troben els uns als altres sense cap directori central. Els protocols d'aplicació no viuen aïllats: es recolzen entre si.

FTP (File Transfer Protocol) és el veterà de la transferència de fitxers: sessions amb usuari i contrasenya, ordres per llistar, pujar i descarregar. Mereix conèixer-se perquè encara es troba en sistemes antics i perquè el seu gran defecte ensenya una lliçó: ho transmet tot en clar, credencials incloses (i fa servir connexions separades per a control i dades, cosa que complica el seu pas pels tallafocs).

El seu substitut modern és SFTP (SSH File Transfer Protocol): la mateixa funció, però muntada sobre el canal xifrat d'SSH (port 22), amb autenticació robusta i tot el trànsit protegit. Quan Meridiano necessita intercanviar fitxers amb clients externs, publica un SFTP; l'FTP pla va quedar vetat per política interna.

Nota per no confondre's: els fitxers del dia a dia dins de l'oficina de València no van per FTP/SFTP, sinó pel protocol de carpetes compartides del servidor (SMB, el port 445 que va treure el cap a netstat la lliçó passada). FTP/SFTP brillen en l'intercanvi entre organitzacions o amb servidors remots.

Tanquem amb el protocol més invisible i agraït. Al mòdul anterior vam configurar mentalment IP, màscares i portes d'enllaç; algú les tecleja a cada portàtil i mòbil de Meridiano? No: ho fa DHCP (Dynamic Host Configuration Protocol), el protocol que assigna la configuració de xarxa automàticament quan un equip es connecta.

L'intercanvi es coneix com a DORA, per les inicials dels seus quatre missatges (sobre UDP, ports 67/68, perquè el client encara no té IP i necessita difusió — el tercer cas d'ús d'UDP que vam veure):

Detalls que importen:

• L'assignació és un lloguer (lease) amb caducitat: l'equip l'ha de renovar periòdicament, i les adreces dels equips que se'n van queden lliures per a altres.
• L'ACK final lliura el paquet complet de configuració: IP, màscara, porta d'enllaç i servidor DNS — exactament les dades la funció de les quals vam aprendre a la lliçó 02-03 i en aquesta. DHCP és el protocol que reparteix el que ja sabem interpretar.
• Els equips que ofereixen serveis porten IP fixa fora del rang DHCP (a Meridiano: servidor .10, router .1, impressores .40): un servidor la IP del qual canviés cada dia seria introbable.

Reprendrem DHCP al mòdul 5, quan estudiem l'adreçament a fons; aquí queda presentat com el que és: el protocol d'aplicació que posa en marxa tots els altres.

Amb la família d'aplicació s'acaba el catàleg. Aquest és el mòdul 2 en una sola taula — guarda-la, perquè és l'esquelet de tot el que ve:

I l'encapsulació de la lliçó 02-01 els assembla: el missatge HTTP viatja en un segment TCP, dins d'un paquet IP, dins d'una trama Ethernet. Cada família amb la seva capçalera, la seva adreça i la seva feina.

• Confondre el protocol amb el programa (una vegada més, perquè és l'error etern): «no em funciona l'Outlook» pot ser un problema d'SMTP (enviar), d'IMAP (llegir), de DNS (trobar el servidor) o del programa mateix. Anomenar el protocol correcte és donar la meitat del diagnòstic.
• Oblidar que la web moderna és HTTPS. Provar un servei amb http:// quan només escolta al 443, o estranyar-se de l'avís de certificat sense mirar què diu, són entrebancs de primera setmana. El cadenat no és decoració: és l'autenticació de TLS.
• Culpar «Internet» quan falla el DNS. Si les webs no carreguen però ping 203.0.113.80 respon, la connectivitat està bé i el que està trencat és la resolució de noms. nslookup ho confirma en deu segons.
• Ignorar la memòria cau DNS en fer canvis. Després de canviar un registre, mig món continuarà veient el valor antic fins que caduquin les memòries cau. La paciència (o abaixar el TTL del registre abans del canvi) forma part de l'ofici.
• Consell: aprèn la taula de ports d'aquesta lliçó (80, 443, 53, 25, 993, 22, 67/68) com a vocabulari bàsic. A netstat, als tallafocs i a les ofertes de feina, els serveis s'anomenen pel seu port.

Exercici 1. En Jon, des de Bilbao, escriu https://intranet.grupomeridiano.example en un portàtil acabat d'encendre que s'acaba de connectar a la xarxa. Ordena cronològicament tots els protocols d'aplicació i de transport que hi intervenen fins que veu la pàgina, indicant el paper de cadascun: DHCP, DNS, TCP, TLS, HTTP.

Exercici 2. Indica quin tipus de registre DNS (A, AAAA, CNAME o MX) resol cada necessitat de Meridiano: a) que www.grupomeridiano.example apunti a la IP pública 203.0.113.80; b) que els correus adreçats a @grupomeridiano.example arribin a mail.grupomeridiano.example; c) que intranet.grupomeridiano.example sigui un àlies del nom real del servidor, servidor01.grupomeridiano.example; d) que www també sigui accessible per IPv6.

Exercici 3. A València, un usuari reporta: «no puc entrar a cap web, ni externes ni la intranet». Des del seu equip comproves: ping 192.168.10.1 respon; ping 203.0.113.80 respon; nslookup www.grupomeridiano.example falla amb «tiempo de espera agotado». Quin protocol/servei assenyalaries com a avariat i per què descartes la LAN, el router i la sortida a Internet?

Solució 1:

1. DHCP (UDP): el portàtil, encara sense IP, fa el seu DORA i rep IP, màscara, porta d'enllaç i servidor DNS.
2. DNS (UDP): el navegador necessita la IP d'intranet.grupomeridiano.example; el resolver l'obté (o la serveix de la memòria cau) i respon, per exemple, 192.168.10.10 via el registre CNAME→A corresponent.
3. TCP: three-way handshake amb 192.168.10.10:443 per obrir la connexió.
4. TLS: sobre aquesta connexió es negocia el túnel xifrat i el servidor s'autentica amb el seu certificat.
5. HTTP: dins del túnel, GET / i resposta 200 OK amb la pàgina, que el navegador mostra.

Solució 2: a) A (nom → IPv4). b) MX (domini → servidor de correu). c) CNAME (àlies d'un altre nom). d) AAAA (nom → IPv6).

Solució 3: L'avariat és el servei DNS (o el camí fins al resolver configurat). Raonament per descart: ping 192.168.10.1 respon → la LAN, el switch i l'equip funcionen; ping 203.0.113.80 respon → el router, la porta d'enllaç i la sortida a Internet funcionen (fins i tot una IP externa!); però nslookup no obté resposta → els noms no es resolen, i sense resolució el navegador no pot ni començar (per això fallen «totes les webs», inclosa la intranet, a les quals s'accedeix per nom). Pas següent natural: revisar quin servidor DNS té configurat l'equip (el va lliurar bé DHCP?) i si aquest servidor està operatiu.

Amb els protocols d'aplicació el mòdul queda complet: HTTP/HTTPS demana i lliura la web amb els seus mètodes i codis (i TLS hi posa sobre lacrat i autenticat), DNS tradueix noms en adreces recorrent la seva jerarquia amb memòria cau a cada nivell i registres A, AAAA, CNAME i MX, el correu viatja amb SMTP i es llegeix amb IMAP (o el veterà POP3) trobant la seva destinació gràcies a l'MX, SFTP mou fitxers xifrats on FTP els movia en clar, i DHCP arrenca la funció repartint amb el seu DORA la configuració que fa possible tota la resta. Mira ara el quadre complet del mòdul: aplicació, transport, xarxa i enllaç — quatre famílies, cadascuna amb la seva missió, la seva unitat de dades i les seves adreces, assemblades per l'encapsulació. Aquest quadre no és un resum qualsevol: és, gairebé literalment, un model en capes, i no som els primers a dibuixar-lo. La indústria el va formalitzar fa dècades en un marc de referència de set capes que dona nom i número a cada funció, ordena el vocabulari de tota la professió i estructura des dels temaris de certificació fins a les converses de suport («és un problema de capa 3»). Aquest mapa és el model OSI, i a recórrer-lo capa a capa dediquem el mòdul 3, començant per la propera lliçó: Introducció al Model OSI.