HTTP/3: opciones prácticas de implementación (parte 3)

¡Hola y bienvenidos a la entrega final de esta serie de tres partes sobre los nuevos protocolos HTTP/3 y QUIC! Si después de las dos partes anteriores (historia de HTTP/3 y conceptos básicos y características de rendimiento de HTTP/3) está convencido de que comenzar a usar los nuevos protocolos es una buena idea (¡y debería serlo!), entonces esta pieza final incluye todos lo que necesita saber para empezar!

Primero, analizaremos qué cambios debe realizar en sus páginas y recursos para utilizar de manera óptima los nuevos protocolos (esa es la parte fácil). A continuación, veremos cómo configurar servidores y clientes (esa es la parte difícil, a menos que esté utilizando una red de entrega de contenido (CDN)). Finalmente, veremos qué herramientas puede usar para evaluar el impacto en el rendimiento de los nuevos protocolos (esa es la parte casi imposible, al menos por ahora).

Cambios en páginas y recursos

Comencemos con algunas buenas noticias: si ya está en HTTP/2, ¡probablemente no tendrá que cambiar nada en sus páginas o recursos cuando cambie a HTTP/3! . Esto se debe a que, como explicamos en las partes 1 y 2, HTTP/3 se parece más a HTTP/2 sobre QUIC, y las características de alto nivel de las dos versiones se han mantenido iguales. Como tal, cualquier cambio u optimización realizada para HTTP/2 seguirá funcionando para HTTP/3 y viceversa.

Sin embargo, si todavía está en HTTP/1.1, o se olvidó de su transición a HTTP/2, o nunca modificó las cosas para HTTP/2, entonces puede preguntarse cuáles fueron esos cambios y por qué eran necesarios. Sin embargo, incluso hoy en día, sería difícil encontrar un buen artículo que detalle las mejores prácticas matizadas . Esto se debe a que, como dije en la introducción de la parte 1, gran parte del contenido inicial de HTTP/2 era demasiado optimista sobre qué tan bien funcionaría en la práctica y, francamente, parte de él tenía errores importantes y malos consejos. Lamentablemente, gran parte de esta información errónea persiste en la actualidad. Esa es una de mis principales motivaciones al escribir esta serie sobre HTTP/3, para ayudar a evitar que eso vuelva a suceder.

La mejor fuente matizada todo en uno para HTTP/2 que puedo recomendar en este momento es el libro HTTP/2 in Action de Barry Pollard. Sin embargo, dado que se trata de un recurso pago y no quiero que se quede con las dudas aquí, he enumerado algunos de los puntos principales a continuación, junto con la forma en que se relacionan con HTTP/3:

1. Conexión única

La mayor diferencia entre HTTP/1.1 y HTTP/2 fue el cambio de 6 a 30 conexiones TCP paralelas a una única conexión TCP subyacente. Discutimos un poco en la parte 2 cómo una sola conexión puede seguir siendo tan rápida como varias conexiones, debido a que el control de la congestión puede causar una pérdida mayor o más temprana de paquetes con más conexiones (lo que deshace los beneficios de su inicio agregado más rápido). HTTP/3 continúa con este enfoque, pero "simplemente" cambia de una conexión TCP a una QUIC. Esta diferencia por sí sola no hace mucho (principalmente reduce la sobrecarga en el lado del servidor), pero conduce a la mayoría de los siguientes puntos.

2. Fragmentación de servidores y fusión de conexiones

El cambio a la configuración de conexión única fue bastante difícil en la práctica porque muchas páginas se fragmentaron en diferentes nombres de host e incluso servidores (como img1.example.com e img2.example.com ). Esto se debió a que los navegadores solo abrieron hasta seis conexiones para cada nombre de host individual, por lo que tener múltiples permitió más conexiones. Sin cambios en esta configuración de HTTP/1.1, HTTP/2 aún abriría múltiples conexiones, lo que reduciría el funcionamiento real de otras funciones, como la priorización (ver más abajo).

Como tal, la recomendación original era deshacer la fragmentación del servidor y consolidar los recursos en un solo servidor tanto como fuera posible. HTTP/2 incluso proporcionó una función para facilitar la transición desde una configuración HTTP/1.1, llamada fusión de conexiones. En términos generales, si dos nombres de host se resuelven en la misma IP de servidor (usando DNS) y usan un certificado TLS similar, entonces el navegador puede reutilizar una única conexión incluso entre los dos nombres de host .

En la práctica, la fusión de conexiones puede ser difícil de realizar correctamente, por ejemplo, debido a varios problemas sutiles de seguridad relacionados con CORS. Incluso si lo configura correctamente, podría terminar fácilmente con dos conexiones separadas. La cosa es que eso no siempre es malo . En primer lugar, debido a la priorización y multiplexación mal implementadas (ver más abajo), la conexión única fácilmente podría ser más lenta que usar dos o más. En segundo lugar, el uso de demasiadas conexiones podría provocar la pérdida temprana de paquetes debido a los controladores de congestión de la competencia. Sin embargo, usar solo unos pocos (pero aún más de uno) podría equilibrar muy bien el crecimiento de la congestión con un mejor rendimiento, especialmente en redes de alta velocidad. Por estas razones, creo que un poco de fragmentación sigue siendo una buena idea (digamos, de dos a cuatro conexiones), incluso con HTTP/2. De hecho, creo que la mayoría de las configuraciones HTTP/2 modernas funcionan tan bien porque todavía tienen algunas conexiones adicionales o cargas de terceros en su ruta crítica.

3. Agrupación de recursos e integración

En HTTP/1.1, solo podía tener un único recurso activo por conexión, lo que generaba un bloqueo de encabezado de línea (HoL) a nivel de HTTP. Debido a que la cantidad de conexiones se limitó a un mísero 6 a 30, la agrupación de recursos (donde los subrecursos más pequeños se combinan en un solo recurso más grande) fue una mejor práctica durante mucho tiempo. Todavía vemos esto hoy en paquetes como Webpack. De manera similar, los recursos a menudo se integraban en otros recursos (por ejemplo, el CSS crítico se integraba en el HTML).

