http://okki666.free.fr/docmaster/articles/linux133.html : "La gestion QoS de Linux et le contrôle du trafic (IProute) permettent de limiter la masse de données circulant sur une interface réseau. Comprenez bien que cette limitation sur un certain type de connexion réseau aura pour effet de "faire de la place" pour d'autres types. En principe, le contrôle du trafic réseau sortant d'une interface est plus aisé que le contrôle du trafic réseau entrant. Il est important de relever ce détail, car sur une machine faisant office de passerelle et possédant deux interfaces, il sera plus simple de contrôler les sorties de l'une que les entrées de l'autre." (Autrement exprimé, le contrôle est plus fiable en émission qu'un réception.) Confirmation dans https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-127/QoS-et-gestion-du-trafic-avec-Traffic-Control : "Traffic Control travaille sur les paquets sortant du noyau. Il n'a pas, initialement, pour objectif de contrôler le trafic des paquets entrants." Exemples suivants empruntés à https://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/ Augmenter le délai du ping. Lancer un ping dans un premier panneau (tmux). Exécuter dans un second panneau tc qdisc add dev enp0s25 root netem delay 200ms et constater le délai qui augmente en moyenne de 200ms sur les résultats du ping. Pour avoir des statistiques : tc -s qdisc ls dev enp0s25 Pour tout supprimer : tc qdisc del dev enp0s25 root ou, plus spécifique tc qdisc del dev enp0s25 root netem delay 200ms Pour attacher un TBF avec un débit maximal (TOUS TYPES DE TRAFICS CONFONDUS - MAIS QUI N'A D'EFFET QU'EN ÉMISSION) soutenu de 1 Mo/s, un pic de 5 Mo/s, un tampon de 10 ko, avec une limite de taille de file d'attente pré-seau calculée de sorte que TBF provoque au plus 70 ms de latence, avec un comportement de crête parfait. Sur une première machine (machine1) : scp login@machine2:CentOS-7-x86_64-Everything-1708.iso . # constater vitesse moyenne de transfert Sur la seconde machine (machine2), à préparer : tc qdisc add dev enp0s25 root tbf rate 8mbit burst 10kb latency 70ms peakrate 40mbit minburst 1540 # constater la baisse de la vitesse moyenne de transfert (il faut patienter pour que ça se stabilise) Pour supprimer cette limitation, reprendre la commande tc en remplaçant simplement add par del. HTTP Outbound Traffic Shaping : "Nettoyage" (plus exactement rétablissement des réglages par défaut) tc qdisc del dev enp0s25 root Mise en place du contrôle de trafic tc qdisc add dev enp0s25 root handle 1:0 htb default 10 tc class add dev enp0s25 parent 1:0 classid 1:10 htb rate 512kbps ceil 640kbps prio 0 iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark 10 iptables -A OUTPUT -t mangle -p tcp --sport 443 -j MARK --set-mark 10 tc filter add dev enp0s25 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10 tc class change dev enp0s25 parent 1:0 classid 1:10 htb rate 100kbps ceil 640kbps prio 0 Test nc 192.168.6.126 443 < /dev/zero # sur la machine distante : nc -l -p 443 > /dev/null Mesure tc -s -d class show dev enp0s25 Contrôle du trafic FTP "sortant" : https://www.cyberciti.biz/faq/linux-traffic-shaping-ftp-server-port-21-22/ (faire plutôt sur CentOS avec nload -u M qui tourne en parallèle) MODIFIER /etc/vsftpd/vsftpd.conf pour y ajouter pasv_min_port=40000 pasv_max_port=41000 tc qdisc del dev enp0s3 root # nettoyage (valeur par défaut) tc qdisc add dev enp0s3 root handle 11: htb default 500 r2q 1 tc class add dev enp0s3 parent 11: classid 11:1 htb rate 128kbps ceil 128kbps quantum 2048 tc class add dev enp0s3 parent 11:1 classid 11:101 htb rate 64kbps ceil 128kbps prio 0 quantum 2048 tc qdisc add dev enp0s3 parent 11:101 handle 1001: sfq tc filter add dev enp0s3 parent 11: protocol ip handle 101 fw classid 11:101 iptables -A POSTROUTING -t mangle -o enp0s3 -p tcp -m multiport --sports 21,40000:41000 -j MARK --set-xmark 101 iptables -A POSTROUTING -t mangle -o enp0s3 -p tcp -m multiport --sports 21,40000:41000 -j RETURN ______ Dernier essai (http://koo.fi/blog/2008/04/23/limiting-the-bandwidth-of-incoming-traffic/) : tc qdisc add dev enp0s25 handle ffff: ingress tc filter add dev enp0s25 parent ffff: protocol ip prio 5 u32 match ip src 213.138.116.78 police rate 10mbit burst 500k drop flowid :1 curl -4 https://download.freebsd.org/ftp/releases/ia64/ia64/ISO-IMAGES/10.4/FreeBSD-10.4-RELEASE-ia64-dvd1.iso > /dev/null MAIS QUOI QUE JE FASSE, LE DÉBIT EN "DOWNLOAD" PLAFONNE À ENVIRON 25 Ko Limiter la bande passante (en sortie) en fonction d'un uid ou gid : http://salmanbaset.blogspot.fr/2010/08/limiting-bandwidth-per-process-in-linux.html Utilitaire bmon (sur Ubuntu) pour visualiser trafic : lftp -e 'get http://kernel.org/pub/linux/kernel/v4.x/linux-4.14.9.tar.gz' lftp -e 'pget -n 4 http://kernel.org/pub/linux/kernel/v4.x/linux-4.14.9.tar.gz' ET SINON nload (sur CentOS) : nload -u M ALTERNATIVE à tc (utilisation de trickle - http://xmodulo.com/limit-network-bandwidth-linux.html). MAIS NE SEMBLE PAS MARCHER MIEUX POUR LIMITER EN RÉCEPTION !!! lancer bmon sur machine A : nc -l -p 443 > /dev/null sur machine B : trickle -u 100 -d 100 nc 192.168.6.123 443 < /dev/zero ACCESSOIREMENT : http://lartc.org/lartc.html Full nat solution with QoS : http://lartc.org/howto/lartc.cookbook.fullnat.intro.html Bandwidth Limiting with IP Masquerade - Howto (alternative à tc.sh) => http://szabilinux.hu/bandwidth/index.html Bandwidth rate shaping with tc stops working after upgrade to SLES 10 SP2 => https://www.novell.com/support/kb/doc.php?id=7002555 Configure Traffic Shaping with HTB (notamment en download) : https://www.youtube.com/watch?v=U-4qgE6HgP8 => ça fonctionne sur la vidéo MAIS je suis incapable de reproduire, cela n'a aucun effet quand j'essaye de faire la même chose.