TCP y UDP

Una vez que DNS te da una dirección IP, tu dispositivo puede enviar paquetes al destino correcto. Pero IP solo mueve paquetes independientes a través de las redes — no hace seguimiento de si llegan, de si llegan en el orden correcto o de si la red está congestionada.

Si divides una página web en muchos paquetes, algunos pueden llegar fuera de orden, algunos pueden retrasarse y algunos pueden perderse por completo. Sin una coordinación adicional, la aplicación receptora no tendría una forma fiable de reconstruir correctamente los datos originales.

Los protocolos de transporte resuelven cuatro problemas fundamentales: orden (reensamblar los datos correctamente), fiabilidad (detectar y reenviar los datos perdidos), multiplexación (permitir que varias aplicaciones compartan una sola dirección IP) y control de congestión (evitar que la red se sobrecargue).

En resumen, IP responde “¿A dónde debería ir este paquete?”
Los protocolos de transporte responden “¿Cómo debería comportarse esta conversación?”

Cuando los datos llegan a la dirección IP de un servidor, el sistema operativo todavía necesita decidir qué programa debe manejarlos. Una sola máquina puede ejecutar un servidor web, un servidor de base de datos, un servicio SSH y muchas otras aplicaciones al mismo tiempo.

Aquí es donde entran los números de puerto. Un puerto es un punto final lógico de comunicación usado por protocolos de transporte como TCP y UDP. Permite que el sistema demultiplexe el tráfico entrante y lo entregue al proceso de aplicación correcto.

Por ejemplo, el puerto 80 se usa normalmente para HTTP, el puerto 443 para HTTPS y el puerto 22 para SSH. Cuando accedes a un sitio web seguro, tu navegador se conecta a la dirección IP del servidor en el puerto 443, indicando que quiere comunicarse mediante HTTPS.

Sin puertos, una máquina solo podría ejecutar una aplicación de red a la vez. Los puertos permiten que ocurran miles de conversaciones simultáneas en una sola dirección IP.

Transmission Control Protocol (TCP) está diseñado para aplicaciones que requieren una entrega de datos completa y precisa. A diferencia del IP sin procesar, TCP trata la comunicación como un flujo continuo de bytes en lugar de paquetes independientes.

A cada segmento de datos se le asigna un sequence number. El receptor usa estos números para reordenar los datos correctamente antes de pasarlos a la aplicación. Si falta un segmento, TCP detecta el hueco y solicita su retransmisión.

TCP también incluye flow control, que evita que un emisor rápido abrume a un receptor más lento. Lo hace mediante un mecanismo de ventana deslizante que limita cuántos datos sin confirmar pueden estar en tránsito.

Por último, TCP implementa congestion control. Supervisa las condiciones de la red y ajusta la velocidad de transmisión para evitar saturar los routers. Esto protege la estabilidad general de la red y, al mismo tiempo, maximiza el rendimiento cuando las condiciones lo permiten.

TCP está orientado a la conexión, lo que significa que ambas partes deben ponerse de acuerdo para comunicarse antes de que comience la transferencia de datos. Este proceso garantiza que tanto el cliente como el servidor estén listos y puedan intercambiar datos.

Primero, el cliente envía un paquete SYN (synchronize). Este paquete propone un número de secuencia inicial y señala el deseo de abrir una conexión.

Segundo, el servidor responde con un SYN-ACK. Esto reconoce la solicitud del cliente y proporciona el propio número de secuencia inicial del servidor.

Finalmente, el cliente envía un ACK para confirmar la recepción del número de secuencia del servidor. En este punto, ambas partes tienen números de secuencia sincronizados y la conexión queda oficialmente establecida.

Solo después de que este protocolo de enlace se completa, TCP comienza a transferir datos de la aplicación.

TCP asigna un número de secuencia a cada byte en el flujo de datos. Esto permite que el receptor detecte segmentos faltantes o fuera de orden y reconstruya correctamente el mensaje original.

El receptor envía de vuelta números de ACK (acknowledgment) que indican el siguiente byte esperado. Si el emisor no recibe un ACK dentro de cierto tiempo, asume que el segmento se perdió.

Cuando se detecta una pérdida, TCP realiza una retransmisión, enviando de nuevo los datos faltantes. Este mecanismo garantiza la fiabilidad incluso cuando los paquetes se descartan debido a congestión o inestabilidad de la red.

TCP también usa una ventana deslizante para el control de flujo. En lugar de esperar un ACK después de cada paquete, el emisor puede transmitir varios segmentos dentro de un tamaño de ventana permitido. Esto mejora la eficiencia sin dejar de mantener garantías estrictas de entrega.

User Datagram Protocol (UDP) es sin conexión. A diferencia de TCP, no realiza un handshake antes de enviar datos. Un emisor simplemente transmite paquetes a la IP y el puerto de destino.

UDP no rastrea números de secuencia para la fiabilidad, no espera confirmaciones y no retransmite paquetes perdidos. Si un paquete se pierde, desaparece.

Como UDP elimina estos mecanismos de coordinación, tiene una sobrecarga y una latencia significativamente menores. Esto lo hace adecuado para casos de uso en los que la velocidad importa más que la entrega perfecta, como streaming en vivo, juegos en línea o consultas DNS.

En resumen, UDP prioriza el rendimiento y la simplicidad sobre la fiabilidad.

TCP es ideal para aplicaciones en las que los datos faltantes o corruptos romperían la funcionalidad. Las páginas web, las APIs, las descargas de archivos y el correo electrónico requieren datos completos y correctamente ordenados. Incluso un solo byte faltante podría corromper el resultado.

UDP es más adecuado para aplicaciones en las que se acepta una pérdida ocasional de paquetes. El video en tiempo real, las llamadas de voz, los juegos y las consultas pequeñas sin estado, como DNS, priorizan la velocidad sobre la perfección. Esperar retransmisiones introduciría un retraso notable.

La decisión clave es esta:
Si la precisión y la integridad son obligatorias, usa TCP.
Si la capacidad de respuesta y la baja latencia son críticas, UDP puede ser la mejor opción.

Si un puerto de destino está cerrado o bloqueado por un firewall, el servidor puede responder de inmediato con un mensaje de connection refused. Esto significa que la máquina es accesible, pero no hay ninguna aplicación escuchando en ese puerto.

Si un cliente envía un SYN pero nunca recibe un SYN-ACK, el intento de conexión eventualmente timeout. Esto a menudo indica que el servidor está caído, no es accesible o está filtrado por un firewall en la ruta.

Cuando la pérdida de paquetes es alta, TCP detecta los acknowledgments faltantes y realiza retransmissions. Aunque se mantiene la fiabilidad, el rendimiento se degrada significativamente.

Bajo una congestión intensa, TCP reduce su tasa de envío mediante algoritmos de control de congestión. La conexión sigue activa, pero el throughput disminuye y la latencia aumenta.