Sin embargo, con HTTP/2, la conexión única multiplexa los recursos, por lo que puede tener muchas más solicitudes de archivos pendientes (dicho de otra manera, una sola solicitud ya no ocupa una de sus pocas y preciadas conexiones). Esto se interpretó originalmente como " Ya no necesitamos agrupar o alinear nuestros recursos para HTTP/2 ". Se promocionó que este enfoque era mejor para el almacenamiento en caché detallado porque cada subrecurso se podía almacenar en caché individualmente y no era necesario volver a descargar el paquete completo si uno de ellos cambiaba. Esto es cierto, pero sólo en una medida relativamente limitada.

Por ejemplo, podría reducir la eficiencia de la compresión, porque funciona mejor con más datos. Además, cada solicitud o archivo adicional tiene una sobrecarga inherente porque debe ser manejado por el navegador y el servidor. Estos costos pueden sumar, digamos, cientos de archivos pequeños en comparación con algunos archivos grandes. En nuestras primeras pruebas, encontré rendimientos seriamente decrecientes en alrededor de 40 archivos. Aunque esos números probablemente sean un poco más altos ahora, las solicitudes de archivos todavía no son tan baratas en HTTP/2 como se predijo originalmente . Por último, no incluir recursos tiene un costo de latencia adicional porque es necesario solicitar el archivo. Esto, combinado con la priorización y los problemas de inserción del servidor (ver a continuación), significa que incluso hoy en día es mejor incorporar algunos de sus CSS críticos. Tal vez algún día la propuesta de paquetes de recursos ayude con esto, pero todavía no.

Todo esto, por supuesto, también es válido para HTTP/3. Aún así, he leído que la gente afirma que muchos archivos pequeños serían mejores que QUIC porque más transmisiones independientes activas al mismo tiempo significan más ganancias de la eliminación del bloqueo de HoL (como discutimos en la parte 2). Creo que puede haber algo de verdad en esto, pero, como también vimos en la parte 2, este es un problema muy complejo con muchos parámetros en movimiento. No creo que los beneficios superen los otros costos discutidos, pero se necesita más investigación. (Una idea escandalosa sería que cada archivo tuviera el tamaño exacto para caber en un solo paquete QUIC, evitando por completo el bloqueo de HoL. Aceptaré regalías de cualquier empresa emergente que implemente un paquete de recursos que haga esto. ;))

4. Priorización

Para poder descargar varios archivos en una sola conexión, debe multiplexarlos de alguna manera. Como se discutió en la parte 2, en HTTP/2, esta multiplexación se dirige utilizando su sistema de priorización. Esta es la razón por la que es importante tener tantos recursos como sea posible solicitados en la misma conexión también, ¡para poder priorizarlos correctamente entre sí! Sin embargo, como también vimos, este sistema era muy complejo , por lo que a menudo se usaba mal y se implementaba mal en la práctica (ver la imagen a continuación). Esto, a su vez, ha significado que algunas otras recomendaciones para HTTP/2, como la agrupación reducida, porque las solicitudes son baratas, y la fragmentación reducida del servidor, para hacer un uso óptimo de la conexión única (ver arriba), han resultado tener un rendimiento inferior en práctica.

Lamentablemente, esto es algo sobre lo que usted, como desarrollador web promedio, no puede hacer mucho, porque es principalmente un problema en los navegadores y servidores. Sin embargo, puede intentar mitigar el problema al no usar demasiados archivos individuales (lo que reducirá las posibilidades de prioridades en competencia) y al seguir usando fragmentación (limitada). Otra opción es usar varias técnicas que influyen en la prioridad, como la carga diferida, JavaScript async y defer , y sugerencias de recursos como preload . Internamente, estos cambian principalmente las prioridades de los recursos para que se envíen antes o después. Sin embargo, estos mecanismos pueden (y lo hacen) sufrir errores. Además, no espere preload un montón de recursos y hacer las cosas más rápido: si todo es repentinamente una alta prioridad, ¡entonces nada lo es! Incluso es muy fácil retrasar recursos realmente críticos mediante el uso de cosas como la preload .

Como también se explicó en la parte 2, HTTP/3 cambia fundamentalmente las partes internas de este sistema de priorización. Esperamos que esto signifique que habrá muchos menos errores y problemas con su implementación práctica, por lo que al menos algo de esto debería resolverse. Sin embargo, aún no podemos estar seguros, porque pocos servidores y clientes HTTP/3 implementan completamente este sistema en la actualidad. Sin embargo, los conceptos fundamentales de priorización no cambiarán . Aún no podrá usar técnicas como la preload sin comprender realmente lo que sucede internamente, porque aún podría priorizar incorrectamente sus recursos.

5. Empuje del servidor y primer vuelo

La inserción del servidor permite que un servidor envíe datos de respuesta sin esperar primero una solicitud del cliente. Nuevamente, esto suena muy bien en teoría, y podría usarse en lugar de incorporar recursos (ver arriba). Sin embargo, como se discutió en la parte 2, push es muy difícil de usar correctamente debido a problemas con el control de congestión, el almacenamiento en caché, la priorización y el almacenamiento en búfer. En general, es mejor no usarlo para la carga general de páginas web a menos que realmente sepa lo que está haciendo, e incluso entonces probablemente sería una microoptimización. Sin embargo, todavía creo que podría tener un lugar con las API (REST), donde puede enviar subrecursos vinculados en la respuesta (JSON) en una conexión precalentada. Esto es cierto tanto para HTTP/2 como para HTTP/3.

Para generalizar un poco, creo que se podrían hacer comentarios similares para la reanudación de la sesión TLS y 0-RTT, ya sea sobre TCP + TLS o mediante QUIC. Como se discutió en la parte 2, 0-RTT es similar a la inserción del servidor (como se usa normalmente) en el sentido de que intenta acelerar las primeras etapas de la carga de una página. Sin embargo, eso significa que está igualmente limitado en lo que puede lograr en ese momento (aún más en QUIC, debido a problemas de seguridad). Como tal, una microoptimización es, nuevamente, cómo probablemente necesite ajustar las cosas en un nivel bajo para beneficiarse realmente de ella. Y pensar que una vez estuve muy emocionado de probar la combinación de servidor push con 0-RTT.

