La explicación más comúnmente utilizada para QUIC es demasiado simplista: HTTP/3 utiliza UDP porque UDP es más rápido que TCP. Sin embargo, desde un punto de vista técnico, esta idea conduce a una conclusión errónea. UDP no ofrece por sí solo las garantías necesarias para HTTP, por lo que QUIC tiene que construir sobre él mecanismos de fiabilidad, control de congestión, recuperación ante pérdidas, multiplexación y seguridad. La elección de usar UDP responde en gran medida a otro problema: TCP funciona de manera excelente, pero tras décadas de despliegue, resulta muy difícil modificarlo y desplegar esas modificaciones en Internet.
Las claves de QUIC en 30 segundos
- QUIC emplea UDP principalmente como un mecanismo de transporte adaptable sobre la infraestructura actual de Internet, no porque UDP sea inherentemente «más rápido».
- Implementa streams, control de flujo, recuperación de pérdidas y control de congestión fuera del kernel, en la capa de usuario.
- Integra TLS 1.3 directamente en el protocolo.
- Esto permite actualizar gran parte del transporte junto con las aplicaciones sin esperar nuevas versiones del sistema operativo.
- El contra es que se traslada parte del trabajo que TCP ha optimizado en el kernel y en hardware a la capa de usuario, pudiendo aumentar la carga en el host.
La propia especificación de QUIC deja bastante claro 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 en sistemas y redes existentes.
Para administradores de sistemas, esto resulta especialmente interesante porque desafía una separación que parecía prácticamente inamovible desde hace décadas.
Resumiendo, la pila tradicional de HTTP sobre TCP podría representarse de la siguiente manera:
Aplicación
|
HTTP
|
TLS
-------------------- espacio de usuario
|
TCP
|
IP
-------------------- núcleo del sistema
|
NIC
Con HTTP/3 y QUIC, la distribución cambia substancialmente:
Aplicación
|
HTTP/3
|
QUIC
|-- Streams
|-- Fiabilidad
|-- Control de flujo
|-- Recuperación de pérdidas
|-- Control de congestión
|-- TLS 1.3
-------------------- espacio de usuario
|
UDP
|
IP
-------------------- núcleo del sistema
|
NIC
Esto no implica que QUIC «evite el kernel» por completo. Los datagramas UDP siguen atravesando la pila de red del sistema operativo. La diferencia está en qué capa se encarga de gran parte de la lógica de transporte.
TCP funciona demasiado bien para cambiarlo fácilmente
TCP ha sido uno de los pilares de Internet durante décadas.
Ofrece entrega fiable, control de flujo, recuperación de pérdidas, ordenación de bytes y control de congestión. Además, sistemas como Linux, otros OS y las tarjetas de red llevan años optimizando su rendimiento.
El problema surge cuando se intenta modificar su comportamiento.
Las aplicaciones suelen depender de la implementación TCP del sistema operativo. Introducir mejoras puede requerir modificar el kernel, desplegar esa versión y esperar a que esa actualización llegue a suficientes clientes y servidores.
Pero existe un segundo obstáculo fuera de los extremos de la conexión.
Entre navegador y servidor, pueden encontrarse dispositivos como:
Cliente
|
NAT
|
Firewall
|
Balanceador
|
Proxy
|
Servidor
Durante años, estos dispositivos han aprendido a trabajar con TCP, inspeccionando estados, flags, secuencias, manteniendo tablas de conexiones y manipulando tráfico. Esto da lugar a lo que en ingeniería de protocolos se denomina ossificación del protocolo.
Una característica que cumple con nuevas especificaciones puede encontrarse con dispositivos que no entienden su comportamiento, dificultando su despliegue.
Así, el éxito de TCP ha dificultado su propia evolución.
QUIC adopta una estrategia diferente: en lugar de crear un protocolo totalmente nuevo en IP que todos los routers y dispositivos tendrían que aprender, utiliza UDP como base.
UDP ya estaba ampliamente desplegado: sistemas operativos con sockets UDP, routers que transportan UDP, NATs que mantienen estados y firewalls que permiten este tráfico.
Por tanto, QUIC puede construir sobre esa infraestructura existente, integrando la lógica de transporte que necesita en la capa de usuario.
La RFC 9000 confirma esta decisión, indicando que los paquetes QUIC se transportan mediante datagramas UDP para facilitar su despliegue en sistemas y redes existentes.
Llevar el transporte a userspace cambia la velocidad de evolución
Uno de los efectos más relevantes se produce en los extremos de la conexión.
Una parte importante del comportamiento de QUIC puede residir en bibliotecas usadas por navegadores, servidores, CDNs, proxies o aplicaciones, permitiendo que su actualización no dependa del kernel del sistema operativo.
Esto facilita modificar e implementar nuevas funcionalidades y algoritmos de control sin esperar a que esas mejoras se integren en el kernel y se desplieguen globalmente.
El modelo simplificado sería:
Nueva implementación QUIC
|
v
Actualización en la aplicación o biblioteca
|
v
Nuevo comportamiento del transporte
Gracias a esto, los controles de congestión, recuperación, planificación de paquetes y demás componentes del transporte pueden evolucionar de forma independiente a la capa del sistema operativo.
Un ejemplo práctico es quiche, la implementación abierta de QUIC y HTTP/3 de Cloudflare. En mayo de 2026, publicaron un problema relacionado con CUBIC, el controlador de congestión por defecto en quiche.
Se detectó que una interacción entre una optimización para periodos de inactividad y la lógica de ventana de congestión podía provocar que ésta quedara en su tamaño mínimo tras un colapso, creando una situación conocida como «QUIC death spiral».
Este ejemplo pone en evidencia una ventaja de esta arquitectura: Cloudflare puede inspeccionar, modificar y desplegar cambios en el comportamiento del transporte dentro de su propia implementación de QUIC, sin depender del sistema operativo.
En TCP, realizar cambios similares en el kernel requiere ciclos de desarrollo y despliegue más largos.
Aunque QUIC sigue haciendo uso de UDP, IP, sockets y buffers del kernel, la frontera se ha desplazado, permitiendo mayor flexibilidad de evolución en los extremos.
El coste de QUIC: TCP lleva décadas de optimización
Mover más trabajo a userspace tiene implicaciones.
TCP no solo es un protocolo maduro, sino que cuenta con una infraestructura de optimización muy desarrollada: TSO, GSO, GRO, checksum offload, optimizaciones del stack de sockets, soporte en NIC, técnicas de zero-copy y más.
Por otro lado, QUIC debe cifrar prácticamente todo, gestionar paquetes, ACKs, streams, pérdidas, retransmisiones y control de congestión en la capa de usuario.
A altas velocidades, procesar grandes volúmenes de datagramas puede suponer una carga significativa para la CPU.
Cloudflare observó este comportamiento en sus primeros despliegues de QUIC.
Por ejemplo, enviar cada paquete UDP mediante una llamada individual a sendmsg() implicaba transitar entre espacio de usuario y kernel por paquete, lo cual genera sobrecarga.
Una solución es agrupar múltiples mensajes en una sola syscall usando sendmmsg(), una API que Linux soporta para reducir llamadas múltiples.
Además, Linux soporta UDP GSO mediante UDP_SEGMENT: en lugar de entregar datagramas individuales, la aplicación proporciona un buffer grande del que el kernel segmenta en datagramas más pequeños para enviar.
userspace
super-buffer
|
v
kernel
|
v
segmentación
/ /
P1 P2 P3 P4
|
NIC
Este método reduce significativamente el número de syscalls y mejora el throughput. Aunque requiere gestión adicional en la capa de usuario, ayuda a recuperar parte de la eficiencia que TCP logró en décadas a través de optimizaciones del kernel y hardware.
No obstante, introduce otro reto: el pacing de paquetes.
El envío rápido sin control de congestión puede generar ráfagas que aumenten pérdidas. La agrupación ayuda a reducir llamadas a syscalls pero puede afectar la programación del envío de cada paquete individual.
Linux dispone de mecanismos como SO_TXTIME y SCM_TXTIME para retrasar el envío de ciertos paquetes, trasladando parte del control temporal hacia el kernel. Esto refleja cómo la frontera entre userspace y kernel continúa adaptándose, incluso cuando la lógica principal del transporte en QUIC se mantiene en la capa de usuario.
QUIC no es simplemente «TCP sobre UDP»
Otra visión simplificada frecuente es considerar a QUIC como una reimplementación de TCP dentro de UDP.
Si bien comparte responsabilidades con TCP, su diseño permite resolver ciertos problemas de otra forma, destacando especialmente la multiplexación.
HTTP/2 permite múltiples streams multiplexados en una conexión TCP; sin embargo, TCP solo ofrece un flujo ordenado de bytes. Si un segmento TCP necesario para reconstruir un stream se pierde, todos los datos posteriores de ese stream esperan, incluso si pertenecen a otros streams HTTP/2.
QUIC incorpora streams directamente en el transporte, permitiendo que una pérdida en un stream no bloquee otros, promoviendo mayor eficiencia y menor latencia.
También integra TLS 1.3 en el establecimiento de conexiones, combinando negociación criptográfica y de transporte en un solo handshake. Además, soporta 0-RTT para conexiones previamente establecidas, aunque con riesgos asociados de replay.
Otra innovación son los Connection IDs: identificadores que mantienen el estado de la conexión aunque cambien las direcciones IP o las rutas, facilitando movilidad y migración en redes móviles y NATs.
El cifrado de QUIC para evitar la osificación
Otra lección aprendida de TCP es que si dispositivos intermedios pueden observar detalles internos del protocolo, terminan dependiendo de esos aspectos específicos, dificultando su evolución.
Por ello, gran parte de la información en QUIC está cifrada.
Un middlebox sigue viendo IP, UDP y ciertos datos necesarios para transportar los datagramas, pero tiene menos visibilidad sobre el estado interno de la conexión.
Esto aumenta la dificultad para diagnosticar tráfico QUIC desde la red, dado que las herramientas de inspección tradicionales no tienen acceso a toda la información.
Pero esa opacidad es también intencionada: si los firewalls no pueden basarse en detalles internos, es menos probable que futuras evoluciones de QUIC sean bloqueadas por dispositivos que dependan de comportamientos específicos.
En definitiva, la comparación entre TCP y QUIC revela que no se trata simplemente de «TCP lento frente a UDP rápido»:
| Característica | TCP | QUIC |
|---|---|---|
| Implementación de transporte | Principalmente en kernel | Gran parte en userspace |
| Protocolo inferior | IP | UDP/IP |
| Fiabilidad | TCP | QUIC |
| Control de congestión | Kernel/TCP | Implementación en QUIC |
| Streams nativos | No | Sí |
| Seguridad | TLS sobre TCP tradicionalmente | |
| Evolución | Ligada al stack del SO | En aplicación o biblioteca |
| Middleboxes | Amplia visibilidad histórica | Menor percepción |
| Offloads | Décadas de optimización | Nuevo ecosistema |
| Migración de conexión | No nativa | Integrada en QUIC |
Esta diferencia explica en buena medida por qué HTTP/3 opta por QUIC. La velocidad es importante, especialmente en condiciones de alta latencia, pérdida o cambios de red. Pero la decisión arquitectónica fundamental fue recuperar la capacidad de evolucionar el transporte sin tener que modificar TCP en toda Internet.
TCP, debido a su enorme éxito, ha generado sobre estructuras y aplicaciones una serie de supuestos que ahora dificultan su modificación.
QUIC, como capa sencilla y ampliamente desplegada sobre UDP, permite construir un transporte moderno en los extremos, asumiendo el trabajo que TCP recibe optimizado en kernel y hardware desde hace décadas.
Proyectos como UDP GSO son cruciales; aunque QUIC ganó en libertad de evolución, necesita ahora reconstruir parte de la maquinaria de rendimiento que TCP ya poseía.
El equilibrio entre flexibilidad en userspace y eficiencia en el kernel hace que esta estrategia sea mucho más interesante que la simple afirmación de que «UDP es más rápido que TCP» para explicar HTTP/3.
Preguntas frecuentes
¿Por qué QUIC utiliza UDP en lugar de TCP?
Porque UDP ya está desplegado y permite que QUIC implemente su lógica de transporte sin depender de modificar TCP en todos los sistemas y dispositivos. La RFC 9000 expresa claramente que QUIC utiliza datagramas UDP para facilitar su despliegue en la infraestructura actual.
¿QUIC es más rápido porque UDP es más rápido?
No necesariamente. Aunque UDP es simple y tiene bajo coste de envío, QUIC necesita proporcionar funciones adicionales como fiabilidad, recuperación ante pérdidas, control de congestión y cifrado. Sus ventajas de rendimiento vienen de su diseño completo y optimizaciones, no solo del uso de UDP.
¿QUIC funciona totalmente en userspace?
No. La mayoría de las implementaciones sitúan gran parte de la lógica en userspace, pero los datagramas UDP siguen atravesando el stack IP del kernel y haciendo uso de la interfaz de red. Además, mecanismos como UDP GSO pueden delegar parte de la gestión hacia el kernel o hardware para mejorar el rendimiento.
¿Cuál es la relación entre HTTP/3 y QUIC?
HTTP/3 se basa en QUIC para su transporte. QUIC ofrece conexiones seguras, streams multiplexados, control de flujo, recuperación de pérdidas y control de congestión. HTTP/3 define el protocolo de aplicación que opera sobre esa capa de transporte.
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 inicial.