Http / 3: Opciones De Implementación Prácticas (Parte 3)

Hola, y bienvenido a la parte final de esta serie de tres partes en los nuevos protocolos HTTP / 3 y QUIC! Si después de la historia anterior de dos partes y los conceptos principales y las funciones de rendimiento HTTP / 3, está convencido de que comienza a usar los nuevos protocolos es una buena idea (¡y debería serlo!), Por lo tanto, esta parte final incluye todo lo que necesita saber. ¡Para empezar!

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

Esta serie se divide en tres partes:

Historia HTTP / 3 y conceptos básicos Esto está orientado a nuevas personas en http / 3 y protocolos en general, y especialmente analiza los conceptos básicos. Características de rendimiento HTTP / 3 Esto es más profundo y técnico. Las personas que ya saben lo básico pueden llegar aquí. Opciones prácticas de implementación HTTP / 3 (Artículo actual) Esto explica los desafíos involucrados en la prueba de implementación y HTTP / 3 por su cuenta. Detalle cómo y si debe cambiar sus páginas web y funciones también. CAMBIOS EN PÁGINAS Y FUNCIONES

Comencemos con algunas buenas noticias: Si ya usa HTTP / 2, ¡probablemente no necesitará cambiar nada en sus páginas o funciones al cambiar a http / 3!. Esto se debe a que, como explicamos en la Parte 1 y la Parte 2, HTTP / 3 es en realidad más como HTTP / 2-Over-Quic, y las características de alto nivel de las dos versiones permanecieron iguales. Como tal, cualquier cambio u optimización realizado a HTTP / 2 aún funcionará para HTTP / 3 y viceversa.

Sin embargo, si aún está en http / 1.1 o olvida su transición a http / 2, o nunca ha ajustado las cosas a http / 2, para que pueda preguntarse cuáles son estos cambios y por los cuales se necesiten. Sin embargo, lo harías difícil encontrar un buen artículo que detalla las mejores prácticas con matices. Esto se debe a que, como dije en la introducción de la Parte 1, gran parte del contenido inicial HTTP / 2 fue excesivamente optimista sobre cómo funcionaría bien en la práctica, y algunos de ellos, francamente, tenían graves errores y malos consejos. Desafortunadamente, en la actualidad, gran parte de esta desinformación persiste hoy. Esta es una de mis motivaciones principales al escribir esta serie en HTTP / 3, para ayudar a evitar que esto vuelva a suceder.

La mejor fuente multifuncional para HTTP / 2 que puedo recomendar en este momento es el libro HTTP / 2 en Barry Pollard Action. Sin embargo, como es un recurso pagado y no quiero que intente adivinar aquí, enumeré algunos de los puntos principales a continuación, junto con la forma en que se relacionan con HTTP / 3:

1. Conexión única

La diferencia más grande entre HTTP / 1.1 y http / 2 fue el cambio de 6 a 30 conexiones paralelas de TCP a una sola conexión TCP subyacente. Discutimos un poco en la Parte 2, ya que una sola conexión aún puede ser tan rápida como múltiples conexiones, debido a cómo el control de congestión puede causar más o más pérdida de paquetes con más conexiones (lo que deshace los beneficios de su agregado más rápido). HTTP / 3 continuó este enfoque, pero «solo» cambia una conexión TCP a una conexión RIIC. Esta diferencia por sí misma no hace mucho (reduce principalmente la sobrecarga en el lado del servidor), pero conduce a la mayoría de los siguientes puntos.

2. Fragmentación del servidor y coalescencia de conexión

El cambio a la configuración de una sola conexión fue bastante difícil en la práctica porque muchas páginas se han fragmentado en diferentes nombres de host e incluso servidores (como IMG1. Ejemplo.com e img2.example.com) Esto ocurrió porque los navegadores solo abren hasta seis conexiones para cada nombre de host individual, ¡así que tiene múltiples conexiones permitidas para más! Sin cambios en esta configuración HTTP / 1.1, HTTP / 2 aún abriría múltiples conexiones, lo que reducirá qué tan bien, como la priorización (ver más abajo), podría funcionar.

