|
|
Optimisation TCP/IP pour connexion Internet haute vitesse
Richard Prescott, 5 décembre 2002
IntroductionBonjour, mon nom est Richard Prescott et c'est moi qui va être la cause de votre mal de tête la nuit prochaine. Pour me présenter brièvement, j'ai étudié à l'École Polytechnique de Montréal de 1992 à 1998. Depuis j'ai travaillé principalement comme programmeur de systèmes embarqués et de serveurs. Je ne suis donc pas un grand expert en réseautique mais plutôt un utilisateur passionné.
Juste comme ça, je suis présentement à la recherche d'un emploi. Si vous avez des suggestions pour moi, vous pouvez venir me voir après la présentation ou m'écrire à l'adresse .
PréalablesLe sujet de l'optimisation d'une connexion TCP/IP est un sujet avancé en soit. J'assume donc comme premier préalable, que vous avez déjà une connectivité fonctionnelle avec votre fournisseur d'accès et que votre intranet -- si vous en avez un -- est mis-en-place et sécuritaire. L'intranet en soit est optionnel. Une seule machine branché à un modem est suffisant pour justifier une optimisation de connexion.
Il est donc malheureusement pas question de "comment monter un pare-feu" ici. Il est plus question de savoir qu'est-ce que nous pouvons faire pour ajuster les performances d'une connexion existante.
Le second préalable est une machine Linux 2.4.20-pre1+ équipé d'un tc récent et branché au modem donnant accès à l'Internet.
Notice LégaleIl va s'en dire que Linux-Québec et moi nous nous dégageons de toutes responsabilités de l'utilisation de l'informations de cette présentation. Nous tentons de donner l'heure juste mais des erreurs peuvent survenir. Vous seul êtes responsable de ce que vous faîtes de votre serveur.
Il serait également intéressant de noter les choses suivantes par rapport à nos deux fournisseurs d'accès haute vitesse Bell et Vidéotron. Autant que je sache, aucuns des deux offrent de services ou de support à la clientèle pour Linux. Aussi, toujours si j'ai bien compris, Bell vous permet d'avoir le nombre d'ordinateurs que vous voulez dans votre intranet sans frais supplémentaire mais sans support alors que Vidéotron demande de les aviser pour vous ajouter des frais supplémentaires. Ils utilisent le même principe que pour les télévisions. Je crois qu'alors chaques machines aura une adresse IP publique distinctive. J'ai tenté de communiqué par courriel (pour avoir un log) aux deux fournisseurs. J'ai reçu aucune réponses autre que des messages automatiques m'invitant à téléphoner. Ce que je n'ai pas fait.
Pourquoi optimiser sa connexion InternetCe n'est pas nécessaire d'optimiser sa connexion Internet. Les ajustements de base sont tout-à-fait viables. Probablement que si vous n'aviez jamais entendu parlé d'optimisation vous n'auriez jamais eu cette préoccupation. Donc la véritable raison pourquoi les gens s'attardent à ajuster leur connectivité est pour les raisons suivantes :
- l'apprentissage,
- limiter l'utilisation de la bande passante à certain <processus. ordinateurs, protocoles, services... >,
- se sentir bien dans son cœur.
La première et le dernière sont probablement les raisons principales. Par contre, il peut arriver que quelqu'un aille un problème spécifique qui puisse se résoudre par une meilleure gestion de la bande passante disponible. On veut peut-être faire une division particulière de la facture d'accès avec son colocataire. On est peut-être du genre à faire beaucoup de FTP et de VoIP en même temps. Qui sait ?!
Première étape d'optimisation : limiter la bande passanteIl peut sembler bizarre de limiter la bande passante alors que ce que nous voulons c'est l'optimiser. En fait il faut être conscient que quoi que ce soit, nous aurons toujours la même bande passante. L'idée ici n'est donc pas de réduire la bande passante mais plutôt de changer le point d'étranglement. Présentement, le point d'étranglement est le modem câble. Il possède d'un côté une connexion ethernet rapide et de l'autre côté une connexion plus lente. On dit que c'est de la haute vitesse mais c'est quand même plus lent que de l'ethernet 10/100 Mb/s. Regardons les chiffres pour en être plus sûre :
|
Aval
|
Amont
|
Sympatico Haute-vitesse
|
1 mb/s
|
160 kb/s
|
Sympatico Haute-vitesse Ultra
|
3 mb/s
|
640 kb/s
|
Vidéotron Haute-vitesse
|
3 mb/s ?
|
128 kb/s
|
Vidéotron Haute-vitesse Extrème
|
4 mb/s
|
640 kb/s
|
Pourquoi limiter la bande passante ?Nous voulons limiter la bande à la machine connectée au modem pour que ce soit elle qui est le choix de comment utiliser cette bande passante. La job du modem devient alors simplement faire suivre les paquets au lien d'avoir en plus à choisir quels sont les paquets que nous devons éliminer.
Comment limiter la bande passante ?En ajoutant une discipline de gestion de queue. En effet, chaque interface (exemple eth0) possède un gestionnaire de paquets à envoyer. On n'a pas besoins de gérer les paquets qui arrivent. Ils arrivent, un point c'est tout. Par contre, il est fort probable que nous avons plus de paquets à envoyer que de paquets que nous pouvons envoyer. Dans ce cas qu'est-ce que l'on peut faire ? Les garder en queue pour plus tard ! Lorsque nous aurons le temps des envoyer, nous le ferons. Mais allons nous mettre en queue jusqu'à temps d'épuiser la mémoire de l'ordinateur ? Non. Il faut alors choisir quels seront les paquets à éliminer dans la queue. Les paquets qui ne seront pas envoyer plus loins que cet ordinateur. En anglais on dit que les paquets subissent un drop . Ce n'est pas grave pour un paquet IP d'être éliminer comme ça. Une connexion IP par définition n'est pas fiable. C'est à la couche supérieur (par exemple TCP) de choisir si l'élimination du paquet est importante et demander à la source d'en envoyer un autre de remplacement.
Une discipline de gestion de queue va donc choisir quel sera le ou les paquets candidats à l'élimination de l'envoi en cours. La discipline la plus simple consiste à éliminer les paquets les plus jeunes.
Nous nous allons aller plus loins que ça et éliminer plus de paquets que le support nous le permet. C'est-à-dire que l'interface ethernet entre l'ordinateur et modem peut peut-être permettre une connectivité à 10Mb/s. Nous nous allons seulement envoyer 128kb/s sur ce câble. La différence entre 10Mb/s et 128kb/s sera éliminée.
C'est l'inverse que dans la vrai vie : c'est celui qui tiend le petit boute du bat qui décide.
Il existe plusieurs gestionnaire de queue d'interface avec Linux:
Gestionnaire
|
Commentaire
|
pfifo_fast
|
par défaut, 3 bandes selon TOS, non configurable (sauf txqueuelen)
|
pfifo / bfifo
|
même chose avec un peu de surveillance ( monitoring ).
|
Token Bucket Filter
|
simple, limitation basé sur le taux de transfert utiliser, permet des bursts, ne permet pas la classification.
|
Stochastic Fairness Queue
|
son but est de faire laisser la chance à chacune des "connexions" selon un algorithme de hashing. C'est une approximation d'un round-robin. Son gros avantage est qu'il se configure tout seul. Il ne permet pas la classification.
|
Pour limiter la bande passante, la commande à utiliser est donc la suivante :
tc qdisc add dev eth0 root tbf rate 128kbit burst 1540 latency 50ms
|
Le burst est la taille en octets du tampon entre chacun des tics du système. Comme il y a 100 tics sur PC par seconde, pour 128kb/s nous avons besoins de 164 octets mais ça ne fait pas de sens puisque les paquets sont souvent plus gros. Pour les grosses bande passantes, on peut utiliser la règle du pouce suivante : passez de mbit à kB et ajouter 50%. C'est une excellente idée de mettre plus que 1540 octets de burst. En effet, ca évite de faire trop de trafic en amont de la connexion modem.
Latency est le temps maximal que le paquet peut attendre dans le système avant de passer devant le juge. 50ms est tout-à-fait arbitraire. Un temps trop long va empêcher l'interactivité alors qu'un temps trop court va éliminer des paquets avant le temps.
Pis après ?C'est bien beau de transférer le point d'étranglement mais si on en fait rien ça ne donne pas grand chose. Maintenant que nous avons le contrôle sur quels sont les paquets qui seront éliminés (le petit boute du bat). Il est maintenant possible de choisir quels seront les paquets condamnés.
Pour choisir quels seront les paquets à condamnés il faut changer de qdisc. En effet, à part m'avoir permit de vous les présenter et de présenter c'était quoi une discipline de gestion de queue, les qdisc déjà vu ne sont pas suffisantes pour arriver à notre but.
Ça nous prend une discipline qui permet la classification de paquets sous d'autres disciplines. Si une discipline à des classes et qu'une classe est associée à une discipline, est-ce que la discipline de la classe peut avoir des classes ? La réponse est oui. Le résultat est un arbre de classification des paquets de la queue à gérer. Je vous ai bien dis que vous alliez avoir mal à la tête la nuit prochaine !?
Ce qui décide dans quelle classe un paquet doit appartenir se nomme un classificateur. Un classificateur va faire un test sur le paquet pour juger. Un classificateur peut être aider d'un filtre qui comporte des clauses plus complexes. Nous allons voir ça plus en détail dans quelques instants. C'est simplement pour permettre de nommer les choses que je vous dit ça maintenant.
Vous avez peut-être remarqué l'argument "root" dans la dernière ligne de commande. Celui-ci indiquait que la classe racine de l'interface eth0 devait être un tbf. Nous allons la remplacer par une des suivantes :
Discipline de classification
|
Description
|
Class Based Queue
|
C'est la mère des disciplines de classification. C'est également la plus difficile à configurer. (Elle est très pointilleuse.)
|
PRIO
|
C'est un pfifo_fast mais dont on peut changer les classes. (Mais pas les créer.)
|
Hierarchy Token Bucket
|
C'est le même algorithme que le TBF mais avec des classes. Cool !
|
On donne un identifiant à chacune des classes et des disciplines. Chacune des disciplines possède un identificateur majeur unique et possède 0 comme identificateur mineur. Chacune des classes possède le même majeur que la discipline à laquelle elle se rapporte et possède un mineur unique à l'intérieur de cette discipline (donc jamais 0).
Avec un discipline PRIO, ça ne donne pas grand chose. Pourquoi ?
tc qdisc add dev eth0 root handle 1: prio
# Les classes 1:1, 1:2, 1:3 sont créer automatiquement
tc qdisc add dev eth0 parent 1:1 handle 2: sfq
tc qdisc add dev eth0 parent 1:2 handle 3: sfq
tc qdisc add dev eth0 parent 1:3 handle 4: sfq
|
Parce que l'on ne tiend pas le petit boute du bat !
Une configuration correcteFaute d'avoir aucun autre requis que le TOS et la limitation de la bande passante. Ma configuration personnelle est la suivante:
tc qdisc add dev eth0 root handle 1: htb default 1
tc class add dev eth0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit
tc qdisc add dev eth0 parent 1:1 handle 2: prio
tc qdisc add dev eth0 parent 2:1 handle 3: sfq
tc qdisc add dev eth0 parent 2:2 handle 4: sfq
tc qdisc add dev eth0 parent 2:3 handle 5: sfq
|
Ajoutons du VoIP !
Je n'ai jamais utilisé cette technologie mais mettons que nous aillons du VoIP et que nous voulions la prioritiser plus que les sessions interactives. Cela va nous donner un exemple d'utilisation de filtre. Nous savons que VoIP utilise généralement le port 1720 UDP comme port de destination. Le VoIP HOWTO nous dit que la bande passante varie mais peut être aussi basse que 2.5kb/s. Allouons plus que ce minimum et s'il n'est pas entièrement utilisé, ce n'est pas grave. Les autres classes pourront empiéter sur la bande réservée.
tc qdisc add dev eth0 root handle 1: htb default 2
tc class add dev eth0 parent 1: classid 1:1 htb rate 64kbit ceil 128kbit
tc class add dev eth0 parent 1: classid 1:2 htb rate 64kbit ceil 128kbit
tc qdisc add dev eth0 parent 1:1 handle 2: sfq
tc qdisc add dev eth0 parent 1:2 handle 3: prio
tc qdisc add dev eth0 parent 3:1 handle 4: sfq
tc qdisc add dev eth0 parent 3:2 handle 5: sfq
tc qdisc add dev eth0 parent 3:3 handle 6: sfq
|
Dans ces lignes de commande, rien n'indique que les paquet VoIP doivent être traiter par la discipline "2:". Il faut donc utiliser un filtre :
tc filter add dev eth0 parent 1: prio 1 u32 match ip dport 1720 0xffff flowid 1:1
|
Un filtre doit être attaché à une discipline. La priorité est un nombre arbitraire qui indique l'ordre d'utilisation des filtres. La même priorité peut être utilisée plus d'une fois.
Le filtre u32 inspecte le contenu du paquet pour prendre sa décision. Il peut donc tenir compte de :
- le protocole
- le port source
- le port destination
- l'adresse source
- l'adresse destination
- une marque laissée par iptable
- TOS
- n'importe quel contenu dont nous connaissons l'index dans le paquet.
ConclusionCette présentation n'a pas fait de vous des experts dans le domaine. (De toute façon je n'en suis pas un.) Par contre, elle vous donne un peu plus de vocabulaire dans ce monde. Maintenant vous savez quels types de problèmes vous pouvez résoudre avec ces outils et quels sont les mots clés à utiliser dans Google pour trouver les renseignements nécessaires à sa résolution.
Annexe
TOSLe type of service est honoré avec pfifo_fast et PRIO sans aucun effort supplémentaire. Mais qu'est-ce que le TOS ? C'est un octet dans l'entête des paquets IP qui donne des indications sur comment traiter le paquet. Voici des exemples de fanions qu'il peut contenir :
- Maximise la fiabilité
- Minimise le coût (nntp)
- Maximise la bande passante (ftp data)
- Minimise le délai (telnet)
Référencesnetfilter.org
lartc.org
HTB Home
|
|
