La capa 4 del modelo OSI, la capa de transporte, es la gran bisagra del modelo: por debajo quedan las capas que mueven datos entre máquinas (física, enlace, red); por encima, las que piensan en aplicaciones (sesión, presentación, aplicación). La capa de transporte une ambos mundos: toma la entrega "de mejor esfuerzo entre equipos" que ofrece la capa 3 y la convierte en comunicación entre procesos, opcionalmente fiable y ordenada. En el módulo 2 (lección 02-04) ya estudiaste sus dos protocolos estrella —TCP con su three-way handshake, secuencias y ACKs, y UDP— junto a los puertos y netstat; no repetiremos nada de eso. Aquí analizaremos la capa 4 como capa: qué servicios define OSI para ella, qué significa realmente "extremo a extremo", cómo se distinguen control de flujo y de congestión, y cómo se diagnostica en la práctica un problema de capa 4.

1. La función de la capa de transporte dentro del modelo
2. Extremo a extremo: la diferencia clave con la capa 3
3. Servicio 1: multiplexación por puertos
4. Servicio 2: segmentación y reensamblado
5. Servicio 3: fiabilidad — dos niveles de servicio como decisión de diseño
6. Servicio 4: control de flujo y control de congestión
7. Diagnóstico de capa 4: puerto cerrado vs host caído

El contrato OSI de la capa 4:

• Qué recibe de arriba (capas 5-7): un flujo de datos de una aplicación que quiere hablar con un proceso concreto de otro equipo.
• Qué servicio ofrece: comunicación entre procesos (no solo entre máquinas), con el nivel de garantías contratado: desde "entrega fiable, ordenada y controlada" hasta "envío suelto sin promesas".
• Qué usa de abajo (capa 3): la entrega de paquetes entre equipos, de mejor esfuerzo — pueden perderse, duplicarse o llegar desordenados.
• Su PDU: el segmento (o datagrama en el servicio sin conexión). Sus direcciones: los puertos.

Una imagen que ayuda: la capa 3 es el servicio postal que lleva cartas al edificio correcto; la capa 4 es la recepción del edificio, que reparte cada carta al departamento correcto y, si el servicio lo incluye, confirma la recepción, reclama las cartas perdidas y reordena las que llegaron descolocadas.

A diferencia de las capas 1-3, la capa 4 no tiene dispositivos de red propios: vive en el sistema operativo de los extremos. El TCP que gestiona la conexión de Marta con la intranet es código del sistema operativo de su PC y del servidor; los routers y switches intermedios ni la miran (con matices: los firewalls y otros equipos de seguridad sí inspeccionan puertos, y por eso se dicen "de capa 4" — volveremos a ello en el diagnóstico).

"Extremo a extremo" es el concepto que define a esta capa, y conviene precisarlo, porque la capa 3 también entrega "de extremo a extremo" en cierto sentido. La diferencia:

Este diseño tiene nombre —principio extremo a extremo— y es una de las decisiones de arquitectura más influyentes de la historia de las redes: la red por dentro se mantiene simple (los routers solo encaminan), y la inteligencia se pone en los bordes (los sistemas operativos de los extremos ejecutan las garantías). Consecuencia práctica: por muchos routers, túneles y operadores que separen el PC de Jon del servidor de Valencia, la conversación TCP es un asunto privado entre esos dos equipos; la VPN y los routers solo transportan sus paquetes sin entender el diálogo. Es el "diálogo entre pares" de la lección 03-01 en su versión más pura.

El primer servicio resuelve esta pregunta: un paquete llega al servidor 192.168.10.10, que ejecuta a la vez el servidor web de la intranet, el servicio de ficheros y una sesión SSH de mantenimiento — ¿a cuál de los tres van estos datos? La IP sola no lo dice: identifica la máquina, no el programa.

La respuesta es la multiplexación por puertos: la capa 4 etiqueta cada segmento con un puerto de origen y uno de destino, de modo que muchas conversaciones de aplicaciones distintas puedan compartir la misma conexión de red sin mezclarse (eso es multiplexar), y el receptor pueda demultiplexar: entregar cada segmento al proceso que escucha en su puerto destino.

