Al mòdul 1 vam deixar enllestit el plànol de la xarxa de Grupo Meridiano: dues estrelles (València i Bilbao) unides per l'enllaç lògic de la VPN. Però un plànol no parla. Quan el PC d'una consultora de València demana un fitxer al servidor, en quin «idioma» el demana? Qui decideix com comença aquesta conversa, com es trossegen les dades, què passa si un tros es perd pel camí? La resposta a totes aquestes preguntes són els protocols de comunicació: els conjunts de regles que fan que màquines de fabricants, sistemes operatius i èpoques diferents s'entenguin a la perfecció. Aquesta lliçó explica què és exactament un protocol, de quins elements es compon, com col·laboren diversos protocols alhora mitjançant l'encapsulació, i acaba amb un exemple panoràmic: tot el que passa, protocol a protocol, quan una consultora de Meridiano obre una pàgina web. És la lliçó-mapa del mòdul: les quatre següents recorren amb detall cada família que avui només presentarem.

1. Què és un protocol i per què cal?
2. L'analogia de la conversa humana
3. Els tres elements d'un protocol: sintaxi, semàntica i temporització
4. Ningú no treballa sol: famílies i piles de protocols
5. L'encapsulació: capçaleres que es van afegint
6. Exemple guiat: una consultora de Meridiano obre una pàgina web
7. Errors comuns, exercicis i conclusió

Un protocol de comunicació és un conjunt de regles, acordades per endavant, que defineix com s'han d'intercanviar les dades entre dos o més dispositius: quin format tenen els missatges, què significa cada part, en quin ordre s'envien i què cal fer quan alguna cosa falla.

La paraula clau és acordades per endavant. A la xarxa de Meridiano hi conviuen un servidor amb Linux, portàtils amb Windows, mòbils amb Android i iOS, una impressora de xarxa i routers d'un fabricant que ni tan sols coneixem. Cap d'aquests aparells no es va dissenyar pensant en els altres i, tanmateix, tots es comuniquen sense problemes. Això només és possible perquè tots implementen els mateixos protocols, que estan publicats com a estàndards oberts (molts d'ells en documents anomenats RFC, Request for Comments, mantinguts per l'IETF).

Sense protocols, cada fabricant s'inventaria el seu propi format i només es podrien parlar entre si els equips de la mateixa marca. Amb protocols estàndard, la interoperabilitat és total: per això pots canviar el router de Bilbao per un altre de qualsevol marca i la VPN amb València continuarà funcionant.

Un protocol ha de respondre, com a mínim, aquestes preguntes:

• Format: quina estructura té cada missatge? On va el remitent, on el destinatari, on les dades?
• Ordre: qui parla primer? Cal «saludar» abans d'enviar dades?
• Errors: com es detecta que un missatge ha arribat corromput o que no ha arribat? Es reenvia o s'ignora?
• Ritme: a quina velocitat es pot enviar sense saturar el receptor?

La millor manera d'intuir què fa un protocol és fixar-se en una cosa que fem servir cada dia sense adonar-nos-en: el protocol d'una trucada de telèfon entre persones.

Fixa't que la conversa té regles implícites que tots dos respecten: qui la inicia, com es confirma que l'altre escolta, com es demana una repetició, com s'acomiada cadascú. Si en Jon despengés i es quedés callat, o si tots dos parlessin alhora sense parar, la comunicació fracassaria encara que tots dos parlin el mateix idioma. Els protocols de xarxa formalitzen exactament aquesta mena de regles, amb la diferència que les màquines no improvisen: cada pas està definit bit a bit.

Aquesta analogia ens acompanyarà durant tot el mòdul: quan a la lliçó 02-04 vegem l'«encaixada de mans» amb què TCP obre una connexió, reconeixeràs immediatament els passos 1-3 de la trucada de l'Ana.

Tot protocol, sigui humà o informàtic, es pot descompondre en tres elements. És una classificació clàssica que convé memoritzar perquè permet «disseccionar» qualsevol protocol que et trobis al llarg de la teva carrera:

Un exemple concret amb els tres elements alhora: quan el PC de l'Ana envia dades al servidor de fitxers i espera confirmació:

• Sintaxi: la confirmació és un missatge amb un format exacte (camps de tants bits, en tal ordre).
• Semàntica: aquest missatge vol dir «he rebut les teves dades fins al byte N, continua».
• Temporització: si la confirmació no arriba en un temps determinat, el PC de l'Ana dona les dades per perdudes i les reenvia automàticament.

L'Ana no veu res de tot això. I aquesta és la segona gran virtut dels protocols: automatitzen la comunicació de manera transparent per a l'usuari.

Aquí arriba la idea més important de la lliçó: no existeix un únic «protocol d'Internet» que ho faci tot. Comunicar dues aplicacions a través d'una xarxa implica resoldre problemes de naturalesa molt diversa, i es va resoldre repartint la feina entre protocols especialitzats que col·laboren:

