La 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 :
Red Hat Linux 7.3
Un noyau 2.4.18-5 avec une prise en charge de la QoS (éventuellement sous forme de module) qui inclut les correctifs suivants :
file d'attente HTB - http://luxik.cdi.cz/~devik/qos/htb/
Remarque : on signale que les noyaux Mandrake au delà de la version 2.4.18-3 (versions 8.1 et 8.2 de la distribution Mandrake) incluent le correctif HTB.
périphérique IMQ - http://luxik.cdi.cz/~patrick/imq/
iptables v1.2.6a ou suivantes. Le module length est absent de la version d'iptables distribuée avec la Red Hat 7.3
Toutes les mentions de périphériques réseau et de configuration dans ce guide pratique se rapportent au schéma suivant :
<-- 128 kbit/s +------------+ <-- 10 Mbit/s -->
Internet <--------------------> | Modem ADSL | <-------------------+
1.5 Mbit/s --> +------------+ |
| eth0
V
+---------------+
| |
| Routeur Linux |
| |
+---------------+
| .. | eth1..ethN
| |
V V
Réseau local |
Les 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.
La 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
Le 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 :
Jeter volontairement les paquets entrants. TCP est conçu pour employer la bande passante disponible tout en évitant la congestion du lien. Durant un échange TCP, les données sont émises jusqu'à ce qu'un paquet soit perdu. TCP remarque la perte et diminue sa fenêtre de transmission. Le cycle reprend, avec un rythme de progression des envois plus faible au cours du transfert et garantit une transmission aussi rapide que possible.
Jouer avec les annonces de fenêtre de réception. Au cours d'un transfert TCP, le récepteur envoie un flux permanent de paquets d'acquittements (ACK). Les paquets ACK incluent une annonce de taille de fenêtre qui précise la quantité maximale de données non-acquittées qui peut être reçue. Ceci permet de ralentir le rythme d'émission. Il n'existe à ce jour pas de mise en œuvre libre de ce type de contrôle de flux pour Linux (quoique je puisse être en train d'y travailler).