Il y a une maladie redoutée qui afflige les fournisseurs de services Internet depuis des années. OK, il y a probablement plusieurs maladies, mais aujourd’hui on parle de ballonnement tampon. Qu’est-ce que c’est, comment le tester et enfin ce que vous pouvez faire à ce sujet. Oh, et un grand bravo à tous ceux qui travaillent sur ce problème. De nombreux programmeurs et ingénieurs, comme Vint Cerf, Dave Taht, Jim Gettys et bien d’autres ont cassé cet écrou pour notre bénéfice collectif.
Lorsque votre ordinateur envoie un paquet TCP/IP à un autre hôte sur Internet, ce paquet est acheminé via votre ordinateur, via la carte réseau, via un commutateur, via votre routeur, via un modem ISP, via quelques routeurs ISP, puis enfin via de très gros routeurs sur son chemin vers le centre de données. Ou peut-être à travers cette chaîne alambiquée d’appareils en sens inverse, pour arriver à un autre bureau. C’est incroyable que tout fonctionne, vraiment. Chacun de ces sauts représente un autre endroit où les choses tournent mal. Et si quelque chose ne va vraiment pas, vous le savez tout de suite. Les pages ne se chargent soudainement pas. Vos appels VoIP sont coupés ou ont des décrochages. Il est assez facile de repérer une connexion rompue, même si la trouver et la réparer n’est pas si simple.
C’est un problème évident. Et si vous avez un problème non évident ? Les sites se chargent, mais juste un peu plus lentement qu’il n’y paraît. Vous savez comment utiliser une ligne de commande, alors vous essayez un ping test. Huh, 15,0 ms pour Google.com. Laissez-le fonctionner pendant une centaine de paquets, et pratiquement aucune perte de paquets. Mais quelque chose ne va pas. Lorsque quelqu’un d’autre diffuse un film ou qu’une machine envoie une sauvegarde à un serveur distant, tout s’effondre. C’est du bufferbloat, et c’est en fait très facile de faire un simple test pour le détecter. Exécutez un test de vitesse et exécutez un test de ping pendant que votre connexion est saturée. Si votre latence sous charge passe par le toit, vous avez probablement un bufferbloat. Il existe même quelques-uns des grands sites de test de vitesse qui proposent désormais des tests de bufferbloat. Mais d’abord, un peu d’histoire.
Histoire de l’effondrement
L’Internet dans les années 1980 était un endroit très différent. Le système de noms de domaine remplacé hosts.txt comme la façon dont le nom d’hôte à la résolution IP a été fait en 1982. Le 1er janvier 1983, l’ARPANET a adopté TCP/IP — l’anniversaire d’Internet. En 1984, un problème se préparait et, en 1986, Internet a subi une crise cardiaque sous la forme d’un effondrement de la congestion.
À cette époque, les réseaux locaux de pointe fonctionnaient à 10 mégabits par seconde, mais les liens de site à site ne transféraient au mieux que 56 kilo-octets par seconde. Fin 1986, les liaisons ont soudainement connu des ralentissements extrêmes, comme la liaison de 400 mètres entre le Lawrence Berkeley Laboratory et l’Université de Californie à Berkeley. Au lieu de 56 Kbps, ce lien transférait soudainement à 40 bits effectifs par seconde. Le problème était l’encombrement. C’est un modèle très similaire à ce qui se passe lorsque trop de voitures se trouvent sur le même tronçon d’autoroute – la circulation ralentit à un rythme effréné.
La version 4.3 de BSD avait une implémentation TCP qui faisait quelques choses intéressantes. Premièrement, il commencerait immédiatement à envoyer des paquets à pleine vitesse. Et deuxièmement, si un paquet était abandonné en cours de route, il le renverrait dès que possible. Sur un réseau local, où la vitesse du réseau est uniforme, cela fonctionne très bien. Sur les débuts d’Internet, en particulier sur cette liaison particulière de Berkeley, la connexion LAN 10 Mb/s était canalisée à 32 kbps ou 56 kbps.
Pour faire face à cette inadéquation, les passerelles de chaque côté du lien disposent d’un petit tampon, d’une valeur d’environ 30 paquets. Dans un scénario de congestion, plus de 30 paquets sont sauvegardés au niveau de la passerelle, et les paquets supplémentaires ont simplement été supprimés. Lorsque des paquets ont été abandonnés ou que la congestion a poussé le temps d’aller-retour au-delà du seuil de délai d’attente, l’expéditeur a renvoyé immédiatement – générant plus de trafic. Plusieurs hôtes essayant d’envoyer trop de données sur la connexion trop étroite entraînent un effondrement de la congestion, une boucle de rétroaction du trafic. Le premier Internet s’est accidentellement DDoS.
La solution consistait en une série d’algorithmes ajoutés à l’implémentation TCP de BSD, qui ont maintenant été adoptés dans le cadre de la norme. En termes simples, pour envoyer le plus rapidement possible, le trafic devait être intelligemment ralenti. La première technique introduite était le démarrage lent. Vous pouvez voir que cela est toujours utilisé lorsque vous exécutez un test de vitesse et que la connexion démarre à une vitesse très lente, puis s’accélère rapidement. Plus précisément, un seul paquet est envoyé au début de la transmission. Pour chaque paquet reçu, un paquet d’accusé de réception (ack) est renvoyé. Lors de la réception d’un accusé de réception, deux autres paquets sont envoyés sur le réseau. Cela se traduit par une montée en puissance rapide jusqu’à deux fois le débit maximal du maillon le plus lent de la chaîne de connexion. Le nombre de paquets « sortants » à la fois est appelé la taille de la fenêtre de congestion. Donc, une autre façon de voir le problème est que chaque succès aller-retour augmente la fenêtre de congestion de un.
Une fois que le démarrage lent a fait son travail et que le premier paquet est abandonné ou expire, le flux TCP passe à l’utilisation d’un algorithme d’évitement de congestion. Celui-ci met l’accent sur le maintien d’un débit de données stable. Si un paquet est abandonné, les fenêtres sont réduites de moitié et chaque fois qu’une fenêtre complète de paquets est reçue, la fenêtre augmente d’une unité. Le résultat est un graphique en dents de scie qui rebondit constamment autour du débit maximal de l’ensemble du chemin de données. C’est un peu trop simplifié, et les algorithmes ont été développés au fil du temps, mais le fait est que le déploiement de cette extension à TCP/IP a sauvé Internet. Dans certains cas, les mises à jour étaient envoyées sur bande, par courrier, une sorte de redémarrage brutal de l’ensemble du réseau.
Avance rapide jusqu’en 2009
Internet a un peu évolué depuis 1986. L’une des choses qui a changé, c’est que le prix du matériel a baissé et que les capacités ont considérablement augmenté. Une passerelle de 1986 mesurerait sa mémoire tampon en kilo-octets, et moins de 100 à cela. Aujourd’hui, il est assez trivial de jeter des mégaoctets et des gigaoctets de mémoire sur des problèmes, et les tampons de routeur ne font pas exception. Que se passe-t-il lorsque des algorithmes écrits pour des tailles de tampon de 50 Ko sont rencontrés avec des tampons de 50 Mo dans des appareils modernes ? Comme on pouvait s’y attendre, les choses tournent mal.
Lorsqu’un grand tampon premier entré, premier sorti (FIFO) se trouve sur le goulot d’étranglement, ce tampon doit se remplir complètement avant que les paquets ne soient supprimés. Un flux TCP est destiné à démarrer lentement jusqu’à 2 fois la bande passante disponible, à commencer très rapidement à supprimer des paquets et à réduire de moitié l’utilisation de la bande passante. Bufferbloat est ce qui se passe lorsque ce flux passe trop de temps à essayer d’envoyer à deux fois la vitesse disponible, en attendant que le tampon se remplisse. Et une fois que la connexion passe dans son mode d’évitement de congestion stable, cet algorithme dépend soit des paquets abandonnés, soit des délais d’attente, où le seuil de délai d’attente est dérivé du temps d’aller-retour observé. Le résultat est que pour toute connexion, la latence aller-retour augmente avec le nombre de paquets mis en mémoire tampon sur le chemin. Et pour une connexion sous charge, les techniques d’évitement de congestion TCP sont conçues pour remplir ces tampons avant de réduire la fenêtre de congestion.
Alors, à quel point cela peut-il être mauvais? Sur un réseau local, votre temps d’aller-retour est mesuré en microsecondes. Votre temps à un hôte Internet devrait être mesuré en millisecondes. Bufferbloat pousse cela à quelques secondes, et à des dizaines de secondes dans certains des pires cas. Là où cela cause vraiment des problèmes, c’est quand cela provoque l’expiration du trafic au niveau de la couche application. Bufferbloat retarde tout le trafic, ce qui peut entraîner des délais d’attente DNS, transformer les appels VoIP en désordre brouillé et faire d’Internet une expérience douloureuse.
La solution est la gestion intelligente des files d’attente. Beaucoup de travail a été fait sur ce concept depuis 1986. La mise en file d’attente équitable a été l’une des premières solutions, rendant les tampons intermédiaires intelligents et divisant les flux de trafic individuels en files d’attente individuelles. Lorsque le lien était encombré, chaque file d’attente libérait un seul paquet à la fois, de sorte que le téléchargement d’un ISO sur Bittorrent n’évincerait pas entièrement votre trafic VoIP. Après de nombreuses itérations, l’algorithme CAKE a été développé et largement déployé. Toutes ces solutions compensent essentiellement un peu de débit maximal afin de garantir une latence considérablement réduite.
Êtes-vous FLENT dans Bufferbloat ?
J’aimerais vous dire que bufferbloat est un problème résolu, et que vous n’avez sûrement pas de problème avec cela sur votre réseau. Ce n’est malheureusement pas tout à fait le cas. Pour savoir si vous avez un problème, utilisez les tests de vitesse sur dslreports, fast.com ou speedtest.net. Chacun de ces trois, et probablement d’autres, donne une sorte de latence sous la mesure de la charge. Il existe un test spécifique Bufferbloat hébergé par waveform et semble être le meilleur à exécuter dans le navigateur. Un réseau idéal affichera toujours une faible latence en cas de congestion. Si votre latence augmente considérablement pendant le test, vous avez probablement un cas de bufferbloat.
Pour les plus nerds d’entre nous, il existe un outil en ligne de commande, flent, qui effectue un test approfondi de bufferbloat. j’ai utilisé la commande, flent rrul -p all_scaled -H flent-fremont.bufferbloat.net pour générer ce graphique, et vous voyez la latence évoluer rapidement au-delà de 100 ms sous charge. Cela exécute le test de réponse en temps réel sous charge et indique clairement que j’ai un petit problème de bufferbloat sur mon réseau. Problème identifié, que puis-je faire ?
Vous pouvez avoir votre gâteau
Puisque nous utilisons tous des routeurs OpenWRT sur nos réseaux… Vous utilisez un routeur open source, n’est-ce pas ? Alternativement, il existe une poignée de routeurs commerciaux qui ont une sorte de SQM intégré, mais nous ne sommes certainement pas satisfaits de cela ici sur Hackaday. La solution FOSS ici est CAKE, un système de gestion de file d’attente, et elle est déjà disponible dans le référentiel OpenWRT. Le forfait que vous recherchez est luci-app-sqm. L’installation qui vous donne une nouvelle page sur l’interface Web – sous Réseau -> SQM QoS.
Sur cette page, choisissez votre interface WAN comme Interface name. Ensuite, convertissez vos résultats de test de vitesse en kilobits/seconde, réduisez environ 5 % et insérez-les dans les vitesses de téléchargement et de téléchargement. Retournez à la Queue Discipline onglet, où nous voulons idéalement utiliser Cake et piece_of_cake.qos comme options. Ce dernier onglet nécessite un peu de travail pour déterminer la meilleure valeur, mais Ethernet with overhead et 22 semblent être des valeurs saines pour commencer. Activez l’instance SQM, puis enregistrez et appliquez.
Et maintenant, nous accordons et testons. Lors de la première installation, le routeur peut avoir besoin d’un redémarrage pour charger le module du noyau. Mais vous devriez voir une différence immédiate sur l’un des tests de bufferbloat. Si votre mémoire tampon de téléchargement ou de téléchargement est toujours excessive, réglez la vitesse de cette direction un peu plus bas de quelques pour cent. Si votre bufferbloat tombe à 0, essayez d’augmenter légèrement la vitesse. Vous recherchez un effet minimal sur la vitesse maximale et un effet maximal sur le bufferbloat. Et c’est tout! Vous avez tué la Bufferbloat Beast !