¿Que significa todo esto?

Todo lo anterior se reduce a una simple regla general: aplica la mayoría de las recomendaciones típicas de HTTP/2 que encuentras en línea, pero no las lleves al extremo .

Aquí hay algunos puntos concretos que en su mayoría son válidos tanto para HTTP/2 como para HTTP/3:

1. Fragmente los recursos en aproximadamente una a tres conexiones en la ruta crítica (a menos que sus usuarios estén en su mayoría en redes con poco ancho de banda), usando preconnect y dns-prefetch cuando sea necesario.
2. Agrupe los subrecursos lógicamente por ruta o característica, o por frecuencia de cambio. De cinco a diez recursos de JavaScript y de cinco a diez CSS por página deberían estar bien. Incrustar CSS crítico aún puede ser una buena optimización.
3. Utilice funciones complejas, como la preload , con moderación.
4. Utilice un servidor que admita correctamente la priorización de HTTP/2. Para HTTP/2, recomiendo H2O. Apache y NGINX están en su mayoría bien (aunque podrían hacerlo mejor), mientras que Node.js debe evitarse para HTTP/2. Para HTTP/3, las cosas están menos claras en este momento (ver más abajo).
5. Asegúrese de que TLS 1.3 esté habilitado en su servidor web HTTP/2.

Como puede ver, aunque está lejos de ser simple, optimizar páginas para HTTP/3 (y HTTP/2) no es ciencia espacial. Sin embargo, lo que será más difícil será configurar correctamente los servidores, clientes y herramientas HTTP/3.

Servidores y Redes

Como probablemente ya comprenda, QUIC y HTTP/3 son protocolos bastante complejos. Implementarlos desde cero implicaría leer (¡y comprender!) cientos de páginas repartidas en más de siete documentos. Afortunadamente, varias empresas han estado trabajando en implementaciones QUIC y HTTP/3 de código abierto durante más de cinco años, por lo que tenemos varias opciones maduras y estables para elegir.

Algunos de los más importantes y estables incluyen los siguientes:

Sin embargo, muchas (quizás la mayoría) de estas implementaciones se encargan principalmente de las cosas de HTTP/3 y QUIC; en realidad no son servidores web completos por sí mismos . Cuando se trata de sus servidores típicos (piense en NGINX, Apache, Node.js), las cosas han sido un poco más lentas, por varias razones. Primero, pocos de sus desarrolladores estuvieron involucrados con HTTP/3 desde el principio, y ahora tienen que ponerse al día. Muchos eluden esto mediante el uso de una de las implementaciones enumeradas anteriormente internamente como bibliotecas, pero incluso esa integración es difícil.

En segundo lugar, muchos servidores dependen de bibliotecas TLS de terceros, como OpenSSL. Esto se debe, nuevamente, a que TLS es muy complejo y debe ser seguro, por lo que es mejor reutilizar el trabajo verificado existente. Sin embargo, aunque QUIC se integra con TLS 1.3, lo usa de maneras muy diferentes a cómo interactúan TLS y TCP . Esto significa que las bibliotecas TLS tienen que proporcionar API específicas de QUIC, lo que sus desarrolladores han sido reacios o lentos durante mucho tiempo. El problema aquí es especialmente OpenSSL, que ha pospuesto la compatibilidad con QUIC, pero también lo utilizan muchos servidores. Este problema empeoró tanto que Akamai decidió iniciar una bifurcación de OpenSSL específica para QUIC, llamada quictls. Si bien existen otras opciones y soluciones, la compatibilidad con TLS 1.3 para QUIC sigue siendo un obstáculo para muchos servidores y se espera que siga así durante algún tiempo.

A continuación, se muestra una lista parcial de servidores web completos que debería poder usar de forma inmediata, junto con su compatibilidad actual con HTTP/3:

• apache
  El soporte no está claro en este momento. No se ha anunciado nada. Es probable que también necesite OpenSSL. (Sin embargo, tenga en cuenta que hay una implementación de Apache Traffic Server).
• NGINX
  Esta es una implementación personalizada. Esto es relativamente nuevo y todavía altamente experimental. Se espera que se fusione con la línea principal NGINX para fines de 2021. Esto es relativamente nuevo y aún muy experimental. Tenga en cuenta que también hay un parche para ejecutar la biblioteca quiche de Cloudflare en NGINX, que probablemente sea más estable por ahora.
• Nodo.js
  Esto usa la biblioteca ngtcp2 internamente. Está bloqueado por el progreso de OpenSSL, aunque planean cambiar a la bifurcación QUIC-TLS para que algo funcione antes.
• IIS
  El soporte no está claro en este momento y no se ha anunciado nada. Sin embargo, es probable que use la biblioteca MsQuic internamente.
• Hipermaíz
  Este integra aioquic, con apoyo experimental.
• Caddie
  Esto utiliza quic-go, con soporte completo.
• H2O
  Esto se usa rápidamente, con soporte completo.
• Litespeed
  Esto usa LSQUIC, con soporte completo.

Tenga en cuenta algunos matices importantes:

• Incluso "soporte total" significa "tan bueno como se puede en este momento", no necesariamente "listo para producción". Por ejemplo, muchas implementaciones aún no son totalmente compatibles con la migración de conexión, 0-RTT, inserción de servidor o priorización HTTP/3 .
• Otros servidores que no figuran en la lista, como Tomcat, (que yo sepa) aún no han hecho ningún anuncio.
• De los servidores web enumerados, solo Litespeed, el parche NGINX de Cloudflare y H2O fueron creados por personas íntimamente involucradas en la estandarización QUIC y HTTP/3, por lo que es más probable que funcionen mejor desde el principio.
  

Como puede ver, el panorama de los servidores aún no está completo, pero ciertamente ya hay opciones para configurar un servidor HTTP/3. Sin embargo, simplemente ejecutar el servidor es solo el primer paso. Configurarlo y el resto de su red es más difícil.

configuración de la red

