TCP y UDP: para qué sirve la capa de transporte
IP permite llevar paquetes entre direcciones de red, pero una máquina ejecuta muchas aplicaciones a la vez. La capa de transporte añade la lógica necesaria para que los datos lleguen al proceso correcto y, según el protocolo, aporta fiabilidad, control de flujo o simplemente un servicio de datagramas con poca sobrecarga. En Internet los dos protocolos clásicos son TCP y UDP.
TCP está especificado actualmente por RFC 9293 como estándar de Internet. UDP mantiene el modelo de datagrama definido por RFC 768. Ambos se apoyan en IP y utilizan números de puerto para multiplexar aplicaciones, pero ofrecen contratos muy distintos. Entender esa diferencia evita el error de pensar que TCP es “mejor” y UDP “peor”: cada uno resuelve necesidades diferentes.
Puertos, sockets y conversaciones entre aplicaciones
Un puerto identifica un punto lógico de comunicación dentro de un host. Una conversación puede describirse mediante direcciones IP, puertos y protocolo de transporte. En TCP suele hablarse de una 5-tupla: IP origen, puerto origen, IP destino, puerto destino y protocolo. Esa combinación permite que miles de conexiones compartan una misma dirección IP sin confundirse.
Los servidores suelen escuchar en puertos conocidos o configurados, mientras que el cliente utiliza normalmente un puerto efímero. DNS suele utilizar 53, HTTPS 443 y SSH 22, pero el número por sí solo no garantiza qué aplicación hay detrás: una política de firewall o un análisis de tráfico debe considerar también contexto y estado. Repasa la visión general en protocolos de red y la resolución de nombres en DNS.
Cómo establece TCP una conexión
TCP es orientado a conexión. Antes de intercambiar el flujo de datos, los extremos sincronizan estado mediante el conocido establecimiento de tres pasos: SYN, SYN-ACK y ACK. Ese intercambio acuerda números de secuencia iniciales y confirma que ambos lados pueden comunicarse. Cerrar una conexión también requiere intercambios explícitos, aunque resets y cierres abruptos pueden terminarla de otra forma.
El handshake no “reserva un circuito” en la red: los paquetes siguen viajando sobre IP y cada router decide su forwarding. La conexión es estado mantenido por los extremos y, a menudo, observado por dispositivos intermedios como NAT o firewalls stateful. Si el SYN sale pero no regresa SYN-ACK, hay que investigar ruta, ACL, firewall, puerto de escucha y retorno.
Secuencia, ACK, retransmisión y entrega ordenada
TCP presenta a la aplicación un flujo fiable y ordenado de bytes. Los números de secuencia permiten identificar qué datos se han enviado; los ACK confirman recepción y los temporizadores permiten retransmitir segmentos que se consideran perdidos. El receptor puede reordenar datos que llegaron fuera de orden antes de entregarlos a la aplicación.
Fiabilidad no significa que la red no pierda paquetes. Significa que TCP detecta determinadas pérdidas y compensa mediante retransmisiones. Esa recuperación tiene coste: si hay pérdida o latencia alta, una aplicación puede esperar mientras el protocolo reconstruye el flujo. Por eso resulta útil separar un problema de conectividad IP de un problema de rendimiento TCP.
Control de flujo y control de congestión
TCP también limita cuánto puede enviar un extremo sin recibir confirmación. El control de flujo protege al receptor mediante una ventana anunciada; el control de congestión intenta no inyectar tráfico a una velocidad que perjudique a la red. Son mecanismos diferentes aunque ambos modifiquen el ritmo efectivo de transmisión.
En troubleshooting, una ventana de recepción pequeña no significa lo mismo que una red congestionada. Capturas con Wireshark permiten observar ACK, retransmisiones, ventanas y tiempos entre paquetes. Conviene correlacionar la captura con métricas de interfaz, latencia y pérdida antes de concluir que el problema está en el protocolo.
UDP: datagramas con un contrato mínimo
UDP ofrece un servicio mucho más simple: cada datagrama conserva sus límites y se entrega a un puerto de destino, pero el protocolo no establece una conexión, no ordena mensajes y no retransmite por sí mismo. Su cabecera es pequeña y el emisor puede empezar a enviar sin un handshake TCP previo.
Eso no implica que una aplicación sobre UDP sea necesariamente no fiable. La propia aplicación puede añadir confirmaciones, temporizadores, recuperación o cifrado. QUIC, por ejemplo, se transporta sobre UDP y construye encima funciones que normalmente asociamos a transportes sofisticados. DNS usa tradicionalmente UDP para muchas consultas y puede usar TCP cuando el caso lo requiere.
MSS, MTU y fragmentación: no son lo mismo
La MTU pertenece al enlace y limita el tamaño de un paquete que puede transportarse sin fragmentación en ese tramo. En TCP, la MSS describe cuánto payload TCP acepta un extremo en un segmento. MSS no incluye las cabeceras IP y TCP y suele derivarse de la MTU esperada.
Problemas de Path MTU Discovery pueden producir conexiones que parecen abrir correctamente pero fallan al transferir determinados tamaños de datos. ICMP participa en esa señalización; por eso bloquear indiscriminadamente mensajes de control puede romper tráfico legítimo. La guía de ICMP desarrolla este punto.
Cuándo elegir TCP o UDP
TCP encaja cuando la aplicación quiere un flujo ordenado y fiable y prefiere delegar retransmisión y control de flujo al transporte. UDP resulta útil cuando la aplicación necesita conservar datagramas, reducir estado de transporte o implementar su propia lógica temporal. Voz, vídeo en tiempo real, DNS y protocolos modernos pueden preferir UDP porque una retransmisión tardía puede ser menos útil que continuar con datos nuevos.
- No elijas por “velocidad” de forma aislada: mide latencia, pérdida y patrón de tráfico.
- No supongas que UDP atraviesa siempre mejor una red: NAT y firewalls también mantienen políticas y estado para UDP.
- No identifiques una aplicación únicamente por el puerto: los puertos pueden cambiar y múltiples protocolos comparten infraestructuras modernas.
TCP/UDP en NAT, ACL y firewalls
ACL y firewalls suelen filtrar por protocolo, direcciones y puertos. Un firewall stateful puede distinguir una nueva conexión TCP de paquetes que pertenecen a una sesión ya permitida. En UDP, donde no existe handshake de transporte, el dispositivo suele mantener estado temporal basándose en los datagramas observados.
NAT/PAT utiliza los puertos para multiplexar muchas conversaciones sobre una dirección pública. Por eso los conceptos de transporte están directamente relacionados con NAT/PAT, ACL y la nueva guía de firewalls.
Troubleshooting de TCP y UDP
Empieza comprobando si la red IP funciona y si existe ruta de retorno. Después confirma que el proceso escucha en el puerto esperado y que ningún filtro bloquea el tráfico. En TCP, diferencia “timeout” de “connection refused”: el segundo suele indicar que el host respondió pero no hay un servicio aceptando esa conexión. En UDP, la ausencia de respuesta es más ambigua porque el protocolo no obliga a contestar.
Herramientas como ss, netstat, nc, curl, dig y una captura de paquetes permiten aislar dónde se rompe la conversación. La guía de comandos de red organiza esas pruebas por hipótesis para evitar diagnosticar únicamente por intuición.