En la lección anterior dejamos los paquetes IP llegando a la máquina correcta, pero con una pregunta abierta: dentro de esa máquina, ¿a qué programa van los datos? En el servidor de Valencia conviven el servicio de ficheros, una web interna y alguna cosa más; en el PC de Marta, un navegador con diez pestañas, el cliente de correo y una videollamada. Los protocolos de transporte resuelven exactamente eso: la comunicación extremo a extremo entre aplicaciones, no entre máquinas. Y añaden algo más: como IP es de "mejor esfuerzo" y puede perder, duplicar o desordenar paquetes, el transporte es el lugar donde se decide cuánta fiabilidad necesita cada comunicación. Sus dos protagonistas encarnan las dos respuestas posibles: TCP, que lo garantiza todo a cambio de trabajo extra, y UDP, que no garantiza casi nada a cambio de velocidad. En esta lección entenderás puertos y sockets, el famoso three-way handshake, los números de secuencia y los ACK, el control de flujo, cuándo elegir cada protocolo y cómo espiar tus propias conexiones con netstat.

1. La misión del transporte: de aplicación a aplicación
2. Puertos: el número de despacho de cada aplicación
3. Sockets: la dirección completa de una conversación
4. TCP: la fiabilidad como servicio
5. El three-way handshake: abrir la conexión
6. Números de secuencia, ACK y retransmisiones
7. Control de flujo y cierre de conexión
8. UDP: la velocidad como servicio
9. TCP vs UDP: tabla comparativa y casos de Meridiano
10. netstat: primer vistazo a tus conexiones

Recapitulemos el reparto de trabajo de la pila con el símil postal que venimos usando: el enlace de datos reparte dentro del barrio, IP lleva el sobre entre ciudades hasta el edificio correcto... y el transporte es el conserje del edificio: recibe el correo y lo sube al despacho exacto al que va dirigido. Un edificio (una máquina, una IP) tiene muchos despachos (aplicaciones), y sin conserje el sobre se quedaría en el portal.

Los protocolos de transporte aportan dos servicios:

• Multiplexación por puertos: permitir que muchas aplicaciones de la misma máquina usen la red a la vez sin mezclarse, identificando cada una con un número de puerto.
• Control de la entrega (opcional): sobre el servicio "sin garantías" de IP, añadir —si la aplicación lo necesita— entrega garantizada, en orden y sin duplicados (TCP), o no añadir nada y ser ultraligero (UDP).

Sus unidades de datos ya las conoces por la encapsulación de 02-01: los segmentos (TCP) y datagramas (UDP) viajan dentro de los paquetes IP, que el campo Protocolo de la cabecera IP (6 = TCP, 17 = UDP) entrega al protocolo de transporte correcto.

Un puerto es un número de 16 bits (0 a 65535) que identifica un punto de comunicación dentro de una máquina. Cada segmento lleva en su cabecera un puerto de origen y un puerto de destino, igual que el paquete IP lleva IP de origen y destino.

Los puertos se organizan en tres rangos:

Los puertos bien conocidos son la "guía telefónica" implícita de Internet: un servidor web escucha en el 80 (HTTP) o el 443 (HTTPS), el DNS en el 53, el correo saliente en el 25... Los veremos protocolo a protocolo en la lección 02-05; de momento basta la idea: cliente que quiere un servicio, llama al puerto estándar de ese servicio. El cliente, por su parte, usa como origen un puerto efímero cualquiera que su sistema operativo le asigna al vuelo.

La combinación IP + protocolo de transporte + puerto se llama socket, y es la dirección completa de un extremo de comunicación: 192.168.10.10:443 identifica sin ambigüedad "la aplicación que escucha en el puerto 443 TCP de la máquina 192.168.10.10". Una conexión queda identificada por la pareja de sockets de sus dos extremos:

Si el término te suena de programar, no es casualidad: los sockets de los lenguajes de programación (la API con la que un programa abre conexiones) son exactamente la puerta de entrada a los protocolos de transporte que estamos estudiando. Cuando tu código hace connect() a una IP y puerto, está pidiendo al sistema operativo lo que viene en el siguiente apartado.