Entonces, la recomendación original era deshacer la fragmentación del servidor y consolidar los recursos en un solo servidor lo más posible. HTTP / 2 incluso proporcionó una función para realizar la transición de una configuración http / 1.1 fácil, llamada la unión de conexión. Modo al por mayor, si dos nombres de host se resuelven al mismo servidor IP (usando DNS) y usan un certificado de TLS similar, el navegador puede reutilizar una sola conexión incluso entre los dos nombres de host.

En la práctica, la coalescencia de la conexión puede ser difícil de tener en cuenta, por ejemplo, debido a varios problemas de seguridad sutiles que involucran a CORS. Incluso si lo configura correctamente, todavía puede terminar fácilmente con dos conexiones separadas. El punto es que no siempre es malo. Primero, debido a la priorización y la multiplexación poco implementada (ver más abajo), la conexión única puede ser fácilmente más lenta que usar dos o más. En segundo lugar, el uso de muchas conexiones puede causar la pérdida temprana de los paquetes debido a los controladores de congestión de la competencia. Use solo unos pocos (pero incluso más de uno), sin embargo, puede equilibrar 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, dos a cuatro conexiones), incluso con http / 2. De hecho, creo que la mayoría de las configuraciones HTTP / 2 modernas tienen un buen rendimiento, ya que todavía tienen algunas conexiones adicionales o cargas de terceros en su camino crítico.

3. Paquete de recursos y en línea

En http / 1.1, puede tener solo una única característica activa por conexión, lo que lleva al bloqueo del encabezado de la línea (HOL) en el nivel HTTP. Como el número de conexiones se limitó a los miseros 6 a 30, la agrupación de recursos (donde los sub-recursos menores se combinan en un solo recurso más grande) fue una práctica recomendada de larga data. Todavía vemos esto hoy en Packers como la mack. Asimismo, los recursos a menudo fueron incrustados en otros recursos (por ejemplo, CSS crítico se incrustó en HTML).

con http / 2, sin embargo, los recursos de conexión múltiplex individuales, puede tener muchas más solicitudes pendientes de archivos (en otras palabras, una sola solicitud no ocupa una más de tus pocas y preciables conexiones). Esto se interpretó originalmente como «Ya no necesitamos agrupar o incrustar nuestros recursos para HTTP / 2». Este enfoque se consideró mejor para el caché de baja granularidad porque cada sub-recurso puede almacenarse en caché individualmente y el paquete completo no necesita ser descargado nuevamente si uno cambia. Eso es cierto, pero solo en cierta medida.

Por ejemplo, puede 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 tratado por el navegador y el servidor. Estos costos pueden alcanzar, di cientos de archivos pequeños en comparación con unos pocos grandes. En nuestras propias pruebas iniciales, descubrí que los devoluciones disminuyeron seriamente en unos 40 archivos. Aunque estos números son probablemente un poco más altos, las solicitudes de archivos aún no son tan baratas en HTTP / 2 como se predice originalmente. Finalmente, ninguna característica en línea tiene un costo de latencia adicional porque el archivo debe ser solicitado. Esto, combinado con la priorización y los problemas de empuje del servidor (ver más abajo), significa que hasta hoy sigue siendo mejor incrustar algunos de sus CS críticos. Tal vez algún día, la propuesta de los paquetes de recursos ayuda con esto, pero aún no.

Todo esto, por supuesto, sigue siendo cierto para HTTP / 3 también. Aun así, leí a las personas que afirman que muchos archivos pequeños serían mejores con el QUIC porque los flujos más independientes simultáneamente los activos significan más beneficios con la eliminación del bloqueo HOL (como discutimos en la Parte 2). Creo que puede haber alguna verdad en ella, pero como también vimos en la Parte 2, este es un problema altamente complejo con muchos parámetros móviles. No creo que los beneficios superen los otros costos discutidos, pero se necesita más investigación. (Un pensamiento escandaloso sería tener todos los archivos exactamente de tamaño para adaptarse a un solo paquete de ROX, ignorando completamente el bloque HOL. Aceptaré regalías de cualquier arranque que implemente un grupo de recursos que lo haga.;)

