Petite étude sur la mise en forme et le comportement du flux IP 
étude réalisé sur un réseau de 100mbits
 machine cliente windows (192.168.0.2)
 machine serveur linux (192.168.0.3)
 
 
les moniteurs réseaux sont sur le serveur linux: iptraf en enregistrements sur:
le trafic par port
le trafic total
La bande passante est sciement limitée a 113Kbit/s (théorique)
Le champs TOS est modifié, pour SMB il passe de 0x10 a 0x8
Le champs TOS  du flux ssh client est a "0", le flux de retour(serveur) est a 0x10
Le champs TOS du flux ftp est a 0x8
Donc la priorité est donnée au flux ssh (0x10)
les disciplines çi-dessous sont appliquées

#####################################################################################

DEV=eth0

iptables -t mangle -F
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 22 -j TOS --set-tos Minimize-Delay
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 139 -j TOS --set-tos 0x8
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 22 -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 80 -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 10000 -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 139 -j MARK --set-mark 2
iptables -t mangle -A OUTPUT -p tcp -o $DEV --sport 20 -j MARK --set-mark 2

## définition de la 1ere classe
   
tc qdisc add dev $DEV root handle 10:0 cbq bandwidth 1Mbit avpkt 1000 
## classe qui encadre le flux (bounded,isolated), dans le pire des cas le flux ne peut dépasser le "rate"
tc class add dev $DEV parent 10:0 classid 10:1 cbq bandwidth 1Mbit rate 113Kbit allot 1500 prio 5 bounded isolated
  
tc class add dev $DEV parent 10:1 classid 10:2 cbq bandwidth 1Mbit rate 30Kbit allot 1500 prio 1  avpkt 1000  
tc class add dev $DEV parent 10:1 classid 10:3 cbq bandwidth 1Mbit rate 50Kbit allot 1500 prio 8  avpkt 1000  

tc qdisc add dev $DEV parent 10:2  handle 2: sfq perturb 10
tc qdisc add dev $DEV parent 10:3  handle 3: sfq perturb 10

tc filter add dev $DEV parent 10: protocol ip handle 1 fw flowid 10:2
tc filter add dev $DEV parent 10: protocol ip handle 2 fw flowid 10:3


tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip u32 match \
ip dport 20 0xffff police rate 20kbit burst 5k drop flowid :1

##############################################################
 en absisse: le nombres d'octets transmis s'incrémentants
 en ordonnée: le temps écoulé en  secondes
 en jaune: flux FTP 
 en marron: flux SMB 
 en vert: flux HTTP 
 le ftp occupe au départ, la totalité de la bande passante, le débit est "trés" élevé
 Ensuite, le flux smb arrive, ralentissant d'autant le débit ftp
 L'arrivé d'un troisième flux, http, se traduit par la chute complete du débit, les courbes s'allongeant 

 



 en absisse: le nombres d'octets transmis
 en ordonnée: le temps écoulé en  secondes
flux ssh en marron 
flux smb en vert 
flux ftp en bleu 
flux total en jaune 
 Cas spécifique  representant l'arrivé d'un flux ftp dans un flux smb occupant presque la totalité de la bande passante,seule une petite partie est utilisé par un flux ssh
 L'arrivé du flux ftp fait chuter la bande passante!! (..je ne sais pas pourquoi,peut etre un défault de mesure!), les flux smb et ftp s'équilibrent ensuite de manière égale, le flux ssh ne subit aucune modification, s'amplifiant meme.
 

 



 en absisse: le nombres d'octets transmis
 en ordonnée: le temps écoulé en  secondes
flux SMB en marron 
flux FTP en vert 
flux SSH en bleu 
flux HTTP en jaune 
flux total en mauve 
Dans ce cas de figure, la bande passante est occupée par un important flux ftp et un faible flux ssh (utilisation  normal d'ssh :)
  
La, viens se rajouter un flux smb, les 2 flux principaux s' équilibre et se divisent équitablement
la bande passante
 La venue d'un 4ème flux (http) va faire rechuter l'ensemble des flux, sauf le flux ssh (prioritaire: classid 10:2 et TOS 0x10) qui lui se met a monter(j'avais lancé une commande tree sur /). 

 



 CONCLUSION 
Le partage de la bande passante (débit/seconde) a l'air équitable:
L'utilisation de 3 flux, divise, aprés stabilisation, la bande passante par 3.
Par contre sous la contrainte, La classe prioritaire conserve sa bande passante et peut meme
l'augmenter dans une certaine mesure
Je downloader un divx par FTP et SMB et, un mp3 par http, j'avais au moins 3 sessions ssh, elles montraits des signes de ralentissement.
IL ME RESTE BEAUCOUP D' ANALYSES A FAIRE ex: histogramme du flux sans shapping, flux sans classe mais avec modification TOS etc...