Une frustration récurrente pour les ingénieurs réseau et les professionnels du télétravail est la chute brutale de débit sur les liaisons longue distance. Un utilisateur disposant d'un accès fibre symétrique à 1 Gbit/s établit un tunnel chiffré transcontinental—par exemple entre Tokyo et Francfort avec un temps d'aller-retour Round-Trip Time (RTT) mesuré à 220 ms. Bien que la charge du processeur CPU soit minime et la bande passante physique largement disponible, les téléchargements volumineux en flux unique s'effondrent de plusieurs centaines de mégabits à seulement 12 ou 18 Mbit/s.

Face à cet étranglement, l'administrateur incrimine fréquemment le coût de calcul du chiffrement ou une restriction imposée par le fournisseur d'accès (FAI). En réalité, la cause fondamentale réside presque systématiquement dans l'algorithme traditionnel de contrôle de congestion de la couche transport : TCP CUBIC.

Pendant des décennies, l'architecture globale d'Internet a fonctionné sur des modèles de congestion basés sur la perte de paquets (Loss-based Congestion Control). Toutefois, au sein de tunnels VPN encapsulés présentant un produit bande passante-délai Bandwidth-Delay Product (BDP) élevé, ces modèles subissent une dégradation critique. L'apparition de TCP BBR (Bottleneck Bandwidth and Round-trip propagation time), conçu par Van Jacobson, Neal Cardwell et l'équipe de recherche de Google, a redéfini l'ingénierie réseau en remplaçant la détection empirique de pertes par une modélisation physique précise du lien.

[Dynamique CUBIC classique basée sur les pertes de paquets]
Croissance cwnd ──> Saturation tampon routeur ──> Débordement (Tail Drop) ──> Perte paquet ──> Réduction fenêtre (-30%)
                         ▲                                                                                   │
                         └──────────────── Reconstitution lente par fonction cubique ────────────────────────┘
                                 Résultat : Bufferbloat sévère, gigue élevée, effondrement du débit

─────────────────────────────────────────────────────────────────────────────────────────────────────────────

[Dynamique TCP BBR basée sur les paramètres physiques]
Mesure continue : Débit de goulot d'étranglement (BtlBw) et RTT physique minimal (RTprop)
Régulation d'émission Kernel Pacing au débit réel ──> Files d'attente toujours vides ──> Aucun surplus en transit
                                 Résultat : Débit maximalisé, zéro Bufferbloat, latence prévisible

Les limites mathématiques du contrôle basé sur les pertes : CUBIC (RFC 9438)

Pour appréhender cette perte d'efficacité, il convient d'analyser la fonction d'ajustement de TCP CUBIC (normalisé dans la RFC 9438).

Selon le principe AIMD (Additive-Increase/Multiplicative-Decrease), CUBIC postule que la perte de paquets constitue l'unique indicateur de congestion réseau. CUBIC explore la capacité du lien en augmentant continuellement sa fenêtre de congestion ($cwnd$) jusqu'à ce que la mémoire tampon d'un routeur intermédiaire déborde et abandonne un paquet (Tail Drop).

Dès qu'une perte est signalée par des acquittements dupliqués (Triple-Duplicate ACK) ou via Selective Acknowledgment (SACK), CUBIC applique une pénalité multiplicative brutale :

$$W_{\max} = \text{Volume de paquets en vol (Flight Size)}$$ $$cwnd_{\text{réduit}} = W_{\max} \times \beta \quad (\text{avec } \beta = 0.7)$$

La fenêtre de transmission est immédiatement amputée de 30 %, sans distinction entre un véritable engorgement matériel et un parasite radio transitoire sur une liaison Wi-Fi ou mobile.

En 1997, Matthew Mathis a formalisé le plafond théorique de débit pour les flux TCP basés sur les pertes, connu sous le nom de Formule de Mathis (Mathis Formula) :

$$\text{Débit} \le \frac{\text{MSS}}{\text{RTT}} \times \frac{C}{\sqrt{p}}$$

Où $\text{MSS}$ représente la taille maximale de segment Maximum Segment Size, $\text{RTT}$ le temps d'aller-retour, $p$ la probabilité de perte de paquet, et la constante $C \approx 1.22$.

Considérons les caractéristiques d'un tunnel VPN transcontinental :

  • $\text{RTT} = 160\text{ ms } (0.160\text{ s})$
  • $\text{MSS} = 1380\text{ octets } (11,040\text{ bits})$
  • Taux de perte aléatoire standard sur les réseaux publics $p = 1% \ (0.01)$ :

$$\text{Débit} \le \frac{11,040}{0.160} \times \frac{1.22}{\sqrt{0.01}} = 69,000 \times 12.2 \approx 841,800\text{ bit/s} \approx 6.7\text{ Mbit/s}$$