Como se explicó en la parte 1, QUIC se ejecuta sobre el protocolo UDP para que sea más fácil de implementar. Sin embargo, esto significa principalmente que la mayoría de los dispositivos de red pueden analizar y comprender UDP. Lamentablemente, esto no significa que UDP esté universalmente permitido . Debido a que UDP se usa a menudo para ataques y no es crítico para el trabajo diario normal además de DNS, muchas redes (corporativas) y firewalls bloquean el protocolo casi por completo. Como tal, es probable que UDP deba tener permiso explícito hacia/desde sus servidores HTTP/3 . QUIC puede ejecutarse en cualquier puerto UDP, pero se espera que el puerto 443 (que generalmente también se usa para HTTPS sobre TCP) sea el más común.

Sin embargo, muchos administradores de red no querrán permitir solo la venta al por mayor de UDP. En cambio, querrán específicamente permitir QUIC sobre UDP. El problema es que, como hemos visto, QUIC está encriptado casi en su totalidad. Esto incluye metadatos de nivel QUIC, como números de paquetes, pero también, por ejemplo, señales que indican el cierre de una conexión. Para TCP, los firewalls rastrean activamente todos estos metadatos para verificar el comportamiento esperado. (¿Vimos un apretón de manos completo antes de los paquetes que transportan datos? ¿Siguen los paquetes los patrones esperados? ¿Cuántas conexiones abiertas hay?) Como vimos en la parte 1, esta es exactamente una de las razones por las que TCP ya no es prácticamente evolucionable. Sin embargo, debido al cifrado de QUIC, los cortafuegos pueden hacer mucho menos de esta lógica de seguimiento de nivel de conexión , y los pocos bits que pueden inspeccionar son relativamente complejos.

Como tal, muchos proveedores de firewall actualmente recomiendan bloquear QUIC hasta que puedan actualizar su software. Sin embargo, incluso después de eso, es posible que muchas empresas no quieran permitirlo, porque el soporte de QUIC del firewall siempre será mucho menor que las características de TCP a las que están acostumbrados.

Todo esto se complica aún más por la función de migración de conexión. Como hemos visto, esta característica permite que la conexión continúe desde una nueva dirección IP sin tener que realizar un nuevo protocolo de enlace, mediante el uso de ID de conexión (CID). Sin embargo, para el cortafuegos, esto parecerá como si se estuviera utilizando una nueva conexión sin usar primero un apretón de manos, lo que podría ser un atacante que envía tráfico malicioso. Los firewalls no solo pueden usar los QUIC CID, porque también cambian con el tiempo para proteger la privacidad de los usuarios. Como tal, será necesario que los servidores se comuniquen con el firewall sobre qué CID se esperan , pero ninguna de estas cosas existe todavía.

Existen preocupaciones similares para los balanceadores de carga para configuraciones a gran escala. Estas máquinas distribuyen las conexiones entrantes a través de una gran cantidad de servidores back-end. Por supuesto, el tráfico de una conexión siempre debe enrutarse al mismo servidor de back-end (¡los demás no sabrían qué hacer con él!). Para TCP, esto podría hacerse simplemente en base a la tupla de 4, porque eso nunca cambia. Sin embargo, con la migración de conexión QUIC, esa ya no es una opción. Nuevamente, los servidores y los balanceadores de carga deberán ponerse de acuerdo de alguna manera sobre qué CID elegir para permitir el enrutamiento determinista . Sin embargo, a diferencia de la configuración del firewall, ya existe una propuesta para configurar esto (aunque está lejos de implementarse ampliamente).

Por último, existen otras consideraciones de seguridad de nivel superior, principalmente en torno a los ataques 0-RTT y de denegación de servicio distribuido (DDoS). Como se discutió en la parte 2, QUIC ya incluye bastantes mitigaciones para estos problemas, pero idealmente, también usarán líneas de defensa adicionales en la red. Por ejemplo, los servidores proxy o perimetrales pueden bloquear ciertas solicitudes 0-RTT para que no lleguen a los back-ends reales para evitar ataques de reproducción. Alternativamente, para evitar ataques de reflejo o ataques DDoS que solo envían el primer paquete de protocolo de enlace y luego dejan de responder (llamado inundación SYN en TCP), QUIC incluye la función de reintento. Esto permite que el servidor valide que es un cliente con buen comportamiento, sin tener que mantener ningún estado mientras tanto (el equivalente de las cookies TCP SYN). Este proceso de reintento ocurre mejor, por supuesto, en algún lugar antes del servidor back-end, por ejemplo, en el balanceador de carga. Nuevamente, esto requiere una configuración y comunicación adicionales para configurarlo.

Estos son solo los problemas más destacados que los administradores de redes y sistemas tendrán con QUIC y HTTP/3. Hay varios más, algunos de los cuales he hablado. También hay dos documentos complementarios separados para los RFC de QUIC que analizan estos problemas y sus posibles mitigaciones (parciales).

¿Que significa todo esto?

HTTP/3 y QUIC son protocolos complejos que dependen de una gran cantidad de maquinaria interna. Todavía no todo está listo para el horario de máxima audiencia , aunque ya tiene algunas opciones para implementar los nuevos protocolos en sus back-ends. Sin embargo, probablemente tomará algunos meses o incluso años para que los servidores más destacados y las bibliotecas subyacentes (como OpenSSL) se actualicen.

Incluso entonces, la configuración adecuada de los servidores y otros intermediarios de la red, de modo que los protocolos puedan usarse de manera segura y óptima, no será trivial en configuraciones a gran escala. Necesitarás un buen equipo de desarrollo y operaciones para hacer correctamente esta transición.

Como tal, especialmente en los primeros días, probablemente sea mejor confiar en una gran empresa de hosting o CDN para instalar y configurar los protocolos por usted. Como se discutió en la parte 2, ahí es donde es más probable que QUIC valga la pena de todos modos, y el uso de una CDN es una de las optimizaciones de rendimiento clave que puede hacer. Personalmente recomendaría usar Cloudflare o Fastly porque han estado íntimamente involucrados en el proceso de estandarización y tendrán las implementaciones más avanzadas y mejor ajustadas disponibles.

