BLOG | OFICINA DEL CTO

QUIC se comerá internet

Miniatura F5
F5
Publicado el 22 de febrero de 2021


QUIC (no es un acrónimo) es una tecnología única, pero es mejor considerarlo como un nuevo protocolo de transporte que resuelve muchos problemas de larga data en Internet y captura la mayor parte del valor proporcionado por TCP, TLS, SCTP, IPSec y HTTP/2. Hay una nueva versión de HTTP llamada HTTP/3 que está diseñada para funcionar con 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 se inició un proceso de estandarización del IETF. Después de mucha evolución y recopilación de datos, esto dará como resultado el primer lote de RFC a principios de 2021. Varias empresas importantes de Internet, incluida 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 realizaba mediante HTTP/3 y QUIC.

Estos primeros despliegues, y el fervor por nuevos estándares además de QUIC en el IETF, indican que este se convertirá en un sustrato importante, y posiblemente dominante, para aplicações de vanguardia en Internet.

Descripción técnica: ¿Por qué QUIC?

Capas rápidas
Figura 1. QUIC aprovecha las capacidades de muchos protocolos heredados.

La figura 1 da al lector una idea de lo que hace QUIC. Sin embargo, esta descomposición funcional no aclara por qué los primeros usuarios de la industria están migrando a QUIC:

  1. Menor latencia. Las transferencias de datos tipo web están dominadas por la latencia de tres capas de protocolos de enlace: una para TCP, al menos una para TLS y una para la solicitud/respuesta HTTP. Los recientes avances en TCP/TLS pueden, en principio, reducir esto a un solo viaje de ida y vuelta, aunque esto rara vez funciona en la práctica. QUIC reducirá esto a un solo viaje de ida y vuelta, o como máximo a dos.

  2. Arroyos. Al igual que HTTP/2, QUIC proporciona a la aplicação múltiples flujos de bytes para aumentar la independencia de datos conceptualmente distintos entregados a través de la misma conexión. Hacerlo en el transporte sólo aumenta esta independencia. Las transmisiones se adaptan naturalmente a las necesidades de entrega de video en streaming y los principales proveedores de contenido de Internet están en camino de entregar transmisión a través de QUIC.

  3. Mejor respuesta ante pérdidas. El diseño de QUIC mejora la capacidad de TCP para detectar y recuperarse de pérdidas de paquetes. Además, al presentar secuencias multiplexadas en lugar de una única secuencia de bytes en orden, la pérdida de un paquete que contiene un objeto no necesariamente retrasa la entrega de un objeto diferente.

  4. Alojamiento múltiple. Al igual que MPTCP y SCTP, las conexiones QUIC se pueden asociar con múltiples direcciones IP para cada punto final. A diferencia de esos protocolos, QUIC tiene buenas posibilidades de triunfar en una Internet que descarta números de protocolo y opciones de encabezado TCP desconocidos.

  5. Seguridad y privacidad. QUIC aplica el cifrado en la capa de transporte, en lugar de por encima de ella. Toda la carga útil UDP está autenticada, lo que evita cualquier modificación transparente por parte de intermediarios, y casi toda la información de transporte está cifrada. Las ramificaciones de esto constituyen un libro blanco en sí mismo. Basta decir que esto mejora sustancialmente las propiedades de privacidad y elimina virtualmente la superficie de ataque que proporciona TCP. A diferencia de IPSec, esto se está ejecutando hoy en día a escala web. También conduce a:

  6. Extensibilidad. Es difícil cambiar TCP porque sus creadores dejaron un espacio de extensión limitado y porque los middleboxes refuerzan el antiguo comportamiento de TCP. QUIC combina el control de versiones explícito con la opacidad de los middleboxes para permitir una mayor innovación en el transporte. Esto permitirá brindar soporte para futuros casos de uso y eventualmente mejorar la capacidad de transporte masivo en comparación con TCP.

Hay dos razones, además de la inercia, por las que algunas aplicações podrían no migrar a QUIC:

  • Complejidad: las aplicações que solo necesitan un único flujo de bytes y no les importa el cifrado no necesitan la carga de trabajo adicional asociada con estas funciones.

  • Cajas intermedias: Un porcentaje no despreciable de rutas de Internet no admiten UDP. El protocolo HTTP/3 se ha diseñado con TCP como alternativa para estas rutas, pero en última instancia el impacto en el rendimiento de los principales sitios web (Google, Facebook, etc.) probablemente dejará obsoletos los dispositivos responsables, excepto cuando los estados nacionales que deseen vigilancia exijan lo contrario.

Se está comiendo Internet