TCP (Transmission Control Protocol) es el protocolo de transporte orientado a conexión y fiable. Sobre el "mejor esfuerzo" de IP, garantiza a las aplicaciones cuatro cosas:

1. Entrega completa: lo que se pierde, se retransmite.
2. Orden: los datos llegan a la aplicación en el orden en que se enviaron, aunque los paquetes lleguen desordenados.
3. Sin duplicados: si algo llega dos veces (por una retransmisión de más), se descarta la copia.
4. Control de flujo: el emisor no satura al receptor.

La aplicación que usa TCP ve algo maravillosamente simple: un flujo continuo de bytes que entra por un extremo y sale intacto por el otro, como una tubería. Toda la complejidad (trocear en segmentos, numerar, confirmar, retransmitir, reordenar) queda escondida. Por eso TCP es la elección de todo lo que no tolera perder ni un byte: páginas web, transferencia de ficheros, correo... En Meridiano, cuando un consultor guarda una propuesta de 40 MB en el servidor, cada uno de esos millones de bytes llega exacto y en orden gracias a TCP.

El precio: TCP necesita establecer una conexión antes de enviar datos, confirmar todo lo que viaja y mantener estado en ambos extremos. Veamos esas piezas.

Antes del primer byte de datos, cliente y servidor ejecutan el apretón de manos en tres pasos (three-way handshake), el equivalente exacto al "¿Dígame? — Hola, soy Ana — Dime, Ana" de la llamada telefónica de la lección 02-01:

• SYN (synchronize): el cliente pide abrir conexión y anuncia su número de secuencia inicial.
• SYN-ACK: el servidor acepta, anuncia el suyo y confirma el del cliente.
• ACK (acknowledgement): el cliente confirma. Desde este momento ambos saben que el otro está ahí, escucha, y con qué números van a contar los bytes.

¿Por qué tres pasos y no dos? Porque ambos extremos necesitan confirmación de que su mensaje llegó: con el SYN-ACK el cliente sabe que el servidor le oyó; con el ACK final el servidor sabe que el cliente oyó su respuesta. Con dos pasos, el servidor abriría conexiones sin saber si el cliente sigue ahí.

Si el puerto de destino está cerrado (nadie escucha), el servidor responde con un segmento RST (reset): el "número equivocado, aquí no es" de TCP.

Establecida la conexión, TCP numera cada byte que envía (los números de secuencia acordados en el handshake) y el receptor va confirmando con ACK hasta qué byte ha recibido todo correctamente. Este mecanismo es el corazón de la fiabilidad:

Observa las piezas de temporización y semántica trabajando juntas:

• El receptor solo confirma datos contiguos: aunque recibió el bloque 3001-4000, sigue respondiendo ack=2001 porque le falta el anterior. Mientras tanto guarda el bloque adelantado para reordenarlo después.
• El emisor detecta la pérdida por dos vías: ACKs duplicados (señal rápida) o timeout (si no llega ningún ACK en un tiempo calculado, retransmite). Es la regla "si en X no hay confirmación, reenvío" que pusimos de ejemplo de temporización en 02-01.
• Resultado: sobre una red que pierde paquetes, la aplicación recibe el 100 % de los bytes, en orden. La fiabilidad no está en la red: se fabrica en los extremos.

Control de flujo: ¿y si el servidor recibe más rápido de lo que puede procesar (disco lento, carga alta)? En cada ACK, el receptor anuncia su ventana (window): cuántos bytes más está dispuesto a aceptar ahora mismo. El emisor nunca envía más allá de la ventana anunciada; si baja a 0, se detiene y espera. Es el "más despacio, que tomo nota" de la conversación telefónica: el receptor marca el ritmo. (TCP hace además control de congestión para no saturar la red intermedia, un tema fascinante que excede este curso introductorio.)

Cierre: cuando la aplicación termina, la conexión se cierra ordenadamente con un intercambio de segmentos FIN y sus ACK, en el que cada extremo se despide por separado ("he terminado de enviar" — "recibido"), porque puede que uno acabe antes que el otro. El equivalente al "venga, hasta luego" / "adiós": nadie cuelga sin avisar. Un cierre abrupto (error, proceso matado) se señala con RST.

UDP (User Datagram Protocol) es la otra respuesta: un protocolo de transporte sin conexión y sin garantías, tan simple que su cabecera cabe en una línea:

