A la lliçó anterior vam deixar els paquets IP arribant a la màquina correcta, però amb una pregunta oberta: dins d'aquesta màquina, a quin programa van les dades? Al servidor de València hi conviuen el servei de fitxers, una web interna i alguna cosa més; al PC de la Marta, un navegador amb deu pestanyes, el client de correu i una videotrucada. Els protocols de transport resolen exactament això: la comunicació d'extrem a extrem entre aplicacions, no entre màquines. I hi afegeixen alguna cosa més: com que IP és de «millor esforç» i pot perdre, duplicar o desordenar paquets, el transport és el lloc on es decideix quanta fiabilitat necessita cada comunicació. Els seus dos protagonistes encarnen les dues respostes possibles: TCP, que ho garanteix tot a canvi de feina extra, i UDP, que no garanteix gairebé res a canvi de velocitat. En aquesta lliçó entendràs ports i sockets, el famós three-way handshake, els números de seqüència i els ACK, el control de flux, quan triar cada protocol i com espiar les teves pròpies connexions amb netstat.

1. La missió del transport: d'aplicació a aplicació
2. Ports: el número de despatx de cada aplicació
3. Sockets: l'adreça completa d'una conversa
4. TCP: la fiabilitat com a servei
5. El three-way handshake: obrir la connexió
6. Números de seqüència, ACK i retransmissions
7. Control de flux i tancament de connexió
8. UDP: la velocitat com a servei
9. TCP vs UDP: taula comparativa i casos de Meridiano
10. netstat: primer cop d'ull a les teves connexions

Recapitulem el repartiment de feina de la pila amb el símil postal que venim fent servir: l'enllaç de dades reparteix dins del barri, IP porta el sobre entre ciutats fins a l'edifici correcte... i el transport és el conserge de l'edifici: rep el correu i el puja al despatx exacte a què va adreçat. Un edifici (una màquina, una IP) té molts despatxos (aplicacions), i sense conserge el sobre es quedaria al portal.

Els protocols de transport aporten dos serveis:

• Multiplexació per ports: permetre que moltes aplicacions de la mateixa màquina facin servir la xarxa alhora sense barrejar-se, identificant-ne cadascuna amb un número de port.
• Control del lliurament (opcional): sobre el servei «sense garanties» d'IP, afegir —si l'aplicació ho necessita— lliurament garantit, en ordre i sense duplicats (TCP), o no afegir-hi res i ser ultralleuger (UDP).

Les seves unitats de dades ja les coneixes per l'encapsulació de 02-01: els segments (TCP) i datagrames (UDP) viatgen dins dels paquets IP, que el camp Protocol de la capçalera IP (6 = TCP, 17 = UDP) lliura al protocol de transport correcte.

Un port és un número de 16 bits (0 a 65535) que identifica un punt de comunicació dins d'una màquina. Cada segment porta a la seva capçalera un port d'origen i un port de destinació, igual que el paquet IP porta IP d'origen i de destinació.

Els ports s'organitzen en tres rangs:

Els ports ben coneguts són la «guia telefònica» implícita d'Internet: un servidor web escolta al 80 (HTTP) o al 443 (HTTPS), el DNS al 53, el correu sortint al 25... Els veurem protocol a protocol a la lliçó 02-05; de moment n'hi ha prou amb la idea: client que vol un servei, truca al port estàndard d'aquell servei. El client, per la seva banda, fa servir com a origen un port efímer qualsevol que el seu sistema operatiu li assigna al vol.

La combinació IP + protocol de transport + port s'anomena socket, i és l'adreça completa d'un extrem de comunicació: 192.168.10.10:443 identifica sense ambigüitat «l'aplicació que escolta al port 443 TCP de la màquina 192.168.10.10». Una connexió queda identificada per la parella de sockets dels seus dos extrems:

