|
|||||||||||
Jeudi 21 Novembre 2024
|
|||||||||||
| Liens- Logiciels- Distributions- Howto- Lug | Contact/abonnement | ||||||||||
Guide pratique de la gestion de la bande passante d'une ligne ADSLVersion française du ADSL Bandwidth Management HOWTODan SingletaryFrançois Romieu - Traduction française Guillaume Lelarge - Relecture de la version française 1.2.fr.1.02003-03-01 Ce document décrit la configuration d'un routeur Linux pour gérer efficacement le trafic sortant à destination d'un modem ADSL ou de tout autre équipement de bande passante similaire (modem câble, RNIS, etc). Un accent particulier est apporté à la diminution de latence pour le trafic de type interactif et ce même durant les périodes de congestion.
1. IntroductionCe document suggère une méthode de gestion de la bande passante pour le trafic sortant avec une connexion ADSL (ou modem câble) à Internet. Le problème provient du fait que de nombreuses lignes ADSL sont bridées aux environs de 128 kbps pour le trafic montant. La situation s'aggrave lorsque la file d'attente du modem ADSL demande de 2 à 3 secondes pour se libérer quand elle est pleine. Lorsque la bande passante dans le sens montant est saturée, une trame peut mettre jusqu'à trois secondes pour atteindre Internet. Les applications interactives comme telnet et les jeux en réseau sont dégradées. 1.1. Mises à jour du documentLa dernière version de ce document se trouve sur l'Internet à l'adresse : http://www.tldp.org. Les mises à jours seront reproduites dans divers sites web et ftp Linux tels que le LDP : http://www.tldp.org. La dernière version française de ce guide pratique est disponible sur le site traduc.org 1.2. Liste de diffusionSouscrivez à la liste de diffusion de gestion de la bande passante pour l'ADSL http://jared.sonicspike.net/mailman/listinfo/adsl-qos afin de poser des questions ou de recevoir des informations de mise à jour.1.3. AvertissementNi l'auteur, ni les éditeurs, ni tout autre personne ayant contribué à ce guide pratique ne sont d'une quelconque façon responsables des dommages physiques, financiers, moraux ou d'un quelconque type survenus suite à l'utilisation des suggestions qu'il contient. 1.4. Disclaimer
Neither the author nor the distributors, or any other contributor of this HOWTO are in any way responsible for physical, financial, moral or any other type of damage incurred by following the suggestions in this text. 1.5. Droits d'utilisation
L'auteur de ce document est Dan Singletary. La version originale de ce guide pratique est publiée en accord avec les termes de la licence de documentation libre GNU GFDL, qui est ci-incluse par référence. La version française de document a été réalisée par François Romieu et Guillaume Lelarge. La publication de ce document a été préparée par Jean-Philippe Guérard. La version française de ce guide pratique est publiée en accord avec les termes de la licence de documentation libre GNU GFDL, qui est ci-incluse par référence. 1.6. Copyright
This document is copyright 2002 by Dan Singletary, and is released under the terms of the GNU Free Documentation License, which is hereby incorporated by reference. La version française de document a été réalisée par François Romieu et Guillaume Lelarge. La publication de ce document a été préparée par Jean-Philippe Guérard. La version française de ce guide pratique est publiée en accord avec les termes de la licence de documentation libre GNU GFDL, qui est ci-incluse par référence. 1.7. Retours d'expérience et correctionsMerci de faire parvenir en anglais à l'auteur vos questions et commentaires relatifs à ce document à <[email protected]>. N'hésitez pas à faire parvenir tout commentaire relatif à la version française de ce document à <[email protected]>. 2. Cadre d'utilisation2.1. PrérequisLa méthode décrite dans ce document devrait s'appliquer à n'importe quelle configuration Linux. Toutefois, elle n'a pour l'instant été testée que dans la configuration suivante :
2.2. OrganisationToutes les mentions de périphériques réseau et de configuration dans ce guide pratique se rapportent au schéma suivant :
2.3. Files d'attente des paquetsLes files d'attente contiennent les données destinées à un périphérique réseau quand celles-ci ne peuvent pas être expédiées immédiatement. La plupart des files d'attente sont du type premier entré/premier sorti (FIFO/first in, first out) sauf lorsqu'elles sont explicitement configurées pour appliquer une autre stratégie. Cela signifie que lorsqu'une file d'attente est remplie, le paquet qui y a été placé en dernier n'est émis qu'après tous ceux qui étaient déjà présents dans la file. 2.3.1. Le lien montantLa bande passante d'un modem ADSL est asymétrique avec des valeurs typiques de 1.5 Mbit/s en descente et 128kbit/s en trafic montant. Par rapport au débit de cette ligne, le routeur Linux et le modem ADSL sont généralement associés par un lien à 10 Mb/s ou plus. Si l'interface du routeur avec le réseau local est également à 10 Mb/s il n'y a aucune mise en attente au niveau du routeur lorsque les paquets transitent à destination d'Internet. Les paquets sont transmis via eth0 aussi rapidement qu'ils sont reçus du réseau local. Les paquets séjournent dans la file d'attente du modem ADSL puisqu'ils arrivent à 10 Mb/s et sont renvoyés à 128kb/s. Une fois la file d'atttente du modem saturée, les nouveaux paquets sont jetés. TCP s'adapte à ce phénomène et ajuste la taille de sa fenêtre de transmission pour employer toute la bande passante disponible. Si les files d'attente et TCP s'accordent pour utiliser toute la bande passante, des tailles de FIFO importantes augmentent la latence du trafic à vocation interactive. Les files d'attente à n voies sont similaires aux files d'attente de type FIFO à cette différence près qu'elles comprennent plusieurs files. Les paquets sont placés dans l'une des n files en fonction de leurs caractéristiques. Chaque file se voit attribuer une priorité et les paquets sont émis à partir de la file de plus haute priorité qui n'est pas vide. Avec cette stratégie, les paquets FTP peuvent être mis dans une file de priorité plus basse que les paquets destinés à telnet de telle sorte qu'un simple paquet telnet est capable de franchir la file d'attente immédiatement même lors d'un transfert FTP. Ce document a été repris pour faire usage d'une nouvelle file d'attente dans Linux, dite de type HTB (Hierarchical Token Bucket). La file HTB ressemble à la file à n voies décrite précédemment mais elle rend possible la limitation de trafic dans chaque classe. En outre, elle autorise la création d'une hiérarchie de classes de trafic. Une description complète d'HTB dépasse le cadre de ce document. Davantage d'informations sont disponibles sur le site http://www.lartc.org 2.3.2. Le lien descendantLe trafic entrant dans le modem ADSL en provenance d'Internet est mis en file d'attente de la même façon que le trafic sortant à ceci près que la file d'attente se situe chez le FAI. Il n'est donc guère possible de contrôler les priorités relatives des flux ou d'appliquer un traitement préférentiel à certains. La seule façon de maintenir une latence décente consiste à s'assurer que les interlocuteurs n'envoient pas les données trop vite. Il n'y a malheureusement pas de méthode directe. Comme une bonne partie du trafic est de type TCP, il est toutefois possible de ralentir les émetteurs :
3. FonctionnementL'optimisation de la bande passante montante s'effectue en deux étapes. Tout d'abord il faut éviter que le modem ADSL ne mette les paquets en attente car on ne peut pas contrôler la façon dont il gère sa file. Ceci s'effectue en limitant la quantité de données émise par le routeur via eth0 un peu en dessous de la bande passante disponible. Le routeur met en file les paquets qui arrivent du réseau local plus vite qu'il ne les émet. La seconde étape consiste à mettre en œuvre une stratégie de file d'attente au niveau du routeur. On examinera une file d'attente qui peut être configurée pour donner la priorité au trafic interactif tel que telnet ou les jeux à plusieurs participants en réseau. La dernière étape porte sur le marquage des paquets au niveau du pare-feu pour affecter des priorités aux paquets avec fwmark. 3.1. Limitation du trafic sortant avec HTB LinuxBien que le lien entre le routeur et le modem soit à 10 Mb/s, voire plus, le modem n'émet au mieux les données qu'à 128kbit/s. Au delà de cette vitesse, les données sont mise en attente dans la file du modem. Un paquet de ping peut atteindre le modem immédiatement mais devoir attendre quelques secondes avant de rejoindre Internet si la file d'attente du modem est remplie. La plupart des modems ADSL ne permettent pas de contrôler la façon dont les paquets sont retirés de la file d'attente ni quelle est la taille de cette dernière. Le premier objectif consiste donc à déplacer le point de congestion des paquets sortants à un endroit où on peut exercer suffisamment de contrôle. La file HTB limite le rythme d'envoi des paquets au modem ADSL. Bien que le rythme montant puisse atteindre 128kb/s, on doit le brider à une valeur légèrement inférieure. Pour limiter la latence, il faut être certain du fait qu'aucun paquet n'est mis en attente au niveau du modem. L'expérience m'a indiqué qu'une limitation à 90kb/s du trafic sortant me donne 95% de la bande passante atteinte en l'absence de HTB. L'activation de HTB à ce rythme prévient la mise en file d'attente par le modem ADSL. 3.2. Gestion des files de priorité avec HTBPour l'instant, les performances n'ont pas été modifiées. La file de type FIFO des paquets a simplement été déplacée du modem ADSL au routeur. Comme Linux a une longueur de file égale à 100 paquets par défaut, la situation s'est probablement aggravée (mais pas pour longtemps). Chaque classe adjacente dans une file HTB peut se voir attribuer une priorité. En plaçant différents types de trafic dans des classes distinctes et en affectant à ces classes des priorités spécifiques, l'ordre dans lequel les paquets sont extraits de la file puis émis est contrôlable. HTB le permet tout en évitant qu'une classe ne soit éteinte puisqu'une bande passante minimale pour chaque classe peut être garantie. En outre, HTB autorise une classe à utiliser jusqu'à un certain niveau la bande passante laissée libre par les autres classes. Une fois les classes en place, on installe des filtres qui répartissent le trafic dans les classes. Plusieurs approches sont envisageables mais le document s'appuie sur les utilitaires courants ipchains/iptables pour marquer les paquets avec un indicateur fwmark. Les filtres dirigent le trafic dans les classes de la file HTB selon leur indice fwmark. De cette façon, les règles de reconnaissance d'iptables aiguillent certains trafics suivant leur classe. 3.3. Classification des paquets sortant avec iptables
La dernière étape de configuration du routeur pour augmenter la priorité du trafic interactif consiste à spécifier au filtre comment identifier le trafic. Ceci s'effectue avec le champ fwmark des paquets. Sans trop rentrer dans les détails, voici une description simplifiée du cheminement des paquets entre quatre classes dont celle d'indice 0x00 a la priorité la plus élevée :
Tout ce qui précède est bien sûr personnalisable en fonction des besoins. 3.4. Des réglages supplémentaires …Deux choses sont encore susceptibles d'améliorer la latence. La MTU peut être positionnée en dessous de la valeur par défaut de 1500 octets. Sa diminution se répercute sur le temps moyen d'attente lors de l'envoi d'un paquet prioritaire lorsqu'un paquet de faible priorité est déjà en cours de transmission. La bande passante en souffre puisque le poids relatif des informations d'en-tête augmente (40 octets pour le couple TCP et IP). La longueur de queue de 100 paquets par défaut, qui demande jusqu'à 10 secondes pour se vider avec une ligne ADSL et une MTU de 1500 octets, peut également être abaissée. 3.5. Une tentative de limitation du trafic entrantL'emploi d'un périphérique de file intermédiaire (IMQ ou Intermediate Queuing Device) place tous les paquets entrants dans une file d'une façon analogue au traitement des paquets sortants. La gestion de la priorité en est simplifiée. On met tout le trafic hors TCP dans la classe 0x00, le trafic TCP étant quant à lui dans la classe 0x01. Les petits paquets vont également dans la classe 0x00 car il s'agit vraisemblablement d'acquittements de données sortantes déjà émises. Une file d'attente FIFO standard est appliquée à la classe 0x00 et une queue de rejet anticipé aléatoire (Random Early Drop/RED) traite la classe 0x01. RED est meilleur qu'une FIFO pour le contrôle de TCP en ce qu'il rejette des paquets avant que la file ne déborde afin de ralentir le trafic qui semble sur le point de devenir incontrôlable. Les deux classes sont également bornées supérieurement à une valeur inférieure à la capacité maximale de la ligne ADSL. 3.5.1. Problèmes soulevés par la limitation de trafic entrantOn souhaite limiter le trafic entrant afin de ne pas remplir la file d'émission du côté du FAI qui est susceptible de contenir jusqu'à 5 secondes de données. La seule façon de limiter le trafic entrant consiste à jeter des paquets tout à fait valables. Ces paquets ont déjà consommé leur quote part de bande passante et le routeur Linux les jette afin de limiter le rythme d'arrivée des paquets futurs. Ces paquets seront sûrement retransmis et consommeront davantage de bande passante. La limitation du trafic porte sur le rythme auquel les paquets vont être acceptés. Comme le taux courant est bien supérieur en raison des paquets jetés, la bande passante descendante doit être bien inférieure à la capacité de la ligne pour maintenir une latence faible. En pratique, j'ai dû brider ma connexion ADSL descendante de 1,5 Mb/s à 700kb/s afin de conserver une bonne latence avec 5 téléchargements simultanés. Plus les sessions TCP sont nombreuses, plus la bande passante perdue dans les paquets jetés est élevée et plus il faut limiter le taux de transfert. Une meilleure méthode consisterait à jouer sur la fenêtre TCP mais je ne connais pas d'outil libre pour le faire sous Linux. 4. RéalisationAprès toutes ces explications, il est temps de passer à la mise en œuvre sous Linux. 4.1. AvertissementsBrider le rythme d'émission des données vers le modem ADSL n'est pas aussi simple qu'il y parait. La plupart des modems DSL établit juste un pont Ethernet entre le routeur Linux et la passerelle du côté du FAI. La couche de liaison de données s'appuie le plus souvent sur ATM qui envoie les données au moyen de cellules de 53 octets. 5 octets sont consommés pour l'en-tête ATM laissant ainsi 48 octets de données utiles. La transmission d'un simple octet de données isolé ne peut donc pas demander moins de 53 octets au niveau du lien ATM. Dans le cas d'un acquittement TCP typique qui comprend 0 octet de données, 20 octets d'en-tête TCP, autant d'en-tête IP et 18 de préambule Ethernet, les données utiles (40 octets) sont inférieures au minimum de 48 octets requis par une trame Ethernet. Afin d'envoyer les 64 (48+16) octets via ATM, deux cellules ATM sont nécessaires, d'où une consommation de 106 octets de bande passante au niveau du lien ADSL. Chaque paquet TCP d'acquittement gaspille donc 42 octets de bande passante. Ceci ne serait pas gênant si Linux prenait en compte l'encapsulation due au modem ADSL. Il ne peut malheureusement pas le faire et se cantonne aux en-têtes TCP et IP ainsi qu'aux 14 octets d'adresse MAC (les 4 octets de CRC gérés au niveau matériel sont ignorés). Linux ne prend pas en compte la taille minimale de trame Ethernet ni la taille de cellule ATM. Tout ceci pour convaincre qu'il faut limiter le trafic sortant à une valeur sensiblement inférieure à la véritable capacité de la ligne (jusqu'à ce qu'on dispose d'un ordonnanceur de paquets capable de prendre en compte les différentes encapsulations employées). Vous pouvez penser avoir trouvé un bon réglage mais constater des sauts de latence au delà de 3 secondes lors d'un téléchargements important. Ceci viendra probablement d'une mauvaise évaluation de la bande passante consommée par les petits paquets d'acquittement. Je travaille depuis quelques mois sur une solution à ce problème et j'ai presque terminé quelque chose qui sera publié afin que chacun puisse le tester. Ma solution repose sur une file en espace utilisateur à la place de la QoS de Linux pour limiter le rythme de transfert des paquets. Il s'agit d'une variante d'HTB en espace utilisateur. Pour l'instant cette solution a été capable de réguler le trafic sortant lors de téléchargements massifs (plusieurs flux) et de transferts point-à-point en volume (gnutella, sic) avec une telle efficacité que la latence dépasse au plus de 400ms la latence nominale de 15ms inhérente à mon lien ADSL. Pour davantage d'informations, abonnez-vous à la liste de diffusion ou surveillez les mises à jour de ce document. 4.2. Script : mon_limiteurCi-suit le source d'un script que j'emploie pour gérer la bande passante de mon routeur Linux. Il s'appuie sur les concepts expliqués dans ce guide. Le trafic sortant est ventilé entre une des 7 files disponibles en fonction de son type. Le trafic entrant est placé dans une file parmi deux, le trafic TCP étant jeté en premier en cas de surcharge de la ligne. Les valeurs conviennent à mon installation mais les résultats peuvent être différents ailleurs.
5. TestLa méthode de test la plus facile consiste à saturer le lien montant avec du trafic à faible priorité. Si le trafic telnet et le ping ont une priorité élevée par opposition aux transferts FTP, l'augmentation de délai des pings lorsqu'un transfert FTP s'établit devrait être négligeable par rapport à ce qu'elle devient en l'absence de file d'attente. Des pings en dessous de 100ms dépendent de la configuration. Des pings au dessus d'une ou deux secondes signalent une anomalie. 6. Ça fonctionne. Et maintenant ?Maintenant que la bande passante est gérée, il faut s'en servir. Après tout, elle a été payée !
|
|||||||||||
|
|||||||||||
|