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 c'était à cause de limitations technologiques, pas de principes premiers. Comme les NIC (contrôleurs d'interface réseau) ont évolué de Mbps à Gbps et les puces de mémoire de Ko à Go, la relation entre la perte de paquets et la 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 créé pour la congestion Internet moderne.
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
tu peux lire le document pour plus de détails, mais l'essentiel est que BBR est une technologie de contrôle de congestion qui :
Il est conçu pour répondre à la congestion réelle plutôt qu'à la perte de paquets. L'équipe BBR a conçu l'algorithme avec le désir d'avoir quelque chose qui réponde à la congestion réelle, plutôt qu'à la perte de paquets. BBR modélise le réseau à envoyer à la vitesse de la bande passante disponible et est 2700 10 fois plus rapide que le TCP précédent sur une liaison de 100 Gb, 1 ms avec XNUMX% de perte
Axé sur l'amélioration des performances du réseau lorsque le réseau n'est pas très bon. TCP BBR équilibre plus précisément l'équité et l'utilisation, ce qui se traduit par de meilleures vitesses de téléchargement sur le même réseau. Cela est particulièrement visible dans les situations où le réseau est endommagé (cependant, cela ne fait pas de mal si vous êtes sur un réseau propre et grinçant)
Il ne nécessite pas que le client implémente BBR . C'est la vraie recette magique. Les algorithmes précédents tels que QUIC exigeaient que le client et le serveur implémentent tous les deux l'algorithme. BBR n'exige pas que le client utilise également BBR. Cela est particulièrement pertinent dans les pays en développement qui utilisent des plates-formes mobiles plus anciennes et ont une bande passante limitée, ou dans les zones où les sites et les services n'ont pas encore effectué le changement. En bref, si votre navigateur ne prend pas en charge QUIC, il n'y avait aucun moyen d'améliorer quoi que ce soit.
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 près de 2 fois une utilisation brute de la bande passante de connexion juste après avoir définir un simple drapeau 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 sûr, la plupart des avantages seront visibles sur points de terminaison clients dans des zones avec de mauvaises conditions de circulation . Donc, si vous basculez entre les machines virtuelles, ne vous inquiétez pas si les choses ne vont pas beaucoup mieux. Cela dit, il n'y a aucun inconvénient à l'utiliser, même dans les zones de bonne connexion.
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 ?
