Seguimos subiendo la pila. La capa de Internet (04-03) movía paquetes entre máquinas; la capa de transporte conecta procesos entre sí: el navegador de Marta con el servidor web de la intranet, el cliente de correo de Jon con el servidor SMTP, cada uno identificado por un puerto. Los dos inquilinos de esta capa — TCP y UDP — ya los diseccionaste en 02-04 (handshake, números de secuencia, ventana, datagramas), así que aquí no repetiremos su mecánica interna. Lo que aporta esta lección es la capa vista desde el teclado: cómo un programa usa TCP a través de sockets (con pseudocódigo línea a línea), cómo se leen los estados de conexión con ss y netstat, qué significa operativamente cada estado, y qué pasa cuando dos procesos se pelean por el mismo puerto — el famoso "address already in use" que un día parará la intranet de Meridiano. Es importante porque, para un desarrollador o un administrador, la capa de transporte no es teoría: es la interfaz con la que su código toca la red todos los días.

1. Qué vive en la capa de transporte
2. TCP y UDP: dos servicios, un repaso en una tabla
3. Sockets: la capa vista por el programador
4. Un servidor TCP mínimo, línea a línea
5. Un cliente TCP mínimo, línea a línea
6. Estados de conexión en la práctica: ss y netstat
7. Puertos en uso y conflictos: "address already in use"
8. TCP vs UDP como decisión de arquitectura

La capa de transporte de TCP/IP corresponde a la capa 4 de OSI (03-05) y tiene dos habitantes principales:

• TCP (Transmission Control Protocol): servicio orientado a conexión y fiable — establece una sesión con el three-way handshake, numera los bytes, confirma con ACKs, retransmite lo perdido y regula el ritmo con la ventana (todo ello visto en 02-04).
• UDP (User Datagram Protocol): servicio sin conexión y sin garantías — envía datagramas sueltos y se desentiende. Rápido, ligero, y honesto sobre lo que no promete.

Ambos comparten la aportación clave de la capa: el multiplexado por puertos. IP entrega el paquete a la máquina 192.168.10.10; el número de puerto de destino decide a qué proceso de esa máquina va el contenido. La pareja completa que identifica una conversación es el socket pair: (IP origen, puerto origen, IP destino, puerto destino) — y en TCP, además, el protocolo. Por eso el servidor de la intranet puede atender a Marta y a Ana a la vez en el mismo puerto 443: las dos conversaciones difieren en la IP y el puerto de origen.

Sin repetir la mecánica de 02-04, fijemos el contraste como contrato de servicio que la capa ofrece a las aplicaciones:

Un matiz que en 02-04 quedó implícito y que ahora, con la mirada de programador, importa mucho: TCP entrega un flujo, no mensajes. Si el cliente hace dos send() de 100 bytes, el servidor puede recibirlos en un solo recv() de 200, o en tres trozos de 80+80+40. Las fronteras las pone la aplicación (por ejemplo, HTTP con su Content-Length). En UDP, en cambio, cada datagrama llega entero o no llega: un send = un recv.

Un socket es el objeto que el sistema operativo ofrece a los programas para usar la capa de transporte. Recuerda de 04-01 que la pila TCP/IP vive dentro del kernel: tu programa no construye segmentos ni calcula ACKs; pide al SO "dame un socket TCP", escribe bytes en él, y el kernel hace todo lo demás (segmentar, numerar, retransmitir, y pasarlo a la capa de Internet).

La API de sockets (nacida en el Unix BSD de los años 80 y calcada desde entonces en C, Python, Java, Go, JavaScript...) gira en torno a un puñado de operaciones:

La asimetría es la del mundo real: el servidor espera en un puerto conocido; el cliente llama. Veámoslo en pseudocódigo.

Así arranca, en esencia, el servidor de la intranet de Meridiano (lo real es nginx + una API, pero el esqueleto de sockets es este):

Línea a línea, con lo que ocurre por debajo:

