Une route a une forme, et le terminal l'affiche comme une liste

OpenTrace est une interface graphique multiplateforme posée sur un moteur de traçage de route en ligne de commande, disponible sous Windows, macOS et Linux, et son apport est d'abord de présentation avant d'être technique. Un traçage produit une colonne d'adresses avec trois valeurs de latence chacune, et cette colonne contient un chemin : une suite de réseaux, souvent au-delà des frontières, parfois sortant d'une ville pour y revenir. Lire la forme dans cette colonne est un travail que le lecteur fait de tête, et c'est exactement le travail qu'un dessin peut faire à sa place. Montrer les sauts sur une carte n'est pas un ornement : c'est la raison pour laquelle quelqu'un qui sait déjà lancer un traçage ouvre une fenêtre pour en regarder un.

Le programme ne remplace pas le moteur en dessous et il est honnête là-dessus : la mesure vient de l'outil en ligne de commande, la fenêtre est une interface qui le pilote et dessine ce qui revient. Cette séparation vaut la peine d'être énoncée, parce qu'elle dit où regarder quand un chiffre paraît faux, et parce qu'une interface qui prétendrait être le tout revendiquerait une précision qu'elle ne possède pas.

Latence et perte, et lesquels de ces chiffres croire

Chaque saut rapporte un délai et un pourcentage de perte, et ce qu'un lecteur peut apporter de plus utile à ces chiffres, c'est de la méfiance envers le milieu du chemin. Les routeurs sont occupés à commuter des paquets, et répondre à la sonde qu'envoie un traçage est une tâche de faible priorité : beaucoup limitent ces réponses ou les jettent purement et simplement. Le résultat est un saut qui affiche une forte perte alors que les sauts suivants sont parfaitement sains — ce qui se lit comme un problème au milieu du réseau et qui est en réalité un routeur qui refuse d'être mesuré.

La règle qui en découle est celle que les professionnels appliquent sans y penser : faire confiance au dernier saut, traiter le milieu du chemin comme indicatif, et ne jamais diagnostiquer une panne à partir d'un seul saut intermédiaire. Un traçage où la perte apparaît au septième saut et continue jusqu'au douzième est une panne. Un traçage où la perte n'apparaît qu'au septième saut et disparaît ensuite est un routeur bridé et une belle histoire sur son emploi du temps.

Pourquoi un mode continu est plus utile qu'une photo instantanée

Le programme prend en charge un mode qui répète la mesure au lieu de la lancer une fois, et c'est la différence entre une photographie et un enregistrement. Les problèmes de réseau intermittents sont la règle plutôt que l'exception — une liaison qui se dégrade sous la charge, une route qui change puis revient, un canal sans fil qui va bien jusqu'à ce qu'un four à micro-ondes se mette en marche — et un traçage unique pris à un moment quelconque montrera généralement un chemin sain et ne prouvera rien. Regarder une minute, ou dix, est ce qui transforme une plainte en description.

C'est aussi là que la forme visuelle gagne sa place une seconde fois. Une mesure répétée produit un tableau de chiffres dans le temps, difficile à lire et facile à survoler ; les mêmes données tracées en une ligne par saut montrent le moment où quelque chose a changé, et ce moment est en général toute la question.

Où les adresses sont résolues, et pourquoi c'est un réglage

Transformer des adresses en noms demande un résolveur, et le choix du résolveur n'est pas neutre : il change ce qui est demandé, à qui c'est demandé, et parfois la réponse qui revient. Le programme propose le résolveur ordinaire du système et un résolveur chiffré en HTTPS, et le second existe pour deux raisons qu'il vaut la peine de séparer. L'une est la confidentialité : une requête DNS en clair dit au réseau quels noms on consulte, et un traçage d'une douzaine de sauts révèle beaucoup sur l'endroit où l'on va. L'autre est la régularité : un résolveur chiffré joint directement a moins de chances d'être intercepté ou réécrit par ce qui se trouve sur le réseau local, ce qui compte quand ce réseau est précisément l'objet du diagnostic.

La base de localisation, et les limites du fait de savoir où est une adresse

Une base d'adresses dans un format binaire standard est fournie, si bien qu'un saut peut être étiqueté avec un pays, une ville et un opérateur sans interroger un service en ligne. Cette dernière partie est la plus importante : la réponse arrive sans révéler à personne quelles adresses vous intéressent. La limite tient aux données et non au programme. La localisation d'une adresse est une déduction à partir de registres d'enregistrement, souvent juste au niveau du pays, à peu près juste au niveau de la ville, et parfois franchement fausse quand un opérateur fait passer le trafic par un site situé ailleurs que ce que disent les registres. Une carte est un bon moyen de voir la forme d'une route et un mauvais moyen de conclure qu'un serveur est dans un bâtiment précis.

Masquer des adresses dit à quoi sert l'outil

Le programme peut masquer une partie d'une adresse, et l'existence de cette option dit quelque chose de la façon dont le diagnostic réseau se passe réellement : dans des captures d'écran, collées dans un ticket, montrées à un collègue, publiées sur un forum d'entraide. Une adresse dans un traçage n'est pas un secret comme un mot de passe, mais c'est un morceau d'infrastructure qui identifie un réseau et parfois un client, et une conversation de support n'a pas besoin de la voir en entier pour être utile. Une fonction de masquage intégrée est un petit aveu que la sortie est faite pour être partagée.

Des interfaces natives, et ce que cela coûte

Utiliser la boîte à outils d'interface de chaque plateforme plutôt qu'une couche commune est un choix au coût visible : le programme se comporte comme le système sur lequel il tourne, et le coût est que le même écran est implémenté plusieurs fois. Pour un outil de diagnostic, c'est un endroit raisonnable pour dépenser cet effort, parce que la fenêtre voisine un terminal, un navigateur et une messagerie, et qu'une fenêtre qui semble étrangère dans cette compagnie est une fenêtre qu'on ferme. Cela veut aussi dire que l'outil peut s'appuyer sur ce que la plateforme fait bien — le rendu de carte, par exemple — au lieu de l'imiter.

Pour qui c'est, et ce qu'il ne peut pas dire

Pour un ingénieur d'exploitation à qui l'on demande pourquoi un site est lent depuis un bureau et normal depuis un autre, et qui doit montrer la réponse plutôt que la décrire. Pour quelqu'un qui joue ou téléphone et veut savoir si le problème est sur le dernier kilomètre, au milieu du réseau ou sur le serveur. Pour une personne sans culture réseau qui a une plainte et aimerait en avoir une image.

Ce qu'il ne peut pas faire mérite d'être dit aussi. Il mesure le chemin d'une machine vers une destination à un instant ; il ne voit pas le chemin depuis une autre machine, et un traçage n'est pas un test de débit — un traçage sain ne dit rien du volume que la liaison peut absorber. Et il diagnostique le réseau, pas l'application : un serveur qui répond lentement et la base de données derrière lui sont identiques d'ici, ce qui explique que l'image soit le début d'un diagnostic et non sa fin.