infra / reseaux-tcp-ip
QoS et performance réseau niveau expert
Explication
Ce que vous allez apprendre
- Comprendre les quatre étapes de la QoS : classification, marquage, mise en forme, ordonnancement
- Distinguer clairement débit et latence, deux mesures différentes souvent confondues
- Prioriser un flux critique (VoIP, SSH) avec
tc(traffic control) sous Linux - Mesurer un débit réel avec
iperf3, en TCP comme en UDP - Régler des paramètres noyau pertinents (buffers, algorithme de congestion BBR) après avoir mesuré
Dans quel contexte ?
Une entreprise utilise la téléphonie sur IP (VoIP) en interne, mais les employés se plaignent de coupures audio dès qu'un collègue lance une sauvegarde volumineuse sur le même lien Internet. Sans QoS, le trafic de sauvegarde et le trafic VoIP se disputent équitablement la bande passante disponible — ce qui dégrade fortement la voix, sensible aux délais, alors que la sauvegarde peut très bien tolérer d'être un peu plus lente. Une règle tc qui priorise le port SIP résout le problème sans changer le matériel.
Le problème : toute la bande passante n'a pas la même valeur
Sur un réseau saturé, un gros transfert de fichier et un appel vocal se disputent la même bande passante. Sans distinction, le réseau traite les deux de façon égale — ce qui dégrade l'appel (des coupures, des délais) alors qu'un transfert de fichier ralenti passe inaperçu. La QoS (Quality of Service, qualité de service) consiste à décider délibérément quel trafic mérite la priorité quand la ressource se fait rare.
| Étape QoS | Rôle |
|---|---|
| Classification | Identifier le type de trafic (port, IP, protocole) |
| Marquage | Taguer le paquet (DSCP) pour les équipements en aval |
| Mise en forme / limitation | Lisser ou plafonner le débit |
| Ordonnancement | Décider quel paquet part en premier |
Piège fréquent
Régler des paramètres réseau à l'aveugle (buffers, algorithme de congestion) sans mesurer d'abord le comportement réel avec iperf3 revient à corriger un problème qu'on n'a pas identifié. Mesure toujours avant d'agir — la même règle que pour l'optimisation logicielle.
Les quatre étapes du mécanisme
La QoS suit toujours la même logique en cascade : d'abord classifier le trafic (identifier de quel type il s'agit, par port, adresse, ou protocole), puis marquer les paquets concernés (un champ spécial de l'en-tête IP indique leur priorité aux équipements suivants), ensuite mettre en forme ou limiter le débit (lisser les pics, rejeter ou re-prioriser ce qui dépasse un seuil), et enfin ordonnancer — décider concrètement quel paquet part en premier quand plusieurs attendent en même temps.
Deux problèmes distincts qu'il ne faut jamais confondre
Le débit (combien de données par seconde) et la latence (combien de temps met un aller-retour) sont deux mesures différentes, souvent découplées : un lien peut avoir énormément de bande passante disponible tout en restant lent à réagir à cause d'une latence élevée. C'est ce que capture le "Bandwidth-Delay Product" : la fenêtre TCP effective (la quantité de données envoyées avant d'attendre une confirmation) divisée par le temps d'aller-retour détermine le débit réellement atteignable — un lien à forte latence peut brider le débit même avec une bande passante généreuse.
Pourquoi mesurer avant d'agir
Régler des paramètres réseau à l'aveugle (buffers, algorithmes de congestion) sans mesurer d'abord le comportement réel (avec des outils comme iperf3) revient à optimiser sans savoir ce qui pose réellement problème — la même leçon que celle vue pour l'optimisation logicielle : toujours mesurer avant de corriger.
Commandes & code
QoS et performance réseau niveau expert
# QoS (Quality of Service) : prioriser certains flux quand la bande passante est limitée
# Sans QoS : tout le trafic est égal -> un gros transfert de fichier peut dégrader un appel VoIP
# Concepts clés
# Classification : identifier à quel type de trafic appartient un paquet (DSCP, ports, IP)
# Marquage : taguer le paquet (champ DSCP dans l'en-tête IP) pour que les équipements en aval le respectent
# Mise en forme (shaping) : lisser le débit pour éviter les pics
# Limitation (policing) : rejeter ou re-marquer le trafic qui dépasse un seuil
# Ordonnancement (queuing) : décider quel paquet part en premier quand plusieurs attendent# --- tc (traffic control) : QoS native sous Linux ---
# Limiter la bande passante sortante d'une interface à 10 Mbit/s (simple, avec tbf)
sudo tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms
# Prioriser le trafic SSH/VoIP au-dessus du reste (HTB : Hierarchical Token Bucket)
sudo tc qdisc add dev eth0 root handle 1: htb default 30
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
sudo tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40mbit ceil 100mbit prio 1 # priorité haute
sudo tc class add dev eth0 parent 1:1 classid 1:30 htb rate 60mbit ceil 100mbit prio 3 # reste du trafic
# Filtre : classe le trafic SSH (port 22) et VoIP (port 5060) dans la classe prioritaire
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 22 0xffff flowid 1:10
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 5060 0xffff flowid 1:10
tc qdisc show dev eth0 # affiche la configuration QoS active
tc -s class show dev eth0 # statistiques par classe (paquets, octets, drops)
# Marquage DSCP au niveau applicatif/pare-feu (pour que les équipements réseau en amont priorisent)
sudo nft add rule inet mangle output ip dscp set cs5 tcp sport 5060 # priorise la VoIP sortante
# --- Diagnostic de performance réseau ---
iperf3 -s # côté serveur : lance un serveur de test de débit
iperf3 -c serveur.exemple.com # côté client : mesure le débit réel entre les deux machines
iperf3 -c serveur.exemple.com -u -b 10M # test en UDP à un débit cible (mesure la perte de paquets)
iperf3 -c serveur.exemple.com -P4 # 4 flux parallèles, utile pour saturer un lien à forte latence
# Tuning noyau pour de la haute performance réseau (serveurs à fort débit)
sudo sysctl -w net.core.rmem_max=16777216 # buffer de réception max
sudo sysctl -w net.core.wmem_max=16777216 # buffer d'émission max
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr # algorithme de congestion moderne (Google BBR)
sysctl net.ipv4.tcp_available_congestion_control # algorithmes disponibles sur ce noyau
# Latence vs bande passante : deux problèmes différents à ne pas confondre
ping -c20 exemple.com # mesure la latence (RTT)
iperf3 -c exemple.com # mesure le débit réel
# Un lien à forte latence + faible fenêtre TCP peut brider le débit même avec beaucoup de bande passante
# (Bandwidth-Delay Product : Débit_max = Fenêtre_TCP / RTT)Résumé
- La QoS classe, marque, met en forme et priorise le trafic pour protéger les flux sensibles (VoIP, SSH) sous contention.
tc(HTB + filtres) est l'outil natif Linux pour du traffic shaping fin ; DSCP permet de propager la priorité en amont.iperf3mesure le débit réel (à ne pas confondre avec la latence mesurée parping) ; BBR améliore le débit sur les liens à forte latence.
Exercices pratiques
Mission : sauver les appels VoIP d'une entreprise pendant les sauvegardes
Objectif : Diagnostiquer pourquoi de la bande passante disponible ne suffit pas à garantir la qualité vocale, et mettre en place une priorisation QoS adaptée.
Contexte
Une entreprise a un lien Internet de 100 Mbit/s. iperf3 confirme que ce débit est bien disponible, largement au-delà des quelques dizaines de kbit/s que consomme un appel VoIP. Pourtant, dès qu'une sauvegarde volumineuse démarre sur le même lien, les appels VoIP internes deviennent hachés et coupent. Le responsable réseau doit comprendre pourquoi la bande passante seule ne protège pas la voix, et configurer tc pour corriger le problème.