Malgré une infrastructure physique de 1 Gbit/s, une simple perte aléatoire de 1 % contraint CUBIC à brider le transfert sous la barre des 7 Mbit/s. Comme CUBIC nécessite de nombreux cycles RTT pour reconstruire sa courbe cubique, l'ampleur de la latence empêche la connexion de retrouver sa pleine capacité avant l'apparition de la prochaine perte aléatoire.

Le fléau du Bufferbloat dans les tunnels chiffrés

Les algorithmes basés sur la perte ne se contentent pas d'anéantir le débit utile ; ils dégradent également les communications interactives en générant du Bufferbloat (engorgement des mémoires tampons).

Comme CUBIC ne ralentit son rythme qu'après débordement complet des files d'attente, il injecte en permanence des paquets excédentaires dans le matériel réseau intermédiaire. Les commutateurs et passerelles résidentielles, équipés de larges tampons FIFO pour amortir les à-coups, retiennent ces datagrammes en mémoire.

Cette mécanique induit une latence artificielle majeure :

  1. Lorsqu'un flux de données massif transite dans le tunnel (comme une synchronisation de fichiers), CUBIC remplit la mémoire tampon du routeur à 100 %.
  2. Les paquets nécessitant une faible latence—tels que les signaux WireGuard Keepalive, les frappes SSH, les résolutions Domain Name System (DNS) ou la voix sur IP (VoIP)—sont bloqués derrière des milliers de paquets volumineux.
  3. Le temps de propagation RTT grimpe de 25 ms à plus de 400 ms.
  4. L'utilisateur constate une gigue importante (Packet Jitter), des coupures audio et des gels d'interface, bien que le lien physique ne soit pas saturé.

L'architecture BBR : opérer à l'optimum de Kleinrock

En 2016, Van Jacobson et Neal Cardwell ont introduit BBR (Bottleneck Bandwidth and RTT) afin d'éliminer ce compromis structurel.

BBR s'affranchit totalement de la détection de pertes. Dans le modèle BBR, la congestion est caractérisée par deux grandeurs physiques indépendantes :

  1. Débit du goulot d'étranglement ($\text{BtlBw}$) : la vitesse maximale de livraison du maillon le plus lent sur l'itinéraire.
  2. Délai de propagation minimal ($\text{RTprop}$) : la latence physique réelle de la liaison en fibre optique, exempte de tout délai de mise en file d'attente.

Leonard Kleinrock a prouvé dès 1979 que le point de fonctionnement parfait d'un réseau est atteint lorsque le volume de données en vol (Inflight Data) est rigoureusement égal au produit bande passante-délai Bandwidth-Delay Product (BDP) :

$$\text{BDP} = \text{BtlBw} \times \text{RTprop}$$

Latence / Débit
       │                       Point optimal de Kleinrock
       │                                     ▼
Débit  ─────────────────────────────┐────────────────────────── (Lien saturé à BtlBw)
       │                           ╱│
       │                          ╱ │
       │                         ╱  │
RTT    │                        ╱   │  Accumulation en file d'attente ─> (Début du Bufferbloat !)
       │                       ╱    │  ┌───────────────────────
RTprop de base ───────────────┴─────┴──┴───────────────────────
       └───────────────────────────────────────────────────────
                                 Volume de données en vol

Au point d'équilibre de Kleinrock :

  • Le débit utile atteint son plafond physique ($\text{Débit} = \text{BtlBw}$).
  • La latence d'aller-retour reste minimale ($\text{RTT} = \text{RTprop}$).
  • La file d'attente dans les mémoires tampons est nulle, éradiquant le Bufferbloat.

Pour préserver cet équilibre sans intervention des routeurs intermédiaires, BBR pilote une machine à états continue :

  • STARTUP : progression géométrique pour mesurer rapidement le débit maximal $\text{BtlBw}$.
  • DRAIN : décélération ciblée pour purger les files d'attente temporaires créées lors de la phase de démarrage.
  • PROBE_BW : ajustement cyclique du rythme d'émission (gain de 1.25x sur un RTT pour explorer la bande passante, 0.75x sur un RTT pour drainer la file, puis maintien à 1.0x sur six cycles RTT).
  • PROBE_RTT : réduction de la fenêtre à 4 segments tous les 10 secondes pendant environ 200 ms afin d'évaluer la latence physique à vide $\text{RTprop}$.

En appliquant un lissage d'émission matériel Kernel Pacing par le biais du planificateur Fair Queueing au lieu de rafales désordonnées, BBR garantit un acheminement fluide.

Évolution de l'algorithme : de BBRv1 à BBRv3

