UDP (User Datagram Protocol) es un protocolo de transporte sin conexión que envía datos sin establecer conexiones ni garantizar la entrega. UDP prioriza la velocidad y la eficiencia sobre la confiabilidad, haciéndolo ideal para aplicaciones en tiempo real.
Resumen rápido — UDP envía datagramas sin handshake, sin confirmación de entrega, y sin control de flujo o congestión, con solo 8 bytes de overhead de header frente a los 20+ de TCP. Esa simplicidad lo hace ideal para DNS, VoIP, gaming en línea, y streaming de video, donde la baja latencia importa más que garantizar cada paquete. Cuando una aplicación necesita algo de confiabilidad sin pagar el costo completo de TCP, protocolos como QUIC (base de HTTP/3) agregan control de congestión y seguridad encima de UDP.
Última actualización: 2026-08-08
Cómo funciona UDP
UDP opera en la capa de transporte (Capa 4 de OSI) y brinda un overhead de protocolo mínimo para la transmisión de datos.
Características de UDP:
Sin conexión:
- Sin handshake antes de la transmisión de datos
- No se mantiene estado de conexión
- Envía datagramas inmediatamente sin configuración
No confiable:
- Sin confirmación de recepción
- Sin retransmisión de paquetes perdidos
- Sin garantía de entrega
Desordenado:
- Los paquetes pueden llegar en cualquier orden
- Sin numeración de secuencia
- La aplicación maneja el orden si es necesario
No regulado:
- Sin control de flujo
- Sin control de congestión
- El emisor determina la tasa de transmisión
Estructura del datagrama UDP:
- Puerto de origen: aplicación emisora (16 bits, opcional)
- Puerto de destino: aplicación receptora (16 bits)
- Length: tamaño total del datagrama (16 bits)
- Checksum: detección de errores (16 bits, opcional para IPv4)
- Data: payload de la aplicación (variable, hasta 65,507 bytes)
Overhead total: 8 bytes (vs. los 20+ bytes de TCP)
Cuándo usar UDP
Usa UDP cuando necesites:
- Overhead de latencia mínimo (sin handshake, sin ACK)
- Transmisión de datos en tiempo real (streaming, gaming, VoIP)
- Broadcasting o multicasting (transmisión de uno a muchos)
- Request-response simple con payload bajo
- Aplicaciones tolerantes a la pérdida de paquetes (1-5% aceptable)
- Alto throughput sin el overhead del control de congestión
- Confiabilidad personalizada implementada en la capa de aplicación
No uses UDP cuando necesites:
- Entrega garantizada de cada paquete
- Transmisión de datos ordenada
- Control de flujo para prevenir abrumar a los receptores
- Control de congestión para evitar el colapso de la red
- Transferencia de archivos sin corrupción
- Integridad de transacción (financiera, base de datos)
- Conexiones confiables de larga duración
Señales de que necesitas UDP
- Aplicación en tiempo real donde la latencia es más crítica que la confiabilidad
- Media en streaming (video, audio) donde los huecos ocasionales son aceptables
- Gaming en línea que requiere actualizaciones rápidas, puede interpolar datos faltantes
- Consultas DNS que necesitan respuestas rápidas con payloads pequeños
- VoIP donde huecos leves de audio son preferibles al retraso
- Broadcasting a múltiples receptores simultáneamente
- La aplicación implementa mecanismos de confiabilidad personalizados
Comparación UDP vs. TCP
| Característica | UDP | TCP |
|---|---|---|
| Conexión | Sin conexión | Orientado a conexión |
| Confiabilidad | No confiable | Confiable (ACK, retransmisión) |
| Orden | Desordenado | Ordenado (números de secuencia) |
| Control de flujo | Ninguno | Sliding window |
| Control de congestión | Ninguno | Slow start, evasión de congestión |
| Overhead | Header de 8 bytes | Header de 20+ bytes |
| Velocidad | Rápido (sin overhead) | Más lento (overhead de características) |
| Handshake | Ninguno | Handshake de tres vías |
| Caso de uso | Tiempo real, streaming | Entrega confiable, archivos |
Comparación de throughput:
- UDP: limitado solo por la capacidad de la red y la aplicación
- TCP: limitado por el control de congestión y de flujo
- Ejemplo: enlace de 100 Mbps, UDP puede usar casi 100 Mbps; TCP varía entre 10-95 Mbps con base en la congestión
Comparación de latencia:
- UDP: transmisión inmediata (0 RTT)
- TCP: 1.5 RTT para el establecimiento de conexión + tiempo de handshake
- Ejemplo: red con 50ms de RTT, UDP comienza inmediatamente; TCP requiere 75ms antes de los primeros datos
Casos de uso de UDP
DNS (Domain Name System)
Cómo funciona:
- El cliente envía una consulta UDP al servidor DNS (puerto 53)
- El servidor responde con un solo paquete UDP
- Payload típico: menos de 512 bytes (tradicional) o menos de 4096 bytes (EDNS)
Por qué UDP:
- Query-response rápido
- El payload pequeño cabe en un solo paquete
- Baja latencia crítica para la navegación web
- DNS sobre TCP como respaldo para respuestas grandes
Compensaciones:
- La pérdida de paquetes causa timeout y reintento
- La aplicación implementa lógica de reintento
- El bit de truncation señala la necesidad de TCP
VoIP (Voice over IP)
Cómo funciona:
- El audio se codifica en paquetes pequeños (20-30ms)
- Los paquetes se transmiten continuamente vía UDP
- El receptor hace buffer, reordena, reproduce el audio
- Los paquetes faltantes causan huecos breves de audio
Por qué UDP:
- Tiempo real: la latencia de 150ms+ es notable
- La pérdida de paquetes es aceptable (interpolación)
- La latencia es peor que los huecos
- Los paquetes retransmitidos llegan demasiado tarde
Métricas de calidad:
- Pérdida de paquetes aceptable: 1-3%
- Objetivo de latencia: menos de 150ms de ida
- Jitter: variación en los tiempos de llegada
Gaming en línea
Cómo funciona:
- Las actualizaciones de estado del juego se envían continuamente
- Predicción e interpolación del cliente
- Estado autoritativo del servidor
- Las actualizaciones faltantes se interpolan
Por qué UDP:
- Movimiento del jugador en tiempo real
- Respuesta rápida crítica para el gameplay
- Puede interpolar posiciones faltantes
- El estado retransmitido estaría obsoleto
Implementación:
- La aplicación implementa confiabilidad para eventos críticos
- No confiable para actualizaciones de posición frecuentes
- Números de secuencia para el orden (capa de aplicación)
- Confirmaciones solo para eventos importantes
Streaming de video
Cómo funciona:
- El video se codifica en segmentos
- Se transmite vía paquetes UDP
- El cliente hace buffer antes de la reproducción
- La corrección de errores hacia adelante agrega redundancia
Por qué UDP:
- Se necesita alto throughput
- Los frames tardíos son peores que los frames faltantes
- Puede solicitar I-frames faltantes
- La retransmisión causaría buffering
Técnicas:
- Forward Error Correction (FEC): datos redundantes
- Bitrate adaptativo: ajusta la calidad al ancho de banda
- Gestión de buffer: equilibra la latencia vs. los huecos
IoT y datos de sensores
Cómo funciona:
- Los sensores transmiten lecturas vía UDP
- Agregación en el gateway o la nube
- Las bases de datos de series de tiempo almacenan los datos
- Las lecturas faltantes se interpolan
Por qué UDP:
- Bajo consumo de energía (sin overhead de conexión)
- Implementación simple en dispositivos con restricciones
- Alto volumen de paquetes pequeños
- La pérdida ocasional es aceptable
Consideraciones:
- Las alertas críticas pueden usar TCP o UDP confiable
- La sincronización de tiempo necesita confiabilidad
- Las actualizaciones de configuración necesitan entrega garantizada
Extensiones de confiabilidad de UDP
Confiabilidad a nivel de aplicación
Confirmaciones personalizadas:
- La aplicación define los paquetes importantes
- El receptor envía ACK por los paquetes recibidos
- El emisor retransmite los paquetes no confirmados
- La confiabilidad selectiva reduce el overhead
Números de secuencia:
- Agrega números de secuencia a los payloads UDP
- El receptor detecta paquetes faltantes
- Solicita retransmisión para los huecos
- Reordena los paquetes recibidos
Forward Error Correction (FEC):
- Agrega datos redundantes a las transmisiones
- Se recupera de la pérdida de paquetes sin retransmisión
- Intercambia ancho de banda por confiabilidad
- Ejemplo: envía 6 paquetes por cada 4 paquetes de datos
Protocolo QUIC
Qué es: protocolo basado en UDP que brinda confiabilidad estilo TCP con latencia reducida.
Características clave:
- Construido sobre UDP (no se necesitan cambios de kernel)
- Establecimiento de conexión: 0-RTT después de la conexión inicial
- Streams multiplexados (sin head-of-line blocking)
- TLS 1.3 integrado
- Mejor desempeño en redes móviles
Comparación:
- TCP: 1.5 RTT para la conexión + handshake TLS
- QUIC: 0-1 RTT para la conexión con TLS integrado
- Overhead: mayor que TCP, menor que TCP+TLS
HTTP/3: usa QUIC sobre UDP para el transporte web
RTP (Real-time Transport Protocol)
Qué es: protocolo para la entrega de audio y video en tiempo real sobre UDP.
Características:
- Números de secuencia para el orden
- Timestamps para la sincronización de reproducción
- Identificación de tipo de payload
- SSRC (synchronization source) para la identificación del stream
RTCP (RTP Control Protocol):
- Retroalimentación de calidad (pérdida de paquetes, jitter)
- Gestión de sesión
- Identificación de participantes
DTLS (Datagram TLS)
Qué es: encriptación TLS para datagramas UDP.
Características:
- Brinda seguridad para UDP
- Similar a TLS para TCP
- Maneja la pérdida de paquetes y el reordenamiento
- Se usa en WebRTC para comunicación segura
Métricas y medición
Métricas de desempeño:
Pérdida de paquetes:
- Porcentaje de paquetes perdidos en tránsito
- VoIP aceptable: menos de 3%
- Streaming de video aceptable: menos de 1% con FEC
- Gaming aceptable: menos de 5% con interpolación
Latencia:
- Retraso de ida desde el emisor al receptor
- Objetivo VoIP: menos de 150ms
- Objetivo gaming: menos de 50ms para la capacidad de respuesta
- Objetivo DNS: menos de 100ms
Jitter:
- Variación en los tiempos de llegada de paquetes
- Afecta a las aplicaciones en tiempo real
- Aceptable VoIP: menos de 30ms
- Aceptable gaming: menos de 50ms
Throughput:
- Bits por segundo entregados
- Sin control de congestión significa que el emisor controla la tasa
- Monitorea la capacidad de red para evitar abrumar
Estadísticas de tráfico UDP:
- DNS: 5-10% del tráfico de internet
- VoIP/Gaming: porcentaje creciente
- Streaming de video: cambiado a TCP (basado en HTTP) para confiabilidad
- UDP general: ~15-20% del tráfico de internet
Según datos de la industria, el tráfico UDP representa aproximadamente el 17% del tráfico global de internet, con DNS, gaming, y comunicaciones en tiempo real como casos de uso principales.
Errores comunes y correcciones
Error: no implementar ninguna confiabilidad para datos importantes Corrección: usa confiabilidad selectiva para paquetes críticos. Implementa ACK/retry a nivel de aplicación. Usa TCP para el canal de control, UDP para los datos.
Error: enviar más rápido que la capacidad de la red Corrección: implementa rate limiting. Monitorea la pérdida de paquetes. Reduce la tasa cuando se detecta pérdida. Usa protocolos conscientes de la congestión (QUIC, RTP con RTCP).
Error: no manejar el orden de los paquetes Corrección: agrega números de secuencia. Haz buffer y reordena en el receptor. Define una ventana aceptable de desorden.
Error: ignorar las limitaciones de MTU Corrección: limita el payload UDP a 1472 bytes para Ethernet (MTU de 1500 - 20 IP - 8 UDP). Fragmenta los payloads más grandes o usa path MTU discovery.
Error: no usar checksums Corrección: usa siempre el checksum de UDP. Detecta paquetes corruptos. La aplicación puede agregar verificaciones de integridad adicionales.
Error: asumir que UDP siempre es más rápido que TCP Corrección: UDP es más rápido para tiempo real, pero TCP puede ser más rápido para transferencias masivas debido a que el control de congestión previene el colapso de la red. Mide el desempeño real.
Error: no considerar problemas de firewall/NAT Corrección: UDP puede estar bloqueado o requerir reenvío de puertos. Implementa hole punching para NAT traversal. Usa STUN/TURN para VoIP/WebRTC.
Preguntas frecuentes
¿Por qué usar UDP si no es confiable? La falta de confiabilidad es aceptable para aplicaciones en tiempo real donde la velocidad importa más que la completitud. La latencia de los mecanismos de confiabilidad de TCP (handshake, ACK, retransmisión) hace que TCP sea inadecuado para datos sensibles al tiempo.
¿Cómo manejan las aplicaciones los paquetes UDP perdidos? Las aplicaciones ignoran los paquetes perdidos (huecos de audio), interpolan los datos faltantes (frames de video), solicitan retransmisión para datos críticos (confiabilidad personalizada), o usan corrección de errores hacia adelante para recuperarse sin retransmisión.
¿Cuál es el tamaño máximo de paquete UDP? Máximo teórico: 65,535 bytes (limitación de IP). Máximo práctico: Path MTU (típicamente 1500 bytes en Ethernet). Recomendado: 1472 bytes para evitar la fragmentación (1500 - 20 header IP - 8 header UDP).
¿UDP puede ser seguro? Sí. Usa DTLS (Datagram TLS) para encriptación. Implementa seguridad a nivel de aplicación. Usa HTTPS sobre QUIC (HTTP/3). Las VPN tunelizan UDP de forma segura.
¿UDP tiene control de congestión? No. UDP no tiene control de congestión integrado. El emisor debe implementar rate limiting. El UDP no regulado puede causar el colapso de la red. QUIC agrega control de congestión a UDP.
¿Cómo maneja UDP el NAT traversal? Los NAT mapean IP:puerto interno a IP:puerto externo. UDP hole punching: ambos lados envían paquetes para establecer mapeos NAT. Los servidores STUN ayudan a descubrir la IP:puerto pública. Los servidores TURN retransmiten el tráfico si falla la conexión directa.
¿Qué es el UDP hole punching? Técnica para establecer una conexión UDP directa entre clientes detrás de NAT. Ambos clientes se envían paquetes a las direcciones públicas del otro simultáneamente. Los NAT crean mapeos, permitiendo la comunicación bidireccional.
¿UDP puede soportar multicast? Sí. UDP soporta comunicación de uno-a-muchos vía direcciones multicast (224.0.0.0 a 239.255.255.255). TCP es solo unicast. El multicast es eficiente para transmitir a múltiples receptores.
¿Qué porcentaje del tráfico de internet es UDP? Aproximadamente el 15-20% del tráfico de internet es UDP. DNS, VoIP, gaming, y HTTP/3 basado en QUIC son los usos principales. Está creciendo con las aplicaciones en tiempo real.
¿Cómo mejora QUIC a UDP? QUIC agrega confiabilidad, control de congestión, y seguridad (TLS 1.3) a UDP. Brinda garantías estilo TCP con menor latencia. Elimina el head-of-line blocking mediante streams multiplexados. Establecimiento de conexión de 0-RTT.
Cómo aplica esto en la práctica
UDP habilita aplicaciones en tiempo real y de alto desempeño:
Comunicaciones en tiempo real:
- VoIP prioriza la baja latencia sobre la completitud
- La videoconferencia usa UDP con códecs adaptativos
- El screen sharing interpola los frames faltantes
- WebRTC usa UDP (vía RTP) para peer-to-peer
Gaming en línea:
- Los movimientos del jugador se envían continuamente vía UDP
- Estado de juego autoritativo del servidor
- La predicción del cliente enmascara la latencia de red
- Los eventos importantes (kills, recolección de objetos) usan confiabilidad
Infraestructura DNS:
- La resolución rápida de consultas es crítica para el desempeño web
- Respaldo a TCP para respuestas grandes
- DNS sobre HTTPS (DoH) usa TCP/TLS para privacidad
- DNS sobre QUIC (DoQ) usa UDP para velocidad y privacidad
Media en streaming:
- El streaming en vivo usa UDP para la entrega en tiempo real
- El bitrate adaptativo se ajusta a la pérdida de paquetes
- La corrección de errores hacia adelante agrega resiliencia
- El video-on-demand típicamente usa TCP (basado en HTTP)
Aplicaciones IoT:
- Los sensores transmiten lecturas pequeñas frecuentes
- UDP reduce el consumo de energía
- Los gateways agregan y agrupan datos
- Las alertas críticas usan TCP o UDP confiable
UDP en Azion
Azion optimiza el desempeño de UDP para aplicaciones en tiempo real:
- Balanceo de carga UDP a través de Edge Application
- Red anycast global reduce la latencia de UDP
- Edge Functions para el procesamiento de paquetes UDP
- Métricas en tiempo real monitorean el tráfico UDP
- Soporte de WebSocket sobre TCP con respaldo
- Servicios DNS usando manejo optimizado de UDP
La red de edge de Azion brinda entrega UDP de baja latencia a través de más de 100 ubicaciones globales.
Recursos relacionados
Fuentes:
- RFC 768. “User Datagram Protocol.” https://tools.ietf.org/html/rfc768
- RFC 3550. “RTP: A Transport Protocol for Real-Time Applications.” https://tools.ietf.org/html/rfc3550
- RFC 6347. “Datagram Transport Layer Security.” https://tools.ietf.org/html/rfc6347
- RFC 9000. “QUIC: A UDP-Based Multiplexed and Secure Transport.” https://tools.ietf.org/html/rfc9000