Al final del mòdul anterior vam deixar una idea a l'aire: OSI és el mapa teòric, però el territori — la Internet real per on viatgen cada dia els paquets de Grupo Meridiano — es va construir amb una altra pila, més pragmàtica i amb menys capes. Aquesta pila és el model TCP/IP, i aquesta lliçó és la teva porta d'entrada: d'on ve, per què va vèncer els protocols que la comunitat OSI va intentar imposar, quina filosofia de disseny el va fer imbatible i com s'organitzen les seves quatre capes. És important perquè, a diferència d'OSI, TCP/IP no és un model que "s'estudia": és el programari que ara mateix s'està executant al teu portàtil, al servidor de la intranet de Meridiano i a cada router del camí entre València i Bilbao. Entendre'l és entendre com funciona de debò allò que configures i diagnostiques.

1. D'ARPANET a Internet: la història de TCP/IP
2. Per què TCP/IP va guanyar els protocols OSI
3. La filosofia de disseny: pragmatisme, robustesa i la cintura de rellotge de sorra
4. Les quatre capes del model TCP/IP
5. La variant acadèmica de cinc capes
6. La pila TCP/IP dins d'un sistema operatiu real
7. La petició de la Marta, ara en quatre capes

TCP/IP no va néixer en un comitè d'estandardització, sinó en un projecte de recerca amb un problema molt concret per resoldre.

• 1969 — ARPANET: l'agència DARPA (Defense Advanced Research Projects Agency, del Departament de Defensa dels EUA) finança una xarxa experimental que connecta quatre universitats. El seu protocol inicial, NCP, funcionava, però només dins d'aquella xarxa homogènia.
• Anys 70 — el problema de la interconnexió: apareixen altres xarxes (ràdio, satèl·lit, xarxes locals) amb tecnologies incompatibles entre si. Vint Cerf i Bob Kahn es plantegen la pregunta fundacional: com connectem xarxes diferents entre si? D'aquí ve la paraula Internet: inter-networking, interconnexió de xarxes.
• 1974: Cerf i Kahn publiquen el disseny de TCP. Poc després es decideix separar TCP en dos protocols: IP (lliurar paquets entre xarxes, sense garanties) i TCP (fiabilitat d'extrem a extrem). Aquesta separació, que ja coneixes pels mòduls 2 i 3, és una de les decisions de disseny més influents de la història de la informàtica.
• 1 de gener de 1983 — el "flag day": ARPANET apaga NCP i encén TCP/IP. És la data que se sol citar com a naixement tècnic d'Internet.
• Anys 80-90: universitats, i després empreses i operadors, adopten TCP/IP en massa. El sistema operatiu Unix BSD l'inclou de sèrie amb la seva API de sockets — si el sistema ja porta la pila de franc, per què implementar-ne una altra?

Aquí convé desfer una confusió freqüent. OSI no va ser només el model de 7 capes que vas estudiar al mòdul 3: la ISO també va definir protocols OSI reals per a cada capa (X.400 per al correu, X.500 per al directori, TP0-TP4 per al transport...). Durant els anys 80 molts governs — inclòs el dels EUA — van arribar a exigir protocols OSI en les seves compres. I tot i així van perdre. Per què?

La comunitat d'Internet (l'IETF, que publica les RFC) va resumir el seu mètode en un lema famós, atribuït a Dave Clark:

"We reject: kings, presidents and voting. We believe in: rough consensus and running code." (Rebutgem reis, presidents i votacions. Creiem en el consens aproximat i el codi que funciona.)

"Rough consensus and running code" vol dir: un estàndard d'Internet no s'aprova per votació política, sinó quan hi ha acord general i almenys dues implementacions independents que funcionen i interoperen. TCP/IP va guanyar perquè, quan les empreses van voler connectar-se en xarxa, ja existia codi funcionant, gratuït i provat — mentre que els protocols OSI continuaven sent, en gran part, documents.

D'aquí ve la frase que resumeix tota aquesta lliçó: OSI va guanyar la guerra del vocabulari; TCP/IP va guanyar la guerra de les xarxes. Parlem amb les 7 capes d'OSI, però construïm amb les 4 de TCP/IP.

TCP/IP no és només una llista de protocols: és una manera de pensar que explica per què Internet escala i sobreviu. Tres principis la defineixen.

La xarxa (els routers intermedis) només fa una cosa: moure paquets IP cap a la seva destinació, sense garanties (best effort, "millor esforç"). No garanteix lliurament, ni ordre, ni absència de duplicats. Això, que sembla una debilitat, és la clau de la seva escalabilitat: un router no necessita recordar res de les teves connexions, només mirar l'adreça de destinació i reenviar (com vas veure a 03-04). Menys feina per paquet → routers més simples → xarxa més gran i barata.

Si la xarxa no garanteix res, qui ho fa? Els extrems. El principi d'extrem a extrem (end-to-end) diu: les funcions complexes (fiabilitat, ordre, control d'errors) s'han d'implementar als equips finals — el PC de la Marta i el servidor .10 —, no dins de la xarxa. És exactament el repartiment de feina que vas veure a 03-05: TCP als extrems reordena, retransmet i controla el flux; els routers del mig ni se n'assabenten.

