TCP estaba demasiado roto para arreglarlo, así que Internet construyó un nuevo protocolo sobre UDP

TCP ha sido la capa de transporte de Internet desde 1974. Cada página web que cargas, cada petición de API que hace tu aplicación, cada correo electrónico que envías — durante cincuenta años, casi todo ha viajado sobre TCP. El protocolo es fiable, probado en batalla y está desplegado en todos los dispositivos conectados a la red del planeta. También es cada vez más un cuello de botella para la forma en que la web moderna funciona realmente, y arreglarlo resultó ser políticamente imposible. Así que la industria construyó algo nuevo sobre UDP en su lugar.

Ese algo nuevo es QUIC, estandarizado por IETF en 2021 como RFC 9000. HTTP/3, la versión más reciente del protocolo que impulsa la web, funciona sobre QUIC. Cloudflare ha servido HTTP/3 a más del 40% de su tráfico. Google ha desplegado QUIC en sus propios servicios desde 2013. El protocolo que se suponía que era un experimento ahora transporta una parte sustancial de Internet.

Qué tenía de malo TCP

El diseño fundamental de TCP fue construido para un mundo de conexiones cableadas fijas y fiables. El protocolo asume que si un paquete se pierde, la red está congestionada y debe ralentizarse. Esto era razonable en 1974. En 2026, con usuarios móviles cambiando constantemente entre Wi-Fi y celular, los paquetes se pierden por razones que no tienen nada que ver con la congestión — interferencia de señal, traspasos entre torres, breves lagunas de cobertura. TCP no puede distinguir entre "la red está congestionada" y "el usuario acaba de entrar a un ascensor", y se ralentiza en ambos casos.

El problema estructural mayor es el bloqueo de cabeza de línea (head-of-line blocking). Una única conexión TCP es un flujo ordenado de datos. Si el paquete 7 se pierde, los paquetes 8 al 100 esperan aunque hayan llegado bien. HTTP/2 abordó una versión de este problema multiplexando múltiples peticiones sobre una única conexión TCP — pero esto en realidad empeoró el bloqueo de cabeza de línea en la capa TCP, no lo mejoró. Un único paquete perdido ahora puede detener todos los flujos multiplexados en la conexión simultáneamente.

También estaba la sobrecarga de establecimiento de conexión. TCP requiere un triple saludo (three-way handshake) antes de que los datos puedan fluir. TLS añade otros 1-2 viajes de ida y vuelta para la negociación criptográfica. Cargar un recurso de un nuevo servidor requiere 2-3 viajes de ida y vuelta completos antes de que llegue el primer byte de contenido. Para un usuario en Tokio conectándose a un servidor en Virginia, cada viaje de ida y vuelta toma aproximadamente 170 milisegundos. Multiplica eso por el número de servidores distintos con los que habla una página web moderna, y la sobrecarga de latencia es significativa.

Por qué lo construyeron sobre UDP

La pregunta lógica es: ¿por qué no arreglar TCP? La respuesta es que TCP está implementado en el núcleo de cada sistema operativo, cada router, cada firewall, cada balanceador de carga y cada middlebox en Internet. Cambiar el comportamiento de TCP requeriría actualizar miles de millones de dispositivos. Algunos de esos dispositivos tienen décadas de antigüedad y nunca serán actualizados. Los middleboxes de red — los dispositivos que inspeccionan, enrutan y filtran el tráfico — asumen el comportamiento de TCP y fallan de formas impredecibles cuando se modifica TCP. IETF probó varias extensiones de TCP a lo largo de los años y descubrió que simplemente eran bloqueadas o eliminadas por los middleboxes en el campo.

UDP, por el contrario, es esencialmente un lienzo en blanco. Es un protocolo de disparar y olvidar sin estado de conexión inherente, ordenamiento ni fiabilidad. Los middleboxes no manipulan UDP como lo hacen con TCP porque no hay nada que manipular. Construir QUIC sobre UDP significa que QUIC puede implementar su propia gestión de conexión, fiabilidad, ordenamiento y control de congestión en espacio de usuario — donde puede ser actualizado sin cambios en el núcleo — mientras sigue pasando por la infraestructura de Internet existente sin cambios.