• Línea 1 — socket(TCP): el kernel crea la estructura interna y devuelve un identificador (en Unix, un descriptor de fichero: para el programa, un socket se lee y escribe casi como un fichero).
• Línea 2 — bind(...): reserva el puerto 8080 en la IP 192.168.10.10. Es el único punto donde puede saltar el error "address already in use" (lo veremos en el apartado 7). Muchos servidores hacen bind a 0.0.0.0 ("todas mis IPs") en lugar de a una concreta.
• Línea 3 — listen(s): a partir de aquí el kernel completa los handshakes él solo. Cuando el SYN de Marta llegue (02-04), el kernel responde SYN-ACK y encola la conexión terminada, sin que el programa haga nada. El socket pasa al estado LISTEN.
• Línea 5 — accept(s): saca de esa cola una conexión ya establecida y devuelve un socket nuevo (c) exclusivo para esa conversación. Detalle crucial: el socket de escucha s sigue vivo y aceptando; por eso el servidor atiende a muchos clientes con un solo puerto. Si no hay conexiones pendientes, accept bloquea (el proceso duerme hasta que llegue alguien).
• Líneas 6-7 — recv/send: leer y escribir en el flujo. Recuerda: flujo de bytes, no mensajes; recv puede devolver "media petición" y la aplicación debe saber recomponerla.
• Línea 8 — close(c): inicia el cierre ordenado de TCP (intercambio de FIN/ACK, visto conceptualmente en 02-04). Este cierre es el origen del estado TIME_WAIT que enseguida verás en ss.

Los servidores reales añaden concurrencia (un hilo o tarea por conexión aceptada) y bucles de lectura, pero el esqueleto — socket → bind → listen → accept → recv/send → close — es idéntico en cualquier lenguaje.

Y así se ve el lado de Marta cuando su navegador (o un script suyo) pide algo a la intranet:

• Línea 1 — igual que en el servidor: el socket es la misma pieza en ambos lados.
• Línea 2 — connect(...): aquí ocurre el handshake completo de 02-04 (SYN → SYN-ACK → ACK). Cuando connect retorna sin error, la conexión está ESTABLISHED en ambos extremos. Fíjate en lo que no hizo el cliente: ningún bind. El kernel le asigna solo un puerto efímero de origen (típicamente entre 32768 y 60999 en Linux) — por eso en las capturas los clientes siempre hablan "desde" puertos altos y raros.
• Líneas 3-5 — simétricas al servidor: escribir, leer, cerrar.

Un fallo en connect es diagnóstico puro, y ya lo conoces de 03-05: rechazo inmediato (RST) = la máquina está viva pero nadie escucha en ese puerto; timeout = la máquina o la red no responden. La capa de transporte te habla; hay que saber escucharla.

Toda conexión TCP vive en una máquina de estados (el handshake y el cierre son transiciones dentro de ella). No hace falta memorizarla entera: en el día a día, tres estados explican el 95 % de lo que verás. La herramienta moderna en Linux es ss (sustituta de netstat, que sigue existiendo y es lo que hay en Windows).

En el servidor de la intranet, un martes cualquiera:

Desglose de las opciones: -t = solo TCP, -n = números sin resolver (no traduce 443 a "https" ni IPs a nombres — más rápido y sin ambigüedad), -l = solo sockets en escucha. En Windows, netstat -ano da la vista equivalente (la -o añade el PID del proceso).

Los tres estados clave, leídos operativamente:

La tercera línea del ejemplo cuenta una historia completa: Jon (192.168.20.7, Bilbao) consultó la intranet a través de la VPN, terminó, y su conexión está en TIME_WAIT esperando su minuto de cuarentena antes de desaparecer.

Otros estados que verás de pasada: SYN-SENT (cliente esperando el SYN-ACK; si se acumulan, el destino no responde), CLOSE-WAIT (el otro lado cerró y tu aplicación aún no ha llamado a close() — si se acumulan durante horas, sospecha de un bug en la aplicación: sockets sin cerrar).

El incidente clásico en Meridiano: Ana despliega una versión nueva de la API de la intranet y el arranque muere con:

Traducción exacta: el bind() de la línea 2 del servidor pidió un puerto que otro socket ya tiene reservado. Las dos causas habituales, de más a menos frecuente:

