L'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 oeuvre 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.
![[Note]](images/note.png) | Note |
|---|---|
Les files HTB permettent à la fois la limitation de trafic et l'envoi prioritaire tout en assurant qu'aucune classe de priorité n'étouffe les autres. Ce dernier point n'était pas possible avec la méthode préconisée par la version 0.1 de ce document. |
La dernière étape porte sur le marquage des paquets au niveau du pare-feu pour affecter des priorités aux paquets avec fwmark.
Bien 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'à 128 kbit/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 128 kb/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 à 90 kb/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.
| Note |
|---|---|
Remarque: les affirmations antérieures de cette section (concernant la mise en file d'attente à N voies) se sont avérées erronées. En l'occurrence, il était possible de classer les paquets dans les éléments de la file de priorité juste au moyen du champ fwmark. Cette fonctionnalité n'était toutefois guère documentée lors de la rédaction de la version 0.1 du guide pratique. |
Pour 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.
| Note |
|---|---|
Remarque: cette documentation reposait à l'origine sur ipchains pour trier les paquets. iptables est à présent utilisé. |
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:
On marque tous les paquets avec l'indice 0x03. Ceci les place tous dans la file de priorité la plus basse.
On marque les paquets ICMP avec l'indice 0x00 afin que ping fournisse la latence des paquets de priorité la plus élevée.
On marque tous les paquets dont le port destination est inférieur à 1024 comme 0x01. Les services système tels telnet et ssh voient leur priorité augmenter. Le port de contrôle de ftp rentre dans cette catégorie. Toutefois, les transferts de données ftp ont lieu avec des ports situés plus haut et ils restent donc dans la catégorie 0x03.
On marque tous les paquets à destination du port 25 (SMTP) avec un indice 0x03 afin d'éviter que l'envoi d'un courrier muni d'un attachement volumineux n'empiète sur le trafic interactif.
On marque tous les paquets en direction d'un serveur de jeu avec un indice 0x02. Les joueurs fous auront une bonne latence sans écraser les applications système qui demandent une latence faible.
On marque tous les paquets de petite taille avec un indice 0x02. Les paquets de type ACK des téléchargements doivent être retournés rapidement afin d'assurer des transferts efficaces. Ceci est possible grâce au module adéquat (c'est-à-dire length) d'iptables.
Tout ce qui précède est bien sûr personnalisable en fonction des besoins.
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.
L'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.
On 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,5Mb/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.