A més, aquest disseny va néixer amb la robustesa com a objectiu explícit: si un router del camí cau, IP simplement encamina per una altra banda i TCP retransmet allò que s'ha perdut. Ningú no ha de "reparar la sessió" al centre de la xarxa, perquè el centre de la xarxa no guarda sessions.

Dibuixa la pila de protocols com un rellotge de sorra:

A dalt, desenes de protocols d'aplicació. A baix, desenes de tecnologies físiques. I al centre, un únic protocol pel qual tot passa: IP. Aquesta és la "cintura del rellotge de sorra" (hourglass waist), i les seves conseqüències són enormes:

• Qualsevol aplicació funciona sobre qualsevol tecnologia de xarxa, sense conèixer-la. La intranet de Meridiano no sap si en Jon hi arriba per fibra, per Wi-Fi o per 4G — i no li cal.
• Innovar a dalt i a baix és independent: es pot inventar un protocol d'aplicació nou (com es va inventar HTTP el 1991) o una tecnologia d'accés nova (com el 5G) sense tocar la resta de la pila. Només cal parlar IP.
• El preu: canviar la mateixa cintura és dificilíssim. Per això la transició d'IPv4 a IPv6 (que aquí només esmentem; la veurem al mòdul 5) fa dècades que està en marxa.

El model TCP/IP organitza tot el que ja saps en quatre capes. No et presenta protocols nous: reagrupa els que vas dominar al mòdul 2.

Observa les dues "fusions" respecte d'OSI (les justificarem a fons a 04-06):

• Accés a la xarxa = física + enllaç: a TCP/IP no li importa com és el medi; en té prou que la trama arribi al salt següent. Ho veurem a 04-02.
• Aplicació = sessió + presentació + aplicació: les funcions de les capes 5 i 6 (que a 03-06 i 03-07 vas veure "dissoltes" en TLS i en els formats de dades) viuen dins de les mateixes aplicacions. Ho veurem a 04-05.

Cada lliçó d'aquest mòdul recorre una capa (04-02 a 04-05), i l'última (04-06) posa els dos models cara a cara.

En molts llibres de text (Tanenbaum, Kurose & Ross...) veuràs una pila de cinc capes: aplicació, transport, xarxa, enllaç i física. No és un tercer model: és TCP/IP amb la capa d'accés a la xarxa dividida en dues, manllevant la separació d'OSI perquè és didàcticament útil (els problemes d'un cable trencat i els d'una taula MAC són molt diferents, com vas veure a 03-02 i 03-03).

Consell pràctic: quan algú digui "capa 2" o "capa 3" sempre està numerant en OSI, encara que estigui treballant amb TCP/IP. Ningú no anomena "capa 2" la capa d'Internet. Els números són d'OSI; els noms de capa TCP/IP es fan servir sense número.

Aquí hi ha la diferència pràctica més important amb OSI: TCP/IP no és un diagrama, és codi instal·lat a la teva màquina. Vegem qui implementa què al PC de la Marta (Windows) i al servidor de la intranet (Linux).

• L'aplicació (navegador, servidor de la intranet) implementa la capa d'aplicació: construeix la petició HTTP, negocia TLS, decideix quin host cal resoldre per DNS.
• El kernel (el nucli del SO) implementa transport i Internet: quan el navegador "envia dades", en realitat les lliura al kernel per l'API de sockets (02-04), i és el kernel qui fabrica segments TCP i paquets IP, consulta la taula de rutes i gestiona retransmissions. Per això no existeix cap programa anomenat tcp.exe: TCP és part del sistema operatiu.
• El driver i la targeta de xarxa implementen l'accés a la xarxa: trames, adreces MAC, senyals.

I les ordres que ja has fet servir són les finestres de configuració i consulta d'aquesta pila del kernel:

Fixa't en el detall conceptual: ipconfig i ip no envien res per la xarxa; llegeixen i escriuen la configuració de la pila TCP/IP que viu dins del kernel. Quan al mòdul 6 fem servir eines de diagnòstic, gairebé totes seran també converses amb aquesta pila.

A 03-01 vas recórrer la petició de la Marta a la intranet baixant les 7 capes d'OSI. Repetim-la en el model real, amb les PDU que ja coneixes:

Quatre passos en lloc de set, i ni una funció nova: DNS, TLS i HTTP viuen junts a la capa d'aplicació (allò que en OSI repartíeu entre 7, 6 i 5); la resta és idèntica. Al servidor .10, la pila puja en ordre invers i lliura la petició al procés del servidor web que escolta al port 443. Mateix territori; mapa més compacte.