1. El proceso viejo sigue vivo. El despliegue no mató la versión anterior, que conserva su LISTEN en el puerto. Diagnóstico en una línea:

   $ ss -tlnp | grep :8080
   LISTEN  0  128  0.0.0.0:8080  0.0.0.0:*  users:(("python3",pid=1147,fd=3))
   

   La opción -p (requiere root) delata al ocupante: proceso python3, PID 1147. Solución: parar ese proceso ordenadamente (el gestor de servicios — systemctl restart — existe precisamente para no llegar aquí). En Windows: netstat -ano | findstr :8080 y buscar el PID en el Administrador de tareas.

2. Conexiones residuales del proceso anterior (TIME_WAIT con ese puerto como origen local en ciertos escenarios de reinicio rápido). Por eso los servidores bien escritos activan la opción de socket SO_REUSEADDR antes del bind: le dice al kernel "permíteme reutilizar el puerto aunque queden restos en TIME_WAIT". Es la primera línea que un desarrollador añade a un servidor tras sufrir esto una vez.

Regla operativa: "address already in use" nunca es un problema de red — es un problema local de la máquina, entre procesos. La red ni se ha enterado.

Y su primo hermano en el cliente: si un cliente abre y cierra miles de conexiones por segundo hacia el mismo destino, puede llegar a agotar los puertos efímeros (todos en TIME_WAIT). Es raro en una pyme como Meridiano, pero explica por qué las aplicaciones intensivas reutilizan conexiones (connection pooling, HTTP keep-alive) en lugar de abrir una por petición.

Elegir transporte no es una preferencia: es una decisión de diseño que se toma respondiendo a dos preguntas — ¿puedo permitirme perder datos? y ¿puedo permitirme esperar? Repasemos los servicios reales de Meridiano:

El patrón que emerge es fiable como una ley: datos que deben llegar íntegros → TCP; tiempo real o intercambios minúsculos donde reintentarlo sale más barato que garantizarlo → UDP. Y una tercera vía moderna que conviene conocer de nombre: QUIC, el transporte de HTTP/3, que corre sobre UDP pero reimplementa fiabilidad, orden y cifrado en la propia aplicación — la prueba de que cuando UDP "no da garantías" en realidad está dando libertad para construir las tuyas.

• Creer que TCP entrega "mensajes". Entrega un flujo de bytes: dos send() pueden llegar como un solo recv() o como varios trozos. Las fronteras de mensaje las define el protocolo de aplicación. Este malentendido es la causa número uno de bugs de red en código de principiantes.
• Asustarse por los TIME_WAIT. Son el funcionamiento correcto del cierre TCP, no conexiones colgadas ni fugas. Preocúpate en cambio por CLOSE-WAIT acumulados: esos sí indican que tu aplicación no cierra sockets.
• Buscar en la red un "address already in use". Es siempre un conflicto local entre procesos por un puerto. ss -tlnp (o netstat -ano) identifica al ocupante en segundos.
• Confundir el socket de escucha con las conexiones. El LISTEN del puerto 443 es uno; cada cliente aceptado tiene su propio socket ESTABLISHED. Cerrar una conexión no afecta al LISTEN, y matar el LISTEN no corta las conexiones ya establecidas.
• Elegir UDP "porque es más rápido" sin plan B. UDP no es TCP-sin-lastre: es un contrato distinto. Si eliges UDP, la fiabilidad que necesites la programas tú (o asumes las pérdidas, como hace el vídeo).
• Consejo: memoriza el trío ss -tln (¿qué escucha?), ss -tn (¿qué conversa?), ss -tlnp (¿quién es el proceso?). Con esas tres órdenes se resuelve la mayoría de dudas "¿está levantado el servicio?" antes de tocar nada más.

1. Ana ejecuta en el servidor de la intranet ss -tn y ve la línea SYN-SENT 0 1 192.168.10.10:41230 192.168.20.7:443 repetida durante 30 segundos, hasta que desaparece con un error. (a) ¿Quién está actuando como cliente y quién como servidor en este intento? (b) ¿Qué significa que el estado se quede clavado en SYN-SENT? (c) Da dos hipótesis compatibles, usando lo aprendido en 03-05.

2. En el pseudocódigo del servidor del apartado 4, explica qué ocurriría exactamente (y qué vería Marta desde su navegador) si: (a) se elimina la línea 3 (listen); (b) el programa se queda procesando una petición lenta en la línea 6 y mientras tanto llegan tres clientes nuevos; (c) se elimina la línea 8 (close) y el servidor atiende cientos de peticiones.