Qué cambia realmente QUIC

La mejora más inmediatamente notable es el tiempo de establecimiento de conexión. QUIC combina el saludo de transporte y el saludo criptográfico TLS 1.3 en un solo viaje de ida y vuelta. Para una primera conexión a un servidor, QUIC requiere un viaje de ida y vuelta antes de que los datos puedan fluir, frente a dos o tres para TCP+TLS. Para un usuario que regresa y que se ha conectado al servidor antes, QUIC admite la reanudación 0-RTT — el cliente puede enviar datos de la aplicación en el primer paquete, con cero viajes de ida y vuelta. La mejora de rendimiento es más pronunciada en redes móviles donde la latencia es alta.

La migración de conexión (Connection migration) resuelve directamente el problema de la transición móvil. Una conexión QUIC se identifica por un ID de conexión elegido por el extremo, no por la cuarteta (IP origen, puerto origen, IP destino, puerto destino) que identifica una conexión TCP. Cuando un teléfono pasa de Wi-Fi a celular y obtiene una nueva dirección IP, todas sus conexiones TCP se rompen y necesitan ser reestablecidas. Las conexiones QUIC sobreviven al cambio de IP — el cliente anuncia su nueva dirección y la conexión continúa sin interrupción.

Flujos multiplexados sin bloqueo de cabeza de línea es la solución estructural que HTTP/2 necesitaba pero no pudo lograr sobre TCP. QUIC implementa múltiples flujos independientes dentro de una conexión; un paquete perdido para el flujo A no bloquea los flujos B, C y D. Cada flujo tiene su propia garantía de orden, por lo que la pérdida en un flujo solo detiene ese flujo.

La realidad del despliegue

La adopción ha sido más rápida que la mayoría de las transiciones de protocolo en la historia de Internet, que aún se "miden en años". Google desplegó QUIC en Chrome en 2015, inicialmente solo para sus propios servicios. IETF estandarizó QUIC y HTTP/3 en 2021. Para 2023, los datos de W3Techs mostraban que HTTP/3 era compatible con aproximadamente el 30% de los sitios web. Cloudflare informa que QUIC transporta aproximadamente el 35-40% de su tráfico, y esa fracción ha crecido de manera constante año tras año.

La adopción en el lado del servidor es fuerte entre las principales CDN (Cloudflare, Fastly, Akamai) y proveedores de nube (AWS CloudFront, Google Cloud). La mayoría de los frameworks web modernos y balanceadores de carga admiten HTTP/3. El lado del cliente está cubierto: Chrome, Firefox, Safari y Edge admiten HTTP/3 de forma predeterminada, al igual que los navegadores móviles.

No todas las conexiones QUIC funcionan mejor que TCP. En conexiones de banda ancha fija de alta calidad, la diferencia es mínima. La implementación en espacio de usuario de QUIC significa que no se beneficia de las optimizaciones de CPU que TCP ha acumulado durante décadas en el kernel — la sobrecarga de procesamiento por paquete es mayor, lo que importa en conexiones de alto rendimiento. Para transferencias de archivos masivos en enlaces rápidos y fiables, TCP sigue siendo competitivo.

Las ganancias son más pronunciadas en tres escenarios: redes móviles de alta latencia, conexiones que sobreviven cambios de dirección IP y cargas de página que implican muchas solicitudes pequeñas a muchos servidores. La web en 2026 está fuertemente inclinada hacia estos tres escenarios, por lo que la migración tiene un impulso sostenido que las versiones anteriores de HTTP no lograron.

QUIC no soluciona todos los problemas del transporte de Internet — el control de congestión, el bufferbloat y la capacidad de la última milla siguen siendo limitaciones reales. Pero resuelve los problemas que eran solucionables sin reemplazar la infraestructura de red física. Es una mejora significativa, entregada a través de uno de los despliegues de protocolo más rápidos en la historia de IETF.