- Dans des environnements comme les réseaux filaires haut débit, le Wi‑Fi 6/7 ou la 5G, où 500 Mb/s à 1 Gb/s ou plus sont possibles par connexion, la pile UDP+QUIC+HTTP/3 affiche un débit de données jusqu’à 45,2 % inférieur à TCP+TLS+HTTP/2
- Au-delà du simple téléchargement de fichiers, sur Chrome, Edge, Firefox, Opera et sur desktop comme mobile, plus la bande passante augmente, plus l’écart de performance entre QUIC et HTTP/2 se creuse
- Les traces de paquets et le profilage noyau/espace utilisateur montrent que le goulot d’étranglement est moins du côté émission que du côté surcoût de traitement à la réception ; avec QUIC, davantage de paquets sont reçus et les ACK sont traités en espace utilisateur
- Côté applications, cela se traduit par une baisse de débit binaire jusqu’à 9,8 % pour la vidéo DASH, et par des temps moyens de chargement de page 3,0 % plus longs sur 100 sites web représentatifs
- Les pistes d’atténuation incluent le déploiement de UDP GRO côté réception, des améliorations de GSO/GRO adaptées à QUIC, l’optimisation de la logique de réception et l’utilisation de plusieurs cœurs CPU, mais la diversité des appareils clients et des OS en complique la mise en œuvre
L’écart de performance de QUIC révélé sur les réseaux rapides
- QUIC est un protocole de transport multiplexé au-dessus d’UDP, standardisé par l’IETF comme base de transport de HTTP/3
- Plusieurs entreprises, dont Google, Akamai, Meta et Cloudflare, déploient QUIC en production depuis 2013, et le protocole est vu, avec HTTP/3, comme un candidat majeur pour transformer les performances du Web
- Les recherches précédentes sur les performances de QUIC s’appuyaient sur des implémentations, environnements de calcul et conditions réseau variés, et beaucoup se concentraient sur des cas d’usage à faible débit
- La mesure se concentre ici sur le comportement de QUIC dans des réseaux rapides où chaque connexion peut atteindre 500 Mb/s ou plus ou 1 Gb/s ou plus, comme les liaisons filaires haut débit, le Wi‑Fi 6/7 et la 5G
- La comparaison ne porte pas sur un protocole isolé, mais sur la pile complète
- Côté QUIC : UDP+QUIC+HTTP/3
- Côté classique : TCP+TLS+HTTP/2
- Dans le résumé, ils sont respectivement appelés QUIC et HTTP/2
Les écarts observés dans les tests de téléchargement de fichiers
- Des expériences de téléchargement simple avec cURL et
quic_clientbasé sur Chromium ont comparé les performances à algorithme de contrôle de congestion, configuration serveur et conditions réseau identiques - À des bandes passantes relativement faibles, en dessous d’environ 600 Mb/s, QUIC et HTTP/2 avaient des performances proches, mais à des débits plus élevés, le débit utile de QUIC était jusqu’à 15,7 % inférieur à celui de HTTP/2
- Plus la bande passante augmentait, plus l’écart devenait net, et pendant la réception des paquets, QUIC affichait une utilisation CPU bien plus élevée que HTTP/2 sur des machines clientes récentes
- Les tests sur les principaux navigateurs montrent un écart encore plus marqué
- Navigateurs testés : Chrome, Edge, Firefox, Opera
- Sur Chrome, QUIC commence à décrocher au-delà d’environ 500 Mb/s
- Quand la bande passante atteint 1 Gb/s, QUIC devient 45,2 % plus lent que HTTP/2
- Sur des clients plus faibles, comme en environnement mobile, l’écart est encore plus important
Impact sur les applications web
- La dégradation des performances ne se limite pas au transfert de gros fichiers ; elle apparaît aussi dans des applications aux schémas de trafic intermittents
- Lors de la livraison de segments vidéo DASH sur Ethernet rapide et en 5G, QUIC montre un débit binaire vidéo jusqu’à 9,8 % inférieur à HTTP/2
- Cette baisse de QoE n’apparaît que lorsque la bande passante sous-jacente est suffisamment élevée
- En 4G, l’effet est masqué
- En 5G, il devient visible
- Dans les tests de navigation web, sur une moyenne de 100 sites représentatifs, le temps de chargement de page (PLT) avec QUIC est 3,0 % plus long qu’avec HTTP/2
- Dans la longue traîne, certains cas montrent un écart de temps de chargement de page supérieur à 50 %
Cause du goulot d’étranglement : traitement côté réception et ACK en espace utilisateur
- Les traces de paquets et les données de performance montrent que le client QUIC reçoit bien plus de paquets que lors d’un téléchargement HTTP/2
- Quand QUIC reçoit à haut débit, la latence entre les paquets de données entrants et les paquets ACK correspondants augmente, ce qui allonge le temps de traitement des paquets QUIC
- Ces deux observations indiquent que la dégradation des performances de QUIC sur Internet rapide provient d’une limite de capacité de traitement côté réception
- Deux raisons expliquent que la réception soit désignée comme goulot d’étranglement
- Les serveurs sont en général plus puissants que les clients, qu’il s’agisse de desktop, de laptop ou de smartphone
- Par conception, QUIC présente des difficultés propres dans le traitement des données reçues
- Un profilage approfondi a identifié deux causes principales
- Un excès de paquets de données
- Lors du téléchargement d’un même fichier, la pile UDP dans le noyau déclenche bien plus de lectures de paquets
netif_receive_skbque TCP - Aucune des implémentations QUIC étudiées n’utilise UDP generic receive offload, c’est‑à‑dire UDP GRO
- UDP GRO consiste à faire fusionner par le module de couche liaison plusieurs datagrammes UDP reçus en un gros datagramme avant de les transmettre à la couche transport
- Cela contraste avec le déploiement généralisé de TCP segmentation offload et avec l’attention récente portée à GSO, l’offload côté émission pour UDP
- Lors du téléchargement d’un même fichier, la pile UDP dans le noyau déclenche bien plus de lectures de paquets
- Le traitement des ACK en espace utilisateur
- En espace utilisateur, QUIC supporte un surcoût plus élevé pour le traitement des paquets reçus et la génération des réponses
- Les causes incluent l’excès de paquets remontés depuis le noyau, le traitement en espace utilisateur des ACK QUIC, ainsi que l’absence de certaines optimisations comme les delayed ACK de QUIC
- Un excès de paquets de données
Mesures préliminaires et pistes d’atténuation
- Une expérience préliminaire de téléchargement d’un fichier de 1 Go dans le navigateur Chrome montre qu’activer QUIC peut à peu près doubler le temps de téléchargement
- Les résultats d’exemple correspondent à la moyenne de 10 exécutions
- Desktop Ethernet : HTTP/2 9,32 s, HTTP/3 18,60 s, soit +99 % ; l’utilisation CPU passe de 77,5 % à 96,9 %
- Pixel 5 low-band 5G : HTTP/2 37,11 s, HTTP/3 78,65 s, soit +112 % ; l’utilisation CPU passe de 121,55 % à 161,77 %
- Pixel 5 mmWave 5G : HTTP/2 30,10 s, HTTP/3 63,20 s, soit +110 % ; l’utilisation CPU passe de 128,43 % à 165,20 %
- Sur desktop, l’utilisation CPU est mesurée au niveau du service réseau du navigateur ; sur smartphone, elle est mesurée au niveau de l’ensemble du processus du navigateur
- Une utilisation CPU supérieure à 100 % signifie que, sur un système multicœur, le processus du navigateur a utilisé plus d’un cœur
- Les atténuations proposées incluent le déploiement de UDP GRO côté réception, des améliorations de GSO et GRO adaptées à QUIC, l’optimisation de la logique de réception QUIC et la réception des données QUIC sur plusieurs cœurs CPU
- Comme les hôtes clients regroupent des PC, des appareils mobiles, des systèmes embarqués et divers OS, avec une hétérogénéité supérieure à celle des serveurs, la mise en œuvre concrète de ces pistes est difficile en pratique
- Les données de mesure et le code source ont été publiés avec l’étude
1 commentaires
Avis sur Hacker News
Le secteur semble prêt à tout, sauf à créer des sites légers.
À la fin des années 90 aussi, avec une connexion rapide, Internet était instantané, les pages étaient petites et il y avait très peu de JavaScript.
On trouve encore aujourd’hui ce genre de pages rapides et légères : elles donnent presque l’impression, assez surréaliste, d’être entièrement chargées avant même qu’on ait relâché le bouton de la souris.
Si l’expérience utilisateur s’était au moins améliorée, ce serait tolérable, mais on n’a même pas gagné cela.
C’est plus rapide et beaucoup plus robuste, et les incohérences d’état entre le frontend et le backend ont disparu.
Par commodité, on accepte un minimum de JavaScript ; il y en a actuellement quelques centaines de lignes, et on en ajoutera encore un peu pour que cela ressemble toujours à une application monopage.
Grâce à cela, on peut supprimer environ 40 000 lignes de React et 20 000 lignes de Kotlin, mais il faut réécrire environ 30 000 lignes de code backend.
Malgré tout, ça me plaît.
J’ai donc déplacé mon site perso vers une version statique en VUE.JS pour acquérir de l’expérience, mais la manière de lier les vues et l’état en passant les noms de variables sous forme de chaînes me semblait étrange, l’extension de l’environnement de build était inutilement complexe, et tout était lent tout en devant être fait d’une manière bien précise.
Comme tout le monde l’utilisait, je pensais que c’était forcément la bonne approche, mais j’ai depuis pris du recul, et j’ai terminé la nouvelle version avec du HTML brut et des templates de générateur de site statique.
La taille du HTML a diminué de 90 %, l’usage de JS de 97 %, et le temps de build est passé de 20 secondes à 2 secondes.
L’expérience utilisateur s’est aussi améliorée, et les visites ont augmenté de 30 % depuis la nouvelle version.
Le Web peut être bien plus agréable quand on utilise moins de Web.
Côté backend aussi, aujourd’hui, la poule aux œufs d’or consiste à vendre des microservices via des produits SaaS headless connectés par API, avec l’idée que les performances s’amélioreront forcément.
https://macharchitecture.com/
Si les gens veulent acheter ce genre de pelles, dans le monde de l’IT, nous n’avons pas d’autre choix que d’en empiler en stock.
Mon blog est un site Hugo rendu statiquement, donc sans aucun JS, et mes projets reposent sur Rails avec du HTML rendu côté serveur, avec seulement un minimum de JS pour ajouter des fonctionnalités agréables à avoir.
Ils fonctionnent même sans JS.
Je dis peut-être ça parce que ce sont mes sites, mais l’expérience est bien meilleure que sur la majeure partie du Web, et nous avons perdu beaucoup trop de choses.
Google avait un jour créé un Speedtest entièrement basé sur JS
À l’époque, Ookla reposait encore sur Flash et ne fonctionnait donc pas sur Chromebook, ce qui posait problème aux installateurs pour vérifier l’état de l’installation
Au passage, j’ai beaucoup appris sur la manière dont TCP réagit à différents facteurs
Les résultats de cet article sont à peu près ceux auxquels on pouvait s’attendre, car on a déplacé le contrôle de flux du noyau — et peut-être de l’adaptateur réseau — vers l’espace utilisateur
TCP fournit le contrôle de flux et la garantie d’ordre, et QUIC revient à les gérer soi-même
Bien sûr, il y a aussi de bonnes raisons à cela
Le contrôle de congestion de TCP est réputé être en retard par rapport aux débits de connexion modernes, et de nouveaux algorithmes comme BBR sont apparus, mais ils ont un coût [1]
L’élément essentiel trop souvent absent des tests réseau ou des tests d’applications web, c’est la latence
Quiconque vit en Asie ou en Australie sait à quel point un aller-retour de 100 ms peut être dévastateur
Cela peut rendre totalement inutilisable quelque chose qui était parfaitement réactif, réduire la bande passante qu’une connexion peut exploiter à cause de la fenêtre, et rendre aussi la gestion des erreurs et du contrôle de congestion moins réactive
Si vous testez un réseau ou une application web, je recommande vivement d’ajouter aléatoirement 100 ms de latence à vos tests [2]
C’est pourquoi l’overhead de QUIC pourrait, en pratique, ne pas avoir tant d’importance
La bande passante effective sur une seule connexion TCP ou un stream QUIC peut en effet être bien inférieure à la bande passante brute réelle
Autrement dit, même avec 45 % de données supplémentaires, cela peut être gagnant si le fait de gérer soi-même le contrôle de congestion augmente le débit effectif entre deux points
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
Avec le recul, c’est évident : avec TCP, on peut simplement dire « noyau, envoie-moi cet énorme buffer », alors qu’avec UDP, qui fonctionne par échange de paquets, même envoyer zéro entraîne sur la plupart des systèmes d’exploitation et du matériel grand public un coût CPU élevé à cause des changements de mode
Il existe des contournements, mais ils ne sont ni simples ni, d’après mon expérience, vraiment mûrs, et ils limitent aussi le choix du langage, de la bibliothèque et de la plateforme utilisables
En prime, j’ai observé une forte baisse du débit quand un MacBook fonctionne sur batterie, probablement liée aux cœurs efficients
Deuxièmement, QUIC gérait mal le contrôle de congestion
J’utilisais quic-go, donc cela peut varier selon les environnements, mais aucun réglage n’a vraiment aidé, et lorsqu’il cohabitait avec un stream TCP, TCP captait davantage de bande passante
Troisièmement, l’API est étrange
Comme QUIC lui-même possède plusieurs streams, ce n’est pas un substitut direct à TCP qu’on pourrait insérer tel quel
L’intention est toutefois de faire de HTTP/3 un substitut interchangeable à un niveau plus élevé, mais je ne l’ai pas essayé, donc je ne peux pas me prononcer
Si vous travaillez au niveau des streams, c’est un point à garder en tête
Au final, j’ai eu un peu l’impression d’une défaite, mais en même temps cela m’a donné un respect renouvelé pour l’optimisation et la résilience de notre vieil ami TCP
C’est une technologie vraiment remarquable, et le système d’exploitation nous la fournit toujours gratuitement
Certains des principaux problèmes de TCP tiennent d’ailleurs moins à des défauts de conception qu’à des valeurs par défaut conservatrices ou héritées
Les limites de buffer sous Linux, Nagle, ce genre de choses
Ce serait bien de pouvoir simplement améliorer TCP plutôt que de réinventer la roue
[1]: https://payload.app/
C’était une décision nécessaire pour que QUIC puisse démarrer, mais maintenant qu’il existe, elle peut être réexaminée
Il n’y a pas d’obstacle technique à implémenter QUIC dans le noyau, et si le gain de performance est important, quelqu’un le fera presque certainement bientôt
La différence est le jour et la nuit
Il existe des préréglages Slow/Fast 4G et 3G, et l’on peut créer des préréglages personnalisés en spécifiant soi-même les débits de téléchargement et d’envoi, la latence en ms, le taux de perte de paquets, la longueur de la file de paquets, ainsi qu’activer la réorganisation des paquets
Daniel Stenberg, créateur et mainteneur de curl, a écrit il y a quelques mois un billet sur HTTP/3 dans curl : https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
L’un des points qu’il souligne est l’utilisation CPU plus élevée de HTTP/3, au point que le CPU limitait le débit.
Je me demande quelle part relève de l’immaturité de l’implémentation, et quelle part tient aux propriétés mêmes de la conception de QUIC.
La troisième recommandation est UDP GRO : modifier le noyau, et idéalement le matériel de la carte réseau, pour regrouper les paquets UDP reçus afin de réduire le travail par paquet et le remplacer par un travail par groupe.
TCP dispose déjà de cela, et il existe aussi des mécanismes similaires côté émission, comme TSO et GSO sous Linux.
Cela ressemble aussi à de l’immaturité, mais si le problème vient d’un manque de fonctionnalités matérielles, il pourrait être plus difficile à corriger.
Le résumé parle du coût du mécanisme d’ACK de QUIC, mais je n’ai pas examiné cet argument en détail.
Une autre fonctionnalité qu’on voit sur les serveurs modernes basés sur TCP est le déchargement de TLS vers le matériel.
Cela semble plus important pour les serveurs qui envoient simultanément de nombreux flux TCP.
Sous Linux, c’est possible via le networking en espace utilisateur ou via « kernel tls », avec déchargement matériel quand c’est possible.
Cette fonctionnalité est aussi liée à une particularité de Linux qui permet de découper un flux TCP en « messages » et de les envoyer à d’autres threads ; je ne sais pas si elle permet de transmettre à l’avance des messages plus loin dans le flux lorsqu’un paquet précédent a été perdu.
Je n’ai jamais eu l’impression que l’objectif était de rendre toutes les connexions plus rapides.
Vu sous cet angle, les compromis ont du sens.
Je ne suis pas spécialiste, donc que quelqu’un qui s’y connaît mieux me corrige.
QUIC a été créé parce qu’il n’existe absolument aucun moyen de faire en sorte que tout le matériel et middleware disséminés sur Internet prennent en charge un nouveau standard TCP ou TLS.
QUIC est donc une solution élégante consistant à faire passer un nouveau standard de transport au-dessus d’UDP sur du matériel Internet hérité.
Dans un monde idéal, on aurait créé de nouveaux standards TCP et TLS, puis remplacé ou mis à jour tous les routeurs et matériels Internet du monde pour les implémenter avec une utilisation CPU plus faible.
Dans le test, quiche, limité par le CPU, reste sous les 200 Mo/s, tandis que nghttp2 dépasse 900 Mo/s.
Je me demande si le CPU était bridé.
Si une implémentation HTTP/3 consomme quatre fois plus de CPU, c’est intéressant, mais si la valeur absolue était déjà très basse au départ, ce n’est pas forcément un gros problème.
Le point clé est que « sur Internet rapide, la pile UDP+QUIC+HTTP/3 réduit le débit de données jusqu’à 45,2 % par rapport à TCP+TLS+HTTP/2 » ; je n’ai pas encore lu l’article en entier, mais l’introduction semble considérer moins de 600 Mbit/s comme un Internet lent.
Prenons Cloudflare : ils ne prennent en charge QUIC qu’entre le client et l’edge, pas pour la connexion vers l’origine.
Si la connexion edge <> origine est réutilisable, stable et « rapide », cela se tient.
https://developers.cloudflare.com/speed/optimization/protoco...
Cela ne donne pas l’impression qu’il y ait un problème fondamental dans le protocole lui-même.
Mais ce type de problème de latence n’augmente pas fortement la consommation de batterie, contrairement à un problème d’utilisation CPU qui pousse le processeur à booster.
Ce n’est pas non plus un problème pour les communications serveur à serveur.
En gros, sur les appareils des utilisateurs finaux, lorsque l’on utilise une connexion très rapide même selon les standards de 2024, les transferts à haut débit « ralentissent ».
La vitesse dont il est question ici n’est pas le débit vendu dans une publicité, mais le débit effectif réel entre l’appareil et le serveur.
Cela ne veut pas dire que l’article est inutile : les implémentations des navigateurs doivent être améliorées, et il le montre bien.
Cela dit, le titre de l’article est presque à 100 % du clickbait.
Passer à un mode de transfert plus lent au moment où l’Internet gigabit se généralise est clairement une erreur.
Dans 30 ans, ce sera encore plus rapide ; s’il faut utiliser un protocole plus ancien pour exploiter toute la vitesse de la ligne, ce serait absurde.
Le même article avait déjà été publié en septembre : QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991 (327 commentaires)
Brave/Vivaldi/Opera, entre autres, doivent être des choix conscients.
Tant que les pubs arrivent vite, le reste n’a pas d’importance.
Cela paraît vraiment très étrange.
Avec QUIC+HTTP/3 seul, et même avec QUIC seul, j’ai déjà atteint 900 Mbit/s.
Cela ressemble à une mauvaise implémentation de TLS, ou à une implémentation initiale peu efficace.
L’utilisation CPU était assez moyenne, environ 5 % sur un cœur EPYC de deuxième génération.
Pour l’anecdote, j’ai eu un problème d’accès à wordpress.org
Quand j’ai commencé à utiliser Wordpress, je pouvais consulter la documentation sans souci, puis à un moment donné je n’ai plus du tout pu accéder au site
Comme j’étais en dual boot avec Linux, ce n’était pas un problème Windows ; le ping fonctionnait bien, et c’était pareil avec trois navigateurs différents
Quand j’allais sur le site, soit il restait bloqué sans rien charger, soit, parfois, la page s’arrêtait de charger en plein milieu
J’ai trouvé la solution aujourd’hui : désactiver Experimental QUIC Protocol dans les paramètres de Chrome
Pendant des mois, j’ai eu des problèmes d’accès à wordpress.org, et ce qui m’inquiète, c’est qu’il n’y avait absolument aucun indice montrant que QUIC en était la cause
Je ne m’en suis rendu compte que de justesse, parce que des erreurs liées à QUIC apparaissaient seulement de temps en temps dans les outils de développement
Je me demande combien d’autres sites Web sont devenus inaccessibles à cause de ce protocole sans que les utilisateurs en connaissent la raison
Ici, Internet rapide signifie 500 Mbps, car QUIC semble devenir limité par le CPU au-delà de ce débit
Je n’ai pas regardé assez en détail pour vérifier si le système de test était une machine grand public classique, ni si le problème se pose encore sur un desktop hautes performances
Ce qui est drôle, c’est que, même sans bien connaître les détails, nous acceptons implicitement l’idée du genre « QUIC est le nouveau HTTP/2 », simplement parce que rapide = bien
C’est un peu comme acheter un nouveau téléphone 5G parce qu’on nous dit qu’il est plusieurs fois plus rapide que la 4G
Alors qu’en réalité 1) mon téléphone 4G n’a jamais fonctionné une seule fois à la vitesse maximale de la 4G, et 2) les problèmes de connexion viennent presque toujours non pas du débit de la ligne Internet, mais d’un serveur DNS, du site Web cible ou des équipements de multiplexage côté opérateur qui posent problème
Malgré tout, ça devient « oui, mais c’est de la 5G »
Les pubs pour le « broadband par fibre optique » où l’on voit des gens regarder la télévision avec les cheveux qui volent au vent sont amusantes aussi
En réalité, ça ne fonctionne pas comme ça
On faisait déjà du streaming avec des connexions à 8 Mb à l’époque, donc 300 Mb peuvent être utiles pour certaines choses, mais je doute qu’on ressente une grande différence
J’aimerais que QUIC ait un mode non-TLS
En développement local, on veut parfois simplement voir ce qui passe sur le fil, et cela ajoute beaucoup de friction inutile
Il ne peut donc pas fonctionner sans cela