Résumé

  • RFC 2398 décrivait douze outils de test TCP selon leur objet, leur fonctionnement, leur automatisation, leur disponibilité et leur environnement requis, au lieu de réduire le « test » à une opération unique.
  • Perturbation active, mesure d’une pile réelle, capture, analyse différée et visualisation livraient des preuves différentes ; ni une courbe ni un débit ne suffisaient à démontrer conformité, sécurité ou réussite applicative.

Le laboratoire TCP de 1998 n’avait pas de pupitre unique. Dbs coordonnait plusieurs transferts et produisait des journaux ASCII. Dummynet insérait files d’attente, bande passante et délai dans une pile réellement exécutée. NIST Net transformait Linux en routeur « sélectivement mauvais ». D’autres outils injectaient des fautes, fabriquaient des paquets, disséquaient des captures ou plaçaient les numéros de séquence sur un axe temporel. RFC 2398 les réunit sans prétendre qu’ils accomplissaient la même chose.

Le formulaire du catalogue constituait déjà une discipline de preuve. Chaque fiche devait donner le nom, la catégorie, le fonctionnement, la part automatisée, la disponibilité, l’environnement requis et les références. Dès lors, le nom d’un outil ne pouvait plus tenir lieu de méthode. Une courbe restait ambiguë si l’on ignorait la charge produite, la pile examinée, le point de capture ou les hypothèses de l’analyseur.

Trois catégories organisaient l’ensemble : correction fonctionnelle, performance et résistance à la charge. Elles se croisaient sans se confondre. Une pile pouvait transférer vite tout en dérogeant à une exigence. Elle pouvait réussir un échange simple puis céder sous pression. Un échec en stress signalait une fragilité, mais ne disait pas encore si elle appartenait au code, au dispositif de mesure ou au banc d’essai.

Dummynet, NIST Net et Orchestra intervenaient en amont. Le premier simulait files finies, débit et délai entre couches d’une pile ; le deuxième retardait, perdait, dupliquait ou limitait des paquets selon des lois fixes ou distribuées ; le troisième pouvait supprimer, retarder, réordonner, dupliquer, modifier ou ajouter des messages. Orchestra laissait néanmoins à l’utilisateur la tâche de lire la trace et de qualifier le comportement. Produire une anomalie et l’interpréter restaient deux actes distincts.

Tcpanaly se situait plus loin dans la chaîne. Il confrontait une trace tcpdump à une connaissance encodée de nombreuses implémentations, cherchait la raison de chaque émission et distinguait, si possible, un écart de comportement d’une erreur de mesure. Le RFC reconnaissait qu’il se classait mal : il dressait le profil d’une conduite plutôt qu’il n’exécutait un test fixe. Tcptrace calculait retransmissions, aller-retour, fenêtres et débit ; Tracelook et Xplot rendaient visibles des variables de capture. Ces outils aidaient à voir l’événement, ils ne l’avaient pas créé.

Netperf, TReno et Ttcp montraient une autre frontière. Un chiffre de débit dépendait du générateur et de la pile dont il intégrait le comportement. TReno temporisait volontairement des paquets UDP ou ICMP comme le ferait un TCP conforme avec contrôle de congestion et SACK, afin de mesurer le chemin indépendamment du TCP des hôtes d’extrémité. Il répondait ainsi à une question différente, et non à toutes les questions mieux que les autres.

Les auteurs limitaient soigneusement la portée du document. Les outils avaient été signalés par le groupe de travail des implémenteurs TCP ; la liste n’était pas exhaustive. Leur disponibilité avait été vérifiée au moment de la publication. Ce constat historique ne garantit ni maintenance actuelle, ni compatibilité présente, ni aptitude universelle.

La section sécurité traçait une limite plus nette encore. Certains outils pouvaient émettre des paquets malveillants ou provoquer un déni de service. Certains exigeaient un noyau étranger ou les privilèges root. Une capture risquait de révéler le courrier et les fichiers d’autrui. Pourtant, aucun des outils recensés n’évaluait la sécurité « de quelque manière que ce soit ». La capacité de perturber un réseau ne conférait pas celle d’en juger la sûreté.

Le graphique n’était donc pas le test. Il occupait une place tardive dans une chaîne de conservation : outil choisi, environnement, condition imposée ou observée, version de l’implémentation, trafic, capture, calcul, représentation puis jugement humain. Si un maillon disparaît, une ligne propre devient une anecdote séduisante. Si tous restent attachés, le résultat peut dire précisément ce qui s’est passé, sans revendiquer davantage que ce que l’expérience pouvait connaître.

Sources