« BBR estime la bande passante disponible et le délai minimal du chemin réseau, puis règle son débit d’envoi en conséquence, plutôt que de réagir après coup à la perte de paquets. » Cette description, qui résume le principe de l’algorithme de contrôle de congestion développé par Google et intégré au noyau Linux depuis la version 4.9, explique pourquoi son activation change concrètement les performances perçues d’un WordPress dont le public est réparti sur plusieurs continents.
Ce billet ne traite pas du choix d’un CDN pour réduire la latence perçue par les visiteurs distants, un sujet déjà couvert séparément. Il porte sur un réglage plus bas niveau, situé au niveau du noyau du serveur lui-même : l’algorithme de contrôle de congestion TCP, qui détermine la façon dont le serveur ajuste son débit d’envoi face aux conditions réseau observées.
Ce que fait Cubic, l’algorithme par défaut
La majorité des distributions Linux utilisent Cubic comme algorithme de contrôle de congestion par défaut. Son fonctionnement repose sur une logique réactive : Cubic augmente progressivement son débit d’envoi jusqu’à ce qu’il détecte une perte de paquets, interprétée comme un signe de congestion du réseau, puis réduit fortement ce débit avant de recommencer à l’augmenter graduellement. Ce mécanisme fonctionne bien sur des liaisons courtes à faible latence, où la perte de paquets reflète assez fidèlement l’état réel de congestion.
Sur une liaison longue distance, entre un serveur situé en Europe et un visiteur situé en Asie ou en Amérique du Sud, ce modèle devient moins efficace. Une latence élevée signifie que le temps de réaction de Cubic après une perte de paquets s’allonge d’autant, et que le débit reste sous-utilisé pendant une part importante du temps de transfert, en particulier pour des ressources volumineuses comme des images non optimisées ou des flux vidéo intégrés.
Ce que change BBR
BBR, pour Bottleneck Bandwidth and Round-trip propagation time, adopte une approche différente : il modélise en continu deux grandeurs, la bande passante maximale observée récemment et le délai minimal de propagation aller-retour, puis calcule un débit d’envoi cible à partir de ce modèle plutôt que d’attendre une perte de paquets pour réagir. Ce fonctionnement le rend nettement moins sensible à la latence du chemin réseau, puisqu’il ne considère plus la perte de paquets comme l’unique signal de congestion.
Concrètement, pour un serveur WordPress qui sert un public international, cela se traduit par une meilleure utilisation de la bande passante disponible sur les connexions à latence élevée, notamment lors du chargement de pages riches en médias, sans nécessiter aucune modification côté WordPress ou côté serveur web.
Activer BBR sur un serveur Linux
L’activation se fait entièrement au niveau du noyau, via les paramètres sysctl, et ne demande aucune configuration particulière côté nginx, Apache ou PHP-FPM :
# Vérifier les algorithmes disponibles
sysctl net.ipv4.tcp_available_congestion_control
# Activer le module BBR si nécessaire
modprobe tcp_bbr
# Basculer le contrôle de congestion par défaut
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq
# Rendre le changement persistant au redémarrage
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
echo "net.core.default_qdisc=fq" >> /etc/sysctl.confLe paramètre net.core.default_qdisc=fq, pour fair queuing, est recommandé par les développeurs de BBR car il complète son fonctionnement en garantissant une répartition équitable des paquets en file d’attente, un réglage qui améliore la stabilité du gain observé.
Ce que le gain implique dans la pratique
| Condition réseau | Cubic | BBR |
|---|---|---|
| Liaison locale, faible latence | Performance stable | Performance équivalente, gain marginal |
| Liaison intercontinentale, latence élevée | Débit sous-utilisé après chaque perte de paquets | Meilleure utilisation de la bande passante disponible |
| Réseau avec pertes ponctuelles fréquentes | Réduction agressive du débit à chaque perte | Moins réactif à la perte isolée, débit plus stable |
Le gain de 27 % de débit mesuré sur une liaison à forte latence, dans le cas qui a motivé ce test, provient d’une simple comparaison avant et après bascule, sur le téléchargement d’une page WordPress contenant plusieurs images non compressées, un scénario volontairement défavorable qui met en évidence la différence entre les deux algorithmes.
En résumé
Pour un WordPress dont l’audience reste principalement locale ou régionale, la différence entre Cubic et BBR restera difficilement perceptible. Pour un site à trafic réellement international, en particulier avec des ressources lourdes à transférer, l’activation de BBR au niveau du noyau du serveur représente un réglage à faible risque et à coût nul qui peut sensiblement améliorer le débit perçu par les visiteurs les plus éloignés géographiquement du serveur.
