La capa 4 del model OSI, la capa de transport, és la gran frontissa del model: per sota queden les capes que mouen dades entre màquines (física, enllaç, xarxa); per sobre, les que pensen en aplicacions (sessió, presentació, aplicació). La capa de transport uneix tots dos mons: pren el lliurament "de millor esforç entre equips" que ofereix la capa 3 i el converteix en comunicació entre processos, opcionalment fiable i ordenada. Al mòdul 2 (lliçó 02-04) ja vas estudiar els seus dos protocols estrella —TCP amb el seu three-way handshake, seqüències i ACK, i UDP— juntament amb els ports i netstat; no repetirem res d'allò. Aquí analitzarem la capa 4 com a capa: quins serveis defineix OSI per a ella, què vol dir realment "extrem a extrem", com es distingeixen control de flux i de congestió, i com es diagnostica a la pràctica un problema de capa 4.

1. La funció de la capa de transport dins del model
2. Extrem a extrem: la diferència clau amb la capa 3
3. Servei 1: multiplexació per ports
4. Servei 2: segmentació i reassemblatge
5. Servei 3: fiabilitat — dos nivells de servei com a decisió de disseny
6. Servei 4: control de flux i control de congestió
7. Diagnòstic de capa 4: port tancat vs host caigut

El contracte OSI de la capa 4:

• Què rep de dalt (capes 5-7): un flux de dades d'una aplicació que vol parlar amb un procés concret d'un altre equip.
• Quin servei ofereix: comunicació entre processos (no només entre màquines), amb el nivell de garanties contractat: des de "lliurament fiable, ordenat i controlat" fins a "enviament solt sense promeses".
• Què fa servir de baix (capa 3): el lliurament de paquets entre equips, de millor esforç — es poden perdre, duplicar o arribar desordenats.
• La seva PDU: el segment (o datagrama en el servei sense connexió). Les seves adreces: els ports.

Una imatge que ajuda: la capa 3 és el servei postal que porta cartes a l'edifici correcte; la capa 4 és la recepció de l'edifici, que reparteix cada carta al departament correcte i, si el servei ho inclou, confirma la recepció, reclama les cartes perdudes i reordena les que van arribar descol·locades.