Aquest conjunt de protocols que col·laboren, cadascun recolzant-se en els serveis de l'anterior, s'anomena pila de protocols (protocol stack). La pila que fa servir pràcticament tot el planeta —i, per descomptat, Meridiano— és la pila TCP/IP, anomenada així pels seus dos protocols més famosos.

Per què repartir així la feina, per funcions? Per les mateixes raons per les quals en programari separem responsabilitats en mòduls:

• Especialització: cada protocol resol un problema i el resol bé.
• Substituïbilitat: pots canviar el cable per Wi-Fi (canvia el protocol d'enllaç) sense tocar res més; la web continua funcionant igual.
• Evolució independent: HTTP ha canviat de versió diverses vegades sense que calgués tocar Ethernet, i a la inversa.

Aquesta organització per funcions està tan consolidada que existeixen dos models de referència que la formalitzen en «capes» numerades: el model OSI i el model TCP/IP. Els dediquem íntegrament els mòduls 3 i 4, així que de moment queda't només amb la idea: les famílies que veurem en aquest mòdul són, precisament, les capes d'aquests models. Quan hi arribis, ja coneixeràs tots els protagonistes.

Si cada protocol de la pila fa una feina diferent, com col·laboren a la pràctica sobre un mateix missatge? Mitjançant un mecanisme elegantíssim anomenat encapsulació: cada protocol embolcalla les dades que rep del protocol superior afegint-hi la seva pròpia capçalera (un bloc d'informació de control amb la seva sintaxi particular), igual que una carta es fica dins d'un sobre, i aquest sobre podria anar dins d'una saca del servei postal.

Vegem-ho amb el PC de l'Ana enviant les dades d'una petició web:

Observa tres coses importants:

1. Cada protocol només llegeix i escriu la seva pròpia capçalera. Ethernet no sap (ni li importa) que a dins hi viatja una petició web; només sap que ha de lliurar la trama a l'equip amb una certa adreça MAC. És com el carter: lliura sobres sense llegir les cartes.
2. A la destinació hi té lloc el procés invers, la desencapsulació: cada protocol retira la seva capçalera, comprova el que li pertoca i passa el contingut al protocol superior, fins que la petició HTTP «neta» arriba al servidor web.
3. Cada unitat té el seu nom: les dades amb capçalera TCP s'anomenen segment; amb capçalera IP, paquet; amb capçalera Ethernet, trama. Anirem fent servir aquests noms amb un rigor creixent a les properes lliçons, i són vocabulari obligat en qualsevol entrevista tècnica.

El diagrama resumeix la idea: a l'emissor les dades baixen per la pila (cada protocol hi afegeix la seva capçalera) i al receptor pugen (cada protocol la retira). Els protocols del mateix nivell «conversen» entre si a través de les seves capçaleres, encara que físicament tot viatgi junt pel cable.

Tanquem la lliçó amb la visió panoràmica promesa. La Marta, consultora a l'oficina de València, escriu www.grupomeridiano.example al seu navegador i prem Enter. En menys d'un segon, i sense que ella vegi res, hi intervenen totes les famílies de protocols del mòdul. No entrarem en el detall de cap (per a això hi ha les lliçons 02-02 a 02-05); l'objectiu és veure el repartiment de papers:

1. Aplicació — resoldre el nom (DNS). El navegador no sap què és www.grupomeridiano.example; les màquines es localitzen per adreces IP. Un protocol d'aplicació anomenat DNS tradueix el nom a una adreça IP, per exemple 203.0.113.80. (Lliçó 02-05.)
2. Transport — obrir la conversa (TCP). El PC de la Marta i el servidor web executen una petita «encaixada de mans» per acordar que parlaran, i TCP s'encarregarà que res no es perdi ni arribi desordenat. (Lliçó 02-04.)
3. Aplicació — demanar la pàgina (HTTP). El navegador formula la petició en l'idioma de la web, HTTP: «dona'm la pàgina principal». El servidor respondrà amb el contingut. (Lliçó 02-05.)
4. Xarxa — encaminar els paquets (IP). La petició, trossejada en paquets, porta l'adreça IP de destinació. El PC de la Marta veu que 203.0.113.80 no és a la seva xarxa local, així que lliura els paquets al router de València, que els encamina cap a Internet salt a salt. (Lliçó 02-03.)
5. Enllaç — creuar cada tram local (Ethernet). Per arribar físicament del PC de la Marta al router, la trama viatja pel switch de València fent servir adreces MAC. A cada tram del camí es repeteix la jugada amb el protocol d'enllaç que toqui (Ethernet, Wi-Fi, fibra de l'operador...). (Lliçó 02-02.)
6. El viatge de tornada. La resposta del servidor recorre el camí invers; TCP recompon els trossos en ordre, HTTP lliura el contingut i el navegador el pinta a la pantalla.

Fixa't en el patró: cap protocol no fa la feina d'un altre. DNS només tradueix noms; TCP només garanteix el lliurament; IP només encamina; Ethernet només creua el tram local. Si demà la Marta es connecta per Wi-Fi en lloc de per cable, només canvia el pas 5. Si la web passa a HTTPS, només es reforça el pas 3. Aquesta modularitat és la que estudiarem peça a peça a la resta del mòdul.

• Pensar que «Internet funciona amb un protocol». Error garrafal de principiant: funciona amb una pila de desenes de protocols coordinats. Quan algú diu «la xarxa va per TCP/IP» està anomenant la pila sencera pels seus dos membres més famosos.
• Confondre protocol amb programa. HTTP no és el navegador, ni SMTP és l'Outlook. El protocol és el conjunt de regles; el programa és una implementació que les segueix. Per això Chrome i Firefox, tot i ser programes diferents, obren les mateixes webs.
• Creure que l'encapsulació afegeix «còpies» de les dades. No: les dades viatgen una sola vegada; el que s'hi afegeix són capçaleres petites (desenes de bytes) davant seu. El cost és mínim comparat amb el que s'hi guanya.
• Saltar-se el «per a què» i anar directe a memoritzar sigles. En aquest mòdul cada protocol es presenta sempre amb el problema que resol. Si saps el problema, la sigla es recorda sola; a l'inrevés, no.
• Consell: quan et trobis un protocol nou a la feina (i et passarà constantment), fes-li sempre les tres preguntes d'aquesta lliçó: quina sintaxi fa servir?, què signifiquen els seus missatges?, quines regles de temporització té? És un mètode d'anàlisi que funciona amb qualsevol protocol, del més vell al més modern.

Exercici 1. Classifica cada regla d'aquesta «conversa» entre el PC de la Marta i el servidor de fitxers segons sigui sintaxi, semàntica o temporització:

1. «Tot missatge comença amb 6 bytes que contenen l'adreça del destinatari.»
2. «Si en 3 segons no rebo confirmació, reenvio les dades.»
3. «El missatge amb codi 550 significa que no tens permís.»
4. «Entre missatge i missatge cal esperar que el receptor confirmi que està a punt.»

Exercici 2. El departament d'administració de Meridiano pregunta per què, en canviar els portàtils de cable a Wi-Fi, «tot va continuar funcionant igual: la web, el correu, els fitxers del servidor». Explica-ho en dues o tres frases fent servir els conceptes de pila de protocols i substituïbilitat.

Exercici 3. Ordena de dins cap a fora com queda encapsulada una petició HTTP del PC de la Marta just abans de sortir pel cable, i anomena la unitat de dades resultant a cada pas: capçalera Ethernet, capçalera IP, capçalera TCP, petició HTTP.

Solució 1:

1. Sintaxi (defineix el format i la posició d'un camp).
2. Temporització (defineix una espera màxima i què cal fer quan s'esgota).
3. Semàntica (defineix el significat d'un missatge).
4. Temporització (defineix el ritme i els torns de l'intercanvi).

Solució 2: Les aplicacions (web, correu, fitxers) fan servir protocols d'aplicació i de transport que no depenen del medi físic. En passar de cable a Wi-Fi només es va substituir el protocol d'enllaç (Ethernet per 802.11), i com que cada família de la pila treballa de manera independent recolzant-se en la de sota, les capes superiors ni es van assabentar del canvi. És exactament la substituïbilitat que motiva organitzar els protocols per funcions.

Solució 3: De dins cap a fora: la petició HTTP (dades d'aplicació) s'embolcalla amb la capçalera TCP (formant un segment), aquest s'embolcalla amb la capçalera IP (formant un paquet) i aquest amb la capçalera Ethernet més la seva cua (formant una trama), que és el que es converteix en bits i surt pel cable. A la destinació es retiren en ordre invers: Ethernet → IP → TCP → HTTP.

Ja sabem què és un protocol: un conjunt de regles —sintaxi, semàntica i temporització— acordades per endavant perquè màquines heterogènies es comuniquin sense ambigüitat, igual que dues persones segueixen sense adonar-se'n el «protocol» d'una trucada telefònica. I sabem una cosa encara més important: que cap protocol no treballa sol. La comunicació es reparteix entre famílies especialitzades —enllaç, xarxa, transport i aplicació— que col·laboren mitjançant l'encapsulació, afegint i retirant capçaleres com sobres dins de sobres, formant la pila TCP/IP que fa servir tot Internet i, per descomptat, Grupo Meridiano. A l'exemple de la Marta obrint una pàgina web hem vist el repartiment de papers complet a vista d'ocell; ara toca aterrar a cada família. Comencem per baix, per la que resol el problema més immediat de tots: com es parlen dos equips que comparteixen el mateix cable, el mateix switch o la mateixa Wi-Fi. És el terreny d'Ethernet, les adreces MAC i ARP, i l'explorem a la propera lliçó: Protocols d'Enllaç de Dades.