Les retours d'expérience sur BBRv1 ont mis en lumière deux axes de progression :

  1. Équité face à CUBIC : dans des tampons profonds, les flux CUBIC occupent agressivement la mémoire jusqu'au débordement, réduisant parfois la part équitable allouée à BBRv1.
  2. Tampons peu profonds : sous un taux de pertes aléatoires extrême (au-delà de 15 à 20 %), BBRv1 pouvait maintenir un volume en vol élevé générant des retransmissions.

L'Internet Engineering Task Force (IETF) et Google ont résolu ces aspects avec BBRv2 et BBRv3 :

  • Prise en charge de l'ECN (Explicit Congestion Notification) : BBRv3 analyse les marqueurs CE (RFC 3168) pour anticiper la saturation avant l'abandon de paquets.
  • Plafond dynamique des données en vol : adaptation du rythme d'émission en fonction du taux de perte observé pour une cohabitation harmonieuse (Fair-Share) avec CUBIC.
  • Phases de mesure RTT accélérées : réduction de l'intervalle PROBE_RTT pour maintenir la stabilité des flux à haute vitesse.
Caractéristique TCP Reno (RFC 5681) TCP CUBIC (RFC 9438) TCP BBRv1 TCP BBRv3
Signal de contrôle Perte de paquet Perte de paquet Modèle Débit & Latence Débit, Latence, Perte & ECN
Mécanisme d'émission En rafales (Bursts) En rafales (Bursts) Lissage noyau (fq) Lissage noyau (fq)
Impact sur Bufferbloat Sévère Sévère Minime Pratiquement nul
Tolérance à 1 % de perte Critique (< 5 % débit) Mauvaise (< 10 % débit) Excellente (95 %+ débit) Maximale (98 %+ débit)
Montée en charge BDP Très lente Modérée Immédiate Immédiate et adaptive
Partage équitable Référence Référence Parfois dominant Équilibré (Fair-Share)

Déploiement et réglages sous Linux

Le contrôle de congestion TCP relève d'une décision unilatérale de l'extrémité (Endpoint Decision). Dans une architecture VPN de couche 3 (WireGuard ou RiceGuard), les flux TCP applicatifs sont encapsulés dans des datagrammes UDP. L'activation de BBR sur la passerelle ou le client gère directement la cadence d'injection des données dans le tunnel chiffré.

Configuration du noyau Linux

L'activation de BBR requiert la combinaison du module avec l'ordonnanceur Fair Queueing (fq) :

# Vérification des modules de congestion installés
sysctl net.ipv4.tcp_available_congestion_control

# Activation de Fair Queueing et sélection de BBR
sudo sysctl -w "net.core.default_qdisc = fq"
sudo sysctl -w "net.ipv4.tcp_congestion_control = bbr"

# Limitation des données non envoyées dans le socket
sudo sysctl -w "net.ipv4.tcp_notsent_lowat = 16384"

Pour pérenniser ces paramètres, inscrivez les directives dans /etc/sysctl.d/99-bbr-optimization.conf :

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_notsent_lowat = 16384
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

La directive tcp_notsent_lowat = 16384 (16 Ko) restreint la mise en mémoire tampon des données applicatives dans le socket local, éliminant le Bufferbloat interne avant que le paquet n'atteigne l'interface réseau.

Analyse de la télémétrie des flux

L'outil ss permet d'inspecter les métriques BBR en temps réel :

# Analyse détaillée des métriques TCP actives
ss -tin '( dport = :443 or sport = :443 )'

Exemple d'affichage retourné par le noyau :

ESTAB 0 0 10.0.0.2:48392 198.51.100.1:443
  bbr:(bw:182.4Mbps,mrtt:158.21,pacing_rate:228.0Mbps,cwnd:240)
  cubic:(...)

Les indicateurs confirment la bande passante estimée bw:182.4Mbps, le temps d'aller-retour minimal mrtt:158.21 ms et la vitesse de régulation matérielle calculée par l'ordonnanceur.

L'architecture de transport RiceGuard et VPNRice

Une infrastructure de réseau chiffré performante repose sur une gestion intelligente des flux pour pallier les insuffisances d'Internet. VPNRice intègre le contrôle de rythme BBR au cœur du protocole RiceGuard :

  • Régulation aux passerelles Anycast : L'ensemble des points d'entrée Anycast de VPNRice appliquent le cadencement BBR et le planificateur FQ sur leurs liaisons de transit, évitant la saturation des mémoires tampons internationales.
  • Résilience face aux pertes aléatoires : Lors de connexions sur des réseaux cellulaires ou Wi-Fi instables, RiceGuard évite la perte artificielle de 70 % de débit inhérente à CUBIC.
  • Préservation de la réactivité pour le jeu et le streaming : En maintenant les tampons au plus près de l'optimum de Kleinrock, VPNRice assure une gigue minimale et une fluidité constante pour les applications en temps réel.