Clientes y QUIC Discovery

Hasta ahora, hemos considerado el soporte del lado del servidor y dentro de la red para los nuevos protocolos. Sin embargo, también se deben superar varios problemas por parte del cliente.

Antes de llegar a eso, comencemos con algunas buenas noticias: ¡La mayoría de los navegadores populares ya tienen soporte (experimental) HTTP/3! Específicamente, al momento de escribir este artículo, este es el estado del soporte (ver también caniuse.com):

• Google Chrome (versión 91+) : habilitado de forma predeterminada.
• Mozilla Firefox (versión 89+) : habilitado de forma predeterminada.
• Microsoft Edge (versión 90+) : Habilitado de forma predeterminada (usa Chromium internamente).
• Opera (versión 77+) : habilitado de forma predeterminada (usa Chromium internamente).
• Apple Safari (versión 14) : Detrás de una bandera manual. Estará habilitado de forma predeterminada en la versión 15, que actualmente se encuentra en la vista previa de la tecnología.
• Otros navegadores : aún no hay señales que yo sepa (aunque otros navegadores que usan Chromium internamente, como Brave, en teoría, también podrían comenzar a habilitarlo).

Tenga en cuenta algunos matices:

• La mayoría de los navegadores se implementan gradualmente, por lo que no todos los usuarios obtendrán la compatibilidad con HTTP/3 habilitada de forma predeterminada desde el principio. Esto se hace para limitar los riesgos de que un solo error pasado por alto pueda afectar a muchos usuarios o que las implementaciones del servidor se sobrecarguen. Como tal, existe una pequeña posibilidad de que, incluso en versiones recientes del navegador, no obtenga HTTP/3 de forma predeterminada y tenga que habilitarlo manualmente.
• Al igual que con los servidores, la compatibilidad con HTTP/3 no significa que todas las funciones se hayan implementado o se estén utilizando en este momento. En particular, 0-RTT, migración de conexión, inserción de servidor, compresión de encabezado QPACK dinámico y priorización de HTTP/3 aún pueden faltar, estar deshabilitados, usarse con moderación o estar mal configurados.
• Si desea utilizar HTTP/3 del lado del cliente fuera del navegador (por ejemplo, en su aplicación nativa), deberá integrar una de las bibliotecas enumeradas anteriormente o utilizar cURL. Apple pronto brindará compatibilidad nativa con HTTP/3 y QUIC a sus bibliotecas de red integradas en macOS e iOS, y Microsoft está agregando QUIC al kernel de Windows y su entorno .NET, pero (que yo sepa) no se ha brindado una compatibilidad nativa similar. anunciado para otros sistemas como Android.

Alt-Svc

Incluso si ha configurado un servidor compatible con HTTP/3 y está usando un navegador actualizado, es posible que se sorprenda al descubrir que HTTP/3 en realidad no se usa de manera consistente . Para entender por qué, supongamos que eres el navegador por un momento. Su usuario solicitó que navegue a example.com (un sitio web que nunca ha visitado antes), y usó DNS para resolver eso en una IP. Envía uno o más paquetes de protocolo de enlace QUIC a esa IP. Ahora varias cosas pueden salir mal:

1. Es posible que el servidor no admita QUIC.
2. Una de las redes intermedias o cortafuegos podría bloquear QUIC y/o UDP por completo.
3. Los paquetes de protocolo de enlace pueden perderse en tránsito.

Sin embargo, ¿cómo sabría (cuál) de estos problemas ha ocurrido ? En los tres casos, nunca recibirá una respuesta a su(s) paquete(s) de protocolo de enlace. Lo único que puede hacer es esperar, con la esperanza de que todavía llegue una respuesta. Luego, después de un tiempo de espera (el tiempo de espera), puede decidir que efectivamente hay un problema con HTTP/3. En ese momento, intentaría abrir una conexión TCP con el servidor, con la esperanza de que HTTP/2 o HTTP/1.1 funcionen.

Como puede ver, este tipo de enfoque podría generar retrasos importantes, especialmente en los años iniciales, cuando muchos servidores y redes aún no admitirán QUIC. Una solución fácil pero ingenua sería simplemente abrir una conexión QUIC y TCP al mismo tiempo y luego usar el protocolo de enlace que se complete primero . Este método se llama "carrera de conexiones" o "globos oculares felices". Si bien esto es ciertamente posible, tiene una sobrecarga considerable. Aunque la pérdida de conexión se cierra casi de inmediato, todavía ocupa algo de memoria y tiempo de CPU tanto en el cliente como en el servidor (especialmente cuando se usa TLS). Además de eso, también hay otros problemas con este método que involucran redes IPv4 versus IPv6 y los ataques de repetición discutidos anteriormente (que mi charla cubre con más detalle).

Como tal, para QUIC y HTTP/3, los navegadores prefieren ir a lo seguro y solo probar QUIC si saben que el servidor lo admite . Como tal, la primera vez que se contacta con un nuevo servidor, el navegador solo usará HTTP/2 o HTTP/1.1 a través de una conexión TCP. Luego, el servidor puede informar al navegador que también admite HTTP/3 para conexiones posteriores. Esto se hace configurando un encabezado HTTP especial en las respuestas enviadas a través de HTTP/2 o HTTP/1.1. Este encabezado se llama Alt-Svc , que significa "servicios alternativos". Alt-Svc se puede utilizar para que un navegador sepa que un determinado servicio también es accesible a través de otro servidor (IP y/o puerto), pero también permite la indicación de protocolos alternativos. Esto se puede ver a continuación en la figura 1.