Google Chrome, los clientes de aplicaciones de Google y la aplicación de Facebook ya admiten HTTP/3. Las implementaciones de Safari, Edge y Firefox 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 enviado o están cerca de hacerlo. Recientemente, un importante proveedor de servicios de internet europeo informó que el 20 % de sus paquetes eran QUIC . Aproximadamente el 5 % de los sitios web utilizaban HTTP/3 en febrero de 2021, pero prevemos que esta cifra aumentará una vez que se publique la RFC.

Además, hay mucho trabajo en las organizaciones de normalización para llevar QUIC más allá del caso de uso HTTP. Los borradores de estándares del IETF proponen DNS, Websockets, SIP y túneles TCP y UDP sobre QUIC. QUIC llegó un poco tarde para incorporarse plenamente a las arquitecturas 5G, pero su interés y aplicabilidad para los proveedores de servicios son evidentes. Finalmente, las API superiores para HTTP/2 y HTTP/3 son bastante similares, por lo que cualquier protocolo o aplicação que se ejecute sobre HTTP/2 se puede trasladar fácilmente para ejecutarse sobre HTTP/3 y QUIC en lugar de TCP.

Amenazas y oportunidades

QUIC y HTTP/3 darán forma a una variedad de mercados . Los sitios web y aplicações de alto rendimiento tienen un fuerte incentivo para cambiar a HTTP/3 y QUIC una vez que el ecosistema madure 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 necesitan una reevaluación fundamental en una Internet denominada QUIC. La inspección de paquetes es mucho más difícil sin acceso a las claves de sesión TLS, lo que normalmente solo es posible con la posesión de la clave privada del dominio. Esto aumenta el valor de una solución de seguridad integrada con un proxy a nivel de aplicación, en lugar de una serie de dispositivos de función única.

Además, la defensa tradicional contra DDoS necesita una puesta a punto. No sólo es más difícil la identificación e inspección de paquetes, sino que las cookies de sincronización TCP han sido reemplazadas por “paquetes de reintento”, que los intermediarios no pueden falsificar fácilmente. Hay formas estándar de coordinación que permiten a los servidores descargar la generación y validación de paquetes de reintento, pero nuevamente, eso requiere un esfuerzo de desarrollo.

El equilibrio de carga de capa 4 tradicional interrumpirá la migración de direcciones QUIC, ya que no puede asociar un flujo que cambia su dirección o puertos a sí mismo y luego enrutarlo al mismo servidor. Nuevamente, existen normas para coordinar y superar este problema, pero se requiere inversión.

El grupo de trabajo MASQUE del IETF está trabajando en la tunelización de tráfico generalizada sobre QUIC, que podría ser la base de los esquemas VPN de próxima generación . Las propiedades de QUIC son mucho mejores para multiplexar flujos arbitrarios que TLS sobre TCP. Estos túneles también pueden reemplazar los túneles IPSec con criptografía a escala web, mejorando algunos casos de uso de proveedores de servicios e incluso proporcionando una manera de optimizar las conexiones QUIC para tipos de enlaces móviles con el consentimiento explícito del cliente.

QUIC requerirá nuevas herramientas de medición y análisis de red. Los sistemas que podrían medir la latencia y la pérdida de TCP no pueden utilizar estas señales, pero hay una señal de latencia explícita en la red y es posible que haya otras señales en camino. Con más información de transporte oculta detrás del cifrado, las capturas de paquetes son menos útiles. Sin embargo, existe un formato de registro estándar emergente que siguen muchas implementaciones de QUIC y que las personas están desarrollando herramientas de análisis para aprovechar.

F5 sigue de cerca los acontecimientos

El personal de F5 ha estado monitoreando los esfuerzos de normalización en el IETF durante años y contribuyendo donde creemos que ayudará a nuestros clientes. BIG-IP ha estado rastreando borradores de versiones de QUIC y HTTP/3 desde el principio, incluidas las versiones públicas desde TMOS v15.1.0.1. NGINX tiene una versión alfa HTTP/3 y la fusionará con la línea principal en breve.

Seguiremos observando las tendencias en esta área y crearemos productos nuevos y emocionantes que reflejen las nuevas capacidades que ofrecen estos protocolos.

CONCLUSIÓN

QUIC tiene un amplio respaldo de la industria y el potencial de ser la base de la mayoría de las aplicações que brindan valor comercial a través de Internet. Cualquiera que ofrezca aplicações a través de Internet debería comenzar a pensar en cómo deberían cambiar sus operaciones para reflejar las nuevas amenazas y oportunidades que traen estos protocolos.