Le noyau Linux nous offre beaucoup de gestionnaires de mises en file d'attente. Le plus largement utilisé est de loin la file d'attente pfifo_fast, qui est celle par défaut. Cela explique aussi pourquoi ces fonctionnalités avancées sont si robustes. Un autre modèle de file d'attente ne coûte rien en développement.
Chacune de ces files d'attente a ses forces et ses faiblesses. Toutes n'ont peut-être pas été bien testées.
Cette file d'attente, comme son nom l'indique (fifo = premier entré, premier sorti), signifie qu'il n'y a pas de traitement spécial pour les paquets reçus. En fait, ce n'est pas tout à fait vrai. Cette file d'attente a trois "bandes". À l'intérieur de chacune de ces bandes, la règle FIFO est appliquée. Cependant, tant qu'il y a un paquet en attente dans la "bande" 0, la "bande" 1 ne sera pas traitée. Il en va de même pour la "bande" 1 et la "bande" 2.
SFQ, comme dit précédemment, n'est pas vraiment déterministe, mais marche (en moyenne). Ses principaux avantages sont qu'elle a besoin de peu de CPU et de mémoire. Une véritable mise en file d'attente équitable nécessite que le noyau garde une trace de toutes les sessions courantes.
Stochastic Fairness Queueing (SFQ) est une implémentation simple de la famille des algorithmes de mise en file d'attente équitable. Cette implémentation est moins précise, mais nécessite aussi moins de calculs que les autres tout en étant presque parfaitement équitable.
Le concept clé dans SFQ est la conversation (ou flux), qui est une séquence de paquets de données ayant suffisamment de paramètres communs pour les distinguer des autres conversations. Les paramètres utilisés dans le cas de paquets IP sont les adresses de source et de destination, ainsi que le numéro de protocole.
SFQ consiste en l'allocation dynamique de files d'attente FIFO, une par conversation. Le gestionnaire de mise en file d'attente travaille en tourniquet (round-robin), envoyant un paquet de chaque FIFO à chaque tour. C'est pour cette raison qu'il est réputé équitable. Le principal avantage de SFQ est qu'il autorise le partage équitable du lien entre plusieurs applications et évite la monopolisation de la bande passante par un client. SFQ ne peut cependant pas distinguer les flux interactifs des flux de masse. On a, en général, recours à CBQ pour effectuer cette distinction, et diriger le flux de masse vers SFQ. [NdT : par flux de masse, il faut entendre gros flot de données, transmis en continu, comme un transfert FTP, par opposition à un flux interactif, comme celui généré par des requêtes HTTP].
Le Token Bucket Filter (TBF) est une file d'attente simple. Elle ne fait que passer les paquets entrants avec un taux de transfert dont les limites sont fixées administrativement. Il est possible de placer en mémoire tampon de courtes rafales de données.
L'implémentation TBF consiste en un tampon (seau), constamment rempli par des morceaux d'informations virtuelles appelés jetons, avec un débit spécifique (débit de jeton). Le paramètre le plus important du tampon est sa taille, qui est le nombre de jetons qu'il peut stocker.
Chaque jeton arrivant laisse sortir un paquet de données entrant de la file d'attente. Ce paquet est alors effacé du seau. L'association de cet algorithme avec les deux flux de jetons et de données, nous donne trois scénarios possibles :
Le dernier scénario est très important, parce qu'il autorise la mise en forme administrative de la bande passante disponible pour les données traversant le filtre. L'accumulation de jetons autorise l'émission de courtes rafales de données sans perte, mais toute surcharge restante causera la perte systématique des paquets.
Le noyau Linux semble aller au-delà de cette spécification, et nous autorise aussi à limiter la vitesse de la transmission par rafales. Cependant, Alexey nous avertit :
Noter que le débit de pointe de TBF est beaucoup plus coriace :
avec un MTU à 1500, P_crit = 150 Koctets/s.
Donc, si vous avez besoin d'un débit de pointe plus
grand, utilisez une alpha avec HZ=1000 :-)
FIXME: Est-ce encore vrai avec TSC (pentium+) ou équivalent ?
FIXME: Si ce n'est pas le cas, ajouter une section sur l'augmentation de fréquence
RED comporte quelques finesses supplémentaires. Quand une session TCP/IP démarre, on ne connaît pas la bande passante disponible. TCP/IP commence donc à transmettre lentement et va de plus en plus vite, mais est limité par le temps de latence au bout duquel les ACKs (acquittements) reviennent.
Une fois qu'un lien est saturé, RED commence à éliminer des paquets, ce qui indique à TCP/IP que le lien est congestionné, et qu'il devrait ralentir. La finesse réside dans le fait que RED simule la congestion réelle, et commence parfois à éliminer des paquets avant que le lien ne soit complètement saturé. Une fois que le lien est complètement saturé, il se comporte comme un contrôleur normal.
Pour plus d'informations sur le sujet, voir le chapitre Dorsale.
Ingress qdisc sert si vous avez besoin de limiter le débit d'un hôte sans l'aide de routeurs ou d'autres machines Linux. Vous pouvez gérer la bande passante entrante et jeter des paquets quand cette bande passante dépasse le débit désiré. Cela peut, par exemple, préserver votre hôte d'une attaque SYN flood. Cela peut aussi servir à ralentir TCP/IP, qui réagit à la perte des paquets par la réduction de la vitesse.
FIXME: au lieu d'éliminer des paquets, pouvons-nous également les envoyer vers une vraie file d'attente ?
FIXME: la mise en forme en éliminant des paquets semble moins désirable que d'utiliser, par exemple, un filtre token bucket. Pas sûr cependant, les routeurs Cisco travaillent de cette manière, et les gens semblent en être contents.
Voir la référence IOS Committed Access Rate à la fin de ce document.
En résumé, vous pouvez utiliser cela pour limiter la vitesse de téléchargement des fichiers et, donc, laisser plus de bande passante disponible pour les autres.
Voir la section sur la protection de votre hôte des attaques SYN flood pour un exemple de la manière dont cela marche.