4. Priorización

Para poder descargar varios archivos en una sola conexión, debe variarlos de alguna manera. Como se explica en la Parte 2 en http / 2, esta multiplexación se dirige utilizando su sistema de priorización. Por eso es importante tener tantos recursos posibles solicitados en la misma conexión, para poder priorizarlos adecuadamente entre sí. Sin embargo, como también vimos, este sistema era muy complejo, lo que a menudo hacía mal uso e implementado en la práctica (ver la imagen a continuación). Esto, a su vez, significa que algunas otras recomendaciones para el embalaje HTTP / 2, como las solicitudes son baratas, y la reducción de la fragmentación del servidor, para que el uso ideal de la conexión única (ver más arriba) -cabida presentando un bajo rendimiento en la práctica..

Desafortunadamente, esto es algo que usted, como desarrollador web común, no puede hacer mucho, ya que es principalmente un problema en los navegadores y servidores. Sin embargo, puede intentar mitigar el problema, no utilizar muchos archivos individuales (que disminuirán las posibilidades de las prioridades de la competencia) y aún utilizando la fragmentación (limitada). Otra opción es usar diversas técnicas de influencia prioritarias, como la carga lenta, el ASYNC JavaScript y el posponión y las puntas de las características como precarga. Internamente, cambian principalmente las prioridades de los recursos que se enviarán antes o más tarde. Sin embargo, estos mecanismos pueden (y tener) sufren de insectos. Además, no espere poner un precio previo en muchos recursos y hacer las cosas más rápido: si todo se convierta repentinamente a una alta prioridad, ¡entonces nada es! Todavía es muy fácil retrasar las características realmente críticas utilizando cosas como la carga previa.

Como se explica en la Parte 2, HTTP / 3 cambia fundamentalmente los aspectos internos de este sistema de priorización. Esperamos que esto signifique que haya mucha menos errores y problemas con su implementación práctica, por lo que se debe resolver al menos algunos de ellos. Sin embargo, no podemos estar seguros, ya que pocos servidores y clientes HTTP / 3 implementan completamente este sistema hoy. Sin embargo, los conceptos fundamentales de la priorización no cambiarán. Aún no podrá usar técnicas como la precarga sin comprender realmente lo que sucede internamente porque esto todavía puede priorizar sus recursos.

5. Push del servidor y primer vuelo

Server Push permite que un servidor envíe datos de respuesta sin que primero espere una solicitud de cliente. Nuevamente, esto se ve muy bien en teoría y se puede utilizar en lugar de recursos incorporados (ver arriba). Sin embargo, como se discutió en la Parte 2, el empuje es muy difícil de usar adecuadamente debido a problemas con el control de congestión, el almacenamiento en caché, priorización y almacenamiento de tampón. En general, es mejor no usarlo para la carga general de las páginas web, a menos que realmente sepa lo que está haciendo e incluso, es probable que sea una microotimización. Todavía creo que podría haber un lugar con API (descanso), donde puede enviar sub-recursos vinculados a la respuesta (JSON) en una conexión calentada. Esto es cierto para http / 2 y http / 3.

Para generalizar un poco, creo que se podría hacer comentarios similares para la reanudación de la sesión de TLS y 0-RTT, ya sea sobre TCP + TLS o a través de QUIC. Como se discutió en la Parte 2, 0-RTT es similar al empuje del servidor (como se usa generalmente), porque intenta acelerar las primeras etapas de la carga de una página. Sin embargo, esto significa que es igualmente limitado en lo que puede alcanzar en ese momento (incluso más en la ROCI, debido a problemas de seguridad). Como tal, una micro optimización es, nuevamente, ya que probablemente necesite ajustar las cosas en un nivel bajo para beneficiarse realmente de él. Y pensar que una vez que estuve muy emocionado de tratar de combinar el empuje del servidor con 0-RTT.

