QUIC suele resumirse con una explicación demasiado sencilla: HTTP/3 utiliza UDP porque UDP es más rápido que TCP. Técnicamente, esa idea lleva a una conclusión equivocada. UDP no aporta por sí mismo las garantías que necesita HTTP y QUIC tiene que construir sobre él fiabilidad, control de congestión, recuperación ante pérdidas, multiplexación y seguridad. La decisión de utilizar UDP responde en buena medida a otro problema: TCP funciona extraordinariamente bien, pero después de décadas de despliegue resulta muy difícil modificarlo y desplegar esos cambios en Internet.
Las claves de QUIC en 30 segundos
- QUIC utiliza UDP principalmente como mecanismo de transporte desplegable sobre la Internet existente, 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 del kernel.
- Integra TLS 1.3 en el propio protocolo.
- Esto permite actualizar buena parte del transporte junto con las aplicaciones sin esperar a nuevas versiones del sistema operativo.
- El precio es trasladar a userspace trabajo que TCP lleva décadas optimizando en kernels y tarjetas de red.
La propia especificación de QUIC deja bastante 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.
La elección resulta especialmente interesante para un administrador de sistemas porque cambia una separación que durante décadas parecía prácticamente inamovible.
Simplificando, la pila tradicional de HTTP sobre TCP puede representarse así:
Aplicación
|
HTTP
|
TLS
-------------------- userspace
|
TCP
|
IP
-------------------- kernel
|
NIC
Con HTTP/3 y QUIC la distribución cambia:
Aplicación
|
HTTP/3
|
QUIC
|-- Streams
|-- Reliability
|-- Flow Control
|-- Loss Recovery
|-- Congestion Control
|-- TLS 1.3
-------------------- userspace
|
UDP
|
IP
-------------------- kernel
|
NIC
Esto no significa que QUIC «evite el kernel». Los datagramas UDP siguen atravesando la pila de red del sistema operativo. La diferencia está en qué capa se responsabiliza de una parte importante de la lógica de transporte.
TCP funciona demasiado bien como para cambiarlo fácilmente
TCP lleva décadas siendo uno de los componentes básicos de Internet.
Proporciona entrega fiable, control de flujo, recuperación de pérdidas, ordenación de bytes y control de congestión. Además, Linux, otros sistemas operativos y los fabricantes de tarjetas de red han dedicado años a mejorar su rendimiento.
El problema aparece cuando se intenta modificar su comportamiento.
Una aplicación normalmente utiliza la implementación TCP proporcionada por el sistema operativo. Introducir determinadas mejoras en el transporte puede exigir modificar el kernel, desplegar esa versión del kernel y esperar a que el cambio llegue a suficientes clientes y servidores.
Pero existe un segundo obstáculo fuera de los endpoints.
Entre un navegador y un servidor pueden encontrarse:
Cliente
|
NAT
|
Firewall
|
Balanceador
|
Proxy
|
Servidor
Durante décadas estos dispositivos han aprendido a trabajar con TCP. Algunos inspeccionan estados, flags o secuencias. Otros mantienen tablas de conexiones o realizan diferentes formas de inspección y manipulación del tráfico.
El resultado es lo que en ingeniería de protocolos se denomina protocol ossification, u osificación del protocolo.
Una característica puede ser perfectamente válida según una nueva especificación y aun así encontrarse con dispositivos intermedios que no entienden el nuevo comportamiento.
El éxito de TCP contribuyó así a dificultar su propia evolución.
QUIC adopta una estrategia distinta: en lugar de crear un nuevo protocolo directamente sobre IP que todos los routers, NAT, firewalls y sistemas operativos tuvieran que aprender, utiliza UDP como sustrato.
UDP ya estaba desplegado.
Los sistemas operativos disponían de sockets UDP. Los routers podían transportarlo. Los NAT sabían mantener estados para él y los firewalls podían permitirlo.
QUIC podía entonces colocar encima la lógica que necesitaba.
La RFC 9000 confirma esta decisión al señalar que los paquetes QUIC se transportan mediante datagramas UDP precisamente para facilitar el despliegue en sistemas y redes existentes.
Llevar el transporte a userspace cambia la velocidad de evolución
La consecuencia más interesante aparece en los extremos de la conexión.
Una parte importante del comportamiento de QUIC puede residir dentro de una biblioteca utilizada por el navegador, servidor web, CDN, proxy o aplicación.
Esto permite que una organización modifique su implementación y distribuya posteriormente una nueva versión del software.
No tiene necesariamente que esperar a que la funcionalidad se incorpore al kernel y después a que millones de sistemas actualicen ese kernel.
El modelo puede simplificarse así:
Nueva implementación QUIC
|
v
Actualización aplicación/biblioteca
|
v
Nuevo comportamiento de transporte
Eso permite trabajar con algoritmos de control de congestión, recuperación de pérdidas, planificación de paquetes y otras partes del transporte con ciclos de despliegue diferentes a los del sistema operativo.
Cloudflare proporciona un ejemplo práctico mediante quiche, su implementación abierta de QUIC y HTTP/3.
La compañía documentó en mayo de 2026 un problema especialmente interesante relacionado con CUBIC, utilizado como controlador de congestión predeterminado por quiche.
Una interacción entre una optimización relacionada con periodos de inactividad y el comportamiento de la ventana de congestión podía provocar que esta quedara atrapada en su tamaño mínimo después de un colapso por congestión.
Cloudflare lo describió como una especie de QUIC «death spiral».
Más allá del fallo concreto, el caso muestra una de las ventajas operativas de esta arquitectura: Cloudflare podía inspeccionar, modificar y desplegar cambios sobre el comportamiento del transporte dentro de su propia implementación QUIC.
En TCP, modificaciones comparables realizadas dentro de la implementación del kernel dependen de otro ciclo de desarrollo y despliegue.
Eso tampoco significa que QUIC sea completamente independiente del sistema operativo. Continúa utilizando UDP, IP, sockets, buffers y numerosas capacidades del kernel. La frontera simplemente se ha desplazado.
El precio de QUIC: TCP lleva décadas siendo optimizado
Mover más trabajo a userspace tiene consecuencias.
TCP no es simplemente un protocolo maduro. Es un protocolo para el que se ha construido una enorme cantidad de infraestructura de aceleración.
Entre otras tecnologías aparecen:
- TCP Segmentation Offload (TSO).
- Generic Segmentation Offload (GSO).
- Generic Receive Offload (GRO).
- checksum offload.
- optimizaciones del stack de sockets.
- soporte específico en NIC.
- técnicas de zero-copy en determinados escenarios.
QUIC necesita además cifrar prácticamente todo su tráfico y gestionar en su implementación paquetes, ACK, streams, pérdidas, retransmisiones y control de congestión.
A velocidades elevadas el coste de procesar individualmente enormes cantidades de datagramas puede convertirse en un problema de CPU.
Cloudflare estudió este comportamiento ya durante sus primeros despliegues de QUIC.
En una implementación sencilla, enviar cada paquete UDP mediante una llamada individual a sendmsg() implica una transición entre userspace y kernel por paquete.
Con millones de paquetes, esas llamadas tienen un coste apreciable.
Una primera posibilidad consiste en utilizar sendmmsg() para agrupar múltiples mensajes en una sola syscall.
Linux proporciona además una herramienta todavía más interesante: UDP Generic Segmentation Offload (UDP GSO).
En lugar de entregar al kernel cada datagrama individualmente:
userspace
send()
packet 1
send()
packet 2
send()
packet 3
send()
packet 4
la aplicación puede proporcionar un buffer mayor:
userspace
super-buffer
|
v
kernel
|
v
segmentación
/ / \ \
P1 P2 P3 P4
|
NIC
Linux incorporó soporte para UDP GSO mediante UDP_SEGMENT. La aplicación puede proporcionar un buffer grande y solicitar que se divida posteriormente en datagramas más pequeños.
Cloudflare comprobó que esta técnica reducía significativamente el número de syscalls y mejoraba el throughput de su implementación experimental.
Esto ayuda a recuperar parte de la eficiencia que TCP consiguió durante décadas mediante optimizaciones del kernel y del hardware.
Pero introduce otro problema interesante: packet pacing.
Un protocolo de transporte no debería limitarse a enviar paquetes tan rápido como permita la CPU. El control de congestión necesita distribuirlos adecuadamente para evitar ráfagas que terminen aumentando pérdidas y congestión.
Agrupar muchos paquetes ayuda a reducir syscalls, pero puede entrar en conflicto con la necesidad de determinar exactamente cuándo debe transmitirse cada uno.
Linux dispone de mecanismos como SO_TXTIME y SCM_TXTIME que permiten trasladar parte de esta programación temporal hacia el kernel. Es un buen ejemplo de cómo la frontera entre userspace y kernel sigue evolucionando incluso cuando QUIC mantiene la lógica principal del transporte fuera de TCP.
QUIC tampoco es simplemente «TCP sobre UDP»
Otra simplificación habitual consiste en considerar QUIC una reimplementación de TCP dentro de UDP.
Comparte responsabilidades con TCP, pero su diseño permite resolver algunos problemas de otra forma.
Uno de ellos es la multiplexación.
HTTP/2 permite múltiples streams dentro de una conexión TCP. Sin embargo, TCP proporciona un único flujo ordenado de bytes.
Si se pierde un segmento TCP necesario para reconstruir ese flujo, los datos posteriores deben esperar aunque pertenezcan a otro stream HTTP/2.
QUIC incorpora streams dentro del propio transporte. La pérdida de datos correspondiente a un stream no obliga a bloquear de la misma manera el progreso de otros streams independientes.
También integra TLS 1.3 en el establecimiento de la conexión.
La RFC 9000 define un handshake que combina la negociación de parámetros criptográficos y de transporte. QUIC puede además utilizar 0-RTT para determinadas conexiones previamente establecidas, aunque esta modalidad tiene consideraciones de seguridad específicas, incluido el riesgo de replay.
Otro cambio importante son los Connection IDs.
Una conexión TCP está estrechamente asociada a direcciones IP y puertos. QUIC incorpora identificadores de conexión que permiten mantener el estado aunque cambie el camino de red.
Esto resulta especialmente práctico en dispositivos móviles.
Un teléfono puede comenzar una conexión utilizando Wi-Fi y posteriormente cambiar a una red móvil. QUIC dispone de mecanismos de migración de conexión diseñados precisamente para manejar cambios de ruta o modificaciones provocadas por NAT.
QUIC cifra también para evitar otra generación de osificación
QUIC aprendió otra lección de TCP: cuanto más puedan observar los dispositivos intermedios sobre el funcionamiento interno de un protocolo, mayor es la posibilidad de que terminen dependiendo de esos detalles.
Por eso una parte considerable de la información de QUIC está protegida criptográficamente.
Un middlebox continúa viendo IP, UDP y determinada información necesaria para transportar los datagramas, pero tiene mucha menos visibilidad sobre el estado interno de la conexión.
Esto tiene un coste.
Diagnosticar tráfico QUIC desde la red puede resultar más complicado que observar determinadas características de TCP. Herramientas tradicionales de monitorización e inspección no tienen acceso a la misma información.
Pero esa opacidad es parcialmente intencionada.
Si un firewall no puede construir su funcionamiento alrededor de detalles internos que deberían pertenecer exclusivamente a los endpoints, es más difícil que una generación futura de QUIC quede bloqueada porque millones de dispositivos hayan aprendido a depender accidentalmente de su comportamiento actual.
La comparación entre TCP y QUIC queda así bastante lejos de «TCP lento frente a UDP rápido»:
| Característica | TCP | QUIC |
|---|---|---|
| Transporte | Implementado principalmente en kernel | Gran parte implementada en userspace |
| Protocolo inferior | IP | UDP/IP |
| Fiabilidad | TCP | QUIC |
| Control de congestión | TCP/kernel | Implementación QUIC |
| Streams nativos | No | Sí |
| Seguridad | TLS sobre TCP habitualmente | TLS 1.3 integrado |
| Evolución | Ligada en buena medida al stack del SO | Puede evolucionar con aplicación/biblioteca |
| Middleboxes | Amplia visibilidad histórica | Menor visibilidad |
| Offloads | Décadas de optimización | Ecosistema más reciente |
| Migración de conexión | No nativa de TCP clásico | Incorporada en QUIC |
Esta diferencia explica mejor por qué HTTP/3 utiliza QUIC.
La velocidad importa, especialmente en conexiones con latencia, pérdidas o cambios de red. Pero la decisión arquitectónica más profunda fue recuperar capacidad para evolucionar el transporte sin tener que modificar TCP en toda Internet.
TCP llegó a una situación paradójica: su enorme éxito hizo que sistemas operativos, aplicaciones y dispositivos de red construyeran décadas de supuestos alrededor de su comportamiento.
QUIC utiliza UDP como una capa suficientemente simple y desplegada sobre la que construir un transporte moderno en los endpoints.
A cambio tiene que asumir trabajo que TCP recibe prácticamente resuelto por kernels y NIC después de décadas de ingeniería.
Por eso proyectos como UDP GSO son importantes. QUIC ganó libertad de evolución, pero ahora necesita construir parte de la maquinaria de rendimiento que TCP ya tenía.
Ese intercambio entre flexibilidad en userspace y eficiencia acumulada en kernel es bastante más interesante que decir simplemente que HTTP/3 eligió UDP porque era más rápido.
Preguntas frecuentes
¿Por qué QUIC utiliza UDP en lugar de TCP?
UDP proporciona una base ampliamente desplegada sobre la que QUIC puede implementar su propia lógica de transporte sin depender de modificar TCP en los sistemas operativos y dispositivos intermedios. La RFC 9000 indica expresamente que QUIC utiliza datagramas UDP para facilitar su despliegue en sistemas y redes existentes.
¿QUIC es más rápido porque UDP es más rápido?
No necesariamente. QUIC debe proporcionar por sí mismo funciones como fiabilidad, recuperación de pérdidas, control de congestión y cifrado. Sus ventajas de rendimiento proceden de su diseño completo, no simplemente de utilizar UDP.
¿QUIC funciona completamente en userspace?
No. Muchas implementaciones sitúan gran parte de la lógica QUIC en userspace, pero los datagramas UDP siguen atravesando el stack IP/UDP del kernel y utilizando la interfaz de red. Además, mecanismos como UDP GSO permiten descargar determinadas operaciones nuevamente hacia el kernel o el hardware.
¿Cuál es la relación entre HTTP/3 y QUIC?
HTTP/3 utiliza QUIC como protocolo de transporte. QUIC proporciona conexiones seguras, streams multiplexados, control de flujo, recuperación ante pérdidas y control de congestión, mientras HTTP/3 define sobre esa base el funcionamiento del protocolo HTTP.
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 información de partida.