Al recibir un encabezado Alt-Svc válido que indique compatibilidad con HTTP/3, el navegador lo almacenará en caché e intentará establecer una conexión QUIC a partir de ese momento. Algunos clientes harán esto tan pronto como sea posible (incluso durante la carga inicial de la página; consulte a continuación), mientras que otros esperarán hasta que se cierren las conexiones TCP existentes. Esto significa que el navegador solo usará HTTP/3 después de haber descargado al menos algunos recursos a través de HTTP/2 o HTTP/1.1 primero . Incluso entonces, no es fácil navegar. El navegador ahora sabe que el servidor admite HTTP/3, pero eso no significa que la red intermedia no lo bloqueará. Como tal, las carreras de conexión todavía son necesarias en la práctica. Por lo tanto, aún podría terminar con HTTP/2 si la red de alguna manera retrasa lo suficiente el protocolo de enlace QUIC. Además, si la conexión QUIC no se establece varias veces seguidas, algunos navegadores pondrán la entrada de caché Alt-Svc en una lista de denegación durante algún tiempo, sin probar HTTP/3 por un tiempo. Como tal, puede ser útil borrar manualmente el caché de su navegador si las cosas no funcionan porque eso también debería vaciar los enlaces Alt-Svc . Finalmente, se ha demostrado que Alt-Svc presenta algunos riesgos de seguridad graves. Por esta razón, algunos navegadores imponen restricciones adicionales sobre, por ejemplo, qué puertos se pueden usar (en Chrome, sus servidores HTTP/2 y HTTP/3 deben estar ambos en un puerto inferior a 1024 o ambos en un puerto superior o igual). a 1024, de lo contrario se ignorará Alt-Svc ). Toda esta lógica varía y evoluciona enormemente entre navegadores, lo que significa que obtener conexiones HTTP/3 consistentes puede ser difícil , lo que también dificulta probar nuevas configuraciones.

Se está trabajando para mejorar un poco este proceso Alt-Svc dos pasos. La idea es usar nuevos registros DNS llamados SVCB y HTTPS, que contendrán información similar a la que hay en Alt-Svc . Como tal, el cliente puede descubrir que un servidor admite HTTP/3 durante el paso de resolución de DNS, lo que significa que puede probar QUIC desde la primera carga de la página en lugar de tener que pasar primero por HTTP/2 o HTTP/1.1. Para obtener más información sobre esto y Alt-Svc , consulte el capítulo Web Almanac del año pasado sobre HTTP/2.

Como puede ver, Alt-Svc y el proceso de descubrimiento de HTTP/3 agregan una capa de complejidad a su ya desafiante implementación de servidor QUIC, porque:

• siempre necesitará implementar su servidor HTTP/3 junto a un servidor HTTP/2 y/o HTTP/1.1;
• deberá configurar sus servidores HTTP/2 y HTTP/1.1 para configurar los encabezados Alt-Svc correctos en sus respuestas.

Si bien eso debería ser manejable en configuraciones de nivel de producción (porque, por ejemplo, una sola instancia de Apache o NGINX probablemente admitirá las tres versiones de HTTP al mismo tiempo), podría ser mucho más molesto en el conjunto de prueba (local). ups (ya puedo verme olvidando agregar los encabezados Alt-Svc o estropearlos). Este problema se ve agravado por la falta (actual) de registros de errores del navegador e indicadores de DevTools, lo que significa que puede ser difícil averiguar por qué exactamente la configuración no funciona.

Problemas adicionales

Como si eso no fuera suficiente, otro problema hará que las pruebas locales sean más difíciles: Chrome hace que sea muy difícil para usted usar certificados TLS autofirmados para QUIC . Esto se debe a que las empresas suelen utilizar certificados TLS no oficiales para descifrar el tráfico TLS de sus empleados (para que, por ejemplo, puedan hacer que sus cortafuegos analicen el tráfico cifrado). Sin embargo, si las empresas comenzaran a hacer eso con QUIC, volveríamos a tener implementaciones de middlebox personalizadas que hacen sus propias suposiciones sobre el protocolo. Esto podría conducir a que potencialmente rompan el soporte del protocolo en el futuro, ¡que es exactamente lo que tratamos de evitar al cifrar QUIC tan extensamente en primer lugar! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

¿Que significa todo esto?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Faro de Google

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog y qvis

Como muestra la discusión anterior, puede ser complicado analizar el comportamiento de HTTP/3 simplemente usando Lighthouse o WebPageTest en este punto. Afortunadamente, hay otras herramientas de nivel inferior disponibles para ayudar con esto. Primero, la excelente herramienta Wireshark tiene soporte avanzado para QUIC, y también puede diseccionar HTTP/3 de manera experimental. Esto le permite observar qué paquetes QUIC y HTTP/3 están pasando realmente por el cable. Sin embargo, para que eso funcione, debe obtener las claves de descifrado de TLS para una conexión determinada, que la mayoría de las implementaciones (incluidos Chrome y Firefox) le permiten extraer mediante la variable de entorno SSLKEYLOGFILE . Si bien esto puede ser útil para algunas cosas, averiguar realmente lo que está sucediendo, especialmente para conexiones más largas, podría implicar mucho trabajo manual. También necesitaría una comprensión bastante avanzada del funcionamiento interno de los protocolos.

Por suerte, hay una segunda opción, qlog y qvis. qlog es un formato de registro basado en JSON específicamente para QUIC y HTTP/3 que es compatible con la mayoría de las implementaciones de QUIC. En lugar de mirar los paquetes que pasan por el cable, qlog captura esta información en el cliente y el servidor directamente, lo que le permite incluir información adicional (por ejemplo, detalles de control de congestión). Por lo general, puede activar la salida de qlog al iniciar servidores y clientes con la variable de entorno QLOGDIR . (Tenga en cuenta que en Firefox, debe configurar la preferencia network.http.http3.enable_qlog . Los dispositivos Apple y Safari usan QUIC_LOG_DIRECTORY en su lugar. Chrome aún no es compatible con qlog).

Estos archivos qlog se pueden cargar en el conjunto de herramientas qvis en qvis.quictools.info. Allí, obtendrá una serie de visualizaciones interactivas avanzadas que facilitan la interpretación del tráfico QUIC y HTTP/3 . qvis también tiene soporte para cargar capturas de paquetes de Wireshark (archivos .pcap ), y tiene soporte experimental para archivos netlog de Chrome, por lo que también puede analizar el comportamiento de Chrome. Un tutorial completo sobre qlog y qvis está más allá del alcance de este artículo, pero se pueden encontrar más detalles en forma de tutorial, como documento e incluso en formato de programa de entrevistas. También puede preguntarme sobre ellos directamente porque soy el principal implementador de qlog y qvis. ;)

