Rendimiento y eficiencia: trabajar con HTTP/3

HTTP/3 está en el horizonte, pisándole los talones a HTTP/2, que podría decirse que todavía es muy joven. Dado que se necesitaron 16 años para pasar de HTTP/1.1 a HTTP/2, ¿alguien debería preocuparse realmente por HTTP/3?

La respuesta corta: sí, es importante, y debe estar al día. Es como HTTP/2 hizo cambios significativos desde HTTP/1.1 al cambiar de ASCII a binario. HTTP/3 nuevamente realiza cambios significativos, esta vez al cambiar el transporte subyacente de TCP a UDP.

Aunque HTTP/3 todavía está en la etapa de diseño y la especificación oficial es un borrador, ya se está implementando y es muy probable que encuentre una versión ejecutándose en su red hoy.

Pero hay algunos dilemas nuevos que plantea el funcionamiento de HTTP/3. Además, ¿cuál es el beneficio? ¿Y qué necesitan saber los ingenieros de redes, los administradores de sistemas y los desarrolladores?

El problema principal: rendimiento y eficiencia

Los desarrolladores de sitios y aplicaciones generalmente construyen con la intención de que sus creaciones se usen realmente. A veces, la base de audiencia es finita, pero a menudo la idea es obtener la mayor cantidad de usuarios posible. Naturalmente, cuanto más popular se vuelve un sitio web, más ingresos puede generar.

Un retraso de 100 milisegundos en el tiempo de carga del sitio web puede afectar las tasas de conversión en un 7 por ciento.

Informe de rendimiento minorista en línea de Akamai: los milisegundos son críticos (2017)

Dicho de otra manera, un sitio de comercio electrónico con ventas de $40,000 por día perdería un millón de dólares al año debido a ese retraso.

Tampoco es ningún secreto que el rendimiento de un sitio es absolutamente crítico para que un sitio se vuelva más popular. La investigación de compras en línea continúa encontrando vínculos entre mayores tasas de rebote y tiempos de carga más prolongados, y entre la lealtad del comprador y el rendimiento del sitio web durante la experiencia de compra.

La investigación también encontró que:

• El 47% de los consumidores esperan que una página web se cargue en 2 segundos o menos.
• El 40% de las personas abandona un sitio web que tarda más de 3 segundos en cargar.

Y ese era el estado de paciencia de los compradores en línea desde hace más de una década . Por lo tanto, el rendimiento es fundamental, y tanto HTTP/2 como HTTP/3 significan un mejor rendimiento del sitio web.

¿HTTP/2? …¿Qué es eso?

Una buena comprensión del protocolo HTTP/2 es crucial para comprender HTTP/3. En primer lugar, ¿por qué había necesidad de HTTP/2?

HTTP/2 comenzó como un proyecto de Google llamado SPDY, resultado de un estudio que informó que el mayor problema de rendimiento en la web era la latencia . El autor concluyó que “más ancho de banda no importa (mucho)”:

Si hacemos una analogía entre la plomería e Internet, podemos considerar que el ancho de banda de Internet es como el diámetro de la tubería de agua. Una tubería más grande transporta un mayor volumen de agua y, por lo tanto, puede entregar más agua entre dos puntos.

Al mismo tiempo, no importa cuán grande sea su tubería, si la tubería está vacía y desea llevar agua de un punto a otro, el agua demorará en viajar a través de la tubería. En la jerga de Internet, el tiempo que tarda el agua en viajar de un extremo de la tubería al otro y viceversa se denomina tiempo de ida y vuelta o RTT .

mike belshe

En el estudio, el objetivo era reducir el tiempo de carga de la página. Mostró que aumentar el ancho de banda ayuda inicialmente, ya que pasar de 1 Mbps a 2 Mbps reduce a la mitad el tiempo de carga de la página. Sin embargo, los beneficios se estabilizan muy rápidamente.

Por el contrario, la disminución de la latencia tiene un beneficio constante y logra los mejores resultados.

HTTP HOL: el problema de bloqueo de cabecera de línea

La causa principal de la latencia dentro del protocolo HTTP/1 es el problema de bloqueo del encabezado de línea. Las páginas web (casi siempre) requieren múltiples recursos: CSS, JavaScript, fuentes, imágenes, AJAX/XMR, etc. Esto significa que el navegador web necesita realizar múltiples solicitudes al servidor. Sin embargo, no se requieren todos los recursos para que la página sea útil.

