Le bufferbloat expliqué : pourquoi le WiFi rame quand même

Une connexion gigabit qui se transforme en diaporama dès que quelqu’un lance un téléchargement n’a rien d’une contradiction. C’est le problème le plus courant des réseaux domestiques, il a un nom — le bufferbloat — et il n’a rien à voir avec la bande passante que vous payez.

Ce qu’est vraiment le bufferbloat

Chaque routeur, modem et saut chez votre FAI conserve une petite file d’attente de paquets en attente de départ. Cette file existe pour une bonne raison : les liaisons réseau ne sont pas parfaitement régulières, et une file absorbe ces à-coups. Le problème commence quand cette file est bien plus grande que nécessaire — dimensionnée pour un débit maximal dans un benchmark, pas pour un appel vidéo familial.

Le TCP, le protocole derrière presque tout ce que vous faites en ligne, ne sait à quelle vitesse envoyer qu’en observant les signes de saturation du réseau. Traditionnellement, ce signe est un paquet perdu : la file est pleine, quelque chose est jeté, et l’expéditeur ralentit. Une file trop grande retarde ce signal au lieu de l’envoyer. Les paquets continuent de s’accumuler au lieu d’être perdus, le TCP continue d’accélérer parce que rien ne lui a dit de s’arrêter, et chaque paquet — y compris celui de votre appel, de votre jeu, de votre requête DNS — doit maintenant attendre derrière une file qui peut durer plusieurs secondes. La connexion n’est pas lente. Elle fait la queue, très longtemps.

Pourquoi cela n’apparaît que sous charge

Une connexion inactive a une file vide, donc sa latence semble excellente — 15, 20, 30 millisecondes, exactement ce que devrait coûter la distance jusqu’au serveur. Lancez un gros téléchargement en arrière-plan et cette même connexion peut bondir à 500ms, 1000ms, parfois plus, parce qu’il y a maintenant toute une file de paquets appartenant à quelqu’un d’autre devant les vôtres. C’est pourquoi le bufferbloat est si facile à manquer avec un test de vitesse classique : un simple chiffre de téléchargement/envoi ne soumet jamais la liaison à la charge bidirectionnelle soutenue que génère un usage réel, donc la file ne se remplit jamais.

Le chiffre qui compte vraiment n’est ni la latence au repos ni la latence en charge isolément — c’est l’écart entre les deux. Une connexion à 40ms au repos et 60ms en charge (écart de 20ms) est globalement saine. Une connexion à 15ms au repos et 900ms en charge (écart de 885ms) est sévèrement engorgée, même si son chiffre au repos semblait parfait une minute plus tôt.

Comment le repérer en 30 secondes

Lancez un test de vitesse qui mesure la latence à la fois au repos et en charge — le Speed Test de ce site fait exactement cela, volontairement. Observez le chiffre de latence en charge pendant les phases de téléchargement et d’envoi. S’il reste dans les 20-30ms du chiffre au repos, c’est propre. S’il grimpe à plusieurs centaines de millisecondes, c’est du bufferbloat, et vous avez maintenant un chiffre à comparer avant et après toute solution.

Ce qui règle vraiment le problème

La vraie solution est une file d’attente plus intelligente sur l’appareil qui contrôle le lien goulot d’étranglement — presque toujours votre routeur, parfois le modem ou l’ONT de votre FAI s’il gère lui-même ses files. Les algorithmes modernes de gestion de file, fq_codel et son successeur cake, gèrent activement la profondeur de la file au lieu de la laisser croître sans limite : ils gardent juste assez de tampon pour absorber les pics et rien de plus, et donnent un tour équitable aux flux concurrents (votre appel, votre téléchargement, votre jeu) au lieu de servir par ordre d’arrivée. La plupart des routeurs sous OpenWrt, et un nombre croissant de firmwares d’origine, exposent cela sous le nom de « Smart Queue Management » ou « SQM » — l’activer est généralement le réglage le plus rentable de tout le routeur.

Il y a un second élément, moins évident, tout aussi important : le SQM ne fonctionne que s’il connaît le vrai plafond de votre liaison. Fixer une limite de bande passante légèrement en dessous de votre débit de ligne réel — les routeurs avec SQM demandent généralement cela directement, quelque chose comme 90-95% de votre vitesse mesurée dans chaque sens — déplace la file de l’équipement non contrôlé de votre FAI vers votre propre routeur, où la gestion intelligente de file peut réellement agir. Sans cette limite, la plus grande file du trajet peut se trouver dans un équipement que vous ne contrôlez pas et ne pouvez pas configurer, et aucun réglage côté routeur ne l’atteint.

Ce qui ne règle pas le problème

Un forfait plus rapide ne règle pas le problème. C’est le mythe que ce guide existe pour démonter : passer de 300 Mbps à un gigabit ne réduit pas une file surdimensionnée, cela permet seulement à cette file de se remplir plus vite. Beaucoup de connexions gigabit sont plus engorgées que beaucoup de connexions à 100 Mbps, parce que le bufferbloat est un problème de gestion de file, pas de bande passante — vous pouvez le vérifier vous-même en lançant le test de latence en charge sur une connexion rapide avec le SQM désactivé et en observant l’écart quand même. Payer plus de vitesse pour régler le bufferbloat, c’est comme élargir une route pour réparer un feu mal réglé : cela ne touche pas la vraie cause, et sur certains routeurs, un forfait plus rapide aggrave le calcul de la file au lieu de l’améliorer, parce que le routeur doit maintenant mettre en mémoire tampon plus de données par seconde avant que le SQM — s’il est activé — ait une chance de les gérer.

Un autre endroit où il se cache : la file de votre propre routeur, pas seulement celle de votre FAI

Il vaut la peine d’être précis sur l’endroit où vit généralement la file surdimensionnée, car « quelque part dans le réseau » n’est pas exploitable. La plupart du temps, c’est le routeur lui-même, ou le modem juste derrière — l’appareil le plus proche du véritable goulot d’étranglement, qui pour la plupart des connexions domestiques est la liaison WAN, pas le WiFi. Un routeur sans aucune gestion de file va allègrement mettre en mémoire tampon des mégaoctets de données qu’il n’a aucun espoir d’envoyer dans un délai raisonnable, parce que rien ne le lui interdit. C’est aussi pourquoi un système mesh ou un répéteur ne règle rarement le bufferbloat à lui seul : ces appareils se trouvent du côté WiFi du réseau, en aval du vrai goulot d’étranglement, et un saut WiFi propre devant une file WAN engorgée reste une connexion engorgée.

Pourquoi c’est le facteur le plus important de votre Sygnal Score

Le Sygnal Score pondère six mesures, et le bufferbloat — mesuré exactement comme décrit ci-dessus, comme l’écart entre latence en charge et latence au repos — vaut 250 des 1000 points totaux, plus que n’importe quel autre bloc individuel. Crédit complet pour un écart de 20ms ou moins, crédit nul à partir de 400ms, avec une transition linéaire entre les deux. Cette pondération est délibérée : une connexion qui affiche d’énormes chiffres de téléchargement et d’envoi mais qui s’effondre dès qu’elle est vraiment utilisée — pour un appel, un jeu, tout ce qui est en temps réel — n’est pas une bonne connexion, et un score basé uniquement sur le débit la qualifierait quand même de bonne. Le bufferbloat est là où une ligne rapide mais défaillante est démasquée.