Sin embargo, no me hago ilusiones de que la mayoría de los lectores aquí deberían usar Wireshark o qvis, porque estas son herramientas de bajo nivel. Aún así, como tenemos pocas alternativas en este momento, recomiendo encarecidamente no probar exhaustivamente el rendimiento de HTTP/3 sin usar este tipo de herramienta , para asegurarse de que realmente sabe lo que está sucediendo en el cable y si lo que está viendo realmente se explica por internos del protocolo y no por otros factores.

¿Que significa todo esto?

Como hemos visto, configurar y usar HTTP/3 sobre QUIC puede ser un asunto complejo y muchas cosas pueden salir mal. Lamentablemente, no hay una buena herramienta o visualización disponible que exponga los detalles necesarios en un nivel de abstracción adecuado. Esto hace que sea muy difícil para la mayoría de los desarrolladores evaluar los beneficios potenciales que HTTP/3 puede aportar a su sitio web en este momento o incluso validar que su configuración funcione como se espera.

Confiar solo en métricas de alto nivel es muy peligroso porque estas pueden verse sesgadas por una gran cantidad de factores (como una emulación de red poco realista, la falta de funciones en los clientes o servidores, el uso parcial de HTTP/3, etc.). Incluso si todo funcionó mejor, como hemos visto en la parte 2, las diferencias entre HTTP/2 y HTTP/3 probablemente serán relativamente pequeñas en la mayoría de los casos, lo que hace que sea aún más difícil obtener la información necesaria de alto nivel. herramientas sin soporte específico de HTTP/3.

Como tal, recomiendo dejar las mediciones de rendimiento de HTTP/2 frente a HTTP/3 durante unos meses más y centrarse en asegurarse de que nuestras configuraciones del lado del servidor funcionen como se espera . Para esto, es más fácil usar WebPageTest en combinación con los parámetros de la línea de comandos de Google Chrome, con una opción de curl para posibles problemas; actualmente, esta es la configuración más consistente que puedo encontrar.

Conclusión y conclusiones

Estimado lector, si leyó la serie completa de tres partes y llegó aquí, ¡lo saludo ! Incluso si solo ha leído algunas secciones, le agradezco su interés en estos nuevos y emocionantes protocolos. Ahora, resumiré los puntos clave de esta serie, proporcionaré algunas recomendaciones clave para los próximos meses y años y, finalmente, le proporcionaré algunos recursos adicionales, en caso de que desee saber más.

Resumen

Primero, en la parte 1, discutimos que HTTP/3 era necesario principalmente debido al nuevo protocolo de transporte QUIC subyacente . QUIC es el sucesor espiritual de TCP e integra todas sus mejores prácticas, así como TLS 1.3. Esto era necesario principalmente porque TCP, debido a su implementación e integración ubicuas en las cajas intermedias, se ha vuelto demasiado inflexible para evolucionar. El uso de QUIC de UDP y el cifrado casi completo significa que (con suerte) solo tenemos que actualizar los puntos finales en el futuro para agregar nuevas funciones, lo que debería ser más fácil. QUIC, sin embargo, también agrega algunas capacidades nuevas e interesantes. En primer lugar, el protocolo de enlace criptográfico y de transporte combinado de QUIC es más rápido que TCP + TLS, y puede hacer un buen uso de la función 0-RTT. En segundo lugar, QUIC sabe que está transportando múltiples flujos de bytes independientes y puede ser más inteligente sobre cómo maneja las pérdidas y los retrasos, mitigando el problema de bloqueo de cabecera de línea. En tercer lugar, las conexiones QUIC pueden sobrevivir a los usuarios que se trasladan a una red diferente (llamada migración de conexión) al etiquetar cada paquete con una ID de conexión. Finalmente, la estructura de paquete flexible de QUIC (que emplea marcos) lo hace más eficiente pero también más flexible y extensible en el futuro. En conclusión, está claro que QUIC es el protocolo de transporte de próxima generación y se utilizará y ampliará durante muchos años .

En segundo lugar, en la parte 2, echamos un vistazo crítico a estas nuevas características, especialmente a sus implicaciones en el rendimiento . Primero, vimos que el uso de UDP por parte de QUIC no lo hace mágicamente más rápido (ni más lento) porque QUIC usa mecanismos de control de congestión muy similares a TCP para evitar sobrecargar la red. En segundo lugar, el protocolo de enlace más rápido y 0-RTT son más micro optimizaciones, porque en realidad son solo un viaje de ida y vuelta más rápido que una pila TCP + TLS optimizada, y el verdadero 0-RTT de QUIC se ve afectado aún más por una variedad de problemas de seguridad que pueden limitar su utilidad En tercer lugar, la migración de la conexión solo es necesaria en algunos casos específicos, y todavía significa restablecer las tasas de envío porque el control de congestión no sabe cuántos datos puede manejar la nueva red. En cuarto lugar, la eficacia de la eliminación del bloqueo de cabeza de línea de QUIC depende en gran medida de cómo se multiplexen y prioricen los datos de flujo. Los enfoques que son óptimos para recuperarse de la pérdida de paquetes parecen perjudiciales para los casos de uso general del rendimiento de carga de páginas web y viceversa, aunque se necesita más investigación. En quinto lugar, QUIC podría ser fácilmente más lento para enviar paquetes que TCP + TLS, porque las API UDP son menos maduras y QUIC encripta cada paquete individualmente, aunque esto puede mitigarse en gran medida con el tiempo. En sexto lugar, HTTP/3 en sí mismo no trae ninguna característica de rendimiento importante a la mesa, pero principalmente reelabora y simplifica las funciones internas de HTTP/2 conocidas. Finalmente, algunas de las funciones más emocionantes relacionadas con el rendimiento que permite QUIC (múltiples rutas, datos no confiables, WebTransport, corrección de errores de reenvío, etc.) no forman parte de los estándares básicos de QUIC y HTTP/3, sino que son extensiones propuestas que tomarán más tiempo para estar disponible. En conclusión, esto significa que QUIC probablemente no mejorará mucho el rendimiento para los usuarios en redes de alta velocidad, pero será importante principalmente para aquellos en redes lentas y menos estables .