Con HTTP/1.0, era necesario que el navegador completara completamente una solicitud, incluida la recepción completa de la respuesta, antes de iniciar la siguiente solicitud. Todo tenía que hacerse en secuencia. Cada solicitud bloquearía la línea de solicitudes, de ahí el nombre.

En un intento de compensar el problema de bloqueo de HOL, los navegadores web realizan múltiples conexiones simultáneas a un solo servidor. Pero han tenido que limitar arbitrariamente este comportamiento: los servidores, las estaciones de trabajo y las redes pueden sobrecargarse con demasiadas conexiones.

HTTP/1.1 introdujo varias mejoras para ayudar a abordar el problema. El principal es la canalización , que permite a los navegadores web iniciar nuevas solicitudes sin necesidad de esperar a que se completen las solicitudes anteriores. Esto mejoró significativamente los tiempos de carga en entornos de baja latencia.

Pero aún requiere que todas las respuestas lleguen secuencialmente en el orden en que se hicieron, por lo que el encabezado de la línea aún está bloqueado. Sorprendentemente, muchos servidores aún no aprovechan esta característica.

Curiosamente, HTTP/1.1 también introdujo keep-alive , lo que permitió a los navegadores evitar la sobrecarga de crear una nueva conexión TCP para cada solicitud HTTP. Este fue uno de los primeros intentos de resolver un problema de rendimiento derivado de TCP. Era tan ineficaz que la mayoría de los expertos en rendimiento lo desaconsejaban porque atascaba el servidor con demasiadas conexiones inactivas. Echaremos un vistazo más de cerca a TCP a continuación, así como también cómo HTTP/2 solucionó este problema.

Solución de bloqueo HTTP HOL de HTTP/2

HTTP/2 introdujo la multiplexación de solicitud-respuesta en una sola conexión. Un navegador no solo puede iniciar una nueva solicitud en cualquier momento, sino que las respuestas se pueden recibir en cualquier orden : el bloqueo se elimina por completo en el nivel de la aplicación.

Como resultado directo, esto significa que los servidores web compatibles con HTTP/2 pueden maximizar la eficiencia; hablaremos más adelante.

Aunque la multiplexación de solicitud-respuesta es la característica principal de HTTP/2, incluye varias otras características importantes. Los lectores pueden notar que todos están algo relacionados.

Trama binaria HTTP/2

HTTP/2 cambia el estándar del protocolo HTTP de un modelo de solicitud-respuesta ASCII legible por humanos ineficiente a un marco binario eficiente. Ya no es solo una solicitud y una respuesta:

Con HTTP/2, los navegadores se comunican con los servidores a través de flujos bidireccionales con múltiples mensajes, cada uno de los cuales consta de múltiples marcos.

HTTP/2 HPACK (Compresión de encabezado)

La nueva compresión de encabezado de HTTP/2, que usa el formato HPACK, ahorra una tonelada de ancho de banda para la mayoría de los sitios. Esto se debe a que la mayoría de los encabezados son los mismos para las solicitudes enviadas dentro de una conexión.

Cloudflare informa ahorros significativos de ancho de banda gracias solo a HPACK:

• 76 % de compresión para encabezados de entrada
• Reducción del 53 % en el tráfico de entrada total
• 69% de compresión para encabezados de salida
• Reducción del 1,4 % al 15 % en el tráfico de salida total

Por supuesto, usar menos ancho de banda generalmente significa un sitio web más rápido.

Priorización de transmisión HTTP/2 y empuje del servidor

Aquí es donde la multiplexación de HTTP/2 realmente permite que el servidor maximice la eficiencia. La multiplexación ayuda a servir recursos más rápidos (p. ej., JavaScript almacenado en memoria caché) antes que los más lentos (p. ej., imágenes grandes, JSON generado en base de datos, etc.). Pero también permite un aumento adicional del rendimiento a través de la priorización de flujo de HTTP/2.

La priorización de transmisiones ayuda a garantizar que los aspectos casi listos de una página se completen por completo sin tener que esperar a que finalicen otras solicitudes que consumen muchos recursos. Esto se logra a través de un árbol de dependencia ponderado. Este árbol se utiliza para informar al servidor a qué respuestas debería asignar la mayor cantidad de recursos del sistema.

Esto es particularmente importante para las aplicaciones web progresivas (PWA). Por ejemplo, digamos que una página tiene cuatro archivos JavaScript. Dos son para la funcionalidad de la página y dos para los anuncios. El peor de los casos es cargar la mitad del JS funcional y la mitad del JS publicitario y luego cargar imágenes grandes, antes de cargar cualquiera de los JS restantes. En ese caso, nada en la página funciona inicialmente, porque todo tiene que esperar al recurso más lento.

