- En entornos donde son posibles 500 Mbps a 1 Gbps o más por conexión, como redes cableadas de alta velocidad, WiFi 6/7 y 5G, la pila UDP+QUIC+HTTP/3 mostró una tasa de transferencia de datos hasta 45.2% menor que TCP+TLS+HTTP/2
- Más allá de la simple descarga de archivos, en Chrome, Edge, Firefox, Opera y en entornos de escritorio y móviles, cuanto mayor es el ancho de banda, más se amplía la brecha de rendimiento entre QUIC y HTTP/2
- Según el rastreo de paquetes y el profiling de kernel y espacio de usuario, el cuello de botella está más cerca del overhead de procesamiento en el lado receptor que del transmisor, y al recibir con QUIC se generan más paquetes y más procesamiento de ACK en espacio de usuario
- El impacto a nivel de aplicación se traduce en una reducción de bitrate de hasta 9.8% en video DASH y en un tiempo de carga de página 3.0% más largo en promedio en 100 sitios web representativos
- Para mitigar esto, se requiere desplegar UDP GRO en el lado receptor, mejoras a GSO/GRO orientadas a QUIC, optimizar la lógica de recepción y aprovechar varios núcleos de CPU, pero la diversidad de dispositivos cliente y sistemas operativos dificulta su implementación
La brecha de rendimiento de QUIC que se hace visible en redes rápidas
- QUIC es un protocolo de transporte multiplexado sobre UDP y fue estandarizado por la IETF como base de transporte para HTTP/3
- Varias empresas como Google, Akamai, Meta y Cloudflare han desplegado QUIC en producción desde 2013, y junto con HTTP/3 ha sido visto como un candidato para cambiar el rendimiento web
- Los estudios previos sobre rendimiento de QUIC variaban en implementación, entorno de cómputo y condiciones de red, y muchos se enfocaban en casos de uso de bajo throughput
- La medición se centra en el comportamiento de QUIC en redes rápidas capaces de alcanzar 500 Mbps o más o 1 Gbps o más por conexión, como enlaces cableados de alta velocidad, WiFi 6/7 y 5G
- El objeto de comparación no es un protocolo aislado, sino la pila completa
- Lado QUIC: UDP+QUIC+HTTP/3
- Lado tradicional: TCP+TLS+HTTP/2
- En el resumen se les llama respectivamente QUIC y HTTP/2
Diferencias observadas en los experimentos de descarga de archivos
- En experimentos de descarga simple de archivos usando cURL y
quic_clientbasado en Chromium, la comparación se hizo alineando el algoritmo de control de congestión, la configuración del servidor y las condiciones de red - Con anchos de banda relativamente bajos, por debajo de unos 600 Mbps, QUIC y HTTP/2 mostraron un rendimiento similar, pero con mayor ancho de banda el throughput de QUIC fue hasta 15.7% menor que el de HTTP/2
- A medida que aumentaba el ancho de banda, la brecha de rendimiento se hacía más clara, y durante la recepción de paquetes QUIC mostró un uso de CPU mucho mayor que HTTP/2 en hosts cliente modernos
- En pruebas con los principales navegadores, la diferencia fue todavía mayor
- Los navegadores evaluados fueron Chrome, Edge, Firefox, Opera
- En Chrome, QUIC empezó a quedarse atrás cuando el ancho de banda superó aproximadamente los 500 Mbps
- Al llegar a 1 Gbps, QUIC fue 45.2% más lento que HTTP/2
- En clientes más débiles, como dispositivos móviles, la brecha fue aún mayor
Impacto en aplicaciones web
- La degradación de rendimiento no se limita a la transferencia de archivos grandes, sino que también aparece en aplicaciones con patrones de tráfico intermitente
- Al entregar chunks de video DASH sobre Ethernet de alta velocidad y 5G, QUIC mostró un bitrate de video hasta 9.8% menor frente a HTTP/2
- Esta caída en la QoE solo se hace visible cuando el ancho de banda base es suficientemente alto
- En 4G, el efecto queda oculto
- En 5G, el efecto sí aparece
- En pruebas de navegación web, tomando como base el promedio de 100 sitios web representativos, el page load time (PLT) de QUIC fue 3.0% más largo que el de HTTP/2
- En la cola larga hubo casos donde la diferencia en tiempo de carga de página superó el 50%
Causa del cuello de botella: procesamiento en recepción y ACK en espacio de usuario
- Según el rastreo de paquetes y los datos de rendimiento, el cliente QUIC recibe muchos más paquetes que durante una descarga con HTTP/2
- Cuando QUIC recibe a altas tasas de transferencia, aumenta la demora entre los paquetes de datos entrantes y los paquetes ACK correspondientes, lo que alarga el tiempo de procesamiento de paquetes QUIC
- Estas dos observaciones apuntan a que la causa de la caída de rendimiento de QUIC en internet rápido está en los límites de capacidad de procesamiento del lado receptor
- Hay dos razones por las que se señala al lado receptor como cuello de botella
- Los servidores suelen ser más potentes que los clientes, como desktops, laptops y smartphones
- Por diseño, QUIC tiene dificultades propias en el procesamiento de recepción de datos
- El profiling profundo identificó dos causas principales
- Exceso de paquetes de datos
- Al descargar el mismo archivo, la pila UDP dentro del kernel genera muchas más lecturas de paquetes
netif_receive_skbque TCP - Ninguna de las implementaciones QUIC analizadas utiliza UDP generic receive offload, es decir, UDP GRO
- UDP GRO consiste en que el módulo de capa de enlace combine varios datagramas UDP recibidos en un solo datagrama grande antes de entregarlos a la capa de transporte
- Esto contrasta con el amplio despliegue de TCP segmentation offload y con el énfasis reciente en GSO como offload de transmisión para UDP
- Al descargar el mismo archivo, la pila UDP dentro del kernel genera muchas más lecturas de paquetes
- Procesamiento de ACK en espacio de usuario
- En espacio de usuario, QUIC tiene mayor overhead para procesar paquetes recibidos y generar respuestas
- Entre las causas están el exceso de paquetes entregados desde el kernel, el procesamiento en espacio de usuario de los ACK de QUIC y la ausencia de algunas optimizaciones como delayed ACK en QUIC
- Exceso de paquetes de datos
Mediciones preliminares y vías de mitigación
- Un experimento preliminar en Chrome descargando un archivo de 1 GB mostró que el tiempo de descarga casi se duplicaba al activar QUIC
- Los resultados de muestra corresponden al promedio de 10 ejecuciones
- Ethernet de escritorio: HTTP/2 9.32 s, HTTP/3 18.60 s, un aumento de 99%; el uso de CPU subió de 77.5% a 96.9%
- Pixel 5 en 5G low-band: HTTP/2 37.11 s, HTTP/3 78.65 s, un aumento de 112%; el uso de CPU subió de 121.55% a 161.77%
- Pixel 5 en 5G mmWave: HTTP/2 30.10 s, HTTP/3 63.20 s, un aumento de 110%; el uso de CPU subió de 128.43% a 165.20%
- El uso de CPU en desktop se mide con base en el servicio de red del navegador, y en smartphones la medición corresponde al proceso completo del navegador
- Valores de uso de CPU por encima de 100% significan que el proceso del navegador usó más de un núcleo en un sistema multinúcleo
- Las mitigaciones propuestas incluyen desplegar UDP GRO en el lado receptor, mejorar GSO y GRO para que sean más amigables con QUIC, optimizar la lógica de recepción de QUIC y recibir datos QUIC usando varios núcleos de CPU
- Como los hosts cliente abarcan PCs, dispositivos móviles, dispositivos embebidos y múltiples sistemas operativos, su heterogeneidad es mayor que la de los servidores, lo que vuelve más difícil implementar estas mitigaciones en la práctica
- Los datos de medición y el código fuente fueron publicados junto con la investigación
1 comentarios
Opiniones de Hacker News
La industria parece dispuesta a hacer cualquier cosa excepto crear sitios livianos
Incluso a fines de los 90, si tenías una conexión rápida, Internet se sentía instantáneo, las páginas eran pequeñas y casi no había JavaScript
Hoy todavía se pueden encontrar páginas rápidas y livianas así; se siente casi surrealista, como si la página terminara de cargar antes de que sueltes el botón del mouse
Sería tolerable si al menos la experiencia de usuario hubiera mejorado, pero ni siquiera obtuvimos eso
Se volvió más rápida y mucho más robusta, y también desaparecieron las inconsistencias de estado entre el frontend y el backend
Por comodidad aceptamos una cantidad mínima de JavaScript; ahora son unos cientos de líneas, y vamos a agregar un poco más para que siga pareciendo una app de una sola página
Con esto podemos eliminar unas 40 mil líneas de React y unas 20 mil de Kotlin, aunque hay que reescribir unas 30 mil líneas de código del backend
Aun así, me gusta
Así que, para ganar experiencia, migré mi página personal a una versión estática en VUE.JS, pero la forma de pasar nombres de variables como strings para enlazar la vista con el estado me pareció extraña; ampliar el entorno de build era innecesariamente complejo, y todo era lento y tenía que hacerse de una manera específica
Como todo el mundo lo usaba, pensé que debía estar bien, pero ahora ya dejé atrás esa perspectiva, y la nueva versión la terminé con HTML puro y plantillas de un generador de sitios estáticos
El tamaño del HTML se redujo 90%, el uso de JS bajó 97% y el tiempo de build pasó de 20 segundos a 2 segundos
La experiencia de usuario también mejoró, y desde la nueva versión las visitas aumentaron 30%
Si usamos menos la web, la web puede ser mucho más genial
En el backend, hoy la gallina de los huevos de oro también es vender microservicios mediante productos SaaS headless conectados por API, asumiendo que el rendimiento obviamente va a mejorar
https://macharchitecture.com/
Si la gente quiere comprar ese tipo de palas, en el mundo de IT no nos queda más que tener esas palas apiladas
Mi blog es un sitio Hugo renderizado de forma estática, así que no tiene nada de JS, y mis proyectos se basan en Rails y HTML renderizado en servidor, con solo el JS mínimo para funciones deseables pero no esenciales
Funciona incluso sin JS
Tal vez lo digo porque es mi sitio, pero la experiencia es mucho mejor que en la mayor parte de la web, y hemos perdido demasiadas cosas
Google creó alguna vez un Speedtest basado en JS puro.
En ese momento, Ookla todavía estaba basado en Flash, así que no funcionaba en Chromebook, y eso era un problema para que los encargados de instalación verificaran el estado de la instalación.
En ese proceso aprendí mucho sobre cómo TCP reacciona a distintos factores.
El resultado de este artículo es casi el esperado, porque el control de flujo se desplazó desde el kernel y quizá desde el adaptador de red hacia el espacio de usuario.
TCP tiene control de flujo y garantía de orden, y QUIC básicamente hace que uno gestione eso directamente.
Claro que hay buenas razones para ello.
El control de congestión de TCP es famoso por haberse quedado atrás frente a las velocidades de conexión modernas, y aunque surgieron algoritmos nuevos como BBR, tienen un costo [1].
Un punto clave que se omite con demasiada frecuencia en las pruebas de red o de aplicaciones web es la latencia.
Si vives en Asia o Australia, sabes lo devastadora que puede ser una latencia de ida y vuelta de 100 ms.
Puede convertir algo totalmente responsivo en algo directamente inutilizable, reducir el ancho de banda que la conexión puede soportar debido a la ventana y volverla menos sensible ante errores y control de congestión.
Si pruebas una red o una app web, recomiendo enfáticamente hacer pruebas agregando 100 ms de latencia al azar [2].
Por eso, puede que la sobrecarga de QUIC en realidad no importe.
Porque el ancho de banda efectivo en una sola conexión TCP o en un stream QUIC puede ser mucho menor que el ancho de banda bruto real.
Dicho de otra forma, aunque haya un 45% de datos adicionales, si al gestionar directamente el control de congestión se logra una mayor velocidad efectiva entre dos puntos, puede valer la pena.
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
Visto en retrospectiva, es obvio: con TCP basta con decirle “kernel, envía este enorme búfer”, mientras que UDP funciona por intercambio de paquetes, así que incluso enviar 0 tiene un costo alto de CPU en la mayoría de los sistemas operativos y hardware de consumo debido a los cambios de modo.
Hay formas de evitarlo, pero no son fáciles y, según mi experiencia, tampoco están lo bastante listas; además limitan la elección de lenguaje, biblioteca y plataforma que puedes usar.
Como extra, vi que el throughput caía mucho al usar una MacBook con batería, probablemente relacionado con los núcleos de eficiencia.
Segundo, QUIC no manejó bien el control de congestión.
Usé quic-go, así que puede variar según el entorno, pero ningún ajuste ayudó mucho, y cuando convivía con streams TCP, TCP se quedaba con más ancho de banda.
Tercero, la API es rara.
QUIC en sí tiene múltiples streams, así que no es un reemplazo directo tipo “enchufar y listo” de TCP.
La intención, eso sí, es que HTTP/3 sea un reemplazo directo en una capa más alta, pero no puedo opinar porque no lo probé.
Si trabajas a nivel de streams, es algo a tener en cuenta.
En conclusión, me sentí bastante derrotado, pero al mismo tiempo terminé con un renovado respeto por la optimización y resiliencia de mi viejo amigo TCP.
Es una tecnología realmente sorprendente, y el sistema operativo siempre te la da gratis.
Algunos de los principales problemas de TCP tampoco son fallas de diseño, sino valores predeterminados conservadores o heredados.
Cosas como los límites de búfer en Linux o Nagle.
Ojalá pudiéramos simplemente mejorar TCP en vez de reinventar la rueda.
[1]: https://payload.app/
Fue una decisión necesaria para que QUIC pudiera despegar, pero ahora que existe, también podría reconsiderarse.
No hay obstáculos técnicos para implementar QUIC en el kernel, y si la ventaja de rendimiento es grande, casi seguro que alguien lo hará pronto.
La diferencia es como el día y la noche.
Hay presets de Slow/Fast 4G y 3G, y también se pueden crear presets personalizados especificando velocidad de descarga y subida, latencia en ms, tasa de pérdida de paquetes, longitud de la cola de paquetes, e incluso activar el reordenamiento de paquetes.
Daniel Stenberg, creador y mantenedor de curl, escribió hace unos meses sobre HTTP/3 en curl: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
Una de las cosas que destacó fue el mayor uso de CPU de HTTP/3, al punto de que la CPU limitaba el rendimiento
Me pregunto cuánto de eso se debe a la inmadurez de la implementación y cuánto a propiedades del diseño de QUIC en sí
La tercera recomendación es UDP GRO, que consiste en modificar el kernel, idealmente el hardware de la NIC, para agrupar paquetes UDP entrantes y reducir el trabajo por paquete, convirtiéndolo en trabajo por grupo
TCP ya tiene esto, y en el lado emisor hay cosas similares como TSO y GSO en Linux
Esto también se siente como inmadurez, pero considerando la posible falta de funciones de hardware, podría ser más difícil de corregir
El resumen habla del costo del esquema de ACK de QUIC, pero no revisé ese argumento en detalle
Otra función que se puede ver en servidores modernos basados en TCP es descargar TLS al hardware
Parece más importante en servidores que envían muchos streams TCP al mismo tiempo
En Linux se puede hacer usando networking en espacio de usuario o mediante “kernel tls”, y si es posible se descarga al hardware
Esta función también está relacionada con una característica particular de Linux que permite dividir un stream TCP en “mensajes” y enviarlos a otros hilos, aunque no sé si puede entregar por adelantado los mensajes posteriores cuando se pierde un paquete anterior
Nunca me dio la impresión de que la intención fuera hacer más rápidas todas las conexiones
Visto desde esa perspectiva, el compromiso tiene sentido
No soy experto, así que espero que alguien que sepa más me corrija
QUIC se creó porque no hay forma de lograr que todo el hardware y middleware de internet, en todas partes, soporte un nuevo estándar de TCP o TLS
Por eso QUIC es una solución elegante para montar un nuevo estándar de transporte sobre UDP encima del hardware heredado de internet
En un mundo ideal, se habrían creado nuevos estándares de TCP y TLS, y se habrían reemplazado o actualizado todos los routers y hardware de internet del mundo para implementarlos con menor uso de CPU
En la prueba, quiche limitado por CPU quedó por debajo de 200 MB/s, mientras que nghttp2 superó los 900 MB/s
Me pregunto si la CPU estaba haciendo throttling
Si una implementación de HTTP/3 usa 4 veces más CPU, es interesante, pero si el valor absoluto ya era muy bajo para empezar, quizá no sea necesariamente un gran problema
La parte clave es que “en internet rápido, el stack UDP+QUIC+HTTP/3 reduce la velocidad de datos hasta un 45,2% frente a TCP+TLS+HTTP/2”, aunque todavía no leí todo el paper, en la introducción parecen considerar internet lento a menos de 600 Mbit/s
Tomando Cloudflare como ejemplo, solo soporta QUIC entre el cliente <> edge, y no en las conexiones al origen
Tiene sentido si la conexión edge <> origen es reutilizable, estable y “rápida”
https://developers.cloudflare.com/speed/optimization/protoco...
No suena como si hubiera un problema fundamental en el protocolo en sí
Pero este tipo de problema de latencia, a diferencia de un problema de uso de CPU que hace que el CPU entre en boost, no aumenta mucho el consumo de batería
Tampoco es un problema en la comunicación entre servidores
Básicamente, en dispositivos de usuario final, incluso en 2024, las transferencias de alto ancho de banda se vuelven “más lentas” cuando se usa una conexión muy rápida
La velocidad de la que se habla aquí no es la velocidad contratada que aparece en la publicidad, sino la velocidad efectiva desde el dispositivo real hasta el servidor
No digo que el paper sea inútil; las implementaciones de los navegadores deben mejorar, y el paper lo muestra bien
Pero el título del paper es casi 100% clickbait
Cambiar a un método de transmisión más lento justo cuando se masifica el internet gigabit es claramente un error
Dentro de 30 años será aún más rápido, y sería absurdo tener que usar protocolos más antiguos para poder aprovechar toda la velocidad de la línea
En septiembre ya se había publicado el mismo artículo: QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991 (327 comentarios)
Brave/Vivaldi/Opera, etc., deberían elegirlo conscientemente
Es como decir que, mientras los anuncios lleguen rápido, lo demás no importa
Esto realmente suena muy raro
Con QUIC+HTTP/3, e incluso solo con QUIC, he llegado a alcanzar 900 mbps
Parece una mala implementación de TLS o una implementación inicial poco eficiente
El uso de CPU era bastante promedio, alrededor del 5% en un núcleo EPYC de segunda generación
Como anécdota, tuve problemas para acceder a wordpress.org
Cuando empecé a usar Wordpress, podía consultar la documentación sin problema, pero en algún momento ya no pude acceder al sitio web en absoluto
Como tenía arranque dual con Linux, no era un problema de Windows; el ping respondía bien y pasaba lo mismo aunque cambiara entre tres navegadores
Al entrar al sitio, se quedaba trabado y no cargaba nada, o a veces la página dejaba de cargar a la mitad
Hoy encontré la solución: desactivar Experimental QUIC Protocol en la configuración de Chrome
Durante meses tuve problemas para acceder a wordpress.org, y me preocupa que no hubiera ninguna señal de que se debiera a QUIC
Apenas lo noté porque en las herramientas de desarrollador aparecía de vez en cuando algún error relacionado con QUIC
Me pregunto cuántos otros sitios web se habrán vuelto inaccesibles por este protocolo sin que los usuarios sepan la causa
Aquí, internet rápido significa 500 Mbps, y la razón es que QUIC parece quedar limitado por la CPU por encima de eso
No lo revisé con suficiente detalle como para confirmar si el sistema de prueba era de consumo general o si el problema persiste incluso en una desktop de alto rendimiento
Lo gracioso es que aceptamos de forma implícita ideas como “QUIC es el nuevo HTTP/2” simplemente porque rápido = bueno, aunque no conozcamos bien los detalles
Es parecido a comprar un nuevo teléfono 5G porque dicen que es varias veces más rápido que 4G
Pero en realidad 1) mi teléfono 4G nunca funcionó a la velocidad máxima de 4G, y 2) los problemas de conexión casi siempre no se deben a la velocidad de la línea de internet, sino a fallas en el servidor DNS, el sitio web de destino o los equipos de multiplexación de conexiones del operador
Aun así, queda el “pero es 5G”
También es gracioso cómo en los anuncios de “broadband de fibra óptica” muestran a la gente viendo TV con el pelo volando como si les pegara el viento
En realidad no funciona así
Antes ya hacíamos streaming con conexiones de 8 Mb, así que 300 Mb será útil para algunas cosas, pero dudo que se sienta una gran diferencia
Me gustaría que QUIC tuviera un modo sin TLS
Durante el desarrollo local, a veces solo quiero ver qué pasa por el cable, y esto agrega mucha fricción innecesaria
Por eso no puede funcionar sin eso