QUIC se suele resumir con una explicación demasiado simplificada: HTTP/3 utiliza UDP porque UDP es más rápido que TCP. Sin embargo, en realidad, esa idea lleva a una conclusión equivocada. UDP no ofrece por sí mismo las garantías que necesita el transporte, por lo que QUIC debe construir sobre él mecanismos como fiabilidad, control de congestión, recuperación de pérdidas, multiplexación y seguridad. La decisión de usar UDP responde en buena medida a otro aspecto: TCP funciona extraordinariamente bien, pero después de décadas de despliegue resulta muy difícil modificarlo y desplegar esas mejoras en toda Internet.
Las claves de QUIC en 30 segundos
- QUIC emplea UDP principalmente como mecanismo de transporte sobre la infraestructura existente de Internet, no porque UDP sea simplemente «más rápido».
- Implementa streams, control de flujo, recuperación de pérdidas y control de congestión fuera de la implementación TCP en el kernel.
- Integra TLS 1.3 directamente en el propio protocolo.
- Esto permite actualizar mucho del comportamiento del transporte junto con las aplicaciones, sin esperar a nuevas versiones del sistema operativo.
- El precio a pagar es trasladar a espacio de usuario trabajo que TCP lleva décadas optimizando en kernels y tarjetas de red.
La propia especificación de QUIC deja clara esta motivación. RFC 9000 define QUIC como un protocolo de transporte seguro y orientado a conexión, cuyos paquetes se transportan dentro de datagramas UDP para facilitar su despliegue sobre sistemas y redes existentes.
Para un administrador de sistemas, esta elección resulta especialmente interesante pues modifica una barrera que durante décadas parecía prácticamente inamovible.
Simplificando, la pila tradicional de HTTP sobre TCP puede representarse así:
Aplicación
|
HTTP
|
TLS
-------------------- usuariospace
|
TCP
|
IP
-------------------- kernel
|
NIC
En cambio, con HTTP/3 y QUIC, la distribución cambia a:
Aplicación
|
HTTP/3
|
QUIC
|-- Streams
|-- Fiabilidad
|-- Control de flujo
|-- Recuperación de pérdidas
|-- Control de congestión
|-- TLS 1.3
-------------------- usuariospace
|
UDP
|
IP
-------------------- kernel
|
NIC
Esto no implica que QUIC «evite el kernel». Los datagramas UDP siguen atravesando la pila de red del sistema operativo. La diferencia radica en qué capa asume parte importante de la lógica del transporte.
TCP funciona tan bien que cambiarlo no es fácil
TCP ha sido durante décadas uno de los pilares de Internet.
Proporciona entrega fiable, control de flujo, recuperación de pérdidas, ordenación de bytes y control de congestión. Además, sistemas operativos como Linux, otros SO y fabricantes de tarjetas de red han dedicado años a optimizar su rendimiento.
El problema surge cuando se intenta modificar su comportamiento.
Una aplicación normalmente utiliza la implementación TCP del sistema operativo. Introducir mejoras en el transporte puede requerir modificar el kernel, desplegar esa versión y esperar que llegue a suficientes clientes y servidores.
Pero hay un segundo obstáculo fuera de los extremos de la comunicación.
Entre navegador y servidor pueden encontrarse:
Cliente
|
NAT
|
Firewall
|
Balanceador
|
Proxy
|
Servidor
Estos dispositivos llevan décadas aprendiendo a trabajar con TCP. Algunos inspeccionan estados, flags o secuencias. Otros mantienen tablas de conexiones o realizan diferentes formas de análisis y manipulación del tráfico.
El resultado es lo que en ingeniería de protocolos se denomina osificación del protocolo, o protocol ossification.
Una característica que puede ser válida en una nueva especificación, puede no ser entendida por dispositivos intermedios.
El éxito de TCP, en realidad, ha dificultado su propia evolución.
QUIC adopta un enfoque diferente: en vez de crear un nuevo protocolo sobre IP que todos los routers, NAT, firewalls y sistemas deban aprender, utiliza UDP como base.
Ya estaba desplegado en los sistemas operativos y en la infraestructura de red.
Los sistemas tenían sockets UDP. Los routers podían transportarlo. Los NAT mantenían su estado. Los firewalls podían permitirlo.
Así, QUIC podía añadir encima la lógica que necesitaba sin alterar toda esa infraestructura.
La RFC 9000 confirma esto al señalar que los paquetes QUIC se transportan con datagramas UDP para facilitar su despliegue en las redes y sistemas existentes.
Llevar el transporte a userspace cambia su ritmo de evolución
Las ventajas más notables aparecen en los extremos de la conexión.
Una parte significativa del comportamiento de QUIC puede residir en una biblioteca utilizada por navegadores, servidores, CDN, proxy o aplicaciones.
Esto permite que cada organización modifique su implementación y despliegue nuevas versiones del software rápidamente.
No tienen que esperar a que esas mejoras se integren en el kernel y que millones de sistemas las actualicen.
El modelo sería así:
Nueva implementación QUIC
|
v
Actualización en la aplicación o biblioteca
|
v
Nuevo comportamiento del transporte
Esto facilita trabajar con algoritmos avanzados de control de congestión, recuperación de pérdidas, planificación de paquetes y otras funciones, con ciclos de despliegue diferentes a los del sistema operativo.
Cloudflare ofrece un ejemplo concreto con quiche, su implementación abierta de QUIC y HTTP/3.
En mayo de 2026, detectaron un problema interesante relacionado con CUBIC, el controlador de congestión predeterminado en quiche.
Una interacción entre una optimización para periodos de inactividad y el comportamiento de la ventana de congestión podía hacer que esta quedara atrapada en su valor mínimo tras una congestión.
Cloudflare lo llamó una especie de «bucle mortal» de QUIC.
Más allá del caso concreto, ilustra una ventaja operativa de esta arquitectura: Cloudflare podía inspeccionar, modificar y desplegar cambios en el comportamiento del transporte dentro de su propia implementación de QUIC.
En TCP, modificar la lógica del kernel depende de ciclos de desarrollo y despliegue diferentes.
Pero esto no significa que QUIC sea totalmente independiente del sistema operativo. Continúa usando UDP, IP, sockets y buffers del kernel. La frontera simplemente se ha desplazado.
El coste de QUIC: TCP lleva décadas siendo optimizado
Mover más trabajo a espacio de usuario tiene implicaciones.
TCP no es solo un protocolo maduro, sino que cuenta con una enorme infraestructura de optimización.
- TCP Segmentation Offload (TSO)
- Generic Segmentation Offload (GSO)
- Generic Receive Offload (GRO)
- Verificación de checksum en hardware
- Optimizaciones en el stack de sockets
- Soporte específico en NIC
- Técnicas de zero-copy en ciertos escenarios
QUIC, además, requiere cifrar casi todo su tráfico, gestionar paquetes, ACKs, streams, pérdidas, retransmisiones y control de congestión en su propia implementación.
Procesar ingentes volúmenes de datagramas a altas velocidades puede convertirse en un cuello de botella para la CPU.
Cloudflare estudió este efecto desde los primeros despliegues de QUIC.
Una implementación sencilla enviaba cada paquete UDP mediante una llamada individual a sendmsg()
. Esto implica una transición entre userspace y kernel por paquete, y en millones de paquetes, ese coste se nota.
Una solución es agrupar múltiples mensajes usando sendmmsg(), reduciendo el número de syscalls.
Otra tecnología avanzada en Linux es UDP GSO, que permite proporcionar un buffer grande y dividirlo en datagramas más pequeños en el kernel, reduciendo llamadas y mejorando throughput.
userspace
super-buffer
|
v
kernel
|
v
segmentación en el kernel
/ / \ \
P1 P2 P3 P4
|
NIC
Linux soporta UDP GSO mediante UDP_SEGMENT. La aplicación puede enviar un buffer grande y solicitar que se divida en datagramas en el kernel, con un impacto de rendimiento significativo.
Esta técnica ayuda a reducir syscalls y aumentar el rendimiento, recuperando parte de la eficiencia que TCP ha conseguido en décadas anteriores mediante optimizaciones hardware y de kernel.
Sin embargo, introduce otro desafío: packet pacing.
El envío de paquetes no debe limitarse solo a la velocidad que permite la CPU. El control de congestión requiere distribuir los paquetes para evitar ráfagas que causen pérdidas o congestión.
Agrupar muchos paquetes ayuda a reducir syscalls, pero puede entrar en conflicto con la necesidad de determinar cuándo transmitir cada uno exactamente.
Linux ofrece mecanismos como SO_TXTIME y SCM_TXTIME que permiten trasladar parte de esta planificación temporal al kernel, lo que refleja cómo la frontera entre espacio de usuario y kernel sigue evolucionando incluso cuando QUIC mantiene la lógica principal del transporte en espacio de usuario.
QUIC no es solo «TCP sobre UDP»
Otra percepción común es que QUIC es simplemente una reimplementación de TCP sobre UDP.
Pero, aunque comparte responsabilidades con TCP, su diseño permite resolver ciertos problemas de una forma diferente.
Un ejemplo clave es la multiplexación.
HTTP/2 permite múltiples streams en una sola conexión TCP, pero TCP solo ofrece un flujo ordenado de bytes.
Si se pierde un paquete TCP que reconstituye ese flujo, los datos posteriores deben esperar, incluso si pertenecen a otros streams HTTP/2.
QUIC incorpora streams dentro del propio transporte, de modo que la pérdida de datos en un stream no impide avanzar en otros streams de forma independiente.
Además, integra TLS 1.3 en la propia negociación de conexión.
La RFC 9000 define un handshake que combina la negociación criptográfica y de transporte. QUIC también puede usar 0-RTT en conexiones ya existentes, aunque con consideraciones de seguridad como el riesgo de reproducción de datos (replay).
Otra innovación importante son los Connection IDs.
Mientras TCP está estrechamente ligado a IP y puertos, QUIC usa identificadores que permiten mantener el estado incluso si cambian las rutas de red, fundamentales en dispositivos móviles.
QUIC cifra también para evitar otra osificación
Otra lección que aprendió QUIC de TCP es que cuanto más puedan los dispositivos intermedios analizar su funcionamiento interno, mayor será la dependencia de esos detalles.
Por eso, muchas partes de la información en QUIC están criptográficamente protegidas.
Un middlebox sólo puede ver IP, UDP y algunos datos necesarios para transportar datagramas, pero no la lógica interna de la conexión.
Este enfoque tiene un coste: identificar y diagnosticar tráfico QUIC en la red es más complejo y las herramientas tradicionales tienen menos acceso.
Pero esta opacidad ayuda a que futuras evoluciones de QUIC no queden atrapadas en dispositivos que dependan de comportamientos internos específicos, favoreciendo la innovación y compatibilidad futura.
La diferencia entre TCP y QUIC, por tanto, no es simplemente «TCP lento frente a UDP rápido»:
| Característica | TCP | QUIC |
|---|---|---|
| Transporte | Implementado mayormente en kernel | Gran parte en espacio de usuario |
| Protocolo base | IP | UDP/IP |
| Fiabilidad | TCP | QUIC |
| Control de congestión | Kernel/TCP | Implementación específica en QUIC |
| Streams nativos | No | Sí |
| Seguridad | Generalmente TLS sobre TCP | TLS 1.3 integrado |
| Evolución | Ligada al stack del sistema operativo | Puede evolucionar en aplicaciones y bibliotecas |
| Middleboxes | Alta visibilidad histórica | |
| Offloads | Décadas de optimización | |
| Migración de conexión | No nativa | Incorporada en QUIC |
Esta diferencia explica por qué HTTP/3 opta por QUIC.
La velocidad importa, especialmente en conexiones con alta latencia, pérdidas o cambios de red. Pero, en el fondo, la decisión fue arquitectónica: recuperar la capacidad de evolucionar el transporte sin modificar TCP en toda Internet.
TCP, debido a su enorme éxito, ha generado décadas de suposiciones en sistemas operativos, aplicaciones y dispositivos de red.
QUIC usa UDP como una capa simple y desplegada ampliamente para construir un transporte moderno en los endpoints.
Este enfoque implica que asume trabajo que TCP realiza en kernels y NIC mediante ingeniería durante décadas.
Por ello, proyectos como UDP GSO son esenciales. QUIC logró mayor libertad de evolución, pero ahora necesita construir parte de la maquinaria de rendimiento que TCP ya tiene a su alcance.
Este intercambio entre flexibilidad en espacio de usuario y eficiencia en kernel es más interesante que la simplificación de decir que «HTTP/3 eligió UDP porque era más rápido».
Preguntas frecuentes
¿Por qué QUIC utiliza UDP en lugar de TCP?
Porque UDP proporciona una base ampliamente desplegada sobre la que QUIC puede implementar su lógica de transporte sin depender de modificar TCP en los sistemas y dispositivos existentes. La RFC 9000 especifica que QUIC emplea datagramas UDP para facilitar su despliegue en redes existentes.
¿QUIC es más rápido porque UDP es más rápido?
No necesariamente. QUIC debe ofrecer funciones como fiabilidad, recuperación, control de congestión y cifrado. Su rendimiento proviene de su diseño completo, no solo del uso de UDP.
¿QUIC funciona completamente en userspace?
No. Aunque muchas implementaciones sitúan gran parte de su lógica en userspace, los datagramas UDP siguen atravesando el stack del kernel y utilizando la interfaz de red. Además, mecanismos como UDP GSO permiten descargar ciertas operaciones otra vez hacia el kernel o hardware.
¿Cuál es la relación entre HTTP/3 y QUIC?
HTTP/3 usa QUIC como protocolo de transporte. QUIC provee conexiones seguras, streams multiplexados, control de flujo, recuperación de pérdidas, control de congestión y seguridad, mientras HTTP/3 define su funcionamiento sobre esas bases.
Fuentes:
- IETF, RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
- Cloudflare, Accelerating UDP Packet Transmission for QUIC, análisis de
sendmsg(),sendmmsg()y UDP GSO. - Cloudflare, When «idle» isn’t idle: how a Linux kernel optimization became a QUIC bug, 12/05/2026.
- First Finger, Why QUIC Moved Transport Logic from the Kernel into Userspace, artículo utilizado como referencia.