Todo esto (puertos conocidos, puertos efímeros del cliente, el concepto de socket) lo trabajaste en 02-04; el matiz OSI que añadimos es el nombre del servicio: la capa 4 multiplexa las comunicaciones de todas las aplicaciones sobre la única pila de red del equipo, y esa es la razón profunda de que los puertos existan.

Las aplicaciones piensan en sus propios términos: "envía este informe de 8 MB a Bilbao". La capa 3 piensa en paquetes que quepan en las tramas del camino. Alguien debe mediar:

• Segmentación (emisor): la capa 4 trocea el flujo de la aplicación en segmentos de tamaño adecuado y los numera.
• Reensamblado (receptor): la capa 4 del otro extremo usa esa numeración para recolocar en orden los segmentos —que la capa 3 puede haber entregado desordenados— y reconstruir el flujo original antes de entregarlo a la aplicación.

El resultado es una de las abstracciones más elegantes del modelo: la aplicación de Marta escribe y lee un flujo continuo de datos, como si hubiera un tubo directo con el servidor, e ignora por completo que por debajo todo viajó troceado, quizá desordenado y quizá retransmitido. La mecánica concreta con la que TCP numera (números de secuencia y ACKs) ya la viste en 02-04. Nota el contraste con la fragmentación de capa 3 (lección anterior): la segmentación es el troceo bien hecho y planificado en origen por la capa 4; la fragmentación es el parche de emergencia cuando un paquete no cabe — una capa 4 bien ajustada segmenta con un tamaño que evita fragmentar.

OSI define que la capa de transporte puede ofrecer distintas clases de servicio, y la realidad lo confirma: hay dos filosofías, que ya conoces encarnadas en TCP y UDP.

• Servicio orientado a conexión y fiable (TCP): antes de enviar datos se establece una conexión (el handshake de 02-04); cada dato se confirma; lo perdido se retransmite; todo se entrega en orden y sin duplicados; al acabar, la conexión se cierra ordenadamente.
• Servicio no orientado a conexión, de mejor esfuerzo (UDP): cada datagrama se lanza de forma independiente, sin conexión previa, sin confirmaciones y sin promesas. Lo que la capa 3 pierda, perdido está.

Lo que añadimos aquí es la perspectiva de decisión de diseño: elegir clase de servicio es un intercambio entre garantías y coste, y quien elige es el diseñador de cada aplicación:

La fila del dato perdido esconde la clave contraintuitiva: para una videollamada, la fiabilidad es contraproducente — retransmitir un fragmento de audio de hace medio segundo obligaría a esperar por un sonido que ya no interesa; mejor perderlo y seguir con la voz actual. No hay una clase "buena" y otra "mala": hay un servicio adecuado a cada necesidad, y por eso la capa 4 ofrece ambos.

Dos servicios que suelen confundirse porque ambos significan "frenar al emisor". La diferencia está en a quién se protege:

• Control de flujo: protege al receptor. Si el servidor envía datos más deprisa de lo que el PC de Marta puede procesarlos, la memoria de recepción de Marta se desborda. El control de flujo es el mecanismo por el que el receptor comunica al emisor cuánto puede aceptar, y el emisor se ajusta. Es la ventana de recepción que viste en TCP (02-04): un acuerdo entre los dos extremos.

• Control de congestión: protege a la red. Aunque ambos extremos sean rapidísimos, el camino entre ellos puede no serlo: si los emisores inyectan más tráfico del que un enlace intermedio soporta, las colas de los routers se llenan y empiezan a descartar paquetes — congestión. El control de congestión es el mecanismo por el que el emisor deduce el estado de la red (las pérdidas y retrasos son su termómetro) y modera su ritmo: arranca prudente, acelera mientras todo llega bien y frena en cuanto detecta pérdidas.