UDP toma los datos de la aplicación, les pone puertos y un checksum, y los entrega a IP. Nada más: sin handshake, sin números de secuencia, sin ACK, sin retransmisiones, sin control de flujo. Cada datagrama es independiente, como una postal: puede llegar, perderse, duplicarse o adelantar a otra, y nadie lo notificará.

¿Para qué sirve un protocolo así? Para los casos donde las garantías de TCP estorban:

• Tráfico en tiempo real (voz, videollamadas): si un fragmento de audio se pierde, retransmitirlo no tiene sentido — llegaría tarde, la conversación ya va por otro punto. Mejor un chasquido de 20 ms que una pausa de 2 segundos esperando retransmisiones. La videollamada diaria entre Valencia y Bilbao viaja en UDP precisamente por esto.
• Intercambios cortos de pregunta-respuesta (DNS es el ejemplo canónico, lo veremos en 02-05): para enviar una consulta de 50 bytes, montar y desmontar una conexión TCP (3 segmentos de apertura + cierre) costaría más que la consulta entera. Con UDP: una pregunta, una respuesta, listo. Si se pierde, la propia aplicación repregunta.
• Difusiones y descubrimiento (DHCP, streaming a muchos destinos): TCP es punto a punto por naturaleza; UDP puede enviar a difusión.

La regla mental: con UDP, la fiabilidad (si hace falta) es responsabilidad de la aplicación. Las aplicaciones modernas de tiempo real añaden sobre UDP justo las garantías que les convienen, ni una más.

Y aterrizada en el día a día de Grupo Meridiano:

Todo lo anterior se puede ver en tu propio equipo con netstat, disponible en Windows y Linux (en Linux moderno, su sucesor es ss, con salida casi idéntica). En el PC de Marta, con la web interna abierta y el fichero subiéndose:

Lectura línea a línea, con los conceptos de la lección:

• Cada fila es una conexión TCP identificada por su pareja de sockets (dirección local y remota, cada una IP:puerto).
• Los puertos locales 528xx son efímeros; los remotos (443, 445) son bien conocidos y delatan el servicio: HTTPS y ficheros contra el servidor de Valencia, HTTPS contra un servidor de Internet.
• Estado ESTABLISHED: el three-way handshake se completó y la conexión está viva. Otros estados que verás: LISTEN (un servidor esperando clientes — añade -a para verlos), SYN_SENT (handshake a medias: SYN enviado sin respuesta, típico de servidor caído o cortafuegos), TIME_WAIT (conexión recién cerrada en cortesía final, estado normal y pasajero).
• Las "conexiones" UDP no aparecen como tales (no hay conexión que listar); con netstat -an verás sus puertos abiertos marcados como UDP, sin estado.

netstat es la primera herramienta que convierte esta lección en algo tangible; la exprimiremos, junto al resto de utilidades, en el módulo 6.

• Confundir el puerto con algo físico. El puerto 443 no es un enchufe: es un número en la cabecera del segmento. Los puertos físicos del switch y los puertos de transporte solo comparten nombre, y mezclarlos delata a un principiante.
• Creer que UDP es "peor" o que "TCP siempre es mejor". Son herramientas para problemas distintos: usar TCP para una videollamada añade retrasos inaceptables; usar UDP para transferir un fichero obliga a reinventar TCP a mano. El profesional elige por requisitos, no por prestigio.
• Olvidar que la fiabilidad de TCP termina en el extremo TCP. TCP garantiza que los bytes llegan al socket receptor; si la aplicación luego los procesa mal o el disco falla, eso ya no es problema de la red. "La red va bien, tu aplicación no" es una frase que dirás muchas veces.
• Ignorar los estados de netstat al diagnosticar. Un SYN_SENT perpetuo dice "nadie responde al handshake" (servicio caído o cortafuegos); un ESTABLISHED dice "la conexión existe, busca el problema más arriba". Distinguirlos ahorra horas.
• Consejo: memoriza ya la pareja 80/443 (HTTP/HTTPS) y el 53 (DNS). En la próxima lección añadiremos el resto de puertos bien conocidos, y en tu carrera los usarás semanalmente.

