Résumé

  • La RFC 9693 impose une phase 1 qui crée un ensemble borné de connexions dans le NAT et fait enregistrer au Responder les quatre-tuples traduits ; la phase 2 mesure ensuite le trafic contre cet état connu.
  • Une phase 2 sans perte établit un résultat de boîte noire sous des paramètres déclarés. Elle ne révèle pas la table interne, ne reproduit pas Internet, ne caractérise pas automatiquement TCP et ne prouve ni marge de production ni continuité applicative.

Le retour doit appartenir à une connexion

La dissymétrie donne son sens à la méthode. Côté client, l’Initiator peut présenter un quatre-tuple inédit. Le DUT crée alors une entrée de suivi, traduit le paquet et le transmet. Côté serveur, le Responder ne peut pas inventer un tuple équivalent : si le paquet n’appartient pas à une connexion existante, la passerelle avec état le rejette.

Le test possède donc deux mémoires. La table de suivi du DUT reste opaque : le Tester n’en connaît ni le contenu, ni la taille, ni la politique. La table du Responder ne contient que les tuples traduits réellement reçus. Un tuple offert, un paquet transmis, une observation enregistrée et une validation dans le sens retour sont quatre reçus distincts.

Cette séparation interdit de confondre « un million de sessions proposées » avec « un million de connexions encore utilisables ». Le mot session ne remplace pas la chaîne de preuve.

L’aléatoire peut remplir la table avant le test

La RFC 4814 recommande des ports pseudo-aléatoires et uniformes afin d’éviter qu’un motif commode favorise la fonction de hachage du matériel. Dans un NAT avec état, chaque quatre-tuple inconnu peut aussi demander une nouvelle entrée.

Pour une seule paire d’adresses, les plages générales de la RFC 4814 produisent 3 170 829 312 combinaisons de ports. Plusieurs plages d’adresses multiplient encore cet espace. Une génération présentée comme réaliste peut donc devenir une expérience d’épuisement involontaire.

La RFC 9693 conserve la distribution pseudo-aléatoire mais borne les plages. La plage source peut compter quelques dizaines de milliers de ports ; la plage destination est plus petite, en cohérence avec les ports éphémères des clients et le nombre plus réduit de services populaires. Ces dimensions font partie du résultat. « Trafic aléatoire » n’est pas un profil reproductible.

La phase 1 fabrique la population mesurée

Pendant la phase 1, seul l’Initiator émet. Le DUT traduit et crée les connexions ; le Responder reçoit et mémorise les tuples traduits sans répondre. La phase remplit en parallèle la table cachée du DUT et la table observable du Tester.

Cette préparation précède obligatoirement le débit, la latence, la perte ou la variation de délai de la phase 2. Elle doit rester nettement sous le débit maximal d’établissement ; sinon la préparation devient elle-même le goulot. Le débit maximal d’établissement doit donc être mesuré auparavant.

Deux états extrêmes rendent les expériences lisibles. Pour mesurer la création, chaque trame utilise un tuple différent et le délai UDP dépasse la durée de la phase 1 : chaque trame sollicite une nouvelle entrée, aucune n’expire. Pour mesurer le transfert en régime établi, la phase 1 énumère tout l’ensemble prévu et le délai couvre les deux phases et leur intervalle : aucune entrée ne doit être créée ou supprimée pendant le chronométrage.

Ces conditions ne prétendent pas imiter tout Internet. Elles isolent le coût de création du coût de transfert dans un état déjà installé.

La réception aller ne valide pas le retour

Le Tester ne peut pas lire la table du DUT. Toutes les trames de phase 1 peuvent atteindre le Responder alors que certaines connexions ont disparu, n’ont pas été enregistrées durablement ou ont été remplacées.

Le Responder reprend donc chaque tuple mémorisé et envoie une trame retour à un débit réduit par un facteur de sécurité. Si les N trames atteignent l’Initiator, le test établit que ces N connexions existaient au moment de la validation et que les débits aller et retour convenaient.

Une perte retour n’identifie pas une cause unique. La table peut être pleine ; le débit R de création ou le débit r de validation peut être trop élevé ; le DUT peut refuser les nouvelles entrées, remplacer selon LRU ou supprimer plusieurs entrées lors d’un ramasse-miettes. L’observation borne l’enquête, elle ne lit pas l’intérieur de la machine.

La capacité se cherche avec un intervalle

La procédure part d’un nombre sûr C0 et d’un débit validé R0. Une recherche exponentielle double le nombre de connexions jusqu’à l’effondrement du DUT ou une forte baisse du débit d’établissement. Une recherche binaire réduit ensuite l’intervalle jusqu’à une erreur E déclarée.

La politique de remplacement change les survivants. Le refus des nouveaux états conserve les premiers ; LRU conserve les derniers ; une collecte par lots peut produire moins de validations que la capacité physique. Le nombre N′ reçu n’est donc pas toujours une lecture directe de la taille.

La suppression possède aussi sa métrique. On charge N connexions, on chronomètre une suppression hors bande propre à l’implémentation, puis on calcule N divisé par la durée. Effacer toute la table et retirer les entrées une à une peuvent avoir des coûts différents.

Ordre, temps et calcul appartiennent au dossier

La RFC recommande une écriture circulaire dans la table du Responder pour garder ses entrées fraîches. Une lecture pseudo-aléatoire suit la discipline de la RFC 4814 ; une lecture circulaire coûte moins cher. Les ordres croissant ou décroissant peuvent former des essais distincts. L’ordre peut exposer un effet de cache, de hachage ou de remplacement.

Les délais, la durée des phases, leur intervalle, le nombre de cœurs actifs, hashsize, nf_conntrack_max, le matériel, le système, le noyau et la version de l’implémentation doivent accompagner le score. Les mesures sont répétées ; la médiane, les 1er et 99e percentiles, le nombre de répétitions et l’erreur de recherche donnent au chiffre sa portée.

UDP trace une limite

UDP permet un débit de trames constant sans violer le contrôle de congestion de TCP ni ajouter une poignée de main. Mais une implémentation peut traiter UDP et TCP différemment. La RFC 9693 le dit explicitement et renvoie à la RFC 9411 pour les protocoles applicatifs comme HTTP.

Un essai sans perte prouve donc le comportement d’un DUT, d’une version, d’une configuration, d’une population de tuples, d’un ordre, d’un délai, d’une direction et d’une allocation CPU. Il ne prouve pas le contenu caché de la table, la représentativité d’Internet, TCP, la réserve opérationnelle ou l’achèvement d’une transaction utilisateur.

La spécification fournit une grammaire commune. Le code exécuté fournit l’observation. La décision reste défendable seulement si les reçus entre les deux sont conservés.

Sources