Votre téléchargement est rapide, alors pourquoi chaque clic semble-t-il lent ?

Télécharger rapidement un gros fichier puis trouver chaque clic lent n’est pas une contradiction. La capacité indique ce qui peut circuler par seconde ; le temps aller-retour indique combien de temps dure un échange avant qu’il ne se passe quelque chose d’utile. Améliorer le premier ne change rien au second, et c’est le second qu’une personne remarque en écrivant, en cliquant ou en parlant. Mesurez la plainte, pas la connexion.

Fichier rapide, clic lent : deux nombres différents

Un transfert massif maintient les données en mouvement en permanence, il peut donc annoncer un débit sain même lorsque chaque requête individuelle attend. De nombreux benchmarks ouvrent aussi plusieurs connexions à la fois, ce qui augmente le chiffre global alors qu’une seule requête reste lente. Les deux résultats sont compatibles, et citer le plus élevé à un utilisateur qui se plaint de latence, c’est ainsi que se perd la confiance.

Le chargement d’une page est une chaîne de petits échanges : résolution de noms, établissement de la connexion, une requête, une réponse, puis des requêtes dépendantes. Chaque étape paie à nouveau l’aller-retour, si bien qu’un chemin à fort délai paraît lent même lorsqu’il dispose de beaucoup de capacité.

Le tunnel ajoute son propre trajet et son traitement, et la route compte plus que l’étiquette sur une carte. Deux sorties dans le même pays peuvent avoir des chemins très différents vers une même destination. Une différence de vingt millisecondes suffit à changer la sensation d’une page, même si elle ne bouge presque pas un chiffre de débit. C’est pourquoi le choix de la sortie doit suivre un échantillon de latence plutôt qu’une icône de drapeau.

Mesurez la plainte, pas la connexion

Choisissez la mesure qui correspond à la phrase prononcée par l’utilisateur. Un téléchargement lent a besoin d’un débit soutenu dans la bonne direction ; un appel qui saccade a besoin des statistiques propres à cette application ; une page qui démarre lentement a besoin des temps de résolution et d’établissement.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

La première commande donne un échantillon d’aller-retour vers un hôte qui répond de façon prévisible, la deuxième rapporte le temps jusqu’au premier octet et le débit soutenu d’une connexion, et la troisième mesure le débit global avec quatre flux parallèles. Exécutez-les vers la même destination à la même heure de la journée, car comparer un échantillon du matin avec un du soir produit une histoire plutôt qu’une mesure.

Gardez la destination fixe lorsque vous comparez des sorties. Changer à la fois le serveur et le tunnel transforme une variable en deux, et le résultat ne peut pas vous dire laquelle comptait. Exécutez chaque sortie au moins trois fois, car un échantillon unique tombe souvent pendant un changement de routage ou une minute bruyante. La médiane est plus utile que le meilleur cas.

Traitez ICMP comme un indice et non comme la réponse. Un hôte qui répond peut traiter les requêtes d’écho sur un chemin différent de celui qu’utilise votre application, et une réponse perdue ne prouve pas que toutes les applications perdent des paquets.

La latence sous charge est un problème de file d’attente

Le schéma qui trouble le plus les gens est une connexion qui semble correcte au repos et inutilisable pendant une sauvegarde. C’est de la file d’attente, pas de la capacité. Un lien montant saturé construit un tampon devant chaque autre paquet, si bien qu’une frappe attend derrière un morceau de l’envoi.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

La première commande échantillonne la latence en arrière-plan tandis que la seconde sature la direction inverse. Si les temps de ping bondissent pendant le transfert puis se rétablissent ensuite, vous avez reproduit le bufferbloat plutôt que découvert un défaut de routage. Le correctif est généralement un réglage de gestion de file d’attente, un débit d’arrière-plan plus faible ou le déplacement du transfert massif hors du chemin interactif.

Réduire le trafic d’arrière-plan facultatif aide souvent plus que changer de pays de sortie. C’est aussi moins cher, réversible et testable en une minute. Planifiez les gros envois en dehors des heures de travail si la file d’attente ne peut pas être gérée, et limitez leur débit s’ils doivent tourner pendant la journée. Un réglage de gestion de file d’attente est le meilleur correctif lorsque le routeur en prend en charge un.

Changez une chose et comparez comparable avec comparable

Pour un délai élevé au repos, comparez les sorties en gardant la destination fixe, puis comparez les routes pour le meilleur candidat. Pour un débit faible et régulier, regardez plutôt la capacité, la charge du serveur et le traitement du client, car ce sont des limites différentes.

Notez ce que vous avez mesuré, contre quelle destination, à quelle heure et avec quels réglages. Une comparaison sans ces quatre faits ne peut pas être répétée, et la personne suivante partira de zéro.

Ensuite, adaptez l’outil à l’affirmation du ticket. "Internet lent" n’est pas une mesure ; "le premier octet a pris 900 ms vers cet hôte alors que le débit était correct" en est une, et elle pointe directement le délai plutôt que la capacité.