Por qué a Fastly le encantan QUIC y HTTP/3
En Fastly, somos muy selectivos y sometemos a un estudio profundo las áreas a las que van destinados nuestros recursos. Eso significa que nos preocupan más los tipos de proyectos que asumimos y las repercusiones que tienen que la cantidad de estos. Por ello nos entusiasma haberle dedicado tanto esfuerzo a QUIC, nuevo protocolo de transporte para Internet que es más sensible, seguro y flexible que el que utiliza Internet en la actualidad.
En el proceso de normalización de QUIC, que se está llevando a cabo en el seno del Grupo Especial sobre Ingeniería de Internet (IETF, por sus siglas en inglés), participa nuestro equipo de ingeniería. Lo hace a través de una de las presidencias del grupo de trabajo sobre QUIC del IETF y editor del documento esencial. Asimismo, estamos trabajando en quicly, nuestra propia implementación de este nuevo protocolo. Estudiemos qué es QUIC con más detalle y por qué nos llena tanto de entusiasmo asignar nuestros recursos a este protocolo.
Definición de QUIC (y de HTTP/3)
QUIC (denominación que no obedece a ningún acrónimo) es un protocolo de transporte por Internet de nueva creación que sustituye al medio más utilizado hoy día, TCP. TCP permite a clientes y servidores comunicarse con fiabilidad ante la pérdida de paquetes, compartir recursos con elegancia entre aplicaciones y garantizar que los datos se entreguen en el mismo orden con que fueron enviados.
El TCP moderno es producto de décadas de experimentación, experiencia y ampliaciones del protocolo principal recogido en la norma RFC 793, cuya publicación se remonta a 1981. Cuando el grupo de trabajo sobre HTTP asumió en el año 2013 el cometido de producir HTTP/2, se centró fundamentalmente en optimizar el modo en que HTTP utiliza TCP. El objetivo del grupo era eliminar el bloqueo de cabeza de línea o bloqueo HOL en los casos en que una solicitud HTTP pendiente impide el uso de una conexión hasta que se reciba una respuesta. Para solventar este problema, HTTP/2 introducía la multiplexación de solicitudes, con lo que se posibilitaba el uso de una sola conexión TCP con mucha más eficacia.
Sin embargo, las labores destinadas a optimizar HTTP revelaron otro problema: el bloqueo HOL también está presente en TCP porque este protocolo entrega datos a la aplicación destinataria en orden. En caso de pérdida de un paquete, el emisor TCP retiene todos los paquetes recibidos de manera subsiguiente en esa conexión hasta que se reciba la retransmisión del paquete perdido. En consecuencia, la aplicación tendrá que esperar a que se reciba esta retransmisión, incluso si hubiera podido utilizar los paquetes recibidos posteriormente (como es el caso en un protocolo como HTTP/2, en el que se dan varias transferencias al mismo tiempo, pero solo se utiliza una conexión TCP).
El problema del bloqueo head-of-line en TCP se pone de manifiesto de varias maneras en HTTP/2. Aunque HTTP/2 tiene mejor rendimiento que HTTP/1 en la mayoría de situaciones, esto no es así cuando las conexiones son deficientes, por ejemplo, en una conexión con altas pérdidas o en una conexión con algo de pérdida y mucha latencia.
QUIC aborda este problema desplazando la capa de envíos de HTTP/2 a un transporte genérico, para evitar el bloqueo HOL tanto en las capas de aplicaciones como en las de transporte. Esto se consigue diseñando un nuevo conjunto de servicios como los de TCP sobre UDP. UDP no integra las garantías de entrega fiable y en orden, ni el control de congestión que ofrece TCP; QUIC las diseña en una nueva capa ubicada sobre ese otro protocolo.
Asimismo, QUIC incorpora un modelo de cifrado que reutiliza los mecanismos de TLS 1.3 para garantizar que las conexiones de las aplicaciones sean confidenciales, estén autenticadas y su integridad quede protegida. TLS es la misma tecnología que protege los datos del protocolo HTTPS, aunque en QUIC protege tanto los datos como el propio protocolo de transporte. Este enfoque dota a QUIC de mayor sensibilidad que TCP ya que le permite empezar la transferencia de datos con antelación.
El primer ámbito en el que aplicar este nuevo protocolo de transporte es HTTP/3. Se trata de la versión de HTTP que está concebida para aprovechar las características de QUIC. Lo que es más importante, HTTP/3 no cambia la semántica de HTTP (direcciones URL y definiciones de encabezados HTTP) con respecto a HTTP/2. Gracias al uso de QUIC, HTTP/3 debería abordar los problemas de rendimiento de HTTP/2 al tiempo que evita el requisito de cambiar el código de la aplicación (la entidad que utiliza HTTP). Esta es de por sí una mejora estimulante, ya que HTTP/3 es un sustituto directo de HTTP/2.
Pero esto es solo el aperitivo. ¿Qué otras emocionantes novedades aporta QUIC a la comunidad internauta?
Diseñado para la última milla
Los servicios web sensibles a la latencia están en expansión, lo cual genera unas exigencias sobre la infraestructura de servicio que no tienen precedentes. Al mismo tiempo, existe un volumen significativo de usuarios que utiliza redes con conexiones pésimas, un volumen que posiblemente se incremente a medida que crece el número de internautas en todo el mundo, a pesar de que la infraestructura web haya experimentado mejoras sustanciales a lo largo de los años.
QUIC está concebido para mejorar el rendimiento mediante la mitigación de problemas de última milla de pérdida y latencia, con lo cual se beneficia sobre todo a usuarios con conexiones pésimas y no tanto a quienes ya posean una conectividad adecuada. Si se cumple lo que este protocolo dice ofrecer, la mayoría de los sitios web y usuarios, especialmente los provenientes de partes del mundo con servicio escaso—ya sea en el despoblado interior de Australia, en la India rural o en las islas del Pacífico austral—, experimentarán mejoras de rendimiento. Creemos que el valor de QUIC tiene probabilidades de incrementarse a medida que la penetración de Internet crece en términos globales.
Los experimentos de Google con su versión patentada y prenormalizada de QUIC muestran mejoras notables respecto a estas mismas situaciones: redes con altos niveles de pérdida o latencia. En concreto, Google registró una reducción del 16,7 % en la latencia de búsqueda de extremo a extremo respecto de las conexiones de ordenadores de sobremesa con las tasas de latencia más altas, y una reducción del 14,3 % respecto de las conexiones de móviles con las tasas de latencia más elevadas. Si tenemos en cuenta que sus páginas de búsqueda figuran entre las URL más optimizadas, la mejora es impresionante. En cuanto al vídeo, registró una reducción del 8,7 % en la repetición del tiempo de carga respecto de las conexiones móviles más problemáticas. Estas ventajas se explican por diversas características de QUIC, como un protocolo de enlace optimizado para la latencia en internet y una recuperación ante pérdidas mejorada y, lo que es más importante, por la omisión de errores e ineficiencias de TCP y del ecosistema de la web que rodea a dicho protocolo.
Nuevo compromiso de agilidad
El protocolo de transporte que utilizamos debe adaptarse y evolucionar si ha de continuar desempeñando la función de aglutinante eficaz entre aplicaciones cada vez más exigentes y el caos subyacente de la Internet. Lograr este objetivo a día de hoy con TCP es difícil por dos motivos.
En primer lugar, TCP suele implementarse en el kernel del sistema operativo (SO) de clientes y de servidores, con lo que hacer cambios en TCP implica cambiar o actualizar el kernel. Los cambios en el kernel tienen repercusiones en todo el sistema, por lo que a menudo se implantan en los servidores con cautela y lentitud.
Los clientes —incluso los instalados en SO móviles con ciclos de actualización más rápidos— son problemáticos porque existe una proporción notable de la población de internautas que está atrasada varios años respecto de la última versión del SO/kernel y porque muchos usuarios en ningún caso actualizan sus SO. Como resultado, en la actualidad incluso cambios sencillos en el ámbito del transporte precisan de varios años para implementarse en Internet.
QUIC está mejor posicionado para evolucionar con rapidez porque está diseñado sobre UDP y lo habitual será que se ejecute en espacios de usuario, haciendo posible así la implantación de cambios rápidos en servidores y clientes.
En segundo lugar, el ecosistema web ya no permite cambios en TCP. En los últimos 20 años de crecimiento de Internet, hemos asistido a un asombroso aumento en el número de elementos de red ubicados en las rutas de acceso entre cualquier servidor y cualquier cliente, tales como dispositivos de "optimización" de TCP, que se dedican a inspeccionar o modificar el encabezado TCP. Estos elementos de red interpuestos, denominados "middleboxes" o "dispositivos intermedios", tienden a invalidar involuntariamente cambios en los encabezados TCP y en el comportamiento de este protocolo, incluso si el servidor y el cliente se muestran dispuestos a ello. Por lo tanto, el ecosistema web ha endurecido el protocolo TCP, lo cual quiere decir que ni siquiera resulta posible implementar cambios pequeños en TCP sin que ello comporte consecuencias no deseadas. TCP Fast Open es un ejemplo perfecto de una de esas modificaciones de TCP: ocho años después de que fuera propuesto por primera vez, sigue sin contar con una implantación amplia, principalmente debido a los dispositivos intermedios.
Esta es otra faceta en la que el diseño de QUIC brilla con luz propia. QUIC cifra y autentica con medios criptográficos tanto los datos de transporte como el propio protocolo, con lo que se impide a los dispositivos intermedios inspeccionar o modificar el encabezado de este y al mismo tiempo se asegura una larga vida para el protocolo. Además, QUIC integra el control de versiones (es cierto, TCP no incluye esta función), lo cual nos da la libertad para tener en cuenta cambios profundos y amplios según convenga en el futuro. El control de versiones también nos permite considerar versiones alternativas susceptibles de diseño, puesta a punto e implementación dentro de nuestros POPs, como ahora analizaremos.
Te presentamos puntos POP dotados de mayor inteligencia
Creemos que existen dos medios a través de los que QUIC puede mejorar la gestión y escalabilidad de las conexiones en el borde y, simultáneamente, gestionar el tráfico en el interior de puntos de presencia (POP o centros de datos) de Fastly.
En primer lugar, nos entusiasma experimentar con diversas modificaciones del transporte, incluidos el control de congestión y la recuperación ante pérdidas, para mejorar la latencia y eficacia del tráfico entre servidores en nuestros POPs. Al localizarse en el espacio de usuario, QUIC puede también integrarse mejor y con mayor profundidad con nuestra infraestructura de herramientas y de registros, facilitando la ejecución de experimentos y el aprendizaje a partir de estos.
En segundo lugar, QUIC aporta dosis significativas de flexibilidad segregando de la vista del destinatario la vista de tráfico del emisor. Sin entrar en detalle, la segregación de estos dos elementos significa, fundamentalmente, que podemos optimizar nuestros servicios sin exigir la operación de cambios en los destinatarios. Es decir, podemos dar forma al uso de QUIC de modo que se ajuste con eficacia a nuestra incomparable arquitectura de CDN y POP, sin exigir que se introduzcan cambios en los usuarios finales, lo cual se podría traducir en tasas aún menores de latencia para estos. ¡Estamos sondeando ideas en este ámbito y nos resulta estimulante el potencial que le vemos!
Como es natural, son muchos más los aspectos de QUIC que deberían interesar a las CDN y a otros operadores de servidores, sin importar la arquitectura que hayan adoptado: por ejemplo, cifra muchos más elementos del transporte, confiriendo así más seguridad a los usuarios; o activa un balanceo de carga sin estado, así como la movilidad de la conexión, permitiendo que un cliente se desplace a la perfección entre redes —p. ej., wifi y móviles— sin perder conexiones.
¿Qué es lo siguiente?
QUIC sigue inmerso en el proceso de normalización y, aunque actualmente hay más de 20 implementaciones de la versión que el IEFT ha desarrollado de este protocolo (incluida la nuestra), todas marchan a paso acelerado hacia la interoperabilidad y la funcionalidad íntegra de HTTP. Según las estimaciones del grupo de trabajo, los borradores esenciales estarán listos en sus versiones definitivas este año; según las nuestras, la versión que el IETF ha desarrollado de QUIC estará disponible en navegadores a finales de año.
Las ventajas de QUIC aún se deben probar para los diversos sitios web y casos de uso que son ajenos al conjunto restringido utilizado por Google. Tenemos la sospecha de que habrá un periodo prolongado en el que las implementaciones tanto de servidores como de navegadores van a precisar optimización, endurecimiento y experiencia operativa. Ya vemos la línea de meta, pero aún queda trabajo por hacer para cruzarla.
Y esto es más que suficiente. Pensamos que las ventajas que ello conlleva para Fastly —y para Internet en su conjunto— merecen el esfuerzo y la espera. A medida que la compatibilidad con HTTP/3 empieza a llegar a clientes disponibles para el público, deseamos profundamente colaborar con nuestros clientes para probar, implementar e innovar juntos en esta nueva y emocionante tecnología.
