QUIC n’est pas assez rapide sur l’Internet haut débit

• QUIC est un protocole dont on attendait une amélioration majeure des performances des applications web, mais ses performances sont en deçà des attentes
• Cet article analyse de manière systématique les performances de QUIC sur les réseaux à haut débit

Résumé

• Sur l’Internet haut débit, la pile UDP+QUIC+HTTP/3 présente jusqu’à 45,2 % de débit de transfert de données en moins par rapport à TCP+TLS+HTTP/2
• L’écart de performance entre QUIC et HTTP/2 se creuse à mesure que la bande passante disponible augmente
• Ce problème est observé avec un client de transfert de données léger et les principaux navigateurs web (Chrome, Edge, Firefox, Opera), sur divers hôtes (desktop, mobile) et sur différents réseaux (haut débit filaire, cellulaire)
• Il 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
• Une analyse rigoureuse par traçage de paquets, ainsi que du profiling dans le kernel et en espace utilisateur, permet d’identifier les causes profondes
• En particulier, la surcharge de traitement côté récepteur est élevée en raison d’un nombre excessif de paquets de données et des ACK de QUIC en espace utilisateur
• L’article propose des recommandations concrètes pour atténuer les problèmes de performance observés

Causes profondes de la dégradation des performances

• Une surcharge excessive de traitement des paquets survient au niveau du kernel côté récepteur
  • QUIC n’utilise pas UDP GRO (Generic Receive Offload) et doit donc traiter bien plus de paquets que TCP
  • Cela se vérifie par un nombre d’appels à la fonction netif_receive_skb bien plus élevé avec QUIC
• QUIC subit aussi une surcharge excessive de traitement des paquets en espace utilisateur
  • Le traitement du grand nombre de paquets transmis par le kernel entraîne une surcharge importante
  • La génération des ACK QUIC en espace utilisateur est également une source de surcharge

Recommandations pour atténuer la dégradation des performances

• Introduire UDP GRO côté récepteur
  • Réduire le nombre de paquets à traiter dans la pile UDP afin de diminuer la surcharge dans le kernel et en espace utilisateur
  • Toutefois, le déploiement de UDP GRO dans des environnements clients variés peut ne pas être simple
• Améliorer pour QUIC les solutions d’offloading comme GSO/GRO
  • Permettre aussi l’offloading de trains de paquets UDP de tailles différentes
  • Ajouter un réglage de pacing approprié à GSO pour éviter la congestion réseau
• Optimiser la logique QUIC côté récepteur
  • Retarder l’envoi des ACK QUIC afin de réduire la surcharge liée à la génération des réponses
  • Utiliser recvmmsg pour lire plusieurs paquets UDP à la fois et améliorer les performances
• Utiliser des téléchargements multithread
  • Pour les gros fichiers, les téléchargements multithread exploitant plusieurs cœurs CPU peuvent améliorer les performances de réception
  • Il faut toutefois prendre en compte les questions d’équité

[GN⁺]

Avis Hacker News

• L’interface de syscall est complexe, et l’API de base est trop lente pour des paquets de taille normale (environ 1 500 octets)
  • GSO aide, mais l’API est complexe et comporte encore récemment de nombreux bugs
• Le coût des syscalls a augmenté à cause des mitigations Spectre
  • Il faut remplacer les sockets BSD / l’API POSIX
  • uring est complexe, mais une API de niveau intermédiaire est nécessaire
• Le tampon UDP système est par défaut beaucoup trop petit
  • Seuls les experts l’utilisent, et les experts ajustent les paramètres
• Il est possible d’optimiser la pile UDP
  • GSO le montre, mais GSO lui-même est coûteux et complexe
• Certaines optimisations actuellement disponibles ne fonctionnent qu’à petite ou moyenne échelle
  • Par exemple, la liaison de connexion pour éviter la recherche de route
• Implémenter GSO peut nettement améliorer les performances
  • Il faudra probablement augmenter la taille des tampons côté plateforme
• Au début de QUIC, la pile UDP était moins optimisée que la pile TCP
  • Des optimisations comme l’offload de réception générique UDP sont nécessaires
• HTTP/2 aussi semble avoir été lancé dans la précipitation
  • Chrome a supprimé la prise en charge du server push
  • Il faut davantage de réflexion
• QUIC et HTTP/2 montrent des performances similaires quand la bande passante réseau est faible
  • Au-delà de 500 Mbps, les performances de QUIC se dégradent
  • C’est surtout un problème sur les réseaux locaux
• Google a tendance à reporter la charge de traitement sur les utilisateurs
  • Par exemple, le codec vidéo AV1 a été déployé alors que les consommateurs n’avaient pas de capacité de décodage matériel
• L’article de recherche est sur arXiv
  • https://arxiv.org/pdf/2310.09423
• Mention d’un ping avec une RTT de 0,23 ms
  • Même avec une latence élevée, QUIC reste le meilleur
• Lire la RFC9000 est difficile et complexe
  • L’idée générale de haut niveau de QUIC est simple, mais la spécification exige de gérer de nombreux cas particuliers
• Un PDF gratuit de l’étude est disponible
  • https://arxiv.org/pdf/2310.09423
• Déplacer les protocoles de connexion en espace utilisateur n’est peut-être pas une bonne idée