Ejercicio 1. Marta tiene abiertas a la vez dos pestañas del navegador contra https://intranet.grupomeridiano.example (que resuelve a 192.168.10.10, puerto 443). Explica cómo es posible que las respuestas de cada pestaña no se mezclen, indicando qué campos de qué cabecera lo hacen posible, y escribe un ejemplo plausible de las dos parejas de sockets.

Ejercicio 2. Durante la subida de un fichero desde Bilbao al servidor de Valencia, la VPN pierde un paquete que transportaba el segmento con seq=5001 (bytes 5001-6000). El emisor ya había enviado también los bytes 6001-8000. Describe la secuencia de ACKs y retransmisiones hasta que todo queda confirmado, y explica qué recibió la aplicación del servidor mientras tanto.

Ejercicio 3. La videollamada Valencia–Bilbao se entrecorta y un compañero propone "cambiarla a TCP, que es el fiable". Explica en 3-4 frases por qué la propuesta empeoraría el problema, y qué dice esto sobre cómo elegir protocolo de transporte.

Solución 1: Ambas pestañas comparten IP local, IP remota y puerto remoto (443), pero el sistema operativo asigna a cada conexión un puerto efímero de origen distinto. Los campos puerto origen y puerto destino de la cabecera TCP, combinados con las IPs de la cabecera IP, identifican cada conexión de forma única, de modo que cada segmento de respuesta se entrega al socket (y a la pestaña) correcto. Ejemplo: pestaña 1 = (192.168.10.21:52840) ↔ (192.168.10.10:443); pestaña 2 = (192.168.10.21:52841) ↔ (192.168.10.10:443).

Solución 2:

1. El servidor recibe 6001-8000 pero le falta 5001-6000: guarda lo adelantado y responde ack=5001 (repetido) a cada segmento que le llega: ACKs duplicados.
2. El emisor, al ver ACKs duplicados (o al agotarse su temporizador), retransmite el segmento seq=5001.
3. Al recibirlo, el servidor ya tiene datos contiguos hasta el 8000 y responde ack=8001, confirmándolo todo de golpe.
4. Mientras tanto, la aplicación del servidor no recibió nada a partir del byte 5001: TCP retiene los bytes 6001-8000 hasta poder entregar el flujo en orden. La aplicación nunca ve huecos ni desorden; solo una breve pausa. Ese es el contrato de TCP.

Solución 3: El problema de una videollamada que se entrecorta es la latencia y las pérdidas puntuales, y TCP responde a las pérdidas con retransmisiones y esperas: cada paquete de audio perdido detendría el flujo hasta ser retransmitido (los datos posteriores quedan retenidos para respetar el orden), convirtiendo microcortes de milisegundos en congelaciones de segundos. El audio antiguo retransmitido además ya no sirve: la conversación va por otro punto. Por eso el tiempo real usa UDP y asume pérdidas pequeñas. Moraleja: el protocolo de transporte se elige según qué tolera la aplicación (¿pérdidas o retrasos?), no según cuál "garantiza más".

El transporte completa el viaje: ya no entregamos a máquinas, sino a aplicaciones. Hemos visto que los puertos multiplexan la red entre todos los programas de un equipo (bien conocidos para los servicios, efímeros para los clientes) y que un socket —IP + protocolo + puerto— es la dirección completa de un extremo. Sobre el mejor esfuerzo de IP, TCP fabrica fiabilidad de extremo a extremo: abre con el three-way handshake (SYN, SYN-ACK, ACK), numera cada byte, confirma con ACKs, retransmite lo perdido, reordena, ajusta el ritmo con la ventana de recepción y se despide con FIN; UDP, en cambio, ofrece datagramas desnudos e inmediatos, perfectos para el tiempo real y las consultas cortas — y la tabla de Meridiano (ficheros y web por TCP; videollamada, DNS y DHCP por UDP) resume el criterio de elección. Con netstat hemos visto por primera vez nuestras conexiones en vivo. Ya solo queda el último piso de la pila, el que motiva todos los demás: los protocolos con los que las aplicaciones hacen cosas útiles — pedir páginas web, traducir nombres como grupomeridiano.example a IPs, mover correo y ficheros, repartir direcciones automáticamente. Todos ellos, en la próxima lección: Protocolos de Aplicación.