• Creure que TCP/IP són només dos protocols. "TCP/IP" és el nom de tota la família (també anomenada Internet protocol suite): inclou UDP, ICMP, DNS, HTTP... Es diu així pels seus dos membres fundadors.
• Pensar que OSI i TCP/IP competeixen i cal triar. Conviuen amb papers diferents: OSI és el vocabulari per pensar i comunicar-te; TCP/IP és allò que està implementat. Un bon professional fa servir tots dos (ho sistematitzem a 04-06).
• Dir "capa 3 de TCP/IP". Els números de capa són argot OSI. En TCP/IP digues "capa d'Internet". Si barreges numeracions, el teu interlocutor no sabrà si la teva "capa 4" és transport (OSI) o aplicació (TCP/IP comptant des de baix).
• Buscar el "programa TCP" al sistema. TCP i IP els implementa el kernel del sistema operatiu. Les aplicacions només veuen sockets. Si un desenvolupador de Meridiano pregunta "quina llibreria HTTP porta el sistema per parlar TCP?", la resposta és: cap llibreria no implementa TCP; totes fan servir el del kernel.
• Menysprear el "best effort" d'IP com un defecte. És una decisió deliberada que fa possible l'escala d'Internet. La fiabilitat no hi falta: és on ha de ser, als extrems.
• Consell: memoritza el dibuix del rellotge de sorra. És la imatge que explica millor per què Internet funciona sobre qualsevol tecnologia i per què IPv4→IPv6 és tan lent.

Situa cada element a la seva capa del model TCP/IP (accés a la xarxa, Internet, transport o aplicació): (a) el three-way handshake, (b) la consulta DNS d'intranet.grupomeridiano.example, (c) el TTL que es decrementa al router de València, (d) la trama amb etiqueta 802.1Q de la VLAN 10, (e) el missatge ICMP "destinació inabastable", (f) la negociació TLS entre el navegador de la Marta i la intranet.

La VPN entre València i Bilbao passa per Internet, i una tarda un router intermedi de l'operador es reinicia. En Jon estava descarregant un fitxer de 200 MB del servidor .10 i la descàrrega es va completar sense errors, només una mica més lenta. Explica quin principi (o principis) de disseny de TCP/IP acaben de salvar la descàrrega, i què va fer cada capa implicada.

Un desenvolupador de Meridiano escriu un script que crida GET /api/proyectos. Per a cadascuna d'aquestes accions, indica si la fa el seu codi/llibreria (espai d'usuari), el kernel o el driver/targeta de xarxa: (1) construir la línia GET /api/proyectos HTTP/1.1, (2) retransmetre un segment perdut, (3) calcular l'FCS de la trama, (4) triar la interfície de sortida consultant la taula de rutes, (5) xifrar les dades amb TLS.

Exercici 1: (a) transport — és TCP (02-04). (b) aplicació — DNS és un protocol d'aplicació (02-05). (c) Internet — el TTL és un camp de la capçalera IP (02-03). (d) accés a la xarxa — 802.1Q és Ethernet/VLAN (03-03). (e) Internet — ICMP acompanya IP a la seva capa (02-03). (f) aplicació — en TCP/IP no hi ha capes de sessió/presentació; TLS viu amb l'aplicació (03-06/03-07 expliquen per què).

Exercici 2: Principis: best effort + robustesa d'IP i principi d'extrem a extrem. La capa d'Internet no guardava cap estat de la descàrrega al router caigut: així que els protocols d'encaminament de l'operador van convergir, els paquets van fluir per un altre camí (encaminament salt a salt, 03-04). Els paquets perduts durant el tall no els va recuperar la xarxa: els va detectar i retransmetre TCP als extrems (el servidor .10 va reenviar allò no confirmat). L'aplicació d'en Jon ni se'n va assabentar: només va veure un flux de bytes una mica més lent. La xarxa va fer el mínim; els extrems van garantir la fiabilitat.

Exercici 3: (1) codi/llibreria — capa d'aplicació en espai d'usuari. (2) kernel — TCP viu al kernel. (3) driver/targeta — l'FCS el calcula normalment el maquinari de la NIC (03-03). (4) kernel — la taula de rutes és del kernel (capa d'Internet). (5) codi/llibreria — TLS l'implementa una biblioteca en espai d'usuari (p. ex. la llibreria TLS que fa servir el llenguatge de l'script), no el kernel.

Ja coneixes el territori en conjunt: TCP/IP va néixer a ARPANET per interconnectar xarxes diferents, va vèncer els protocols OSI gràcies al running code i a les especificacions obertes, i se sosté sobre tres idees — una xarxa mínima de millor esforç, la intel·ligència als extrems i IP com a cintura universal per on tot passa. Les seves quatre capes (accés a la xarxa, Internet, transport i aplicació) no porten protocols nous: reorganitzen tot el que vas aprendre al mòdul 2, i viuen com a codi real al kernel, les biblioteques i els drivers de cada màquina de Meridiano. En les properes quatre lliçons baixarem a cada capa amb mirada pràctica — no "què fa" (això ja ho saps), sinó "com es veu i es toca en un sistema real". Comencem per baix, per la capa que TCP/IP va deixar deliberadament oberta per funcionar sobre qualsevol cable, ona o fibra: la capa d'accés a la xarxa.