Get best of the week

Comparación de rendimiento HTTP / 3 y HTTP / 2



En Cloudflare, anunciamos soporte HTTP / 3 en septiembre pasado cuando celebrábamos nuestro noveno cumpleaños . Nuestro objetivo siempre ha sido mejorar Internet. La colaboración en el campo de los estándares es una parte importante del proceso, y tenemos la suerte de participar en el desarrollo de HTTP / 3.

Aunque HTTP / 3 aún se encuentra en la etapa de borrador, notamos un gran interés en el nuevo protocolo por parte de nuestros usuarios (la infraestructura de Cloudflare sirve a más del 10% de los sitios de Internet, aproximadamente por persona). Hasta la fecha, más de 113,000 zonas han activado el soporte HTTP / 3, y si tiene un navegador experimental, ¡ahora puede acceder a estas zonas usando el nuevo protocolo! Es genial que tanta gente lo haya incluido: trabajar en HTTP / 3 de una gran cantidad de sitios web reales significa que puede probar más propiedades diferentes desde los navegadores.

Inicialmente lanzamos HTTP / 3 en asociación con Google, que también incluía soporte experimental para Chrome Canary. Desde entonces, cada vez más navegadores han agregado soporte experimental: apareció en las versiones de Firefox Nightly , en varios navegadores basados ​​en Chromium como Opera y Edge (a través del motor base de Chromium), y en las versiones preliminares de Safari. Monitoreamos de cerca estos desarrollos y ayudamos siempre que podemos. Tener una gran red de sitios que han habilitado HTTP / 3 brinda a los desarrolladores de navegadores un excelente campo de pruebas para validar el código.

Entonces, ¿cuál es el estado actual?


El proceso de estandarización de IETF involucra una serie de borradores para preparar un “borrador final” listo para etiquetar como un estándar RFC. Los miembros del equipo QUIC trabajan juntos en el análisis, la implementación y la interoperabilidad para identificar posibles problemas. Lanzamos el soporte de protocolo en la etapa de la versión 23 del borrador, y luego seguimos todos los cambios, y al momento de escribir (14 de abril de 2020) la última era la versión 27. Con cada borrador, la calidad de las definiciones de QUIC mejora y se acerca a un "consenso general" sobre cómo debe comportarse el protocolo. Para evitar el análisis perpetuo con configuraciones infinitamente dopilivaniya al ideal, con cada nueva versión del borrador, la barra para realizar cambios en las especificaciones aumenta. Esto significa que con cada versión hay menos cambios, y el RFC final corresponderá estrechamente al protocolo que ya hemos lanzado en producción.

Beneficios


Una de las principales ventajas de HTTP / 3 fue el aumento en el rendimiento, especialmente cuando se solicitan varios objetos al mismo tiempo. En HTTP / 2, cualquier interferencia (pérdida de paquetes) en una conexión TCP bloquea todos los flujos a la vez (bloquea el comienzo de una línea). Como HTTP / 3 se basa en UDP, solo se interrumpe un flujo cuando se pierde un paquete, pero no todos.

Además, HTTP / 3 admite 0-RTT (tiempo de recepción-transmisión cero), es decir, las conexiones posteriores pueden comenzar mucho más rápido que la primera, eliminando la necesidad de confirmar TLS desde el servidor al establecer una conexión. Esto significa que el cliente comienza a solicitar datos mucho antes que con una negociación completa de TLS, es decir, el sitio web comienza a cargarse en el navegador antes.

Las animaciones a continuación muestran el efecto de la pérdida de paquetes. En el primer ejemplo, se reciben solicitudes del cliente al servidor a través de HTTP / 2 para recibir dos recursos. Las solicitudes y respuestas relacionadas están coloreadas en verde y amarillo. Las respuestas se dividen en varios paquetes. Desgraciadamente, se pierde un paquete; como resultado, la transferencia de ambos recursos se retrasa.



En el segundo ejemplo, las solicitudes de dos recursos se reciben a través de HTTP / 3. Se pierde un paquete, bloqueando la transferencia del recurso amarillo, pero sin afectar el verde.



Las mejoras en el procedimiento para negociar una sesión significan que las "conexiones" con los servidores se establecen mucho más rápido, es decir, los datos llegan más rápido al navegador. Teníamos curiosidad sobre cuánto se reflejaba esto en el tráfico real, por lo que realizamos varias pruebas. Para evaluar la contribución de 0-RTT, lanzamos varias pruebas de control para medir el tiempo hasta el primer byte (tiempo hasta el primer byte, TTFB). En promedio, sobre HTTP / 3, el primer byte aparece después de 176 ms. En el caso de HTTP / 2, vemos 201 ms, es decir, ¡HTTP / 3 aquí reduce el retraso en un 12,4%!