¿Qué significa eso?

Todo lo que se ha descrito anteriormente se resume a una regla práctica simple: Aplique las recomendaciones más típicas de HTTP / 2 que usted encuentra en línea, pero no los lleve al extremo.

Aquí hay algunos puntos de concreto que se aplican principalmente http / 2 y http / 3:

de los recursos de la fragmentación en aproximadamente una a tres conexiones en la ruta crítica (a menos que sus usuarios estén principalmente en Red de ancho de banda baja), utilizando DNS predefinidos y pre-buscar donde sea necesario. Paquete de sub-recursos lógicamente por ruta o recurso, o por frecuencia de cambio. Cinco a diez características de JavaScript y cinco a diez características CSS por página deben ser suficientes. CSS crítico incorporado puede ser una buena optimización. Use características complejas como la precarga, moderada. Use un servidor que admite correctamente la priorización HTTP / 2. Para http / 2, recomiendo H2O. Apache y NGINX están en su mayoría bien (aunque podría ser mejor), mientras que los nodos.js deben evitarse para HTTP / 2. Para HTTP / 3, las cosas están menos claras en este momento (ver más abajo). Asegúrese de que TLS 1.3 esté habilitado en su servidor web http / 2.

Como puede ver, aunque lejos de las páginas simples de optimización de HTTP / 3 (y HTTP / 2) no es una ciencia espacial. Sin embargo, lo que será más difícil es configurar correctamente los servidores, los clientes y las herramientas HTTP / 3.

servidores y redes

Como probablemente ya debe comprender, QUIC y HTTP / 3 son protocolos muy complejos. ¡Implementarlos de cero implicaría la lectura (y la comprensión!) Cientos de páginas se difundieron en más de siete documentos. Afortunadamente, varias compañías han trabajado en implementaciones de QUIC y HTTP / 3 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 lo siguiente:

Sin embargo, muchos (quizás más) de estas implementaciones cuidan principalmente de HTTP / 3 y ROCI; 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 ligeramente más lentas por varias razones. Primero, pocos de sus desarrolladores estaban involucrados con HTTP / 3 desde el principio y ahora necesitan actualizar. Muchos evitan esto utilizando una de las implementaciones enumeradas anteriormente internamente como bibliotecas, pero incluso esta integración es difícil.

En segundo lugar, muchos servidores dependen de bibliotecas TLS de terceros, como OpenSSL. Nuevamente, esto se debe a que TLS es muy complejo y debe estar seguro, por lo que es mejor reutilizar el trabajo existente verificado. Sin embargo, aunque el QUIC se integra en TLS 1.3, lo utiliza en formas muy diferentes de cómo interactúan las TLS y TCP. Esto significa que las bibliotecas de TLS deben proporcionar API específicas de KIC, que sus desarrolladores reacios o son lentos durante mucho tiempo. El problema aquí especialmente es OpenSSL, que ha retrasado el soporte de RIGHT, pero también es utilizado por muchos servidores. Este problema fue tan malo que Akamai decidió iniciar un tenedor específico del OpenSSL ROC, llamado Quedicls. Si bien hay otras opciones y soluciones alternativas, el soporte TLS 1.3 para RIGS sigue siendo un bloqueador para muchos servidores y se espera que continúe esto durante algún tiempo.

Una lista parcial de servidores web completos que debe poder usar fuera de la caja, junto con su soporte HTTP / 3 actual, luego:

