Hasta ahora en esta serie, he detallado cómo QUIC y HTTP/3 han superado los problemas de seguridad y privacidad que plagan el Protocolo de Control de Transporte (TCP) y HTTP/2 de una forma preparada para el futuro. En este artículo, analizaré cómo se comparan en lo que respecta a la característica más importante de cualquier protocolo: el rendimiento.
Comparación del rendimiento de HTTP/3 frente a HTTP/2
Aunque todavía es un poco pronto para responder definitivamente a esta pregunta, dado que la mayoría de las comparaciones (públicas) entre HTTP/2 y HTTP/3 se basan en pruebas de laboratorio y no en implantaciones en el mundo real, tenemos algunos datos que pueden arrojar algo de luz.
En primer lugar, el documento original de Google en el que se describían los mecanismos básicos de QUIC informaba de una reducción media del 8% en el tiempo de carga de los resultados de búsqueda de Google en ordenadores de sobremesa y del 3,6% en móviles. Y para el 1% de los usuarios más lentos de Google, la carga fue hasta un 16% más rápida. Al analizar la transmisión de vídeos en YouTube, observaron hasta un 20% menos de parones (cuando la reproducción del vídeo tiene que detenerse para esperar a que lleguen nuevos datos) en países como la India.
Estas cifras pueden no parecer grandes mejoras a primera vista. Sin embargo, a la escala de Google, pueden suponer fácilmente millones de ingresos adicionales, ya que el rendimiento de la Web está vinculado a la participación de los usuarios y a las conversiones de las visitas.
En segundo lugar, Wix, una popular y potente herramienta de creación de sitios web, realizó experimentos comparando HTTP/2 con HTTP/3 en los millones de sitios web de sus clientes. Analizando principalmente los tiempos de establecimiento de la conexión, descubrieron mejoras de hasta el 33% en la media y a menudo más en el percentil 75 (Figura 1). Para algunos países, como Filipinas, esto puede tener un impacto significativo: más de 250ms. Del mismo modo, al analizar otra popular métrica de rendimiento web denominada Largest Contentful Paint (LCP), descubrieron mejoras de hasta el 20% en el percentil 75, lo que a menudo reducía el valor de LCP en más de 500 ms (o aproximadamente una quinta parte de los 2.500 ms que Google recomienda como valor objetivo). No está nada mal para cambiar a un nuevo protocolo.
Por último, mi empleador Akamai, la mayor red de distribución de contenidos (CDN) del mundo, lleva varios años probando y ajustando HTTP/3. En general, vemos ganancias similares a las velocidades de establecimiento de conexión. Además, nos hemos fijado en el rendimiento medio (uso efectivo del ancho de banda), que también debería mejorar, por ejemplo, con la mejor detección y recuperación de pérdida de paquetes de QUIC.
Para un gran cliente de medios de Akamai durante un evento de retransmisión en directo de fútbol europeo que también fue popular en Latinoamérica, observamos un rendimiento sustancialmente mayor en HTTP/3 en comparación con HTTP/2 (Tabla 1). Por ejemplo, vimos que cerca del 69% de las conexiones HTTP/3 alcanzaban un rendimiento de 5 Mbps o más (indicado por Netflix como el umbral mínimo para la transmisión de vídeo Full HD), frente a sólo el 56% de las conexiones HTTP/2. En la práctica, esto significa que los flujos de vídeo serán de mayor calidad visual y/o tendrán menos paradas en HTTP/3.
| Versión HTTP | 1mbps | 3mbps | 5mbps | 10mbps | 15mbps | 25mbps | 50mbps |
|---|---|---|---|---|---|---|---|
| HTTP/2 | 73.5% | 62.0% | 56.4% | 47.4% | 40.9% | 31.1% | 18.2% |
| HTTP/3 | 86.2% | 76.5% | 69.7% | 56.7% | 47.7% | 35.0% | 19.2% |
Sigue siendo difícil obtener mediciones sólidas del rendimiento de implantaciones HTTP/3 reales
Dado que HTTP/3 requiere un proceso de arranque(que utiliza una función llamada alt-svc), puede resultar difícil hacer una comparación/división limpia entre HTTP/2 y HTTP/3. Además, muchas grandes empresas no son partidarias de compartir cifras en bruto por razones comerciales.
Aun así, el hecho de que empresas como Google, Meta, Apple, Twitch y grandes CDN como Akamai, Cloudflare y Fastly estén desplegando los protocolos a escala debería ser un buen indicador de las ventajas prácticas (de rendimiento) que aportan. Esto es así porque QUIC y HTTP/3 son (mucho) más caros de alojar en sus plataformas, ya que cuestan más tiempo de CPU y memoria que TCP y HTTP/2, debido, por ejemplo, a su mayor cifrado. Este coste se ve (aparentemente) suficientemente compensado por los beneficios de los protocolos en su cuenta de resultados.
En mi próximo post, hablaré del impacto de este gasto y de otros factores limitantes a la hora de desplegar QUIC y HTTP/3 y de si esto los frenará.
Robin Marx es Experto en Protocolo y Rendimiento Web en Akamai. Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.