TCP versus UDP para desarrolladores — Cuándo realmente importa el protocolo

Estás desarrollando un juego multijugador. Los jugadores están quejándose de retrasos. Has optimizado tu código de servidor, reducido las consultas a la base de datos y tu latencia p99 parece correcta. El problema es más sencillo: estás usando TCP. Eso es todo. Eso es el retraso.

TCP y UDP no son simplemente dos cajas en una lista de protocolos — representan apuestas fundamentales sobre lo que hará la red. La elección equivocada no solo te cuesta rendimiento. Cambia la naturaleza de los fallos cuando ocurren.

La apuesta que hace TCP

TCP te promete un flujo de bytes confiable y ordenado. Si un paquete se pierde, TCP lo retransmite. Si los paquetes llegan fuera de orden, TCP los reordena. Tu aplicación ve datos limpios y secuenciales, cada vez.

Esa garantía te cuesta tres cosas:

• Latencia de handshake — TCP requiere un handshake de tres vías antes de que un solo byte de datos de la aplicación se mueva. En una red con un tiempo de retorno de 50ms, se pierden 150ms antes de que incluso comience tu primera solicitud.
• Bloqueo de cabeza de línea — Este es el que mata los juegos. Si el paquete #5 se pierde, TCP mantiene los paquetes #6, #7 y #8 en un buffer esperando que #5 se retransmita y llegue. El flujo se bloquea. La actualización de posición del jugador de hace 100ms está sentada en un buffer mientras la red se arregla.
• Sobrecarga de control de congestión — El algoritmo de ventana de congestión de TCP (CUBIC, BBR, etc.) reduce la tasa de envío cuando detecta una pérdida. En una red con pérdida, esto significa que TCP reduce el tráfico justo en el momento en que la red se ve afectada — momento en que los usuarios lo sienten más.

Lo que realmente ofrece UDP

UDP envía un datagrama y no se fija. No hay handshake, no hay confirmación, no hay retransmisión. Si un paquete se pierde, desaparece. El receptor recibe lo que llega, en el orden en que llega.

Eso no es una limitación — es el punto. Cuando necesitas baja latencia más que garantías de entrega, UDP te permite hacer esa elección explícitamente. La lógica de fiabilidad se mueve a la capa de aplicación, donde puedes tomar decisiones más inteligentes sobre qué realmente necesita retransmitirse.

En un juego, una actualización de posición del jugador de hace 50ms es inútil — quieres la actual. Con TCP, tendrías que almacenar y esperar. Con UDP, envías el estado más reciente y omites lo obsoleto. La experiencia es más suave incluso con más pérdida de paquetes.

TCP vs UDP: la comparación que realmente importa

Propiedad	TCP	UDP
Configuración de conexión	Handshake de tres vías (agrega 1.5× RTT antes del primer byte)	Ninguno — se inicia inmediatamente
Garantía de entrega	Sí — se retransmite en caso de pérdida	No — se envía y se olvida
Orden de paquetes	Controlada por la pila	Tu problema
Bloqueo de cabeza de línea	Sí — un paquete perdido bloquea el flujo	No — cada datagrama es independiente
Control de congestión	Incorporado (CUBIC, BBR, etc.)	Ninguno — implementa tu propio o omite
Sobrecarga típica de latencia	150–300ms en conexiones frías	Sub-milisegundo
Casos de uso	HTTP/1.1, HTTP/2, bases de datos, transferencia de archivos, correo electrónico	DNS, juegos, transmisión en vivo, HTTP/3 (QUIC)

Dónde realmente pertenece cada protocolo

DNS corre sobre UDP — y hay una lección en eso

Cada consulta DNS que realiza tu aplicación se realiza por UDP por defecto. La solicitud cabe en un solo paquete, la respuesta cabe en un solo paquete, y obtienes tu respuesta en una sola vuelta de red. Sin sobrecarga de handshake, sin estado que mantener en el servidor.

Si la respuesta es demasiado grande (registros DNSSEC, muchos registros A), DNS cae a TCP. Pero el caso común — una búsqueda de un nombre de host — es pura UDP porque la apuesta es obvia: el handshake de tres vías tardaría más que la consulta en sí.

Puedes ver este comportamiento en acción con el IO Tools DNS Lookup tool — introduce un dominio y observa cuán rápido se resuelven los tipos de registro. Esa velocidad es UDP eliminando una vuelta completa de sobrecarga de handshake.

Juegos: UDP es la única respuesta real

Cada biblioteca principal de red de juegos — Valve’s GameNetworkingSockets, Epic’s EOS transport, Unity’s UTP — se construye sobre UDP. La razón es el bloqueo de cabeza de línea.