Finalmente, en esta parte 3, vimos cómo usar e implementar de manera práctica QUIC y HTTP/3 . Primero, vimos que la mayoría de las mejores prácticas y lecciones aprendidas de HTTP/2 deberían trasladarse a HTTP/3. No hay necesidad de cambiar su estrategia de agrupación o integración, ni de consolidar o fragmentar su granja de servidores. Server push todavía no es la mejor característica para usar, y la preload puede ser igualmente una poderosa arma de fuego. En segundo lugar, hemos discutido que puede tomar un tiempo antes de que los paquetes de servidores web listos para usar brinden soporte completo de HTTP/3 (en parte debido a problemas de soporte de la biblioteca TLS), aunque hay muchas opciones de código abierto disponibles para los primeros usuarios y varios CDN importantes tienen una oferta madura. En tercer lugar, está claro que la mayoría de los principales navegadores tienen soporte HTTP/3 (básico), incluso habilitado de forma predeterminada. Sin embargo, existen grandes diferencias en cómo y cuándo usan HTTP/3 y sus nuevas funciones en la práctica, por lo que comprender su comportamiento puede ser un desafío. En cuarto lugar, hemos discutido que esto empeora por la falta de soporte explícito de HTTP/3 en herramientas populares como Lighthouse y WebPageTest, lo que hace que sea especialmente difícil comparar el rendimiento de HTTP/3 con HTTP/2 y HTTP/1.1 en este momento. En conclusión, es probable que HTTP/3 y QUIC aún no estén listos para el horario estelar, pero pronto lo estarán .

Recomendaciones

Del resumen anterior, puede parecer que estoy presentando fuertes argumentos en contra del uso de QUIC o HTTP/3. Sin embargo, eso es bastante opuesto al punto que quiero hacer.

En primer lugar, como se explicó al final de la parte 2, aunque es posible que su usuario "promedio" no experimente mejoras importantes en el rendimiento (dependiendo de su mercado objetivo), es probable que una parte significativa de su audiencia vea mejoras impresionantes . Es posible que 0-RTT solo ahorre un solo viaje de ida y vuelta, pero eso aún puede significar varios cientos de milisegundos para algunos usuarios. Es posible que la migración de la conexión no sostenga descargas rápidas constantes, pero definitivamente ayudará a las personas que intentan obtener ese PDF en un tren de alta velocidad. La pérdida de paquetes en el cable puede ser en ráfagas, pero los enlaces inalámbricos pueden beneficiarse más de la eliminación del bloqueo de cabeza de línea de QUIC. Es más, estos usuarios son los que normalmente encontrarían el peor rendimiento de su producto y, en consecuencia, se verían más afectados por él. Si se pregunta por qué es importante, lea la famosa anécdota de rendimiento web de Chris Zacharias.

En segundo lugar, QUIC y HTTP/3 mejorarán y serán más rápidos con el tiempo . La versión 1 se ha centrado en realizar el protocolo básico, manteniendo las funciones de rendimiento más avanzadas para más adelante. Como tal, creo que vale la pena comenzar a invertir en los protocolos ahora, para asegurarse de que pueda usarlos y las nuevas funciones de manera óptima cuando estén disponibles en el futuro. Dada la complejidad de los protocolos y sus aspectos de implementación, sería bueno darse un tiempo para familiarizarse con sus peculiaridades. Incluso si no quiere ensuciarse las manos todavía, varios de los principales proveedores de CDN ofrecen compatibilidad con HTTP/3 madura de "pulsar el interruptor" (particularmente, Cloudflare y Fastly). Lucho por encontrar una razón para no probar eso si está usando un CDN (que, si le importa el rendimiento, realmente debería hacerlo).

Como tal, aunque no diría que es crucial comenzar a usar QUIC y HTTP/3 tan pronto como sea posible, creo que ya se pueden obtener muchos beneficios, y solo aumentarán en el futuro .

Otras lecturas

Si bien este ha sido un largo cuerpo de texto, lamentablemente, en realidad solo araña la superficie técnica de los protocolos complejos que son QUIC y HTTP/3.

A continuación encontrará una lista de recursos adicionales para el aprendizaje continuo, más o menos en orden ascendente de profundidad técnica:

• "Explicación de HTTP/3", Daniel Stenberg
  Este libro electrónico, del creador de cURL, resume el protocolo.
• “HTTP/2 en acción”, Barry Pollard
  Este excelente libro completo sobre HTTP/2 tiene consejos reutilizables y una sección sobre HTTP/3.
• @programaciónart, Twitter
  La mayoría de mis tweets están dedicados a QUIC, HTTP/3 y rendimiento web (incluidas las noticias) en general. Vea, por ejemplo, mis hilos recientes sobre las características de QUIC.
• “YouTube”, Robin Marx
  Mis más de 10 charlas en profundidad cubren varios aspectos de los protocolos.
• “El blog de Cloudlare”
  Este es el producto principal de una empresa que también ejecuta un CDN en el lateral.
• “El blog de Fastly”
  Este blog tiene excelentes discusiones sobre aspectos técnicos, integrados en un contexto más amplio.
• QUIC, los RFC reales
  Encontrará enlaces a los documentos IETF QUIC y HTTP/3 RFC y otras extensiones oficiales.
• Blog de ingenieros de IIJ: Excelentes explicaciones técnicas detalladas de los detalles de las funciones QUIC.
• Artículos académicos HTTP/3 y QUIC, Robin Marx
  Mis trabajos de investigación cubren la multiplexación y priorización de flujos, las herramientas y las diferencias de implementación.
• QUIPS, EPIQ 2018 y EPIQ 2020
  Estos documentos de talleres académicos contienen investigaciones detalladas sobre seguridad, rendimiento y extensiones de los protocolos.

Con eso, te dejo, querido lector, con una mejor comprensión de este valiente nuevo mundo. Siempre estoy abierto a recibir comentarios, ¡así que hágame saber lo que piensa de esta serie!