QUIC (no es un acrónimo) es algo único, pero la mejor forma de entenderlo es como un nuevo protocolo de transporte que resuelve muchos problemas históricos de Internet y reúne la mayoría de las ventajas que ofrecen TCP, TLS, SCTP, IPSec y HTTP/2. Existe una nueva versión de HTTP, denominada HTTP/3, diseñada para funcionar sobre UDP/QUIC en lugar de TCP/TLS.
Google implementó una versión temprana de HTTP sobre QUIC en sus navegadores y servidores web ya en 2014. En 2016 comenzó un proceso de estandarización del IETF. Tras una larga evolución y recopilación de datos, este proceso dará lugar al primer conjunto de RFC a principios de 2021. Varias grandes empresas de Internet, entre ellas F5, han lanzado productos que utilizan QUIC o han implementado QUIC en su infraestructura. En octubre de 2020, el 75 % del tráfico de Facebook se transmitía mediante HTTP/3 y QUIC.
Estos primeros despliegues y el entusiasmo por desarrollar nuevos estándares sobre QUIC en el IETF indican que esta tecnología se convertirá en una base importante, y posiblemente dominante, para las aplicaciones de vanguardia en Internet.
Descripción técnica: ¿por qué QUIC?
La figura 1 permite al lector hacerse una idea de lo que hace QUIC. Sin embargo, esta descomposición funcional no aclara por qué las empresas pioneras del sector están adoptando QUIC:
- Menor latencia. En las transferencias de datos similares a las de la web, la latencia viene determinada principalmente por tres capas de negociación: una para TCP, al menos una para TLS y otra para la solicitud/respuesta HTTP. En principio, los avances recientes en TCP/TLS permiten reducirlas a un solo viaje de ida y vuelta, aunque esto rara vez funciona en la práctica. QUIC las reducirá a un solo viaje de ida y vuelta y, como máximo, a dos.
- Flujos. Al igual que HTTP/2, QUIC proporciona a la aplicación varios flujos de bytes para aumentar la independencia de los datos conceptualmente distintos que se transmiten a través de una misma conexión. Implementarlos en la capa de transporte aumenta aún más esta independencia. Los flujos se adaptan de forma natural a las necesidades de la transmisión de vídeo, y los principales proveedores de contenidos de Internet están avanzando a buen ritmo en la distribución de contenidos en streaming mediante QUIC.
- Mejor respuesta ante pérdidas. El diseño de QUIC mejora la capacidad de TCP para detectar las pérdidas de paquetes y recuperarse de ellas. Además, al ofrecer flujos multiplexados en lugar de un único flujo de bytes ordenado, la pérdida de un paquete que contiene un objeto no tiene por qué retrasar la entrega de otro objeto.
- Multihoming. Al igual que ocurre con MPTCP y SCTP, las conexiones QUIC pueden asociarse a varias direcciones IP para cada extremo. A diferencia de esos protocolos, QUIC tiene muchas posibilidades de atravesar una red de Internet que descarta los números de protocolo desconocidos y las opciones de cabecera TCP.
- Seguridad y privacidad. QUIC aplica el cifrado en la capa de transporte, en lugar de hacerlo por encima de ella. Se autentica toda la carga útil UDP, lo que impide cualquier modificación transparente por parte de intermediarios, y se cifra casi toda la información de transporte. Las implicaciones de esto darían para un libro blanco. Baste decir que mejora sustancialmente las garantías de privacidad y elimina prácticamente la superficie de ataque que ofrece TCP. A diferencia de IPSec, esto ya funciona a escala web. También da lugar a:
- Extensibilidad. TCP es difícil de modificar porque sus creadores dejaron un espacio limitado para extensiones y porque los dispositivos intermedios imponen el comportamiento antiguo de TCP. QUIC combina un control de versiones explícito con la opacidad frente a los dispositivos intermedios para permitir una mayor innovación en el transporte. Esto permitirá admitir futuros casos de uso y, con el tiempo, mejorar la capacidad de transporte masivo en comparación con TCP.
Hay dos razones, además de la inercia, por las que algunas aplicaciones podrían no migrar a QUIC:
- Complejidad: las aplicaciones que solo necesitan un único flujo de bytes y no requieren cifrado no necesitan la carga de trabajo adicional asociada a estas funciones.
- Dispositivos intermedios: Un porcentaje nada desdeñable de las rutas de Internet no admite UDP. HTTP/3 se ha diseñado con la posibilidad de recurrir a TCP para estas rutas, pero, en última instancia, es probable que el impacto en el rendimiento de los principales sitios web (Google, Facebook, etc.) deje obsoletos a los dispositivos responsables, salvo cuando los Estados que desean ejercer vigilancia impongan lo contrario.
Se está comiendo Internet
Google Chrome, los clientes de aplicaciones de Google y la aplicación de Facebook ya son compatibles con HTTP/3. Las implementaciones de Safari, Edge y Firefox también lo admiten, pero (por ahora) está desactivado de forma predeterminada.
En el lado del servidor, las implementaciones y/o despliegues de Google, Microsoft, Facebook, Apple, Cloudflare, LiteSpeed, F5 BIG-IP, NGINX, Fastly y Akamai ya se han lanzado o están a punto de hacerlo. Recientemente, un importante proveedor europeo de servicios de Internet informó de que el 20 % de sus paquetes eran QUIC. En febrero de 2021, alrededor del 5 % de los sitios web utilizaban HTTP/3, pero esperamos que esta cifra aumente una vez que se publique el RFC.
Además, las organizaciones de normalización están trabajando intensamente para ampliar el uso de QUIC más allá de HTTP. Los borradores de estándares del IETF proponen utilizar DNS, WebSockets, SIP y túneles tanto TCP como UDP sobre QUIC. QUIC llegó un poco tarde para integrarse plenamente en las arquitecturas 5G, pero su interés y aplicabilidad para los proveedores de servicios son evidentes. Por último, las API de nivel superior de HTTP/2 y HTTP/3 son bastante similares, por lo que cualquier protocolo o aplicación que funcione sobre HTTP/2 puede adaptarse fácilmente para ejecutarse sobre HTTP/3 y QUIC en lugar de TCP.
Amenazas y oportunidades
QUIC y HTTP/3 transformarán diversos mercados. Los sitios web y las aplicaciones de alto rendimiento tendrán importantes motivos para pasarse a HTTP/3 y QUIC una vez que el ecosistema haya madurado por completo, y esperamos que nuestros clientes demanden compatibilidad con HTTP/3 a un ritmo similar al de su implementación de HTTP/2.
Los productos de seguridad requieren una reevaluación profunda en una Internet dominada por QUIC. La inspección de paquetes resulta mucho más difícil sin acceso a las claves de sesión TLS, algo que normalmente solo es posible si se dispone de la clave privada del dominio. Esto aumenta el valor de una solución de seguridad integrada con un proxy de nivel de aplicación, frente a una serie de dispositivos con una única función.
Además, la defensa tradicional contra ataques DDoS necesita una puesta a punto. No solo resulta más difícil identificar e inspeccionar los paquetes, sino que las cookies SYN de TCP se han sustituido por «paquetes de reintento», que los intermediarios no pueden falsificar fácilmente. Existen mecanismos estándar de coordinación que permiten a los servidores delegar la generación y validación de paquetes de reintento, pero, una vez más, esto requiere trabajo de desarrollo.
El balanceo de carga tradicional de capa 4 impedirá la migración de direcciones de QUIC, ya que no puede reconocer como propio un flujo que cambia de dirección o de puerto y, por tanto, dirigirlo al mismo servidor. También en este caso existen estándares para coordinarse y resolver este problema, pero requieren inversión.
El grupo de trabajo MASQUE del IETF está trabajando en la tunelización generalizada del tráfico a través de QUIC, que podría servir de base para esquemas de VPN de próxima generación. Las propiedades de QUIC son mucho más adecuadas para multiplexar flujos arbitrarios que las de TLS sobre TCP. Estos túneles también pueden sustituir a los túneles IPSec mediante criptografía a escala web, mejorando algunos casos de uso de los proveedores de servicios, e incluso ofrecer una forma de optimizar las conexiones QUIC para distintos tipos de enlaces móviles con el consentimiento explícito del cliente.
QUIC requerirá nuevas herramientas de medición y análisis de redes. Los sistemas que podían medir la latencia y la pérdida de paquetes de TCP no pueden utilizar estas señales, pero existe una señal explícita de latencia para la red, y puede que haya más señales en camino. Al quedar más información de transporte oculta mediante el cifrado, las capturas de paquetes resultan menos útiles. Sin embargo, existe un formato estándar de registro emergente que siguen muchas implementaciones de QUIC y que se está aprovechando para desarrollar herramientas de análisis.
F5 sigue de cerca los avances
El personal de F5 lleva años siguiendo las iniciativas de estandarización del IETF y contribuyendo cuando considera que puede ser útil para nuestros clientes. BIG-IP ha seguido las versiones preliminares de QUIC y HTTP/3 desde el principio, incluidas las versiones públicas desde TMOS v15.1.0.1. NGINX dispone de una versión alfa de HTTP/3, que pronto se integrará en la rama principal.
Seguiremos de cerca las tendencias en este ámbito y desarrollaremos productos nuevos e innovadores que aprovechen las nuevas funcionalidades que ofrecen estos protocolos.
Conclusión
QUIC cuenta con un amplio respaldo del sector y tiene el potencial de convertirse en la base de la mayoría de las aplicaciones que aportan valor empresarial a través de Internet. Cualquier organización que ofrezca aplicaciones a través de Internet debería empezar a plantearse cómo adaptar sus operaciones a las nuevas amenazas y oportunidades que plantean estos protocolos.
Sobre el autor
Artículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.