<styles>...

Traffic shaping express

La gestion des files d’attente

Sous GNU/Linux, la gestion et la mise en forme du trafic réseau peut s’avérer assez complexe à mettre en oeuvre. Le principe général est le suivant :

• Sélectionner le type de paquet à traiter dans la couche netfilter, par exemple, les paquets « interactifs » d’une session ssh (port 22), les paquets correspondant à la réception du mail (port 25), etc.

• Marquer ces paquets avec la directive --set-mark de netfilter

• Modifier et hiérarchiser la file d’attente des paquets concernés à l’aide d’un gestionnaire ad hoc (le meilleur gestionnaire sous Linux est htb, Hierarchical Token Bucket).

Même si la documentation est abondante, la solution n’est pas simple à mettre en service, et il n’est pas évident d’en obtenir les effets attendus :)

Pourtant, on aimerait parfois trouver une solution simple pour répondre aux questions suivantes :

• comment limiter la vitesse d’upload de FTP lorsque je « pousse » sur mon serveur un gros fichier, ce qui rend ma connexion quasi-inutilisable pendant ce temps ?

• Comment simuler une connexion par modem pour tester le comportement de mon nouveau site ouaibe, visité via un ancien modem 56K ?

La gestion des files d’attente de paquets, comme on peut la réaliser avec le programme tc, après marquage via netfilter, et dans un script utilisant un gestionnaire comme htb est possible.

Certes.

Mais bien lourde pour résoudre nos simples petits problèmes...

trickle, génial et simplissime !

La réponse à ces questions porte un nom : trickle.

Ce petit logiciel permet la limitation précise de la bande passante, de façon bi-directionnelle, de n’importe quel programme, pour peu qu’il ne soit pas compilé de façon statique.

Le mécanisme est malin : trickle utilise un vieux truc, le détournement (en redéfinissant à l’identique) des appels de fonctions de la bibliothèque standard (la libc).

Ce détournement s’effectue grâce au mécanisme Unix de « preload », qui permet à trickle de s’interposer lors de l’appel de ces fonctions, et de traiter à sa façon les appels aux fonctions réseau (read, write, recvfrom, sendto, ...).

La limitation de bande passante est ainsi obtenue, entièrement en espace utlisateur (à contrario, les gestionnaires de type htb sont exécutés en espace kernel), en mettant à contribution de simples algorithmes appliqués aux appels de fonctions de lecture et écriture de sockets, détournés des fonctions standard.

Malin, donc.

Les férus de sécurité reconnaîtront d’ailleurs là le mécanime d’une bibliothèque un peu oubliée aujourd’hui ⁽¹⁾, libsafe, qui, pour son fonctionnement, utilisait le même hack. Libsafe interceptait les appels aux fonctions standard de manipulation de chaînes de caractères, pour en offrir une version plus sécurisée, insensible aux attaques de type « buffer overflow »...

Ce mode de fonctionnement a ses revers : le mécanisme utilisé ne permet pas de limiter la bande passante d’un programme qui aurait été compilé de façon statique (qui n’appellerait donc plus du tout la bibliothèque standard externe, pas plus que les fonctions que trickle fournit en remplacement de ces appels...).

Voyons si trickle répond à nos deux questions...

pages : 1 2 3 >>