Pourquoi un VPN semble lent pendant les envois : le délai de file

Une sauvegarde commence à s’envoyer, le compteur de transfert semble sain, et l’appel vidéo devient une bouillie. Le lien ne manque pas de bande passante au sens où ce chiffre le suggère ; les paquets attendent dans une file quelque part et les paquets interactifs restent derrière les données en vrac. C’est le délai de file, communément appelé bufferbloat. Un VPN peut ajouter sa propre file, mais il crée rarement le problème à lui seul.

Bande passante et délai sont des mesures différentes

Le débit répond à la question du volume de données déplacé par seconde, tandis que le délai répond au temps qu’un paquet met à parcourir le chemin. Un lien saturé peut retenir un gros arriéré et afficher quand même un bon débit, car la file se vide à la vitesse de la ligne dès que la rafale se termine. Le trafic interactif souffre en premier, car un appel a besoin d’un paquet toutes quelques millisecondes, pas d’un gros fichier au final. Mesurer seulement le résultat d’un test de débit masque donc le symptôme qui vous a fait regarder.

Remarquez aussi le sens sous charge. Un tampon d’envoi plein peut retarder tout le reste alors que la capacité de téléchargement reste inactive.

Mesurez l’aller-retour sous charge

Prenez une référence sur un lien calme, puis répétez la même mesure pendant qu’un transfert contrôlé s’exécute. Comparez les deux passes plutôt que les chiffres absolus.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

La première commande échantillonne le temps d’aller-retour, et la seconde crée un envoi soutenu sans avoir besoin d’un service de test de débit. Une référence qui reste plate, suivie d’une passe en charge qui grimpe de centaines de millisecondes, voilà la signature à rechercher. Certains réseaux déclassent l’ICMP, alors traitez ping comme un indice et confirmez avec l’affichage de latence de l’application elle-même. Gardez le test court sur les liens à quota, car un contraste reproductible compte plus qu’une longue saturation.

Déplacez la file là où se trouve le goulot

La gestion de file n’aide que sur l’appareil qui retient réellement l’arriéré. Inspectez ce que fait l’interface avant d’ajouter des règles.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

La commande show indique la discipline actuelle ainsi que les compteurs d’arriéré et de rejet, ce qui vous dit si cette interface est le goulot ou si elle ne fait que transporter le trafic. Remplacer la discipline racine par un algorithme de file équitable donne aux flux courts leur propre tour au lieu d’une seule FIFO partagée avec les données en vrac. Appliquez-la sur l’interface WAN du routeur quand le routeur est le goulot, pas sur l’appareil du tunnel par habitude. Conservez la configuration précédente et retestez à la fois la réactivité en charge et le débit de transfert, car un débit en vrac un peu plus faible est un bon échange pour des appels utilisables.

Ce que le tunnel change et ce qu’il cache

Un VPN ajoute du chiffrement et un saut de plus, et il cache aussi les flux individuels aux équipements hors du tunnel. Cela compte quand un appareil en amont propose une priorisation par application, car il voit des paquets chiffrés plutôt que les conversations d’origine. Un routeur qui termine le tunnel lui-même a une vue et une charge de travail différentes et peut classifier à l’intérieur. Aucune des deux dispositions n’élimine la file sur le lien d’accès, qui est généralement là où le délai s’accumule.

Si le délai ne suit pas la charge, arrêtez de régler les files et regardez ailleurs : conditions du Wi-Fi, problèmes de taille de paquet ou une mauvaise sortie. Des réglages de file appliqués sans mesure ne font que déplacer le mystère.