apache El soporte no es de Curso en este momento. Nada fue anunciado. Probablemente también necesita el OpenSSL. (Tenga en cuenta que, sin embargo, hay una implementación de servidor de tráfico Apache. «Nginx, esta es una implementación personalizada. Esto es relativamente nuevo y aún muy experimental. Se espera que se fusione con la línea principal NGINX hasta el final de 2021. Esto es relativamente nuevo y aún muy experimental. Tenga en cuenta que hay un parche para ejecutar la biblioteca de CloudFlare Quiches en Nginx, que es probablemente más estable por ahora. Node.js Esto utiliza la biblioteca NGTCP2 internamente. Está bloqueado por el progreso de OpenSSL, aunque planean cambiar a la bifurcación de QUIC-TLS para obtener algo que funcione anteriormente. IIS El apoyo no está claro en este momento y no se ha anunciado nada. Probablemente, usará la biblioteca MSQUIC internamente. HyperCorn integra aioquic, con apoyo experimental. Caddy Esto usa Kic-Go, con soporte completo. H2O se usa rápidamente, con soporte completo. Litespeed Esto usa LSQUIC, con soporte completo.

Observe algunos matices importantes:

incluso «soporte completo» significa «lo más bueno posible en este momento», no necesariamente «listo para la producción». Por ejemplo, muchas implementaciones aún no proporcionan soporte completo para la migración de la conexión, 0-RTT, servidor Push o priorización HTTP / 3. Otros servidores que no figuran en la lista, como Tomcat, (lo que sé) aún no han hecho ningún anuncio. Desde los servidores web listados, solo LITEPEED, NGINX NGINX PATCH de CloudFlare y H2O han sido realizados por personas estrechamente involucradas en la estandarización de QUIC y HTTP / 3, por lo que es más probable que funcione mejor al principio.

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

Configuración de red

Como se explica en la Parte 1, el QUIC se ejecuta en la parte superior del protocolo UDP para facilitar la implementación. Esto, sin embargo, significa solo que la mayoría de los dispositivos de red pueden analizar y comprender el UDP. Desafortunadamente, esto no significa que el UDP esté permitido universalmente. A medida que el UDP se usa a menudo para los ataques y no es crítico para el trabajo diario normal más allá de DNS, muchas redes corporativas y firewalls bloquean casi por completo. Como tal, probablemente UDP debe permitirse explícitamente a / desde sus servidores HTTP / 3. El QUIC puede ejecutarse en cualquier puerto UDP, pero espera que el puerto 443 (que generalmente se usa para HTTPS en TCP) es el más común.

Sin embargo, muchos administradores de red no querrán permitir solo UDP en la venta al por mayor. En su lugar, querrán permitir específicamente el KIC en UDP. El problema es que, como hemos visto, el KIC está casi completamente encriptado. Esto incluye metadatos de nivel de QUIC, como los números de paquetes, pero también, por ejemplo, las señales que indican un cierre de conexión. Para TCP, los firewalls rastran activamente todos estos metadatos para verificar el comportamiento esperado. (¿Vimos un apretón de manos completo antes de los paquetes de transporte de datos? ¿Los paquetes siguen los estándares 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 puede ser prácticamente evolucionado.. Sin embargo, debido al encriptación de QUIC, los firewalls 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 firewalls de proveedores actualmente recomiendan bloquear el RIG. Hasta que puedan actualizar su software. Sin embargo, incluso después de eso, es posible que muchas compañías no quieran permitir, porque el soporte para el firewallx, siempre será mucho más pequeño que los recursos TCP que están acostumbrados.

Todo esto es aún más complicado por el recurso de migración de conexión. Como hemos visto, esta función permite que la conexión continúe desde una nueva dirección IP sin la necesidad de realizar un nuevo apretón de manos, mediante el uso de ID de conexión (CIDS). Sin embargo, para el firewall, esto se verá como si se usara una nueva conexión sin que primero use un apretón de manos, que bien puede ser un atacante que envía un tráfico malicioso. Los firewalls no solo pueden usar los CIDs KICI porque también cambian con el tiempo para proteger la privacidad de los usuarios. Como tal, habrá cierta necesidad de que los servidores se comuniquen con el firewall en el que se esperan los cids, pero nada de esto todavía existe.

Hay preocupaciones similares para los equilibradores de carga para configuraciones a gran escala. Estas máquinas distribuyen conexiones entrantes en una gran cantidad de servidores de back-end. El tráfico para una conexión debe, por supuesto, siempre se enruta al mismo servidor de back-end (otros no sabrían qué hacer con él). Para TCP, esto se podría hacer simplemente basado en 4-tuple, porque nunca cambia. Sin embargo, con la migración de la conexión de RIOG, esta ya no es una opción. Nuevamente, los servidores y los equilibradores de carga deberán acordar de alguna manera a la que el CIDS elija permitir el enrutamiento determinista. Sin embargo, a diferencia de la configuración de Firewall, ya existe una propuesta para configurar esto (aunque esto está lejos de ser ampliamente implementado).

Finalmente, hay otras consideraciones de seguridad de nivel superior, especialmente alrededor de 0-RTT y ataques de denegación de servicios distribuidos (DDo). Como se discutió en la Parte 2, Quic ya incluye algunas atenuaciones para estos problemas, pero, idealmente, también usarán líneas de defensa adicionales en la red. Por ejemplo, los servidores proxy o de borde pueden bloquear ciertas solicitudes de 0 rtt para alcanzar los extremos reales reales para evitar ataques repetidos. Alternativamente, para evitar ataques de reflexión o ataques DDO que envíen solo el primer paquete de apretón de manos y luego deja de responder (llamado Syn Inundación en TCP), el RICE incluye la nueva función Intento. Esto permite que el servidor de validación sea un cliente de buen comportamiento sin tener que mantener a ningún estado mientras tanto (el equivalente de las cookies SYN TCP). Este nuevo proceso de intento ocurre mejor, por supuesto, en algún lugar antes del servidor de back-end, por ejemplo, en el equilibrador de carga. Sin embargo, nuevamente, esto requiere una configuración y comunicación adicional para configurar.

Estos son solo los problemas más destacados que los administradores de la red y del sistema, tendrán RIGHT y HTTP / 3. Hay varios otros, algunos de los cuales ya he dicho. También hay dos documentos de acompañamiento separados para RFCS RFCS que discuten estos problemas y su posible mitigación (parcial).

¿Qué significa todo esto?

HTTP / 3 y QUIC son protocolos complejos que dependen de muchos mecanismos internos. No todo esto está listo para la hora de máxima, aunque ya tiene algunas opciones para implementar los nuevos protocolos en sus extremos de back-fines. Probablemente tomará unos meses hasta los años para que se actualicen los servidores más prominentes y las bibliotecas subyacentes (como OpenSSL).

Aun así, configurando correctamente los servidores y otros intermedios de la red, por lo que los protocolos se pueden usar de manera segura y ociosa, no serán triviales en la configuración de gran escala. Necesitará un buen equipo de desarrollo y operaciones para hacer esta transición correctamente.

De esta manera, especialmente en los primeros días, es probable que sea mejor confiar en una gran empresa de alojamiento o CDN para configurar y configurar los protocolos para usted. Como se discutió en la Parte 2, es donde es más probable que el QUIC regrese de todos modos, y usar un CDN es una de las principales optimizaciones de rendimiento que puede hacer. Personalmente, recomiendo usar CloudFlare o rápidamente porque estaban estrechamente involucrados en el proceso de estandarización y tendrán las implementaciones más avanzadas y bien establecidas disponibles.

Clientes y Quic Discovery

Hasta ahora, consideramos el soporte lateral de servidor y la red para los nuevos protocolos. Sin embargo, varios problemas también deben superarse en el lado del cliente.

Antes de llegar a eso, comencemos con algunas buenas noticias: ¡la mayoría de los navegadores populares ya tienen (experimentales) HTTP / 3 SOPORTE! Específicamente, en el momento de la escritura, aquí está el estado de soporte (consulte también 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 (utiliza cromo internamente). Opera (versión 77+): habilitado por defecto (utiliza cromo internamente). Apple Safari (versión 14): detrás del manual de la bandera. Se habilitará de forma predeterminada en la versión 15, que se encuentra actualmente en la vista previa de la tecnología. Otros navegadores: Sin señales todavía que conozco (aunque otros navegadores que usan el cromo internamente, como valientes, podrían, en teoría, también comenzar a habilitarlo).

Nota Algunos matices:

La mayoría de los navegadores se están lanzando gradualmente, por lo que no todos los usuarios obtendrán la compatibilidad http / 3 habilitada de forma predeterminada desde el principio. Esto se hace para limitar los riesgos de que un solo error pasado por alto podría afectar a muchos usuarios o que las implementaciones del servidor se sobrecargan. Tales, existe la pequeña posibilidad de que, incluso en las últimas versiones del navegador, no obtendrá HTTP / 3 de forma predeterminada y tendrá que habilitarlo manualmente. Los servidores, el soporte HTTP / 3 no significa que todas las funciones se hayan implementado o utilicen en este momento. Particularmente, 0-RTT, la migración de la conexión, la compresión del encabezado del servidor, la compresión del encabezado de QPACK dinámico y la prioridad HTTP / 3 aún pueden faltar, deshabilitadas, se usan con moderación, o Poormo configuradas. Si desea usar el lado de cliente HTTP / 3 fuera del navegador (por ejemplo, en su aplicación nativa), entonces tendrá que integrar una de las bibliotecas enumeradas anteriormente o usar CURL. Apple HIR LLEGARÁ HTTP / 3 y el soporte nativo de HTTP / 3 y QUIC a sus bibliotecas de redes incorporadas en MacOS y IOS, y Microsoft está agregando RIG al kernel de Windows y anunció para otros sistemas como Android.

Alt-SVC

Incluso si ha configurado un servidor HTTP / 3 compatible y está utilizando un navegador actualizado, es posible que se sorprenda al encontrar que HTTP / 3 ISN ‘ En realidad ser usado constantemente. Para entender por qué, supongamos que eres el navegador por un momento. Su usuario ha requerido que navegue a Ejemplo.com (la web nunca haya visitado antes), y ha utilizado DNS para resolverlo a una IP. Envía uno o más paquetes de apretón de manos de ROX a esa IP. Ahora, varias cosas pueden ir mal:

El servidor puede no admitir ax. Una de las redes o firewalls intermedios puede bloquear completamente a KIG y / o UDP. Los paquetes de apretón de manos pueden perderse en tránsito.

Sin embargo, ¿cómo sabría (que) se ha producido uno de los problemas? En los tres casos, nunca recibirá respuesta a su (s) paquete (s) de apretón de manos. Lo único que puedes hacer es esperar, con la esperanza de que todavía pueda entrar una respuesta. Luego, después de algún tiempo de espera (el tiempo de espera), es posible que decida el problema con HTTP / 3. En ese momento, intentaría abrir una conexión TCP al servidor, con la esperanza de que funcione http / 2 o http / 1.1.

Como puede ver, este tipo de enfoque podría ingresar mayores retrasos, especialmente En el (los) año (s) inicial (es) cuando muchos servidores y redes no apoyarán a Rich. Una solución fácil pero ingenua simplemente será abrir tanto una conexión RIIC como TCP al mismo tiempo y luego usaría el apretón de manos que se complete primero. Este método se llama «Racing de conexión» o «globos oculares felices». Si bien esto es ciertamente posible, tiene disponible en lo alto. A pesar de que la conexión perdida se cierra casi de inmediato, todavía ocupa un tiempo de memoria y CPU tanto en el cliente como en el servidor (especialidad cuando se usa TLS). Además de eso, también hay otros problemas con este método que involucra a las redes IPv4 versus IPv6 y los ataques de reproducción discutidos anteriormente (lo que mi charla cubre con más detalle).

tal, para KIC y HTTP / 3, Los navegadores preferirían jugar a la caja fuerte y solo probarían a RIG. Si saben que el servidor lo respalda. Dicha, la primera vez que se comunica con un nuevo servidor, el navegador solo usará HTTP / 2 o HTTP / 1.1 sobre la conexión TCP. Luego, el servidor puede permitir que el navegador sepa que también admite HTTP / 3 para las conexiones posteriores. Esto se hace mediante la configuración en el 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 usar para que un navegador sepa que un servicio determinado también se puede alcanzar a través de otro servidor (IP y / o Puerto), pero también permite la indicación de los protocolos alternativos. Esto se puede ver a continuación en la Figura 1.

Al recibir un encabezado ALT-SVC válido que indique HTTP / 3 Soporte, el navegador almacenará esto y intentará configurar la conexión RIOG. Los mismos clientes lo harán de esto lo más pronto posible (incluso durante la carga de la página inicial, ver más abajo), mientras que otros esperarán hasta que las conexiones TCP (s) existentes se cierren. Esto significa que el navegador solo usará http / 3 después de que haya descargado al menos a algunos recursos a través de http / 2 o http / 1.1 primero. Incluso entonces, no es una navegación suave. El navegador ahora sabe que el servidor admite HTTP / 3, pero eso no significa que la red intermedia no lo bloquee. Tales, las carreras de conexión aún se necesitan en la práctica. Por lo tanto, aún así, puede terminar con HTTP / 2 si la red de alguna manera retrasa el apretón de manos de ROXF. Additionally, if the QUIC connection fails to establish a few times in a row, some browsers will put the Alt-Svc cache entry on a denylist for some time, not trying HTTP/3 for a while. As such, it can be helpful to manually clear your browser’s cache if things are acting up because that should also empty the Alt-Svc bindings. Finally, Alt-Svc has been shown to pose some serious security risks. For this reason, some browsers pose extra restrictions on, for instance, which ports can be used (in Chrome, your HTTP/2 and HTTP/3 servers need to be either both on a port below 1024 or both on a port above or equal to 1024, otherwise Alt-Svc will be ignored). All of this logic varies and evolves wildly between browsers, meaning that getting consistent HTTP/3 connections can be difficult, which also makes it challenging to test new set-ups.

There is ongoing work to improve this two-step Alt-Svc process somewhat. The idea is to use new DNS records called SVCB and HTTPS, which will contain information similar to what is in Alt-Svc. As such, the client can discover that a server supports HTTP/3 during the DNS resolution step instead, meaning that it can try QUIC from the very first page load instead of first having to go through HTTP/2 or HTTP/1.1. For more information on this and Alt-Svc, see last year’s Web Almanac chapter on HTTP/2.

As you can see, Alt-Svc and the HTTP/3 discovery process add a layer of complexity to your already challenging QUIC server deployment, because:

you will always need to deploy your HTTP/3 server next to an HTTP/2 and/or HTTP/1.1 server; you will need to configure your HTTP/2 and HTTP/1.1 servers to set the correct Alt-Svc headers on their responses.

While that should be manageable in production-level set-ups (because, for example, a single Apache or NGINX instance will likely support all three HTTP versions at the same time), it might be much more annoying in (local) test set-ups (I can already see myself forgetting to add the Alt-Svc headers or messing them up). This problem is compounded by a (current) lack of browser error logs and DevTools indicators, which means that figuring out why exactly the set-up isn’t working can be difficult.

Additional Issues

As if that wasn’t enough, another issue will make local testing more difficult: Chrome makes it very difficult for you to use self-signed TLS certificates for QUIC. This is because non-official TLS certificates are often used by companies to decrypt their employees’ TLS traffic (so that they can, for example, have their firewalls scan inside encrypted traffic). However, if companies would start doing that with QUIC, we would again have custom middlebox implementations that make their own assumptions about the protocol. This could lead to them potentially breaking protocol support in the future, which is exactly what we tried to prevent by encrypting QUIC so extensively in the first place! 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.

What Does It All Mean?

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.

Google Lighthouse

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

Compartir