Con la priorización de secuencias, los navegadores web pueden indicar al servidor que envíe los dos archivos JS de la funcionalidad de la página antes de enviar cualquiera de los archivos JavaScript publicitarios. De esta forma, los usuarios no tienen que esperar a que los anuncios se carguen por completo antes de usar la funcionalidad de la página. Aunque el tiempo de carga general no ha mejorado, el rendimiento percibido ha aumentado significativamente. Desafortunadamente, este comportamiento dentro del navegador web sigue siendo principalmente una cuestión de algoritmos, en lugar de ser algo especificado por los desarrolladores web.

Del mismo modo, la función de inserción del servidor de HTTP/2 permite que el servidor envíe respuestas al navegador para solicitudes que aún no ha realizado. El servidor puede aprovechar las brechas en la transmisión, utilizando de manera eficiente el ancho de banda mediante la precarga en los recursos del navegador que el servidor sabe que solicitará pronto. Parte de la esperanza aquí es eliminar la práctica de la inserción de recursos, que simplemente infla los recursos y hace que tarden más en cargarse.

Desafortunadamente, ambas funciones necesitan una configuración cuidadosa por parte de los desarrolladores web para tener éxito. Simplemente habilitarlos no es suficiente.

HTTP/2 claramente trae muchas ventajas potenciales, algunas de ellas más baratas de aprovechar que otras. ¿Cómo les va en el mundo real?

Adopción de HTTP frente a HTTP/2

SPDY se creó en 2009. HTTP/2 se estandarizó en 2015. SPDY se convirtió en el nombre de una rama de desarrollo inestable del código, y HTTP/2 se convirtió en la versión final. El resultado es que SPDY se ha vuelto obsoleto y HTTP/2 es comúnmente el estándar que todos siguen.

Después de la estandarización, la adopción de HTTP/2 (o "h2") creció rápidamente a alrededor del 40 % de los 1000 sitios web principales. Esto fue impulsado principalmente por grandes proveedores de alojamiento y nube que implementaron soporte en nombre de sus clientes. Desafortunadamente, varios años después, la adopción de HTTP/2 se ha ralentizado y la mayoría de Internet todavía está en HTTP/1.

Falta de soporte del navegador para el modo de texto claro HTTP/2

Hubo muchas solicitudes de HTTP/2 para que el cifrado fuera una parte obligatoria del estándar. En cambio, el estándar definió los modos cifrado (h2) y de texto sin cifrar (h2c). Como tal, HTTP/2 podría reemplazar completamente a HTTP/1.

A pesar del estándar, todos los navegadores web actuales solo admiten HTTP/2 a través de conexiones cifradas e intencionalmente no implementan el modo de texto claro. En cambio, los navegadores confían en el modo de compatibilidad con versiones anteriores de HTTP/1 para acceder a servidores inseguros. Este es un resultado directo de un impulso ideológico para hacer que la web sea segura de forma predeterminada.

¿Por qué HTTP/3? ¿Y cómo es diferente?

Con el problema de bloqueo de cabecera de línea HTTP ahora solucionado por HTTP/2, los desarrolladores de protocolos han centrado su atención en el siguiente controlador de latencia más importante: el problema de bloqueo de cabecera de línea TCP .

Protocolo de control de transmisión (TCP)

Las redes IP (protocolo de Internet) se basan en la idea de que las computadoras se envían paquetes entre sí. Un paquete es solo datos con alguna información de direccionamiento adjunta en la parte superior.

Pero las aplicaciones generalmente necesitan manejar flujos de datos. Para lograr esta ilusión, el protocolo de control de transmisión (TCP) presenta a las aplicaciones una tubería a través de la cual puede fluir un flujo de datos. Al igual que con la mayoría de las tuberías, existe la garantía de que los datos saldrán de la tubería en el mismo orden en que ingresan, también conocido como "primero en entrar, primero en salir" (FIFO). Estas características han hecho que TCP sea muy útil y ampliamente adoptado.

Como parte de las garantías de entrega de datos que proporciona TCP, debe ser capaz de manejar una amplia variedad de situaciones. Uno de los problemas más complejos es cómo entregar todos los datos cuando una red está sobrecargada, sin empeorar la situación para todos. El algoritmo para esto se llama control de congestión y es una parte en constante evolución de las especificaciones de Internet. Sin un control de congestión suficiente, Internet se detiene.