En un juego competitivo de disparos rápidos, estás enviando actualizaciones de posición cada 64 ticks — cada 15ms. Si un paquete se pierde y TCP mantiene los siguientes cinco mientras espera la retransmisión, has introducido 75ms de estallido en el momento exacto en que no debería ocurrir. Con UDP, envías la próxima actualización inmediatamente. El cliente interpola sobre la brecha. La experiencia es suave.

La mayoría del código de red de juegos construido sobre UDP implementa su propia fiabilidad selectiva — números de secuencia, colas de prioridad, ACK selectivos — pero solo para los datos que realmente lo necesitan: mensajes de chat, recogidas de objetos, estado de partida. Los datos de posición son inseguros por diseño. Una lectura obsoleta es peor que ninguna lectura.

Transmisión de video: depende del caso de uso

La transmisión en vivo (Twitch, transmisiones deportivas) utiliza protocolos basados en UDP — RTP, WebRTC, SRT — porque unas pocas frames perdidas son aceptables pero la latencia no. No puedes bufferizar 30 segundos de una partida en vivo para garantizar una entrega suave.

VOD (Netflix, YouTube) realmente utiliza TCP, porque el buffer oculta el costo. Algunos segundos de pre-buffer significan que la sobrecarga de retransmisión de TCP es invisible — solo ves una reproducción suave. El costo de latencia no importa cuando estás viendo algo que ocurrió ayer.

HTTP/3 corre sobre UDP — y cambia el rendimiento de la web

HTTP/3 corre sobre QUIC, que corre sobre UDP. Google construyó QUIC específicamente para solucionar el problema del bloqueo de cabeza de línea de TCP en el tráfico web. Con HTTP/2 sobre TCP, un paquete perdido bloquea todos los flujos multiplexados que comparten esa conexión. QUIC implementa multiplexado de flujos en la capa de transporte con reconocimiento independiente — un paquete perdido bloquea un flujo, no todos los flujos.

QUIC también integra TLS en el handshake, reduciendo la configuración inicial fría a una sola vuelta de red (0-RTT en recuperación de sesión). En redes con pérdida — conexiones móviles, WiFi congestionado — esto es una mejora significativa. Hasta 2024, aproximadamente 30% de sitios web soportan HTTP/3, y todos los navegadores principales lo habilitan por defecto. Si estás desplegando detrás de Cloudflare o un CDN moderno, probablemente ya estés sirviendo HTTP/3 sin haberlo configurado explícitamente.

El árbol de decisión práctica

Cuando eliges un transporte para un nuevo protocolo o servicio, la pregunta no es «TCP o UDP?» — es «qué fallos puedo tolerar?»

• Cada byte debe llegar, en orden, o la operación falla → TCP. Subidas de archivos, conexiones a bases de datos, llamadas a APIs, correo electrónico. Datos perdidos significan datos corruptos o un error de parseo.
• La latencia importa más que la entrega garantizada → UDP. Juegos, transmisión en vivo, llamadas por voz, telemetría de sensores. Una lectura obsoleta es peor que ninguna lectura.
• Necesitas ambos, por mensaje → Construye sobre UDP con fiabilidad selectiva. QUIC lo hace. El canal de datos de SCTP de WebRTC lo hace. Bibliotecas como ENet y GameNetworkingSockets lo hacen también — aunque implementarlo por ti es un trabajo no trivial que es fácil de hacer mal de forma sutil.

Un error que vale la pena señalar: asumir que «tráfico interno» significa que puedes usar UDP de forma descuidada. La pérdida de paquetes dentro de un datacenter es rara pero no nula — fallos de hardware, congestión de red bajo carga máxima, switches mal configurados. Si tu aplicación corrompe silenciosamente los datos en caso de pérdida, un red interior no te salvará.

Resumen

TCP es la opción correcta por defecto para la mayoría del código de aplicación. Si estás haciendo llamadas a APIs, hablando con una base de datos o transfiriendo archivos, las garantías de TCP son exactamente lo que necesitas y el costo de sobrecarga es invisible a escalas humanas.

UDP es la opción correcta cuando la latencia es una restricción rígida y tu aplicación puede gestionar su relación con la fiabilidad. Eso es un conjunto específico de problemas — juegos en tiempo real, medios en vivo, protocolos personalizados — no una optimización general de rendimiento que se busca cuando TCP parece lento.

El error real no es usar TCP cuando UDP sería más rápido. Es no saber cuál estás eligiendo, o por qué, y sorprenderse cuando el modo de fallo llega.

También te puede interesar