Ambos mecanismos operan a la vez y el emisor respeta al más restrictivo de los dos. Y ambos son extremo a extremo puro: los routers de en medio no piden nada — como mucho, descartan, y ese descarte es la señal. Que miles de millones de conexiones TCP se autorregulen así, sin coordinador central, es la razón de que Internet no se colapse; los algoritmos concretos son materia avanzada, pero el principio es este.

Al diagnóstico por capas le añadimos hoy su cuarto escalón, con la pregunta que lo caracteriza: "la máquina responde, pero ¿responde el servicio?". La distinción estrella es puerto cerrado vs host caído, porque se ven distinto y significan cosas opuestas.

El caso: el servidor 192.168.10.10 aloja la intranet (puerto 443). Ana no puede abrirla. Dos comprobaciones:

Los tres desenlaces posibles del intento de conexión, y qué significa cada uno:

La lógica del diagnóstico combina ambas pruebas:

• Ping responde + puerto rechazado → problema de capa 4/7 en el servidor: el proceso de la intranet está caído. No toques la red: reinicia o revisa el servicio. Es nuestro caso: el servidor web se había detenido tras una actualización; el equipo, perfectamente vivo.
• Ping responde + puerto en silencio (timeout) → host vivo pero algo descarta la conexión: casi siempre un firewall (en el servidor o en el camino). El silencio, frente al rechazo, es la huella típica del cortafuegos.
• Ping sin respuesta + puerto en silencio → probablemente el host caído o inalcanzable: vuelve a las capas 1-3 (¿enlace? ¿rutas? ¿equipo apagado?). (Con la cautela de que algunos firewalls también bloquean el ping: por eso se valoran las dos pruebas juntas, no cada una por separado.)

Fíjate en el salto conceptual respecto al diagnóstico de capa 3: el ping pregunta "¿estás ahí, máquina?"; la conexión al puerto pregunta "¿estás ahí, programa?". Son preguntas distintas a capas distintas, y la diferencia entre "me rechazan" y "me ignoran" vale un diagnóstico entero. Las herramientas específicas para esto (escáneres de puertos, netstat en profundidad, capturas) llegan en el módulo 6.

• Concluir "el servidor está caído" porque no carga la web. Distingue máquina y servicio: si el ping responde, el host vive y el problema es del servicio (capa 4-7). Diagnósticos opuestos, soluciones opuestas.
• Confundir control de flujo y de congestión. Flujo = protege al receptor, lo pide el receptor. Congestión = protege a la red, lo infiere el emisor. En una entrevista técnica, esta distinción se pregunta tal cual.
• Creer que UDP es "peor" o que "TCP siempre es mejor". Son clases de servicio para necesidades distintas; la fiabilidad tiene un coste que a veces (voz, vídeo en directo) es peor que la pérdida.
• Olvidar que los firewalls actúan en capa 4. Un firewall que descarta en silencio produce timeouts que se confunden con un host caído. Ante un timeout con ping correcto, piensa "firewall" antes que "red rota".
• Pensar que los routers participan en TCP. No lo hacen: las garantías son cosa de los dos extremos. Si hay retransmisiones masivas, la red pierde paquetes (búscalo abajo: congestión, o errores de capa 1-2 como los CRC de la lección 03-03), pero quien retransmite es el extremo.
• Consejo: memoriza el trío de resultados — conecta / me rechazan / me ignoran — y su lectura. Es el diagnóstico de capa 4 entero en tres palabras.

Ejercicio 1. Clasifica cada mecanismo como multiplexación, segmentación/reensamblado, fiabilidad, control de flujo o control de congestión: (a) el servidor reduce su ritmo de envío porque el PC de Marta anuncia que su memoria de recepción está casi llena; (b) el PC de Jon entrega los datos del puerto 443 al navegador y los del 22 al terminal; (c) TCP reenvía un segmento del que no llegó confirmación; (d) el emisor de la copia nocturna baja el ritmo al detectar pérdidas en el enlace VPN; (e) el informe de 8 MB se trocea en segmentos numerados.