En octubre del '86, Internet tuvo el primero de lo que se convirtió en una serie de 'colapsos de congestión'. Durante este período, el rendimiento de datos de LBL a UC Berkeley (sitios separados por 400 yardas y tres saltos IMP) se redujo de 32 Kbps a 40 bps.

V.Jacobson (1988)

Ahí es donde entra el problema de bloqueo de cabecera de línea de TCP.

Problema de bloqueo de TCP HOL

El control de congestión de TCP funciona mediante la implementación de mecanismos de retroceso y retransmisión de paquetes, que se utilizan cada vez que se detecta una pérdida de paquetes. El retroceso está destinado a ayudar a calmar la red. La retransmisión garantiza que los datos finalmente se entreguen.

Esto significa que los datos TCP pueden llegar al destino desordenados, y es responsabilidad de la parte receptora reordenar los paquetes antes de volver a ensamblarlos en el flujo. Desafortunadamente, esto significa que un solo paquete perdido puede hacer que todo el flujo TCP se detenga mientras el servidor espera su retransmisión. Por lo tanto, la cabeza de línea está bloqueada.

Otro proyecto de Google tenía como objetivo resolver este problema mediante la introducción de un protocolo llamado QUIC.

El protocolo QUIC se basa en UDP en lugar de TCP, y QUIC forma la base para HTTP/3.

¿Qué es UDP?

El protocolo de datagramas de usuario (UDP) es una alternativa a TCP. No proporciona la ilusión de un flujo ni las mismas garantías que ofrece TCP. En su lugar, simplemente proporciona una manera fácil de colocar datos en un paquete, dirigirlo a otra computadora y enviarlo. No es confiable , no está ordenado y no viene con ningún tipo de control de congestión.

Su propósito es ser ligero y proporcionar las características mínimas necesarias para permitir la comunicación. De esta forma la aplicación puede implementar sus propias garantías. Esto suele ser muy útil en aplicaciones en tiempo real. Por ejemplo, en las llamadas telefónicas, los usuarios generalmente prefieren recibir el 90 % de los datos de inmediato, en lugar del 100 % de los datos eventualmente.

Solución TCP HOL de HTTP/3

Resolver el problema de bloqueo de TCP HOL requería más que solo cambiar a UDP, ya que todavía es necesario garantizar la entrega de todos los datos y evitar colapsos de congestión de la red. El protocolo QUIC está diseñado para hacer todo esto al proporcionar una experiencia optimizada de tipo HTTP sobre UDP.

A medida que QUIC asume el control de la gestión de secuencias, la estructuración binaria, etc., HTTP/2 no tiene mucho que hacer cuando se ejecuta sobre QUIC. Esto es parte del factor impulsor para que esta nueva combinación de QUIC + HTTP se estandarice como HTTP/3.

Nota: Hay muchas versiones de QUIC, ya que el protocolo ha estado en desarrollo e implementado en entornos de producción durante años. Incluso hay una versión específica de Google llamada GQUIC. Como tal, es importante hacer una distinción entre los antiguos protocolos QUIC y el nuevo estándar HTTP/3.

Siempre encriptado

HTTP/3 incluye cifrado que se basa en gran medida en TLS, pero no lo usa directamente. Uno de los principales desafíos de implementación para HTTP/3 es que las bibliotecas TLS/SSL deben modificarse para agregar la nueva funcionalidad requerida.

Este cambio se debe a que HTTP/3 difiere de HTTPS en cuanto a lo que cifra. Con el antiguo protocolo HTTPS, solo los datos en sí están protegidos por TLS, lo que deja visible una gran cantidad de metadatos de transporte. En HTTP/3 tanto los datos como el protocolo de transporte están protegidos. Esto puede sonar como una característica de seguridad, y lo es. Pero se hace de esta manera para evitar muchos de los gastos generales presentes en HTTP/2. Por lo tanto, cifrar el protocolo de transporte y los datos hace que el protocolo sea más eficaz.

Impacto de HTTP/3 en la infraestructura de red

HTTP/3 no está exento de controversia. Las principales preocupaciones son acerca de la infraestructura de red.

HTTP/3 del lado del cliente

En el lado del cliente, es bastante común que el tráfico UDP esté muy limitado y/o bloqueado. La aplicación de estas restricciones a HTTP/3 derrota el objetivo del protocolo.

