QUIC no es lo suficientemente rápido en internet rápido
-
Contexto de la investigación
- Se esperaba que QUIC desempeñara un papel importante en la mejora del rendimiento de las aplicaciones web.
- Este artículo investiga de forma sistemática el rendimiento de QUIC en redes de alta velocidad.
-
Hallazgos principales
- En internet de alta velocidad, la pila UDP+QUIC+HTTP/3 reduce la velocidad de transferencia de datos hasta en un 45.2% en comparación con TCP+TLS+HTTP/2.
- A medida que aumenta el ancho de banda base, la diferencia de rendimiento entre QUIC y HTTP/2 se amplía.
- Este problema afecta no solo la transferencia de archivos, sino también diversas aplicaciones como el streaming de video (con una reducción de hasta 9.8% en el bitrate de video) y la navegación web.
-
Método de análisis
- Se identificó la causa raíz del problema mediante análisis de trazas de paquetes y perfilado del kernel y del espacio de usuario.
- La sobrecarga de procesamiento en el lado receptor es alta, y en particular los paquetes de datos excesivos y los ACK de QUIC en espacio de usuario son la causa del problema.
-
Recomendaciones de mejora
- Se presentan recomendaciones concretas para mitigar los problemas de rendimiento observados.
Resumen de GN⁺
- Este artículo analiza los problemas de rendimiento de QUIC en entornos de red de alta velocidad y aporta ideas importantes que pueden contribuir a mejorar el rendimiento de las aplicaciones web.
- Al identificar la causa de la degradación del rendimiento de QUIC como la sobrecarga de procesamiento en el lado receptor y proponer medidas concretas para resolverla, ofrece información útil para ingenieros de redes y desarrolladores.
- Otro protocolo con funciones similares es HTTP/2, y la comparación de rendimiento con este sugiere la dirección de mejora para QUIC.
1 comentarios
Comentarios de Hacker News
La industria está intentando de todo excepto hacer sitios web ligeros. A finales de los 90, si tenías una conexión rápida a internet, las páginas eran pequeñas y casi no tenían JavaScript. Incluso hoy todavía se pueden encontrar estas páginas ligeras que cargan rápido, y la experiencia es casi surrealista. Si la experiencia de usuario hubiera sido mejor, habría sido más tolerable.
Trabajé en el Speedtest puro en JS en Google. En ese momento, Ookla estaba basado en Flash, así que no funcionaba en Chromebooks. Aprendí mucho sobre cómo TCP responde a distintos factores. Al ver este artículo, pensé que el resultado era el esperado, porque empuja el control de flujo del kernel al espacio de usuario. TCP tiene control de flujo y secuenciación. QUIC hace que eso se gestione por su cuenta. El control de congestión de TCP no encaja con las velocidades de conexión modernas, así que se necesitan algoritmos nuevos como BRR, pero tienen un costo. La lección más grande es que no hay que pasar por alto la importancia de la latencia en las pruebas de red. La gente que vive en Asia o Australia sabrá qué tan letal puede ser una latencia RTT de 100 ms. Puede que el overhead de QUIC no importe mucho en la práctica, porque el ancho de banda real a través de una sola conexión TCP o un stream de QUIC puede ser mucho menor que el ancho de banda bruto.
Daniel Stenberg, creador y mantenedor de Curl, escribió en su blog sobre HTTP/3. Destacó el alto uso de CPU de HTTP/3 y mencionó que la CPU puede limitar el throughput. Me pregunto si esto se debe a la inmadurez de la implementación o a la forma en que QUIC está diseñado.
Dicen que, en internet rápido, el stack UDP+QUIC+HTTP/3 reduce la velocidad de transferencia de datos hasta en 45.2% frente a TCP+TLS+HTTP/2. Todavía no he leído todo el paper, pero menos de 600 Mbit/s se considera "internet lento".
Dicen que QUIC no es lo suficientemente rápido en internet rápido. Alcancé una velocidad de 900mbps con quic+http3, y me pregunto si la implementación de TLS es mala o si las primeras implementaciones son ineficientes. El uso de CPU fue en promedio de alrededor de 5% en un core gen 2 epyc.
Aquí, "internet rápido" significa 500Mbps, y dicen que es porque quic depende de la CPU. No verifiqué si el sistema de prueba era un sistema de consumo común o si esto también es un problema en desktops de alto rendimiento.
Yo pensaba que QUIC estaba optimizado para la latencia. Está optimizado para cargar muchos paquetes pequeños en páginas web y videojuegos. Puede quedarse corto cuando solo se mide el throughput total. Me pregunto si, a nivel de protocolo, podría detectar transferencias de archivos grandes o streaming de video de alto ancho de banda y cambiar a algo menos intensivo en CPU. También me pregunto si QUIC está menos optimizado que TCP a nivel de hardware/SO.
Ojalá QUIC tuviera un modo sin TLS. A veces, al desarrollar en local, quiero poder ver lo que se transmite, y esto agrega una fricción innecesaria.