Si el terme et sona de programar, no és casualitat: els sockets dels llenguatges de programació (l'API amb què un programa obre connexions) són exactament la porta d'entrada als protocols de transport que estem estudiant. Quan el teu codi fa connect() a una IP i un port, està demanant al sistema operatiu el que ve a l'apartat següent.

TCP (Transmission Control Protocol) és el protocol de transport orientat a connexió i fiable. Sobre el «millor esforç» d'IP, garanteix a les aplicacions quatre coses:

1. Lliurament complet: el que es perd, es retransmet.
2. Ordre: les dades arriben a l'aplicació en l'ordre en què es van enviar, encara que els paquets arribin desordenats.
3. Sense duplicats: si alguna cosa arriba dues vegades (per una retransmissió de més), la còpia es descarta.
4. Control de flux: l'emissor no satura el receptor.

L'aplicació que fa servir TCP veu una cosa meravellosament simple: un flux continu de bytes que entra per un extrem i surt intacte per l'altre, com una canonada. Tota la complexitat (trossejar en segments, numerar, confirmar, retransmetre, reordenar) queda amagada. Per això TCP és l'elecció de tot allò que no tolera perdre ni un byte: pàgines web, transferència de fitxers, correu... A Meridiano, quan un consultor desa una proposta de 40 MB al servidor, cadascun d'aquests milions de bytes arriba exacte i en ordre gràcies a TCP.

El preu: TCP necessita establir una connexió abans d'enviar dades, confirmar tot el que viatja i mantenir estat a tots dos extrems. Vegem aquestes peces.

Abans del primer byte de dades, client i servidor executen l'encaixada de mans en tres passos (three-way handshake), l'equivalent exacte al «Digui? — Hola, soc l'Ana — Digues, Ana» de la trucada telefònica de la lliçó 02-01:

• SYN (synchronize): el client demana obrir connexió i anuncia el seu número de seqüència inicial.
• SYN-ACK: el servidor accepta, anuncia el seu i confirma el del client.
• ACK (acknowledgement): el client confirma. Des d'aquest moment tots dos saben que l'altre hi és, escolta, i amb quins números comptaran els bytes.

Per què tres passos i no dos? Perquè tots dos extrems necessiten confirmació que el seu missatge ha arribat: amb el SYN-ACK el client sap que el servidor l'ha sentit; amb l'ACK final el servidor sap que el client ha sentit la seva resposta. Amb dos passos, el servidor obriria connexions sense saber si el client encara hi és.

Si el port de destinació està tancat (ningú no hi escolta), el servidor respon amb un segment RST (reset): el «s'ha equivocat de número, aquí no és» de TCP.

Establerta la connexió, TCP numera cada byte que envia (els números de seqüència acordats al handshake) i el receptor va confirmant amb ACK fins a quin byte ho ha rebut tot correctament. Aquest mecanisme és el cor de la fiabilitat:

Observa les peces de temporització i semàntica treballant juntes:

• El receptor només confirma dades contigües: encara que ha rebut el bloc 3001-4000, continua responent ack=2001 perquè li falta l'anterior. Mentrestant desa el bloc avançat per reordenar-lo després.
• L'emissor detecta la pèrdua per dues vies: ACK duplicats (senyal ràpid) o timeout (si no arriba cap ACK en un temps calculat, retransmet). És la regla «si en X no hi ha confirmació, reenvio» que vam posar d'exemple de temporització a 02-01.
• Resultat: sobre una xarxa que perd paquets, l'aplicació rep el 100 % dels bytes, en ordre. La fiabilitat no és a la xarxa: es fabrica als extrems.

Control de flux: i si el servidor rep més ràpid del que pot processar (disc lent, càrrega alta)? A cada ACK, el receptor anuncia la seva finestra (window): quants bytes més està disposat a acceptar ara mateix. L'emissor no envia mai més enllà de la finestra anunciada; si baixa a 0, s'atura i espera. És el «més a poc a poc, que en prenc nota» de la conversa telefònica: el receptor marca el ritme. (TCP fa a més control de congestió per no saturar la xarxa intermèdia, un tema fascinant que excedeix aquest curs introductori.)

Tancament: quan l'aplicació acaba, la connexió es tanca ordenadament amb un intercanvi de segments FIN i els seus ACK, en què cada extrem s'acomiada per separat («he acabat d'enviar» — «rebut»), perquè pot ser que un acabi abans que l'altre. L'equivalent al «vinga, fins després» / «adeu»: ningú no penja sense avisar. Un tancament abrupte (error, procés mort) se senyala amb RST.

UDP (User Datagram Protocol) és l'altra resposta: un protocol de transport sense connexió i sense garanties, tan simple que la seva capçalera cap en una línia:

UDP pren les dades de l'aplicació, hi posa ports i un checksum, i les lliura a IP. Res més: sense handshake, sense números de seqüència, sense ACK, sense retransmissions, sense control de flux. Cada datagrama és independent, com una postal: pot arribar, perdre's, duplicar-se o avançar-ne un altre, i ningú no ho notificarà.

Per a què serveix un protocol així? Per als casos en què les garanties de TCP fan nosa:

• Trànsit en temps real (veu, videotrucades): si un fragment d'àudio es perd, retransmetre'l no té sentit — arribaria tard, la conversa ja va per un altre punt. Millor un espetec de 20 ms que una pausa de 2 segons esperant retransmissions. La videotrucada diària entre València i Bilbao viatja en UDP precisament per això.
• Intercanvis curts de pregunta-resposta (DNS n'és l'exemple canònic, el veurem a 02-05): per enviar una consulta de 50 bytes, muntar i desmuntar una connexió TCP (3 segments d'obertura + tancament) costaria més que la consulta sencera. Amb UDP: una pregunta, una resposta, llestos. Si es perd, la mateixa aplicació torna a preguntar.
• Difusions i descobriment (DHCP, streaming a moltes destinacions): TCP és punt a punt per naturalesa; UDP pot enviar en difusió.

La regla mental: amb UDP, la fiabilitat (si cal) és responsabilitat de l'aplicació. Les aplicacions modernes de temps real afegeixen sobre UDP just les garanties que els convenen, ni una més.

I aterrada al dia a dia de Grupo Meridiano:

Tot l'anterior es pot veure al teu propi equip amb netstat, disponible a Windows i Linux (al Linux modern, el seu successor és ss, amb una sortida gairebé idèntica). Al PC de la Marta, amb la web interna oberta i el fitxer pujant-se:

Lectura línia a línia, amb els conceptes de la lliçó:

• Cada fila és una connexió TCP identificada per la seva parella de sockets (adreça local i remota, cadascuna IP:port).
• Els ports locals 528xx són efímers; els remots (443, 445) són ben coneguts i delaten el servei: HTTPS i fitxers contra el servidor de València, HTTPS contra un servidor d'Internet.
• Estat ESTABLISHED: el three-way handshake s'ha completat i la connexió és viva. Altres estats que veuràs: LISTEN (un servidor esperant clients — afegeix -a per veure'ls), SYN_SENT (handshake a mitges: SYN enviat sense resposta, típic de servidor caigut o tallafoc), TIME_WAIT (connexió acabada de tancar en cortesia final, estat normal i passatger).
• Les «connexions» UDP no hi apareixen com a tals (no hi ha connexió a llistar); amb netstat -an veuràs els seus ports oberts marcats com a UDP, sense estat.

netstat és la primera eina que converteix aquesta lliçó en una cosa tangible; l'espremerem, juntament amb la resta d'utilitats, al mòdul 6.

• Confondre el port amb una cosa física. El port 443 no és un endoll: és un número a la capçalera del segment. Els ports físics del switch i els ports de transport només comparteixen nom, i barrejar-los delata un principiant.
• Creure que UDP és «pitjor» o que «TCP sempre és millor». Són eines per a problemes diferents: fer servir TCP per a una videotrucada afegeix retards inacceptables; fer servir UDP per transferir un fitxer obliga a reinventar TCP a mà. El professional tria per requisits, no per prestigi.
• Oblidar que la fiabilitat de TCP acaba a l'extrem TCP. TCP garanteix que els bytes arriben al socket receptor; si després l'aplicació els processa malament o el disc falla, això ja no és problema de la xarxa. «La xarxa va bé, la teva aplicació no» és una frase que diràs moltes vegades.
• Ignorar els estats de netstat en diagnosticar. Un SYN_SENT perpetu diu «ningú no respon al handshake» (servei caigut o tallafoc); un ESTABLISHED diu «la connexió existeix, busca el problema més amunt». Distingir-los estalvia hores.
• Consell: memoritza ja la parella 80/443 (HTTP/HTTPS) i el 53 (DNS). A la propera lliçó hi afegirem la resta de ports ben coneguts, i a la teva carrera els faràs servir setmanalment.

Exercici 1. La Marta té obertes alhora dues pestanyes del navegador contra https://intranet.grupomeridiano.example (que resol a 192.168.10.10, port 443). Explica com és possible que les respostes de cada pestanya no es barregin, indicant quins camps de quina capçalera ho fan possible, i escriu un exemple plausible de les dues parelles de sockets.

Exercici 2. Durant la pujada d'un fitxer des de Bilbao al servidor de València, la VPN perd un paquet que transportava el segment amb seq=5001 (bytes 5001-6000). L'emissor ja havia enviat també els bytes 6001-8000. Descriu la seqüència d'ACK i retransmissions fins que tot queda confirmat, i explica què va rebre l'aplicació del servidor mentrestant.

Exercici 3. La videotrucada València–Bilbao s'entretalla i un company proposa «canviar-la a TCP, que és el fiable». Explica en 3-4 frases per què la proposta empitjoraria el problema, i què diu això sobre com triar protocol de transport.

Solució 1: Totes dues pestanyes comparteixen IP local, IP remota i port remot (443), però el sistema operatiu assigna a cada connexió un port efímer d'origen diferent. Els camps port origen i port destinació de la capçalera TCP, combinats amb les IP de la capçalera IP, identifiquen cada connexió de manera única, de manera que cada segment de resposta es lliura al socket (i a la pestanya) correcte. Exemple: pestanya 1 = (192.168.10.21:52840) ↔ (192.168.10.10:443); pestanya 2 = (192.168.10.21:52841) ↔ (192.168.10.10:443).

Solució 2:

1. El servidor rep 6001-8000 però li falta 5001-6000: desa allò avançat i respon ack=5001 (repetit) a cada segment que li arriba: ACK duplicats.
2. L'emissor, en veure ACK duplicats (o quan s'esgota el seu temporitzador), retransmet el segment seq=5001.
3. En rebre'l, el servidor ja té dades contigües fins al 8000 i respon ack=8001, confirmant-ho tot de cop.
4. Mentrestant, l'aplicació del servidor no va rebre res a partir del byte 5001: TCP reté els bytes 6001-8000 fins a poder lliurar el flux en ordre. L'aplicació no veu mai forats ni desordre; només una breu pausa. Aquest és el contracte de TCP.

Solució 3: El problema d'una videotrucada que s'entretalla és la latència i les pèrdues puntuals, i TCP respon a les pèrdues amb retransmissions i esperes: cada paquet d'àudio perdut aturaria el flux fins a ser retransmès (les dades posteriors queden retingudes per respectar l'ordre), convertint microtalls de mil·lisegons en congelacions de segons. L'àudio antic retransmès a més ja no serveix: la conversa va per un altre punt. Per això el temps real fa servir UDP i assumeix pèrdues petites. Moralitat: el protocol de transport es tria segons què tolera l'aplicació (pèrdues o retards?), no segons quin «garanteix més».

El transport completa el viatge: ja no lliurem a màquines, sinó a aplicacions. Hem vist que els ports multiplexen la xarxa entre tots els programes d'un equip (ben coneguts per als serveis, efímers per als clients) i que un socket —IP + protocol + port— és l'adreça completa d'un extrem. Sobre el millor esforç d'IP, TCP fabrica fiabilitat d'extrem a extrem: obre amb el three-way handshake (SYN, SYN-ACK, ACK), numera cada byte, confirma amb ACK, retransmet allò perdut, reordena, ajusta el ritme amb la finestra de recepció i s'acomiada amb FIN; UDP, en canvi, ofereix datagrames nus i immediats, perfectes per al temps real i les consultes curtes — i la taula de Meridiano (fitxers i web per TCP; videotrucada, DNS i DHCP per UDP) resumeix el criteri d'elecció. Amb netstat hem vist per primera vegada les nostres connexions en viu. Ja només queda el darrer pis de la pila, el que motiva tots els altres: els protocols amb què les aplicacions fan coses útils — demanar pàgines web, traduir noms com grupomeridiano.example a IP, moure correu i fitxers, repartir adreces automàticament. Tots ells, a la propera lliçó: Protocols d'Aplicació.