A diferència de les capes 1-3, la capa 4 no té dispositius de xarxa propis: viu al sistema operatiu dels extrems. El TCP que gestiona la connexió de la Marta amb la intranet és codi del sistema operatiu del seu PC i del servidor; els routers i switches intermedis ni se la miren (amb matisos: els firewalls i altres equips de seguretat sí que inspeccionen ports, i per això se'n diuen "de capa 4" — hi tornarem al diagnòstic).

"Extrem a extrem" és el concepte que defineix aquesta capa, i convé precisar-lo, perquè la capa 3 també lliura "d'extrem a extrem" en cert sentit. La diferència:

Aquest disseny té nom —principi extrem a extrem— i és una de les decisions d'arquitectura més influents de la història de les xarxes: la xarxa per dins es manté simple (els routers només encaminen), i la intel·ligència es posa a les vores (els sistemes operatius dels extrems executen les garanties). Conseqüència pràctica: per molts routers, túnels i operadors que separin el PC d'en Jon del servidor de València, la conversa TCP és un assumpte privat entre aquells dos equips; la VPN i els routers només transporten els seus paquets sense entendre el diàleg. És el "diàleg entre parells" de la lliçó 03-01 en la seva versió més pura.

El primer servei resol aquesta pregunta: un paquet arriba al servidor 192.168.10.10, que executa alhora el servidor web de la intranet, el servei de fitxers i una sessió SSH de manteniment — a quin dels tres van aquestes dades? La IP sola no ho diu: identifica la màquina, no el programa.

La resposta és la multiplexació per ports: la capa 4 etiqueta cada segment amb un port d'origen i un de destinació, de manera que moltes converses d'aplicacions diferents puguin compartir la mateixa connexió de xarxa sense barrejar-se (això és multiplexar), i el receptor pugui demultiplexar: lliurar cada segment al procés que escolta al seu port de destinació.

Tot això (ports coneguts, ports efímers del client, el concepte de socket) ho vas treballar a 02-04; el matís OSI que hi afegim és el nom del servei: la capa 4 multiplexa les comunicacions de totes les aplicacions sobre l'única pila de xarxa de l'equip, i aquesta és la raó profunda que els ports existeixin.

Les aplicacions pensen en els seus propis termes: "envia aquest informe de 8 MB a Bilbao". La capa 3 pensa en paquets que càpiguen a les trames del camí. Algú hi ha de mitjançar:

• Segmentació (emissor): la capa 4 troceja el flux de l'aplicació en segments de mida adequada i els numera.
• Reassemblatge (receptor): la capa 4 de l'altre extrem fa servir aquesta numeració per recol·locar en ordre els segments —que la capa 3 pot haver lliurat desordenats— i reconstruir el flux original abans de lliurar-lo a l'aplicació.

El resultat és una de les abstraccions més elegants del model: l'aplicació de la Marta escriu i llegeix un flux continu de dades, com si hi hagués un tub directe amb el servidor, i ignora completament que per sota tot va viatjar trossejat, potser desordenat i potser retransmès. La mecànica concreta amb què TCP numera (números de seqüència i ACK) ja la vas veure a 02-04. Fixa't en el contrast amb la fragmentació de capa 3 (lliçó anterior): la segmentació és el trossejament ben fet i planificat en origen per la capa 4; la fragmentació és el pedaç d'emergència quan un paquet no cap — una capa 4 ben ajustada segmenta amb una mida que evita fragmentar.

OSI defineix que la capa de transport pot oferir diferents classes de servei, i la realitat ho confirma: hi ha dues filosofies, que ja coneixes encarnades en TCP i UDP.

• Servei orientat a connexió i fiable (TCP): abans d'enviar dades s'estableix una connexió (el handshake de 02-04); cada dada es confirma; el que es perd es retransmet; tot es lliura en ordre i sense duplicats; en acabar, la connexió es tanca ordenadament.
• Servei no orientat a connexió, de millor esforç (UDP): cada datagrama es llança de manera independent, sense connexió prèvia, sense confirmacions i sense promeses. El que la capa 3 perdi, perdut queda.

El que hi afegim aquí és la perspectiva de decisió de disseny: triar classe de servei és un intercanvi entre garanties i cost, i qui tria és el dissenyador de cada aplicació:

La fila de la dada perduda amaga la clau contraintuïtiva: per a una videotrucada, la fiabilitat és contraproduent — retransmetre un fragment d'àudio de fa mig segon obligaria a esperar un so que ja no interessa; millor perdre'l i seguir amb la veu actual. No hi ha una classe "bona" i una altra "dolenta": hi ha un servei adequat a cada necessitat, i per això la capa 4 ofereix tots dos.

Dos serveis que se solen confondre perquè tots dos volen dir "frenar l'emissor". La diferència és a qui es protegeix:

• Control de flux: protegeix el receptor. Si el servidor envia dades més de pressa del que el PC de la Marta pot processar-les, la memòria de recepció de la Marta es desborda. El control de flux és el mecanisme pel qual el receptor comunica a l'emissor quant pot acceptar, i l'emissor s'hi ajusta. És la finestra de recepció que vas veure a TCP (02-04): un acord entre els dos extrems.

• Control de congestió: protegeix la xarxa. Encara que tots dos extrems siguin rapidíssims, el camí entre ells pot no ser-ho: si els emissors injecten més trànsit del que un enllaç intermedi suporta, les cues dels routers s'omplen i comencen a descartar paquets — congestió. El control de congestió és el mecanisme pel qual l'emissor dedueix l'estat de la xarxa (les pèrdues i els retards són el seu termòmetre) i modera el seu ritme: arrenca prudent, accelera mentre tot arriba bé i frena tan bon punt detecta pèrdues.

Tots dos mecanismes operen alhora i l'emissor respecta el més restrictiu dels dos. I tots dos són extrem a extrem pur: els routers del mig no demanen res — com a molt, descarten, i aquest descart és el senyal. Que milers de milions de connexions TCP s'autoregulin així, sense coordinador central, és la raó que Internet no es col·lapsi; els algorismes concrets són matèria avançada, però el principi és aquest.

Al diagnòstic per capes hi afegim avui el quart esglaó, amb la pregunta que el caracteritza: "la màquina respon, però respon el servei?". La distinció estrella és port tancat vs host caigut, perquè es veuen diferent i signifiquen coses oposades.

El cas: el servidor 192.168.10.10 allotja la intranet (port 443). L'Ana no la pot obrir. Dues comprovacions:

Els tres desenllaços possibles de l'intent de connexió, i què vol dir cadascun:

La lògica del diagnòstic combina totes dues proves:

• Ping respon + port rebutjat → problema de capa 4/7 al servidor: el procés de la intranet està caigut. No toquis la xarxa: reinicia o revisa el servei. És el nostre cas: el servidor web s'havia aturat després d'una actualització; l'equip, perfectament viu.
• Ping respon + port en silenci (timeout) → host viu però alguna cosa descarta la connexió: gairebé sempre un firewall (al servidor o pel camí). El silenci, davant del rebuig, és l'empremta típica del tallafoc.
• Ping sense resposta + port en silenci → probablement el host caigut o inassolible: torna a les capes 1-3 (enllaç? rutes? equip apagat?). (Amb la cautela que alguns firewalls també bloquegen el ping: per això es valoren les dues proves juntes, no cadascuna per separat.)

Fixa't en el salt conceptual respecte al diagnòstic de capa 3: el ping pregunta "hi ets, màquina?"; la connexió al port pregunta "hi ets, programa?". Són preguntes diferents a capes diferents, i la diferència entre "em rebutgen" i "m'ignoren" val un diagnòstic sencer. Les eines específiques per a això (escàners de ports, netstat en profunditat, captures) arriben al mòdul 6.

• Concloure "el servidor està caigut" perquè no carrega la web. Distingeix màquina i servei: si el ping respon, el host viu i el problema és del servei (capa 4-7). Diagnòstics oposats, solucions oposades.
• Confondre control de flux i de congestió. Flux = protegeix el receptor, ho demana el receptor. Congestió = protegeix la xarxa, ho infereix l'emissor. En una entrevista tècnica, aquesta distinció es pregunta tal qual.
• Creure que UDP és "pitjor" o que "TCP sempre és millor". Són classes de servei per a necessitats diferents; la fiabilitat té un cost que de vegades (veu, vídeo en directe) és pitjor que la pèrdua.
• Oblidar que els firewalls actuen a capa 4. Un firewall que descarta en silenci produeix timeouts que es confonen amb un host caigut. Davant d'un timeout amb ping correcte, pensa "firewall" abans que "xarxa trencada".
• Pensar que els routers participen en TCP. No ho fan: les garanties són cosa dels dos extrems. Si hi ha retransmissions massives, la xarxa perd paquets (busca-ho a baix: congestió, o errors de capa 1-2 com els CRC de la lliçó 03-03), però qui retransmet és l'extrem.
• Consell: memoritza el trio de resultats — connecta / em rebutgen / m'ignoren — i la seva lectura. És el diagnòstic de capa 4 sencer en tres paraules.

Exercici 1. Classifica cada mecanisme com a multiplexació, segmentació/reassemblatge, fiabilitat, control de flux o control de congestió: (a) el servidor redueix el seu ritme d'enviament perquè el PC de la Marta anuncia que la seva memòria de recepció és gairebé plena; (b) el PC d'en Jon lliura les dades del port 443 al navegador i les del 22 al terminal; (c) TCP reenvia un segment del qual no va arribar confirmació; (d) l'emissor de la còpia nocturna abaixa el ritme en detectar pèrdues a l'enllaç VPN; (e) l'informe de 8 MB es troceja en segments numerats.

Exercici 2. Els desenvolupadors que mantenen la intranet de Meridiano afegeixen un mòdul d'avisos interns en temps real: cada pocs segons, cada PC rep l'estat actualitzat dels avisos (l'últim estat substitueix l'anterior; un estat perdut no importa perquè de seguida arriba el següent). Quina classe de servei de transport encaixa millor i per què? Cita dos costos del servei orientat a connexió que aquest cas no amortitza.

Exercici 3. Des de Bilbao, en Jon prova contra el servidor de València: ping 192.168.10.10 respon bé, però la connexió al port 443 es queda en silenci fins a esgotar el temps (timeout). L'Ana, des de València, connecta al 443 sense problema. (a) Què descarta el ping d'en Jon? (b) Per què el timeout (i no un rebuig) és una pista clau? (c) Formula la hipòtesi més probable sabent que l'Ana sí que connecta des de la xarxa local.

Solució 1. (a) Control de flux (el receptor demana moderació explícitament). (b) Multiplexació — en rigor, demultiplexació: repartir per port de destinació. (c) Fiabilitat (retransmissió del que no s'ha confirmat). (d) Control de congestió (l'emissor infereix l'estat de la xarxa per les pèrdues i es modera). (e) Segmentació amb numeració per al posterior reassemblatge.

Solució 2. Hi encaixa el servei no orientat a connexió, de millor esforç (UDP): les dades són periòdiques, petites, substituïbles i sensibles a la frescor — retransmetre un estat vell és inútil perquè el següent ja ve de camí. Costos del servei orientat a connexió que no s'amortitzen: (1) el handshake i el manteniment d'una connexió per cada PC per a missatges minúsculs i espaiats; (2) les retransmissions i esperes d'ordre: davant d'una pèrdua, TCP aturaria el lliurament fins a recuperar una dada ja obsoleta, afegint just la latència que es vol evitar. (També són cost els ACK i les capçaleres més grans per a tan poca càrrega útil.)

Solució 3. (a) El ping correcte descarta problemes de capes 1-3 entre en Jon i el servidor: hi ha camí d'anada i tornada a través de la VPN i el host és viu. (b) Perquè un rebuig hauria significat "host viu, ningú no escolta al 443" (servei aturat); el silenci vol dir que els intents de connexió no arriben a ser contestats: alguna cosa els descarta pel camí o a la destinació — la signatura típica d'un firewall. (c) Hipòtesi més probable: un firewall (al servidor o als routers/VPN) permet ICMP i el trànsit local, però bloqueja o no permet el port 443 des de la xarxa de Bilbao (192.168.20.0/24); com que l'Ana connecta des de la xarxa local de València, el servei en si funciona — el filtre discrimina per origen. Pas següent natural: revisar les regles del firewall del servidor i dels routers respecte al trànsit entre seus.

La capa de transport converteix el lliurament de millor esforç entre màquines de la capa 3 en comunicació entre processos, amb quatre serveis que ja saps anomenar: multiplexació per ports, segmentació i reassemblatge que ofereixen a les aplicacions la il·lusió d'un flux continu, fiabilitat com a decisió de disseny amb dues classes de servei (l'eterna elecció TCP/UDP de 02-04, ara entesa com a intercanvi garanties-cost), i el doble fre del control de flux (protegeix el receptor) i el control de congestió (protegeix la xarxa). Tot això, executat només als extrems: el principi extrem a extrem que manté simple l'interior de la xarxa. I en diagnòstic, has guanyat la pregunta de capa 4 — respon la màquina o respon el servei? — amb el seu trio de respostes: connecta, em rebutgen, m'ignoren. Amb això culminen les quatre "capes de fontaneria", les que el mòdul 2 ja t'havia presentat per protocols. A partir de la propera lliçó entrem en territori nou: les capes superiors que el mòdul 2 va tractar com un sol bloc. La primera és la més escorredissa de les set, aquella que gairebé cap protocol no implementa per separat i tanmateix és a tot arreu: la capa de sessió.