Résumé

  • RFC 2013 définissait quatre compteurs Counter32 en lecture seule pour l’entité UDP entière : datagrammes remis aux utilisateurs UDP, reçus sans application au port de destination, non remis pour une autre erreur et envoyés par l’entité.
  • udpTable indexait chaque écouteur uniquement par adresse IPv4 locale et port local. La ligne nommait un point d’écoute, ni le pair distant, ni le processus, ni une instance de socket, ni un datagramme particulier.
  • RFC 4113 a ensuite explicité les adresses et ports locaux et distants, l’instance et le processus. Cette attribution enrichie ne prouve toujours pas le traitement applicatif, la réception d’une réponse ou l’issue du service.

Un compteur possède un dénominateur, pas un récit

La brièveté du groupe UDP de RFC 2013 était fonctionnelle. udpInDatagrams totalisait les datagrammes remis aux utilisateurs UDP. udpNoPorts isolait ceux qui arrivaient sans application au port visé. udpInErrors rassemblait les autres échecs de remise. udpOutDatagrams comptait les datagrammes envoyés depuis l’entité.

Ces quatre définitions séparent de vrais états au niveau UDP. Elles ne sont pourtant indexées par aucun endpoint. Elles ne conservent ni adresse distante, ni processus, ni instant, ni identifiant de message, ni relation entre une entrée et une sortie. Deux compteurs qui bougent pendant la même période ne créent pas, par proximité, une requête et sa réponse.

RFC 1902 précisait en outre la nature de Counter32 : croissance jusqu’à 2^32−1, puis retour à zéro; aucune valeur initiale définie; une lecture isolée généralement sans contenu informatif; discontinuités possibles lors de la réinitialisation du système de gestion. Il faut donc un intervalle et une preuve de continuité pour interpréter un écart. L’écart obtenu demeure celui de toute l’entité.

Un annuaire local sans case « correspondant »

udpTable décrivait les endpoints où une application locale acceptait alors des datagrammes. L’index ne contenait que udpLocalAddress et udpLocalPort. L’adresse 0.0.0.0 représentait une écoute sur toutes les interfaces locales; le port se situait entre 0 et 65535.

Une ligne pouvait donc établir qu’au moment du relevé l’agent représentait ce couple local comme un écouteur. Rien dans la ligne ne disait de quel système distant venait un datagramme. Rien ne nommait le processus propriétaire. Deux sockets réutilisant le même couple ne pouvaient pas être distinguées. Aucun compteur par ligne ne reliait l’inventaire aux quatre totaux.

Le mot « accepte » doit lui aussi rester à son niveau. L’existence de l’écouteur ne prouve pas qu’un datagramme précis a été lu par le programme, validé, interprété ou suivi d’une action. Elle ne prouve ni émission de réponse, ni arrivée de cette réponse, ni résultat pour l’utilisateur. Le registre indique le guichet; il ne tient pas le procès-verbal de l’entretien.

La remise à l’utilisateur UDP n’était pas l’achèvement applicatif

udpInDatagrams va plus loin qu’une présence sur une interface : son texte parle de remise aux utilisateurs UDP. C’est un résultat précis du moteur de transport. Il serait faux de le réduire à « un paquet a été vu ». Il serait tout aussi faux de le hausser au rang de transaction terminée.

Le compteur ne dit pas que l’application a vidé le tampon, compris le format, autorisé l’opération ou modifié son état. udpNoPorts prouve l’absence d’application au port pour les datagrammes comptés, mais ne nomme pas l’émetteur. udpInErrors agrège les autres causes de non-remise sans les attribuer. udpOutDatagrams s’arrête à l’envoi depuis l’entité et ne certifie aucune réception distante.

La frontière probante est donc nette : dispositions UDP et coordonnées locales d’un côté; acteurs, datagrammes, causalité et effets de l’autre.

Le successeur a fait de l’identité de l’endpoint un objet explicite

RFC 4113 a remplacé RFC 2013 en 2005. Il a conservé les quatre compteurs de base, ajouté des compteurs de grande capacité et déprécié udpTable pour deux raisons : sa dépendance à IPv4 et son incapacité à représenter les endpoints UDP « connectés ». La première limite relève de l’histoire de la visibilité des familles d’adresses. La seconde révèle ce qui manquait au registre local.

udpEndpointTable pouvait représenter un écouteur ouvert à tout système distant ou un endpoint lié à une adresse et un port distants. Son index réunissait types, valeurs et ports locaux et distants, puis udpEndpointInstance. Cette instance distinguait plusieurs processus partageant le même tuple, notamment avec SO_REUSEADDR ou SO_REUSEPORT. udpEndpointProcess ajoutait l’identifiant du processus du système, ou zéro, avec une correspondance attendue vers les MIB de ressources hôte ou d’applications.

Le progrès est une amélioration de l’identité de gestion, pas la création d’une session fiable. On peut mieux répondre à « quel endpoint et quel processus ? ». On ne peut toujours pas conclure qu’un datagramme déterminé a été traité, qu’une réponse est arrivée ou que le service a réussi. Un PID peut manquer, être réutilisé et n’avoir de sens que localement.

Cette visibilité plus riche augmente aussi la sensibilité. RFC 4113 avertit que les indices peuvent révéler les ports ouverts sans balayage. La table est en lecture, non un actionneur; l’accès à l’observation reste néanmoins un pouvoir à protéger.

Décrire strictement ce que la source permet

RFC 2013 n’avait pas vocation à fournir un journal applicatif. Le contresens apparaîtrait plutôt dans une analyse qui transformerait un total d’entité en incident d’un service, un port local en interlocuteur, « envoyé » en « reçu », ou une remise UDP en résultat commercial.

Une affirmation solide conserve sa portée : entre deux relevés compatibles, tel compteur d’entité a augmenté; à tel instant, l’agent exposait tel écouteur local. L’attribution à un flux exige une capture ou un événement corrélé. Le traitement exige une preuve applicative. La livraison distante exige une observation distante. Le succès exige une définition et une mesure au niveau du service.

Un port est une coordonnée. Un compteur est un dénominateur. Une conversation est une suite d’événements attribués. Le modèle de 2005 a rendu davantage de cette suite visible; il n’a pas inventé le dernier reçu.

Sources

Limites de preuve

Les sources établissent les textes, la filiation documentaire, les sémantiques de compteur et le modèle successeur. Elles n’établissent ni implémentation d’un fournisseur, ni taux de déploiement, ni défaut, incident, SLA, trafic mesuré ou résultat applicatif réel.