Ejercicio 2. Los desarrolladores que mantienen la intranet de Meridiano añaden un módulo de avisos internos en tiempo real: cada pocos segundos, cada PC recibe el estado actualizado de los avisos (el último estado sustituye al anterior; un estado perdido no importa porque enseguida llega el siguiente). ¿Qué clase de servicio de transporte encaja mejor y por qué? Cita dos costes del servicio orientado a conexión que este caso no amortiza.

Ejercicio 3. Desde Bilbao, Jon prueba contra el servidor de Valencia: ping 192.168.10.10 responde bien, pero la conexión al puerto 443 se queda en silencio hasta agotar el tiempo (timeout). Ana, desde Valencia, conecta al 443 sin problema. (a) ¿Qué descarta el ping de Jon? (b) ¿Por qué el timeout (y no un rechazo) es una pista clave? (c) Formula la hipótesis más probable sabiendo que Ana sí conecta desde la red local.

Solución 1. (a) Control de flujo (el receptor pide moderación explícitamente). (b) Multiplexación — en rigor, demultiplexación: repartir por puerto destino. (c) Fiabilidad (retransmisión de lo no confirmado). (d) Control de congestión (el emisor infiere el estado de la red por las pérdidas y se modera). (e) Segmentación con numeración para el posterior reensamblado.

Solución 2. Encaja el servicio no orientado a conexión, de mejor esfuerzo (UDP): los datos son periódicos, pequeños, sustituibles y sensibles a la frescura — retransmitir un estado viejo es inútil porque el siguiente ya viene de camino. Costes del servicio orientado a conexión que no se amortizan: (1) el handshake y el mantenimiento de una conexión por cada PC para mensajes minúsculos y espaciados; (2) las retransmisiones y esperas de orden: ante una pérdida, TCP detendría la entrega hasta recuperar un dato ya obsoleto, añadiendo justo la latencia que se quiere evitar. (También son coste los ACKs y cabeceras mayores para tan poca carga útil.)

Solución 3. (a) El ping correcto descarta problemas de capas 1-3 entre Jon y el servidor: hay camino de ida y vuelta a través de la VPN y el host está vivo. (b) Porque un rechazo habría significado "host vivo, nadie escucha en el 443" (servicio parado); el silencio significa que los intentos de conexión no llegan a ser contestados: algo los descarta por el camino o en el destino — la firma típica de un firewall. (c) Hipótesis más probable: un firewall (en el servidor o en los routers/VPN) permite ICMP y el tráfico local, pero bloquea o no permite el puerto 443 desde la red de Bilbao (192.168.20.0/24); como Ana conecta desde la red local de Valencia, el servicio en sí funciona — el filtro discrimina por origen. Siguiente paso natural: revisar las reglas del firewall del servidor y de los routers respecto al tráfico entre sedes.

La capa de transporte convierte la entrega de mejor esfuerzo entre máquinas de la capa 3 en comunicación entre procesos, con cuatro servicios que ya sabes nombrar: multiplexación por puertos, segmentación y reensamblado que ofrecen a las aplicaciones la ilusión de un flujo continuo, fiabilidad como decisión de diseño con dos clases de servicio (la eterna elección TCP/UDP de 02-04, ahora entendida como intercambio garantías-coste), y el doble freno del control de flujo (protege al receptor) y el control de congestión (protege a la red). Todo ello, ejecutado solo en los extremos: el principio extremo a extremo que mantiene simple el interior de la red. Y en diagnóstico, ganaste la pregunta de capa 4 — ¿responde la máquina o responde el servicio? — con su trío de respuestas: conecta, me rechazan, me ignoran. Con esto culminan las cuatro "capas de fontanería", las que el módulo 2 ya te había presentado por protocolos. A partir de la próxima lección entramos en territorio nuevo: las capas superiores que el módulo 2 trató como un solo bloque. La primera es la más escurridiza de las siete, esa que casi ningún protocolo implementa por separado y sin embargo está en todas partes: la capa de sesión.