Curiosamente, los borradores y los RFC no regulan todos los aspectos del protocolo. Por ejemplo, el método de transferencia de paquetes afecta el rendimiento.y algoritmo de control de congestión de tráfico. El control de congestión es un método de adaptación a redes congestionadas en el lado del cliente y del servidor: cuando se pierden paquetes, la calidad de la comunicación disminuye. Dado que QUIC es un nuevo protocolo, se requiere experimentación y ajuste para diseñar e implementar adecuadamente un sistema de gestión de sobrecarga.

Como un punto de partida simple y seguro, la especificación de detección de pérdidas y control de congestión recomienda el algoritmo de Reno , pero se puede utilizar cualquier otro. Comenzamos con el algoritmo New Reno , pero en base a la experiencia, asumimos que no era óptimo. Recientemente cambiamos a CUBIC - Y en una red con transmisiones de gran tamaño y mayor pérdida de paquetes, CUBIC se desempeñó mejor que New Reno. Pronto hablaremos más sobre esto, estad atentos para una actualización del blog.

En la pila HTTP / 2 actual, tenemos BBR v1 (TCP). Esto significa que las pruebas no realizan una comparación exacta de manzanas con manzanas, ya que estos algoritmos de control de congestión se comportan de manera diferente en diferentes tamaños de engranajes. Sin embargo, al cambiar de HTTP / 2 a HTTP / 3, ya vemos una mejora en sitios más pequeños. En grandes áreas, nuestra pila HTTP / 2 optimizada y finamente optimizada muestra un rendimiento brillante.

Una pequeña página de prueba de 15K se carga sobre HTTP / 3 en promedio en 443 ms, en comparación con 458 ms para HTTP / 2. Pero si aumenta el tamaño de la página a 1 MB, esta ventaja desaparece: específicamente en nuestra red, el protocolo HTTP / 3 ahora funciona un poco más lento que HTTP / 2 - 2.33 s versus 2.30 s.







Los puntos de referencia sintéticos son interesantes, pero es interesante cómo se muestra HTTP / 3 en el mundo real.

A modo de comparación, queríamos atraer un servicio de terceros que pueda descargar sitios de nuestra red, simulando un navegador web. WebPageTest es un marco común para medir el tiempo de carga de la página, con buenos diagramas en cascada (cascada). Para analizar el backend, utilizamos nuestro propio sistema Browser Insights , arreglando los tiempos en el borde de nuestra red. Luego conectaron ambas partes mediante una pequeña automatización.

Como un caso de prueba para medir el rendimiento, tomamos nuestro propio blog . Configuramos nuestras instancias de WebPageTest para cargar el sitio desde ubicaciones en todo el mundo, tanto sobre HTTP / 2 como sobre HTTP / 3. Incluye HTTP / 3 e información del navegador. Por lo tanto, cada vez que un navegador con soporte HTTP / 3 carga la página, los scripts de prueba solicitan datos analíticos recopilados del navegador. Se repitió el mismo procedimiento para HTTP / 2 para poder compararlo.

El siguiente gráfico muestra el tiempo de carga de la página blog.cloudflare.com real con una comparación de las métricas HTTP / 3 y HTTP / 2. Tenemos tales métricas para diferentes puntos geográficos.



Como puede ver, el rendimiento de HTTP / 3 sigue siendo inferior al rendimiento de HTTP / 2. La diferencia es de aproximadamente 1-4% en promedio en América del Norte. Resultados similares en Europa, Asia y Sudamérica. Sospechamos que esto puede deberse a una diferencia en los algoritmos de control de congestión: BBR v1 funciona en HTTP / 2 y CUBIC en HTTP / 3. En el futuro, intentaremos implementar el mismo algoritmo de control de sobrecarga en ambos protocolos para obtener una comparación más precisa de manzanas con manzanas.

Conclusión


En general, estamos muy contentos de ayudar a avanzar el nuevo estándar. Nuestra implementación se mantiene bien, en algunas situaciones muestra un mejor rendimiento y, en el peor de los casos, HTTP / 2 similar. A medida que finalice el estándar, esperamos que los navegadores agreguen soporte HTTP / 3 en las versiones principales. En cuanto a nosotros, apoyaremos los borradores más recientes y buscaremos nuevas formas de optimizar HTTP / 3 para mejorar aún más el rendimiento, ya sea configurando el control de congestión, la priorización o la configuración del sistema (CPU y ancho de banda del canal).

Mientras tanto, si desea probar HTTP / 3 en acción, simplemente actívelo en nuestro tablero y descargue el conjunto de prueba (Nightly, Canary) de cualquiera de los principales navegadores. Consulte nuestra documentación para desarrolladores para obtener instrucciones sobre cómo habilitar HTTP / 3 .

More articles:


All Articles