¿Es QUIC la capa de transporte que las aplicaciones en tiempo real llevaban esperando?

Si alguna vez has construido aplicaciones en tiempo real para la web, seguramente te hayas topado con la misma verdad incómoda: el Internet stack no se diseñó realmente pensando en este tipo de aplicaciones.

La usamos para videoconferencia, colaboración en directo, cloud gaming, telemetría, feeds de datos de mercado, escritorios remotos y un largo etcétera de aplicaciones sensibles a la latencia. Sin embargo, los protocolos que transportan la mayor parte de ese tráfico se diseñaron hace décadas, para un mundo en el que la fiabilidad importaba más que la inmediatez.

TCP: fiable, pero rígido

TCP ha sido uno de los protocolos más exitosos jamás creados y sigue siendo la base de una enorme parte del tráfico de Internet. El problema para el tiempo real es que TCP hace que cada byte debe entregarse de forma fiable y en orden. Si se pierde un paquete, todo lo que va detrás tiene que esperar. Para cargar una página web, o cualquier otro contenido que no sea en tiempo real, eso es exactamente lo que se quiere. Para una aplicación basada en tiempo real en la que los datos quedan obsoletos casi al instante, puede convertirse en una fuente importante de latencia.

UDP: rápido, pero básico

Este empeño excesivo en la fiabilidad es una de las razones por las que el desarrollo de aplicaciones "real-time" se decantó por UDP hace ya tiempo. En una llamada de voz o vídeo, un paquete que llega con medio segundo de retraso suele ser inútil. El usuario prefiere perder un frame o sufrir un pequeño corte de audio antes que esperar a recibir información obsoleta. UDP asume ese modelo manteniendo la capa de transporte simple y evitando requisitos de retransmisión, lo que permite a las aplicaciones priorizar la inmediatez sobre la entrega perfecta.

Por supuesto, esa simplicidad tiene un coste. En cuanto decides construir sobre UDP, descubres rápidamente que todas las capacidades que TCP daba gratis siguen teniendo que existir en algún sitio. Fiabilidad, control de congestión, cifrado, control de flujo, gestión de conexiones... ninguno de esos problemas desaparece.

WebRTC: la solución, a cambio de complejidad

Hemos dedicado suficientes años a trabajar con WebRTC como para saber exactamente a qué nos referimos.

WebRTC hace posible la comunicación en tiempo real entre navegadores y dispositivos móviles. Pero cualquiera que haya llevado un sistema así a producción sabe también cuánta maquinaria se esconde bajo la superficie. Con los años, el ecosistema ha ido acumulando una colección considerable de tecnologías pensadas para hacer que UDP sirva para la comunicación en tiempo real a gran escala. Y si alguna vez has pasado horas persiguiendo problemas de conectividad, comparando candidatos ICE, inspeccionando respuestas STUN, o tratando de entender por qué dos extremos pueden comunicarse con todo el mundo menos entre sí, sabes que la "comunicación en tiempo real" a menudo se convierte en "depuración en tiempo real".

La industria se encuentra, por tanto, en una posición interesante: TCP es fiable pero a veces demasiado rígido, UDP es flexible pero deja demasiada responsabilidad en manos de la aplicación, y WebRTC resuelve muchos de esos problemas, pero a costa de una complejidad considerable.

Aparece QUIC

Aquí es donde QUIC podría entrar en escena.

En lugar de obligar a las aplicaciones a elegir entre TCP y una colección de piezas construidas sobre UDP, QUIC intenta ofrecer una capa de transporte moderna que combina los puntos fuertes de ambos enfoques. Funciona sobre UDP, pero incluye funcionalidades que antes los desarrolladores tenían que conseguir por otro lado: cifrado integrado, multiplexación de streams, control de congestión moderno, migración de conexión, y una semántica de transporte pensada para el Internet de hoy y no para el de hace varias décadas.

Puede que lo más importante sea que QUIC elimina una de las mayores frustraciones heredadas de TCP: varios streams pueden convivir dentro de la misma conexión sin que un paquete perdido en uno de ellos bloquee el avance de los demás. Ese cambio aparentemente sencillo resuelve un problema con el que los ingenieros de red llevan años lidiando.

Nuestra opinión: qué viene después

Lo que hace a QUIC especialmente interesante es la posibilidad de que se convierta en la base de la próxima generación de transportes para aplicaciones en tiempo real. Tecnologías como WebTransport ya están explorando esa dirección, exponiendo capacidades que permiten a las aplicaciones aprovechar de forma mucho más directa el modelo de transporte de QUIC. Aunque el ecosistema todavía está evolucionando, no cuesta imaginar un futuro en el que los desarrolladores recurran a transportes basados en QUIC en lugar de recurrir automáticamente a TCP o a WebRTC.

Que QUIC llegue a convertirse en un sucesor real de WebRTC para muchos casos de uso está por ver, pero desde luego seguiremos de cerca su evolución y la adopción que haga de él la industria.