Table des matières de l'article :
Selon beaucoup, Internet d'aujourd'hui ne déplace pas les données comme il le devrait. La plupart des utilisateurs de téléphones portables dans le monde subissent des retards de quelques secondes à quelques minutes ; le Wi-Fi public dans les aéroports et les lieux de conférence est souvent pire.
Par exemple, les chercheurs scientifiques universitaires dans les départements de physique ou de climatologie doivent échanger des pétaoctets de données par jour avec des collaborateurs mondiaux, mais constatent que leur infrastructure multi-Gbps soigneusement conçue ne fournit souvent que quelques Mbps sur des distances intercontinentales.
Ces problèmes découlent d'un choix de conception fait lorsque le contrôle d'encombrement TCP a été créé dans les années 80, en interprétant la perte de paquets comme une « congestion ».
Cette équivalence était vraie à l'époque, mais elle était due à des limitations technologiques, et non à des principes fondamentaux. À mesure que les cartes réseau (NIC) sont passées du Mbps au Gbps et les puces mémoire du Ko au Go, la relation entre perte de paquets et congestion est devenue plus ténue.
Aujourd'hui, le contrôle de congestion basé sur les pertes TCP, même avec le meilleur actuel, CUBIC11, est la principale cause de ces problèmes.
Lorsque les tampons de goulot d'étranglement sont volumineux, le contrôle de congestion basé sur les pertes les maintient pleins, provoquant un gonflement du tampon.
Lorsque les tampons de goulot d'étranglement sont petits, le contrôle d'encombrement basé sur la perte interprète à tort la perte comme un signal d'encombrement, ce qui entraîne un faible débit. La résolution de ces problèmes nécessite une alternative au contrôle d'encombrement basé sur les pertes.
Trouver cette alternative nécessite de comprendre d'où et comment la congestion du réseau provient.
C’est là qu’intervient TCP BBR. Il s’agit d’un algorithme de contrôle de congestion TCP conçu pour les réseaux Internet modernes congestionnés.
TCP : le partage de la bande passante est important.
TCP essaie d'équilibrer le besoin d'être rapide (transmission de données rapide) et équilibré (partage de la bande passante pour plusieurs utilisateurs), avec beaucoup plus de poids sur l'équilibre.
La plupart des implémentations TCP utilisent un algorithme de backoff qui donne environ ½ bande passante.
En bref, si vous avez une bande passante sortante de 1 gigabit par seconde sur votre serveur, vous pouvez être à peu près sûr que le trafic sortant de votre serveur Web fonctionnant sur TCP ne dépassera guère 500 ou 600 mégabits par seconde.
C'est le principal problème de TCP, son utilisation entraîne un gaspillage (ou plutôt inutile) de bande passante.
BBR TCP : les notions importantes
Vous pouvez consulter l'article pour plus de détails, mais en résumé, BBR est une technologie de contrôle de la congestion qui :
Il est conçu pour réagir à la congestion réelle, et non à la perte de paquets. L'équipe BBR a conçu cet algorithme dans le but de répondre à la congestion réelle, et non à la perte de paquets. BBR modélise le réseau pour transmettre les données à la vitesse de la bande passante disponible et est 2 700 fois plus rapide que les protocoles TCP précédents sur une liaison de 10 Gb/s, avec un temps de réponse de 100 ms et une perte de 1 %.
Conçu pour améliorer les performances du réseau en cas de faible qualité, le protocole TCP BBR répartit plus efficacement l'équité et l'utilisation des ressources, ce qui se traduit par de meilleures vitesses de téléchargement sur un même réseau. Ce gain est particulièrement perceptible lorsque le réseau est dégradé (mais il reste bénéfique même sur un réseau performant).
Il n'est pas nécessaire que le client implémente BBR . C'est là toute la magie. Les algorithmes précédents, comme QUIC, exigeaient que le client et le serveur les implémentent. BBR, lui, ne l'impose pas au client. C'est particulièrement important dans les pays en développement où les plateformes mobiles sont anciennes et la bande passante limitée, ou dans les régions où les sites et services n'ont pas encore effectué la transition. En bref, si votre navigateur ne prend pas en charge QUIC, aucune amélioration n'est possible.
Regardons de plus près BBR sur la route.
Tout cela semble bien, mais voyons à quel point cette technologie est bonne en pratique et pas seulement en théorie. Pour tester les choses, j'ai configuré deux machines virtuelles dans deux régions différentes et j'ai effectué un test Iperf rapide pour vérifier leurs performances :
[4] 0.0-10.0 s 9.97 Go 8.55 Gbits/s
Pour simuler les conditions idéales où BBR est utile (perte de paquets élevée), nous exécutons la commande tc suivante, qui simule la perte de paquets à un certain pourcentage.
sudo tc qdisc ajouter dev eth0 root netem perte 1.5%
Lorsque des machines virtuelles existantes se connectent, nous constatons une baisse significative des performances (à laquelle nous nous attendions) :
[3] 0.0-10.3 s 1.10 Go 921 Mbits/s
Nous avons donc activé BBR, côté serveur uniquement en utilisant la commande suivante (uniquement disponible sur Linux Kernel Major à 4.10) :
sysctl -w net.ipv4.tcp_congestion_control = bbr
Nous avons effectué le même Iperf e
[3] 0.0-10.0 s 2.90 Go 2.49 Gbits/s
Nous constatons une utilisation de la bande passante brute de connexion presque doublée juste après avoir activé une simple option sur le serveur.
Où utiliser TCP BBR ? Partout.
Fondamentalement, il n'y a aucune raison réelle de ne pas utiliser une technologie comme TCP BBR et de réfléchir à l'endroit où elle devrait être utilisée et à l'endroit où le temps ne serait pas perdu et peut-être même stupide.
Bien entendu, les gains seront surtout visibles sur les postes clients situés dans des zones à faible trafic . Par conséquent, si vous basculez entre différentes machines virtuelles, ne vous inquiétez pas si les performances ne s'améliorent pas significativement. Cela dit, son utilisation ne présente aucun inconvénient, même dans les zones bénéficiant d'une bonne connectivité.
Il faut dire que parmi ses utilisations non standard, par exemple, la mise en œuvre de BBR peut aider à gérer une attaque DDOS volumétrique basée sur TCP ou des effets Slashdotting où un site Web est atteint par des centaines de milliers de visiteurs par minute.
Fondamentalement, il s'agit simplement d'activer un noyau Linux supérieur à 4.10 et d'activer un indicateur, avec une simple commande en ligne de commande.
Pourquoi ne pas le faire ?
