Gigue et perte de paquets lors d’un appel VPN : que comparer

Une parole robotique et des syllabes avalées sonnent différemment parce que ce sont deux défauts différents. La gigue modifie le moment d’arrivée des paquets ; la perte signifie qu’ils n’arrivent pas du tout. L’un comme l’autre peut survenir alors qu’un test de débit annonce un téléchargement sain, car le débit et la livraison à temps mesurent des choses différentes. Faites correspondre les preuves au son avant de changer le moindre réglage.

Pourquoi les paquets en retard et les paquets manquants sonnent différemment

Les médias quittent l’émetteur à un rythme régulier, et les réseaux réels les livrent avec des espacements irréguliers. Les applications tamponnent un peu pour lisser cela, échangeant du délai contre de la continuité : augmentez le tampon et la conversation paraît lente, réduisez-le et des trous apparaissent. Un paquet qui arrive après son échéance de lecture est bel et bien perdu, même s’il n’a jamais été jeté. C’est pourquoi deux connexions de même bande passante peuvent produire des appels très différents.

Le sens compte aussi. Les médias entrants et sortants peuvent emprunter des chemins différents, surtout quand un côté est sur un réseau mobile.

Les chiffres à lire pendant la mauvaise fenêtre

Utilisez les statistiques de l’application elle-même là où elle en propose, et lisez-les pendant que l’appel est mauvais, pas après sa fin. Un relais média est souvent un autre hôte que le site du service, si bien qu’un ping vers la page d’accueil mesure un chemin que l’appel n’utilise pas. Regardez le pourcentage de perte, le temps aller-retour et la gigue séparément, et notez si le client émet ou subit le problème. Une reconnexion VPN pendant l’appel est un troisième événement à consigner, pas à fusionner avec les autres.

Les captures d’écran du panneau de statistiques valent mieux qu’un souvenir de l’appel, car les chiffres se comparent plus tard. Vingt secondes de pourcentage de perte vous disent si le chemin perd des paquets maintenant, mais pas si la perte est en rafales ni quand elle a commencé.

Pour cela, répétez la mesure dans une seconde condition au lieu de lire une fenêtre comme un verdict. Deux fenêtres prises dans des conditions différentes disent plus qu’une longue fenêtre prise sans aucune condition.

Ce qu’un tampon de gigue fait à l’échéance

Un tampon de gigue retient brièvement les paquets entrants pour que les arrivées irrégulières — la variation de délai que RFC 3393 définit comme une métrique — puissent être lues sur une horloge régulière. La taille du tampon fixe l’échéance de lecture : tout paquet plus tardif que cette échéance est écarté, quel que soit son contenu. Les codecs diffèrent par ce qu’ils savent masquer, et un codec qui interpole une trame manquante peut cacher une perte, mais pas une série. C’est pourquoi le même pourcentage de perte donne une qualité d’appel différente selon les codecs.

Régler le tampon est un compromis, pas une correction. Un tampon plus grand achète de la continuité au prix du délai de conversation, et il ne peut pas récupérer les paquets qui arrivent après l’échéance.

Comparez la radio et la charge avant la sortie

Gardez la sortie et l’application fixes tout en changeant une condition locale à la fois. Une icône de signal forte ne dit rien de la congestion du canal. Si le problème suit une pièce ou un point d’accès, la radio est l’investigation suivante.

ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9

ping donne un compte de pertes et une dispersion que vous pouvez comparer entre conditions, et mtr montre la perte par saut le long du chemin. Les sauts intermédiaires qui échouent alors que les suivants répondent donnent généralement une priorité plus basse à ICMP au lieu de jeter le trafic utilisateur. Répétez les deux pendant qu’un envoi contrôlé tourne, car une liaison bonne au repos et inutilisable sous charge indique une file d’attente, pas le VPN. Si une seule condition reproduit le problème, l’autre condition vient d’être écartée.

Ne réparez que ce que la comparaison soutient

Chaque comparaison soutient une réparation, et en appliquer plusieurs à la fois détruit les preuves. Un chemin local faible demande un meilleur canal ou de l’Ethernet, un trafic concurrent demande une ordonnance ou une discipline de file, et une sortie mauvaise demande de comparer une autre sortie dans les mêmes conditions. Quand vous changez le transport du VPN, gardez le profil valide et changez une variable à la fois. Retestez la même conversation avec une activité de fond normale au lieu de juger le succès à la hausse d’un score de test de débit.

Notez la direction, la perte, la gigue, le temps aller-retour et la condition dans laquelle chacun a été mesuré. Ce relevé transforme une plainte vague sur la qualité d’appel en constat sur lequel quelqu’un peut agir. Gardez-le avec le ticket pour que la comparaison suivante parte de la même base.