QUIC n’est pas assez rapide sur un Internet rapide
-
Contexte de la recherche
- QUIC est censé jouer un rôle important dans l’amélioration des performances des applications web.
- Cet article étudie de manière systématique les performances de QUIC sur des réseaux à haut débit.
-
Principales découvertes
- Sur un Internet haut débit, la pile UDP+QUIC+HTTP/3 réduit le débit de transfert de données jusqu’à 45,2 % par rapport à TCP+TLS+HTTP/2.
- Plus la bande passante de base augmente, plus l’écart de performance entre QUIC et HTTP/2 se creuse.
- Ce problème affecte non seulement le transfert de fichiers, mais aussi diverses applications comme le streaming vidéo (jusqu’à 9,8 % de baisse du bitrate vidéo) et la navigation web.
-
Méthode d’analyse
- Une analyse des traces de paquets ainsi qu’un profiling du noyau et de l’espace utilisateur ont permis d’identifier la cause profonde du problème.
- Le surcoût de traitement côté réception est élevé, en particulier à cause d’un volume excessif de paquets de données et des ACK de QUIC en espace utilisateur.
-
Recommandations d’amélioration
- L’article propose des recommandations concrètes pour atténuer les problèmes de performances observés.
Le résumé de GN⁺
- Cet article analyse les problèmes de performance de QUIC dans des environnements réseau à haut débit et fournit des insights importants pouvant contribuer à améliorer les performances des applications web.
- Il identifie le surcoût de traitement côté réception comme cause de la dégradation des performances de QUIC et propose des pistes concrètes pour y remédier, offrant ainsi des informations utiles aux ingénieurs réseau et aux développeurs.
- Un autre protocole aux fonctionnalités similaires est HTTP/2, et la comparaison de performances avec celui-ci permet de dégager des pistes d’amélioration pour QUIC.
1 commentaires
Commentaires Hacker News
Le secteur essaie tout sauf de créer des sites web légers. À la fin des années 90, si l’on avait une connexion Internet rapide, les pages étaient petites et il y avait très peu de JavaScript. Aujourd’hui encore, on peut trouver ces pages légères qui se chargent vite, et l’expérience en est presque surréaliste. On l’aurait mieux supporté si l’expérience utilisateur avait été meilleure.
J’ai travaillé sur le Speedtest en pur JS chez Google. À l’époque, Ookla reposait sur Flash, donc cela ne fonctionnait pas sur les Chromebooks. J’ai beaucoup appris sur la façon dont TCP réagit à divers facteurs. En voyant cet article, je me dis que le résultat est conforme à ce que j’attendais, parce que le contrôle de flux est déplacé du noyau vers l’espace utilisateur. TCP possède un contrôle de flux et un séquencement. QUIC vous laisse gérer cela vous-même. Le contrôle de congestion de TCP n’est pas adapté aux vitesses de connexion modernes, c’est pourquoi de nouveaux algorithmes comme BRR sont nécessaires, mais cela a un coût. La plus grande leçon est qu’il ne faut pas négliger l’importance de la latence dans les tests réseau. Les gens qui vivent en Asie ou en Australie savent à quel point une latence RTT de 100 ms peut être dévastatrice. L’overhead de QUIC n’est peut-être pas réellement important, parce que la bande passante effective via une seule connexion TCP ou un flux QUIC peut être bien inférieure à la bande passante brute.
Daniel Stenberg, créateur et mainteneur de Curl, a écrit un billet de blog sur HTTP/3. Il y soulignait l’utilisation élevée du CPU par HTTP/3 et mentionnait que le CPU pouvait limiter le débit. Je me demande si cela vient du manque de maturité des implémentations ou de la manière dont QUIC est conçu.
Il est dit que, sur un Internet rapide, la pile UDP+QUIC+HTTP/3 réduit la vitesse de transfert de données jusqu’à 45,2 % par rapport à TCP+TLS+HTTP/2. Je n’ai pas encore lu tout l’article, mais moins de 600 Mbit/s y est considéré comme un « Internet lent ».
QUIC ne serait pas assez rapide sur un Internet rapide. J’ai atteint 900mbps avec quic+http3, et je me demande si c’est l’implémentation TLS qui est mauvaise ou si les premières implémentations sont inefficaces. L’utilisation CPU tournait en moyenne autour de 5 % sur un cœur Epyc gen 2.
Ici, « Internet rapide » signifie 500 Mbps, et il est dit que cela vient du fait que quic dépend du CPU. Je n’ai pas vérifié si le système de test était un système grand public standard ni si le problème apparaissait aussi sur des desktops hautes performances.
Je pensais que QUIC était optimisé pour la latence. Il est optimisé pour charger de nombreux petits paquets dans les pages web et les jeux vidéo. Il peut être insuffisant si l’on mesure uniquement le débit global. Je me demande s’il est possible, au niveau du protocole, de détecter les transferts de gros fichiers ou le streaming vidéo à haut débit et de basculer vers quelque chose de moins gourmand en CPU. Je me demande aussi si QUIC est moins optimisé que TCP au niveau matériel/OS.
J’aimerais que QUIC ait un mode sans TLS. En développement local, j’ai parfois envie de voir ce qui transite, et cela ajoute une friction inutile.