<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Gestionnaires de mise en file d'attente simples, sans classes</title><link href="style.css" rel="stylesheet" type="text/css" /><meta content="DocBook XSL Stylesheets V1.73.2" name="generator" /><link rel="start" href="index.html" title="HOWTO du routage avancé et du contrôle de trafic sous Linux" /><link rel="up" href="ch09.html" title="Chapitre 9. Gestionnaires de mise en file d'attente pour l'administration de la bande passante" /><link rel="prev" href="ch09.html" title="Chapitre 9. Gestionnaires de mise en file d'attente pour l'administration de la bande passante" /><link rel="next" href="ch09s03.html" title="Conseils pour le choix de la file d'attente" /></head><body><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Gestionnaires de mise en file d'attente simples, sans classes</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch09.html">Précédent</a> </td><th align="center" width="60%">Chapitre 9. Gestionnaires de mise en file d'attente pour l'administration de la
bande passante</th><td align="right" width="20%"> <a accesskey="n" href="ch09s03.html">Suivant</a></td></tr></table><hr /></div><div class="sect1" lang="fr"><div class="titlepage"><div><div><h2 class="title"><a id="lartc.qdisc.classless" />Gestionnaires de mise en file d'attente simples, sans classes</h2></div></div></div><p>Comme nous l'avons déjà dit, la gestion de mise en file d'attente permet
de modifier la façon dont les données sont envoyées.
Les gestionnaires de mise en file d'attente sans classes sont ceux qui, en
gros, acceptent les données et qui ne font que les réordonner, les retarder ou
les jeter.
</p><p>Ils peuvent être utilisés pour mettre en forme le trafic d'une interface
sans aucune subdivision.
Il est primordial que vous compreniez cet aspect de la mise en file d'attente
avant de continuer sur les gestionnaires de mise en files d'attente basés sur
des classes contenant d'autres gestionnaires de mise en file d'attente.
</p><p>Le gestionnaire le plus largement utilisé est de loin
<code class="literal">pfifo_fast</code>, qui est celui par défaut.
Ceci explique aussi pourquoi ces fonctionnalités avancées sont si robustes.
Elles ne sont rien de plus « <span class="quote">qu'une autre file d'attente</span> ».
</p><p>Chacune de ces files d'attente a ses forces et ses faiblesses.
Toutes n'ont peut-être pas été bien testées.
</p><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="pfifo-fast" /><code class="literal">pfifo_fast</code></h3></div></div></div><p>Cette file d'attente, comme son nom l'indique : premier entré,
premier sorti (<em class="wordasword">First In First Out</em>), signifie que les
paquets ne subissent pas de traitements spéciaux.
En fait, ce n'est pas tout à fait vrai.
Cette file d'attente a trois « <span class="quote">bandes</span> ».
A l'intérieur de chacune de ces bandes, des règles FIFO s'appliquent.
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.
</p><p>Le noyau prend en compte la valeur du champ Type de Service
des paquets et prend soin d'insérer dans la bande 0 les paquets
ayant le bit « <span class="quote">délai minimum</span> » activé.
</p><p>Ne pas confondre ce gestionnaire de mise en file d'attente sans classes
avec celui basé sur des classes PRIO !
Bien qu'ils aient des comportements similaires,
<code class="literal">pfifo_fast</code> ne possède pas de classes et vous ne
pourrez pas y ajouter de nouveaux gestionnaires avec la commande
<span class="command"><strong>tc</strong></span>.
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a id="N10AA7" />Paramètres & usage</h4></div></div></div><p>Vous ne pouvez pas configurer le gestionnaire
<code class="literal">pfifo_fast</code>,
dans la mesure où c'est celui par défaut.
Voici sa configuration par défaut :
</p><div class="variablelist"><dl><dt><span class="term"><code class="option">priomap</code></span></dt><dd><p>Détermine comment les priorités des paquets sont reliées aux bandes,
telles que définies par le noyau. La relation est établie en se basant sur
l'octet <acronym class="acronym">TOS</acronym> du paquet, qui ressemble à ceci :
</p><pre class="literallayout">
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TOS | MBZ |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre><p>Les quatre bits <acronym class="acronym">TOS</acronym> (le champ TOS) sont définis
comme suit :
</p><pre class="literallayout">
Binaire Décimal Signification
-----------------------------------------
1000 8 Minimise le Délai (Minimize delay) (md)
0100 4 Maximalise le Débit (Maximize throughput) (mt)
0010 2 Maximalise la Fiabilité (Maximize reliability) (mr)
0001 1 Minimalise le Coût Monétaire (Minimize monetary cost) (mmc)
0000 0 Service Normal
</pre><p>Comme il y a 1 bit sur la droite de ces quatre bits, la valeur
réelle du champ <acronym class="acronym">TOS</acronym> est le double de la valeur des bits
<acronym class="acronym">TOS</acronym>. <strong class="userinput"><code>tcpdump -v -v</code></strong> fournit la
valeur de tout le champ <acronym class="acronym">TOS</acronym>, et non pas seulement la
valeur des quatre bits.
C'est la valeur que l'on peut voir dans la première colonne du tableau
suivant :
</p><pre class="literallayout">
TOS Bits Signification Priorité Linux Bande
------------------------------------------------------------------------
0x0 0 Service Normal 0 Best Effort 1
0x2 1 Minimise le Coût Monétaire (mmc) 1 Filler 2
0x4 2 Maximalise la Fiabilité (mr) 0 Best Effort 1
0x6 3 mmc+mr 0 Best Effort 1
0x8 4 Maximalise le Débit (mt) 2 Masse 2
0xa 5 mmc+mt 2 Masse 2
0xc 6 mr+mt 2 Masse 2
0xe 7 mmc+mr+mt 2 Masse 2
0x10 8 Minimise le Délai (md) 6 Interactive 0
0x12 9 mmc+md 6 Interactive 0
0x14 10 mr+md 6 Interactive 0
0x16 11 mmc+mr+md 6 Interactive 0
0x18 12 mt+md 4 Int. Masse 1
0x1a 13 mmc+mt+md 4 Int. Masse 1
0x1c 14 mr+mt+md 4 Int. Masse 1
0x1e 15 mmc+mr+mt+md 4 Int. Masse 1
</pre><p>[NdT : par flux de masse
(<em class="wordasword">bulk flow</em>), il faut entendre « <span class="quote">gros flot
de données transmises en continu</span> » comme un transfert FTP.
A l'opposé, un flux interactif (<em class="wordasword">interactive flow</em>),
correspond à celui généré par des requêtes SSH].
</p><p>Beaucoup de nombres. La seconde colonne contient la valeur
correspondante des quatre bits <acronym class="acronym">TOS</acronym>, suivi de leur
signification.
Par exemple, 15 représente un paquet voulant un coût monétaire minimal,
une fiabilité maximum, un débit maximum <span class="emphasis"><em>ET</em></span> un délai
minimum.
J'appellerai ceci un « <span class="quote">paquet Hollandais</span> ».
</p><p>La quatrième colonne liste la manière dont le noyau Linux
interprète les bits <acronym class="acronym">TOS</acronym>, en indiquant à quelle priorité
ils sont reliés.
</p><p>La dernière colonne montre la carte des priorités par défaut.
Sur la ligne de commande, la carte des priorités ressemble à ceci :
</p><pre class="literallayout">
1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
</pre><p>Ceci signifie , par exemple, que la priorité 4 sera reliée à la
bande numéro 1.
La carte des priorités vous permet également de lister des priorités
plus grandes (> 7) qui ne correspondent pas à une relation avec le
champ <acronym class="acronym">TOS</acronym>, mais qui sont configurées par d'autres
moyens.
</p><p>Le tableau suivant provenant de la RFC 1349 (à lire pour plus de
détails) indique comment les applications devraient configurer leurs bits
<acronym class="acronym">TOS</acronym> pour fonctionner correctement :
</p><pre class="literallayout">
TELNET 1000 (minimise le délai)
FTP
Contrôle 1000 (minimise le délai)
Données 0100 (maximalise le débit)
TFTP 1000 (minimise le délai)
SMTP
phase de commande 1000 (minimise le délai)
phase DATA 0100 (maximalise le débit)
Domain Name Service
requête UDP 1000 (minimise le délai)
requête TCP 0000
Transfert de Zone 0100 (maximalise le débit)
NNTP 0001 (minimise le coût monétaire)
ICMP
Erreurs 0000
Requêtes 0000 (presque)
Réponses <même chose que requête> (presque)
</pre></dd><dt><span class="term"><code class="option">txqueuelen</code></span></dt><dd><p>La longueur de cette file d'attente est fournie par la configuration
de l'interface, que vous pouvez voir et configurer avec
<span class="command"><strong>ifconfig</strong></span> et <span class="command"><strong>ip</strong></span>.
Pour configurer la longueur de la file d'attente à
<code class="literal">10</code>, exécuter :
<strong class="userinput"><code>ifconfig eth0 txqueuelen 10</code></strong>
</p><p>Vous ne pouvez pas configurer ce paramètre avec
<span class="command"><strong>tc</strong></span> !
</p></dd></dl></div></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="TBF" />Filtre à seau de jetons
(<em class="wordasword">Token Bucket Filter</em>)</h3></div></div></div><p>Le <em class="wordasword">Token Bucket Filter</em> (<acronym class="acronym">TBF</acronym>)
est un gestionnaire de mise en file d'attente simple.
Il ne fait que laisser passer les paquets entrants avec un débit
n'excédant pas une limite fixée administrativement.
L'envoi de courtes rafales de données avec un débit dépassant cette limite
est cependant possible.
</p><p><acronym class="acronym">TBF</acronym> est très précis, et peu gourmand du point de vue
réseau et processeur.
Considérez-le en premier si vous voulez simplement ralentir une interface !
</p><p>L'implémentation <acronym class="acronym">TBF</acronym> consiste en un tampon (seau),
constamment rempli par des éléments virtuels d'information 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 correspond au
nombre de jetons qu'il peut stocker.
</p><p>Chaque jeton entrant laisse sortir un paquet de données de la
file d'attente de données et ce jeton est alors supprimé du seau.
L'association de cet algorithme avec les deux flux de jetons et de données,
nous conduit à trois scénarios possibles :
</p><div class="itemizedlist"><ul><li><p>Les données arrivent dans <acronym class="acronym">TBF</acronym> avec un débit
<span class="emphasis"><em>EGAL</em></span> au débit des jetons entrants.
Dans ce cas, chaque paquet entrant a son jeton correspondant et passe la
file d'attente sans délai.
</p></li><li><p> Les données arrivent dans <acronym class="acronym">TBF</acronym> avec un débit
<span class="emphasis"><em>PLUS PETIT</em></span> que le débit des jetons.
Seule une partie des jetons est supprimée au moment où les paquets de
données sortent de la file d'attente, de sorte que les jetons s'accumulent
jusqu'à atteindre la taille du tampon.
Les jetons libres peuvent être utilisés pour envoyer des données avec un
débit supérieur au débit des jetons standard, si de courtes rafales de
données arrivent.
</p></li><li><p>Les données arrivent dans <acronym class="acronym">TBF</acronym> avec un débit
<span class="emphasis"><em>PLUS GRAND</em></span> que le débit des jetons.
Ceci signifie que le seau sera bientôt dépourvu de jetons, ce qui provoque
l'arrêt de <acronym class="acronym">TBF</acronym> pendant un moment.
Ceci s'appelle « <span class="quote">une situation de dépassement de limite</span> »
(<em class="wordasword">overlimit situation</em>).
Si les paquets continuent à arriver, ils commenceront à être éliminés.
</p></li></ul></div><p>Le dernier scénario est très important, car il autorise la
mise en forme administrative de la bande passante disponible pour les
données traversant le filtre.
</p><p>L'accumulation de jetons autorise l'émission de courtes rafales de
données sans perte en situation de dépassement de limite, mais toute surcharge
prolongée causera systématiquement le retard des paquets, puis leur rejet.
</p><p>Notez que, dans l'implémentation réelle, les jetons correspondent à des
octets, et non des paquets.
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a id="N10B6E" />Paramètres & usage</h4></div></div></div><p>Même si vous n'aurez probablement pas besoin de les changer,
<acronym class="acronym">TBF</acronym> a des paramètres.
D'abord, ceux toujours disponibles sont :
<div class="variablelist"><dl><dt><span class="term"><code class="option">limit or latency</code></span></dt><dd><p><code class="option">Limit</code> est le nombre d'octets qui peuvent être mis
en file d'attente en attendant la disponibilité de jetons.
Vous pouvez également indiquer ceci d'une autre manière en configurant le
paramètre <code class="option">latency</code>, qui spécifie le temps maximal
pendant lequel un paquet peut rester dans <acronym class="acronym">TBF</acronym>.
Ce dernier paramètre prend en compte la taille du seau, le débit, et s'il
est configuré, le débit de crête (<code class="option">peakrate</code>).
</p></dd><dt><span class="term"><code class="option">burst/buffer/maxburst</code></span></dt><dd><p>Taille du seau, en octets.
C'est la quantité maximale, en octets, de jetons dont on disposera
simultanément.
En général, plus les débits de mise en forme sont importants, plus le
tampon doit être grand.
Pour 10 Mbit/s sur plateforme Intel, vous avez besoin d'un tampon d'au
moins 10 kilo-octets si vous voulez atteindre la limitation
configurée !
</p><p>Si votre tampon est trop petit, les paquets pourront être rejetés
car il arrive plus de jetons par top d'horloge que ne peut en contenir le
tampon.
</p></dd><dt><span class="term"><code class="option">mpu</code></span></dt><dd><p>Un paquet de taille nulle n'utilise pas une bande passante nulle.
Pour ethernet, la taille minimale d'un paquet est de 64 octets.
L'Unité Minimale de Paquet (<em class="wordasword">Minimun Packet Unit</em>)
détermine le nombre minimal de jetons à utiliser pour un paquet.
</p></dd><dt><span class="term"><code class="option">rate</code></span></dt><dd><p>Le paramètre de la vitesse.
Voir les remarques au-dessus à propos des limites !
</p></dd></dl></div>
</p><p>Si le seau contient des jetons et qu'il est autorisé à se vider, alors il
le fait par défaut avec une vitesse infinie. Si ceci vous semble inacceptable,
utilisez les paramètres suivants :
<div class="variablelist"><dl><dt><span class="term"><code class="option">peakrate</code></span></dt><dd><p>Si des jetons sont disponibles et que des paquets arrivent,
ils sont immédiatement envoyés par défaut ;
et pour ainsi dire à « <span class="quote">la vitesse de la lumière</span> ».
Cela peut ne pas vous convenir, spécialement si vous avez un grand seau.
</p><p>Le débit de crête (<em class="wordasword">peak rate</em>) peut être
utilisé pour spécifier la vitesse à laquelle le seau est autorisé à se
vider.
Si tout se passe comme écrit dans les livres, ceci est réalisé en libérant
un paquet, puis en attendant suffisamment longtemps, pour libérer le
paquet suivant.
Le temps d'attente est calculé de manière à obtenir un débit égal au débit
de crête.
</p><p>Cependant, étant donné que la résolution du minuteur
(<em class="wordasword">timer</em>) d'UNIX est de 10 ms et que les paquets
ont une taille moyenne de 10 000 bits, nous sommes limités à un débit de
crête de 1mbit/s !
</p></dd><dt><span class="term"><code class="option">mtu/minburst</code></span></dt><dd><p>Le débit de crête de 1Mb/s ne sert pas à grand chose si votre débit
habituel est supérieur à cette valeur. Un débit de crête plus élevé peut
être atteint en émettant davantage de paquets par top du minuteur, ce qui
a pour effet de créer un second seau.
</p><p>Ce second <em class="wordasword">bucket</em> ne prend par défaut
qu'un seul paquet, et n'est donc en aucun cas un seau.
</p><p>Pour calculer le débit de crête maximum, multipliez le
<em class="wordasword">mtu</em> que vous avez configuré par 100
(ou plus exactement par HZ, qui est égal à 100 sur Intel
et à 1024 sur Alpha).
</p></dd></dl></div>
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a id="N10BCD" />Configuration simple</h4></div></div></div><p>Voici une configuration simple, mais <span class="emphasis"><em>très</em></span>
utile :
</p><pre class="screen"># tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
</pre><p>Pourquoi est-ce utile ? Si vous avez un périphérique réseau avec
une grande file d'attente, comme un modem DSL ou un modem câble, et que le
dialogue se fasse à travers une interface rapide, comme une interface
ethernet, vous observerez que télécharger vers l'amont
(<em class="wordasword">uploading</em>) dégrade complètement l'interactivité.
</p><p>[NdT : <em class="wordasword">uploading</em> désigne une
opération qui consiste à transférer des données ou des programmes stockés dans
un ordinateur local vers un ordinateur distant à travers un réseau.
La traduction officielle pour ce terme est
« <span class="quote">téléchargement vers l'amont</span> ».
On parle alors de voie montante.
Le <em class="wordasword">downloading</em> désigne l'opération inverse (transfert
d'un hôte distant vers l'ordinateur local) et est traduit par
« <span class="quote">téléchargement</span> » ou
« <span class="quote">téléchargement vers l'aval</span> ».
On parle alors de la voie descendante.]
</p><p>Le téléchargement vers l'amont va en effet remplir la file d'attente du
modem. Celle-ci est probablement <span class="emphasis"><em>ENORME</em></span> car cela aide
vraiment à obtenir de bon débit de téléchargement vers l'amont.
Cependant, ceci n'est pas forcément ce que voulez.
Vous ne voulez pas forcément avoir une file d'attente importante de manière
à garder l'interactivité et pouvoir encore faire des choses pendant que vous
envoyez des données.
</p><p>La ligne de commande au-dessus ralentit l'envoi de données à un débit
qui ne conduit pas à une mise en file d'attente dans le modem.
La file d'attente réside dans le noyau Linux, où nous pouvons lui imposer une
taille limite.
</p><p>Modifier la valeur 220kbit avec votre vitesse de lien
<span class="emphasis"><em>REELLE</em></span> moins un petit pourcentage.
Si vous avez un modem vraiment rapide, augmenter un peu le paramètre
<code class="option">burst</code>.
</p></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="lartc.sfq" />Mise en file d'attente stochastiquement équitable
(<em class="wordasword">Stochastic Fairness Queueing</em>)</h3></div></div></div><p><em class="wordasword">Stochastic Fairness Queueing</em>
(<acronym class="acronym">SFQ</acronym>) est une implémentation simple de la famille des
algorithmes de mise en file d'attente équitable.
Cette implémentation est moins précise que les autres, mais elle nécessite
aussi moins de calculs tout en étant presque parfaitement équitable.
</p><p>Le mot clé dans <acronym class="acronym">SFQ</acronym> est conversation (ou flux),
qui correspond principalement à une session <acronym class="acronym">TCP</acronym> ou un flux
<acronym class="acronym">UDP</acronym>.
Le trafic est alors divisé en un grand nombre de jolies files d'attente
<acronym class="acronym">FIFO</acronym> : une par conversation.
Le trafic est alors envoyé dans un tourniquet, donnant une chance à chaque
session d'envoyer leurs données tour à tour.
</p><p>Ceci conduit à un comportement très équitable et empêche qu'une seule
conversation étouffe les autres.
<acronym class="acronym">SFQ</acronym> est appelé « <span class="quote">Stochastic</span> » car il n'alloue
pas vraiment une file d'attente par session, mais a un algorithme qui
divise le trafic à travers un nombre limité de files d'attente en utilisant
un algorithme de hachage.
</p><p>A cause de ce hachage, plusieurs sessions peuvent finir dans le même
seau, ce qui peut réduire de moitié les chances d'une session d'envoyer un
paquet et donc réduire de moitié la vitesse effective disponible.
Pour empêcher que cette situation ne devienne importante,
<acronym class="acronym">SFQ</acronym> change très souvent son algorithme de hachage pour que
deux sessions entrantes en collision ne le fassent que pendant un nombre
réduit de secondes.
</p><p>Il est important de noter que <acronym class="acronym">SFQ</acronym> n'est seulement
utile que dans le cas où votre interface de sortie est vraiment saturée !
Si ce n'est pas le cas, il n'y aura pas de files d'attente sur votre
machine Linux et donc, pas d'effets.
Plus tard, nous décrirons comment combiner <acronym class="acronym">SFQ</acronym> avec d'autres
gestionnaires de mise en files d'attente pour obtenir le meilleur des deux mondes.
</p><p>Configurer spécialement <acronym class="acronym">SFQ</acronym> sur l'interface ethernet
qui est en relation avec votre modem câble ou votre routeur DSL est vain sans
d'autres mises en forme du trafic !
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a id="N10C34" />Paramètres & usage</h4></div></div></div><p><acronym class="acronym">SFQ</acronym> est presque configuré de base :
</p><div class="variablelist"><dl><dt><span class="term"><code class="option">perturb</code></span></dt><dd><p>Reconfigure le hachage une fois toutes les <code class="option">pertub</code>
secondes. S'il n'est pas indiqué, le hachage se sera jamais reconfiguré.
Ce n'est pas recommandé. 10 secondes est probablement une bonne valeur.
</p></dd><dt><span class="term"><code class="option">quantum</code></span></dt><dd><p>Nombre d'octets qu'un flux est autorisé à retirer de la file
d'attente avant que la prochaine file d'attente ne prenne son tour.
Par défaut, égal à la taille maximum d'un paquet (<acronym class="acronym">MTU</acronym>).
Ne le configurez pas en dessous du <acronym class="acronym">MTU</acronym> !
</p></dd></dl></div></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a id="N10C53" />Configuration simple</h4></div></div></div><p>Si vous avez un périphérique qui a une vitesse identique à celle
du lien et un débit réel disponible, comme un modem téléphonique, cette
configuration aidera à promouvoir l'équité :
</p><pre class="screen"># tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)
</pre><p>Le nombre <code class="literal">800c</code> est un descripteur
(<em class="wordasword">handle</em>) automatiquement assigné et
<code class="option">limit</code> signifie que <code class="literal">128</code> paquets
peuvent attendre dans la file d'attente.
Il y a <code class="literal">1024</code> « <span class="quote">seaux de hachage</span> » disponibles
pour la comptabilité, <code class="literal">128</code> pouvant être actifs à la
fois (pas plus de paquets ne conviennent dans la file d'attente).
Le hachage est reconfiguré toutes les 10 secondes.
</p></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ch09.html">Précédent</a> </td><td align="center" width="20%"><a accesskey="u" href="ch09.html">Niveau supérieur</a></td><td align="right" width="40%"> <a accesskey="n" href="ch09s03.html">Suivant</a></td></tr><tr><td valign="top" align="left" width="40%">Chapitre 9. Gestionnaires de mise en file d'attente pour l'administration de la
bande passante </td><td align="center" width="20%"><a accesskey="h" href="index.html">Sommaire</a></td><td valign="top" align="right" width="40%"> Conseils pour le choix de la file d'attente</td></tr></table></div></body></html>