En segundo lugar, es bastante común que HTTP sea monitoreado y/o interceptado. Incluso con el tráfico HTTPS, las redes observan regularmente los elementos de transporte de texto claro del protocolo para determinar si deben interrumpir la conexión con el fin de evitar el acceso a ciertos sitios web desde redes específicas o dentro de regiones específicas. En algunos países, esto es incluso obligatorio por ley para ciertos proveedores de servicios. El cifrado obligatorio en HTTP/3 hace que esto sea imposible.

No es solo un filtrado a nivel gubernamental. Muchas universidades, bibliotecas públicas, escuelas y hogares con padres preocupados eligen activamente bloquear el acceso a ciertos sitios web o al menos mantener un registro de los sitios visitados. El cifrado obligatorio en HTTP/3 hace que esto sea imposible.

Vale la pena señalar que actualmente es posible un filtrado limitado. Esto se debe a que el campo de indicación del nombre del servidor (SNI), que contiene el nombre de host del sitio web pero no la ruta, los parámetros de consulta, etc., aún no está encriptado. Pero esto cambiará en un futuro cercano con la introducción de ESNI (SNI encriptado), que se agregó recientemente al estándar TLS.

HTTP/3 del lado del servidor

En el lado del servidor, es una buena práctica bloquear los puertos y protocolos que no esperan tráfico, lo que significa que los administradores del servidor ahora deben abrir UDP 443 para HTTP/3, en lugar de confiar en sus reglas TCP 443 existentes.

En segundo lugar, la infraestructura de la red puede hacer que las sesiones TCP sean pegajosas , lo que significa que siempre se enrutarán al mismo servidor, incluso cuando cambien las prioridades de enrutamiento. Como HTTP/3 se ejecuta sobre UDP, que no tiene sesiones, la infraestructura de la red debe actualizarse para rastrear los ID de conexión específicos de HTTP/3, que se han dejado sin cifrar específicamente para ayudar en el enrutamiento persistente.

En tercer lugar, es bastante común que se inspeccione HTTP para detectar abusos, monitorear problemas de seguridad comunes, detectar y prevenir la propagación de malware y virus, etc. Esto no es posible con HTTP/3 debido a su encriptación. Aún así, las opciones en las que el dispositivo interceptor tiene una copia de las claves de seguridad aún son posibles, suponiendo que los dispositivos implementen la compatibilidad con HTTP/3.

Finalmente, muchos administradores se oponen a tener que administrar aún más certificados SSL, aunque eso es un problema menor ahora que servicios como Let's Encrypt están disponibles.

Hasta que haya soluciones ampliamente aceptadas y conocidas para abordar estas preocupaciones, creo que es probable que muchas redes grandes simplemente bloqueen HTTP/3.

Impacto de HTTP/3 en el desarrollo web

No hay mucho de qué preocuparse en este frente. Las funciones de priorización de flujo de HTTP/2 y envío del servidor todavía están presentes en HTTP/3. Vale la pena que los desarrolladores web se familiaricen con estas características si realmente quieren optimizar el rendimiento de su sitio.

Usando HTTP/3 ahora mismo

Los usuarios de Google Chrome, o el navegador Chromium de código abierto, ya están configurados para usar HTTP/3. Los lanzamientos de calidad de producción de los servidores HTTP/3 todavía están un poco lejos; la especificación no está del todo finalizada al momento de escribir este artículo. Pero mientras tanto, hay muchas herramientas con las que jugar, y tanto Google como Cloudflare ya han impulsado el soporte a sus entornos de producción.

La forma más sencilla de probarlo es usando Caddy en Docker. Se necesita un certificado SSL para esto, por lo que una dirección IP de acceso público facilita las cosas. Los pasos son:

1. Configuración de DNS. Obtenga un nombre de host que funcione y que esté activo en Internet, por ejemplo, yourhostname.example.com IN A 192.0.2.1 .
2. Creación de archivos Caddy. Debe contener estas líneas:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Ejecutando Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —o fuera de Docker, caddy --quic .
2. Ejecutar cromo con QUIC habilitado: chromium --enable-quic
3. (Opcional) Instalación de una extensión de indicador de protocolo.
4. Navegando al servidor habilitado para QUIC , donde debería estar visible un explorador de archivos.

Los desarrolladores también pueden probar sus servidores con las siguientes herramientas útiles:

• Prueba HTTP/2 de Keycdn
• HTTP3Check de LiteSpeed
• Prueba del servidor SSL de Qualys

¡Gracias por leer!