3. Meridiano va a montar dos servicios nuevos: (a) un sistema de copia de seguridad nocturna que sube los ficheros del servidor de Valencia a un almacenamiento en Bilbao a través de la VPN; (b) un panel en recepción que muestra la temperatura de la sala de servidores, actualizada cada 2 segundos desde un sensor. Elige transporte para cada uno y justifícalo con las dos preguntas del apartado 8.

1. (a) El servidor de la intranet actúa aquí como cliente: el puerto de origen es efímero (41230) y el destino es el 443 del PC de Jon o de algún equipo de Bilbao (192.168.20.7) — probablemente un chequeo o integración. Los roles cliente/servidor son por conexión, no por máquina. (b) SYN-SENT clavado significa que se envió el SYN y nunca llegó el SYN-ACK: el handshake no arranca; el kernel reintenta el SYN varias veces y acaba rindiéndose (ese es el error a los ~30 s). (c) Hipótesis compatibles con un timeout (03-05): la máquina .20.7 está apagada o inalcanzable (¿VPN caída? — comprobable con ping), o un cortafuegos descarta silenciosamente los SYN hacia ese puerto. Si el puerto simplemente estuviera cerrado con la máquina viva, habría llegado un RST y el error sería inmediato ("connection refused"), no un timeout.

2. (a) Sin listen, el socket nunca entra en estado LISTEN y el kernel responde a los SYN entrantes con RST: Marta vería un "conexión rechazada" inmediato. (Según el lenguaje, además, el accept de la línea 5 fallaría al ejecutarse.) (b) Nada grave a corto plazo: el kernel completa los handshakes por su cuenta y encola las tres conexiones ya establecidas (dentro del límite del backlog); los tres clientes ven su conexión abierta pero sin respuesta hasta que el servidor termine y vuelva a accept. Perciben lentitud, no rechazo — así se ve un servidor monohilo saturado. Si la cola se desborda, los siguientes SYN sí se descartan. (c) Cada conexión atendida queda abierta para siempre: los ESTABLISHED (y en el cliente, esperas colgadas) se acumulan, y con ellos los descriptores de fichero del proceso, hasta agotar el límite del SO y hacer que accept empiece a fallar. Es la fuga de sockets clásica: se diagnostica viendo cientos de conexiones viejas en ss -tn asociadas al proceso.

3. (a) Copia de seguridad: TCP. ¿Puedo perder datos? No — un backup corrupto es peor que no tener backup. ¿Puedo esperar? Sí — es nocturno, la latencia da igual; y la ventana de TCP además aprovechará bien el túnel VPN regulando el ritmo. (b) Panel de temperatura: UDP es razonable. ¿Puedo perder datos? Sí — si se pierde la lectura de las 10:00:02, la de las 10:00:04 la sustituye; el dato viejo caduca solo. ¿Puedo esperar? No tiene sentido retransmitir una lectura obsoleta. Un datagrama pequeño cada 2 s sin handshake es el ajuste natural. (TCP tampoco sería incorrecto aquí — con tan poco tráfico apenas se notaría — pero UDP expresa mejor el diseño: última lectura gana.)

La capa de transporte es donde la red deja de ser fontanería y se convierte en interfaz de programación: TCP y UDP son dos contratos de servicio — flujo fiable frente a datagramas sin promesas — y el socket es la puerta por la que cualquier programa los usa, con el ritual socket → bind → listen → accept en el servidor y socket → connect en el cliente, mientras el kernel hace el trabajo sucio de 02-04 por debajo. Ya sabes leer el estado de esa maquinaria (ss -tln para lo que escucha, ss -tn para lo que conversa), interpretar operativamente LISTEN, ESTABLISHED y TIME_WAIT, desarmar un "address already in use" en dos órdenes, y elegir transporte como lo que es: una decisión de arquitectura que se responde con dos preguntas. Nos queda un último peldaño en la pila: la capa de aplicación, donde viven los protocolos que Marta y Jon usan sin saberlo — y donde veremos, paso a paso, qué ocurre desde que el código de la intranet pide GET /api/proyectos hasta que esos bytes entran en el socket que acabas de aprender a abrir.