LE REMPLISSAGE ETHERNET, EN BREF
Pourquoi un court message peut-il apparaître comme une trame plus longue ?
Ethernet peut ajouter un remplissage avant le FCS pour respecter le format minimal de la trame MAC. Le remplissage se situe en dehors d'un paquet IPv4 et ne doit pas devenir des données applicatives. Un logiciel de capture peut observer un traitement avant le remplissage ou recevoir un enregistrement sans le FCS, de sorte que la longueur affichée seule ne prouve pas une transmission sous-dimensionnée. Vérifiez le point d'observation et la convention de longueur.
Construire la trame externe
Le remplissage respecte le format externe ; il n'ajoute aucune signification applicative.
Localiser l'observateur
Le logiciel peut voir une étape différente de celle de la liaison physique.
Respecter la frontière interne
Pour IPv4, utilisez la longueur totale IP plutôt que de traiter le remplissage comme des données.
Vérifier le décompte
Précisez quels en-têtes, étiquettes et octets de FCS la longueur inclut.
Vérifier la capture
Enregistrez la direction, les déchargements, la longueur conservée et les paramètres de FCS.
Vérifier l'analyseur
Confirmez que la longueur de la couche supérieure définit le contenu applicatif valide.
Liste de sélection et de vérification — développer
| Vérification | Ce qu'il faut confirmer | Comment vérifier |
|---|---|---|
| Convention de trame | En-têtes, étiquettes et FCS | Documentez le début et la fin exacts du décompte. |
| Point d'observation | Avant la carte réseau, le câble ou le récepteur | Conservez les paramètres d'interface et de collecte. |
| Exhaustivité de la capture | Longueur d'origine ou longueur conservée | Vérifiez la troncature et les limites de collecte. |
| Frontière de protocole | Longueur IP valide ou autre longueur de protocole | Inspectez la longueur spécifiée et le comportement de l'analyseur. |
| Preuves de défaut | Compteurs, direction et heure | Corrélez le trafic connu aux deux extrémités. |
Exemples conceptuels, non à l'échelle, ne constituant ni des mesures ni des affirmations sur la mise en œuvre d'un produit particulier.
Un automate envoie un court message d'état, mais le contenu transmis sur Ethernet est plus long. Une capture affiche 60 octets, tandis que la documentation décrit une trame minimale de 64 octets. Ne concluez pas immédiatement qu'un commutateur a supprimé quatre octets. Le message applicatif, l'encapsulation Ethernet et la capture logicielle sont des couches d'observation différentes. Placer le remplissage au bon endroit explique l'apparente contradiction.
Distinguer le message, le paquet IP et la trame Ethernet
Une application se soucie d'un état, d'une commande ou d'une mesure, mais la transmission nécessite des informations que les équipements réseau peuvent reconnaître. Considérez le message comme une note, le paquet IP comme son enveloppe et la trame Ethernet comme l'emballage extérieur pour cette liaison. L'analogie explique les couches, pas trois boîtes physiques : le câble transporte une séquence continue de bits.
Dans l'exemple Ethernet non étiqueté ordinaire utilisé ici, la trame MAC va de l'adresse de destination jusqu'à la séquence de contrôle de trame, ou FCS. Une adresse MAC identifie un émetteur ou un destinataire sur la liaison ; le FCS aide un récepteur à détecter les erreurs de transmission. Le préambule précède la trame, et l'intervalle intertrame est un temps d'inactivité entre les transmissions. Ni l'un ni l'autre ne fait partie de ce décompte de 64 octets.
Le minimum s'applique à la trame MAC externe, pas à la longueur de chaque instruction d'automate. Lors de la lecture de documentation ou de captures, établissez d'abord où commence et où finit le décompte. Mélanger données applicatives, en-têtes et FCS peut faire paraître une encapsulation ordinaire comme un contenu applicatif supplémentaire.
Ajouter le remplissage avant de former la séquence de contrôle de trame
Si le contenu de couche supérieure fourni est trop court, le traitement d'émission Ethernet ajoute un remplissage après ce contenu et avant le FCS. C'est comme un calage protecteur : il occupe de l'espace sans ajouter de mots à la note. Qu'un logiciel, un pilote ou un matériel effectue une opération donnée dépend de l'interface réseau ou de la mise en œuvre embarquée.
Prenons un exemple délibérément borné : un en-tête Ethernet non étiqueté de 14 octets transporte un paquet IPv4 de 28 octets. Ce paquet IP peut se composer d'un en-tête IPv4 ordinaire et d'un en-tête UDP, sans charge utile applicative UDP. L'ajout de 18 octets de remplissage et d'un FCS de quatre octets produit une trame MAC de 64 octets. Cela illustre la structure ; ce n'est pas une mesure d'un appareil FCTEL.
Le remplissage est inclus dans le contenu protégé par la somme de contrôle Ethernet. Il ne peut pas être modifié arbitrairement une fois que le FCS est formé. Le récepteur vérifie la trame reçue, pas seulement le message applicatif. Aucun calcul de CRC n'est nécessaire pour comprendre la séquence : former le contenu de trame requis, puis générer sa valeur de contrôle correspondante.
Le remplissage ne doit pas devenir des données applicatives supplémentaires
Pour IPv4, le champ de longueur totale dans l'en-tête IP définit la longueur du paquet IP, y compris son en-tête et ses données mais hors remplissage Ethernet externe. Le récepteur transmet la portion IP vers le haut pour une interprétation ultérieure. La RFC 894 sépare explicitement le remplissage du paquet IP et spécifie un remplissage d'octets nuls lorsqu'il est nécessaire pour l'encapsulation qu'elle décrit.
Un analyseur de couche supérieure ne doit pas traiter tous les octets Ethernet capturés restants comme du contenu applicatif. Il doit valider la longueur et les limites de son protocole plutôt que d'ajouter le remplissage externe à une commande. Il ne doit pas non plus simplement supprimer tous les zéros de fin : un zéro peut être une donnée valide. C'est le protocole, et non l'apparence visuelle d'un octet, qui détermine la limite.
Les autres protocoles de couche deux ont besoin de leurs propres règles d'encapsulation ; la longueur totale d'IPv4 ne peut pas être appliquée mécaniquement à tous les protocoles. Le remplissage ne doit pas transporter d'instructions de contrôle privées ni de mémoire non initialisée. L'habitude pratique consiste à vérifier séparément la limite de la trame externe et celle du message interne.
Pourquoi un logiciel peut afficher 60 octets ou même moins
Un logiciel de capture ne reçoit pas nécessairement la représentation complète sur le fil. De nombreuses interfaces vérifient le FCS entrant sans transmettre ces quatre octets au système d'exploitation. Le logiciel peut donc enregistrer 60 octets correspondant à une trame MAC complète de 64 octets sur le fil. La documentation de Wireshark souligne cette distinction : une longueur affichée de 60 seule ne prouve pas une transmission sous-dimensionnée.
Une capture côté émission peut observer un autre point, avant que le matériel n'ajoute le remplissage et le FCS. Son enregistrement peut être plus court que 60 octets même si le matériel produit ensuite une trame transmise valide. Un écran d'émetteur, un écran de récepteur et une observation du lien physique sont des points de vue différents. Comparer deux longueurs affichées ne suffit pas à prouver que l'équipement entre eux a supprimé du contenu.
Distinguez également la longueur d'origine de la longueur capturée. Un collecteur peut ne conserver que le début de chaque trame, de sorte que chaque octet d'origine n'est pas nécessairement sauvegardé. Vérifiez les paramètres de capture, la livraison du FCS, la direction et le comportement de déchargement, puis comparez les preuves des pairs. Prouver la représentation physique sur le fil exige une méthode de test appropriée avec des conditions d'acquisition énoncées.
Le traitement du VLAN n'implique pas un nombre de remplissage fixe
Les octets de remplissage du 18 appartiennent uniquement à l'exemple précédent. Différentes longueurs de contenu, l'étiquetage et le traitement d'encapsulation modifient la quantité nécessaire. Une étiquette VLAN occupe une partie de la région d'en-tête ; ne la comptez pas deux fois lorsqu'elle est déjà incluse. La taille minimale de trame et l'unité de transmission maximale, ou MTU, sont également des concepts différents.
Un commutateur reçoit des trames, identifie les destinations de transfert et forme la sortie appropriée sur le lien suivant. L'équipement qui ajoute ou retire des étiquettes doit maintenir les exigences de sortie. Le document de dépannage Cisco référencé illustre un cas de plateforme spécifique où le retrait d'une étiquette nécessite un nouveau remplissage. Il aide à expliquer une limite de traitement, et non une implémentation interne universelle pour chaque commutateur.
Le remplissage normal d'un court message complet n'est pas un défaut. Une trame réellement sous-dimensionnée, une transmission anormale causée par un lien endommagé et un enregistrement de capture raccourci lors de la collecte nécessitent des investigations différentes. Les noms et conditions des compteurs de port varient selon l'équipement. Corréler les compteurs avec les heures et directions de capture est plus utile que de remplacer un commutateur simplement parce qu'un enregistrement semble court.
Appliquer la distinction à une connexion de commutateur industriel
La page publiée du commutateur Fast Ethernet cinq ports mini DIN-rail FCTEL liste cinq ports électriques Ethernet et une adaptation 10/100M. Cela fournit une base produit réelle pour un scénario de connexion PLC et IHM. Cela n'établit pas de capacités de capture, de miroir de port, de contrôle spécial du remplissage ni de seuils d'erreur particuliers. Vérifiez la configuration choisie par rapport à sa propre documentation.
Si un terminal envoie de façon répétée de courts messages d'état tandis qu'un autre transfère un fichier plus volumineux, les seuls décomptes d'octets applicatifs ne décrivent pas la charge du port. Chaque trame consomme également des opportunités d'encapsulation et de transmission, y compris l'espacement requis. De nombreux petits messages peuvent utiliser des ressources de traitement et de lien. Commencez par des observations du débit de trames, du trafic réel et du cycle applicatif plutôt que d'exiger des formules complexes.
Si une application transportée de manière transparente semble gagner des octets de fin, vérifiez d'abord les limites du protocole et l'analyseur. Comparez ce que la source, tout convertisseur et la destination observent chacun. Ne traitez pas automatiquement le remplissage Ethernet comme faisant partie d'un message série, et ne changez pas les modes d'équipement simplement pour éliminer le remplissage. Établissez d'abord la couche concernée.
Utiliser trois questions pour circonscrire une investigation sur le terrain
Premièrement, identifiez le point d'observation : avant la transmission par la source, après la réception par le pair ou une copie fournie par un commutateur. Deuxièmement, documentez la convention de longueur : en-têtes inclus, disponibilité du FCS et conservation ou non d'une trame complète. Troisièmement, corrélez les longueurs de protocole, la charge utile et les compteurs d'erreurs pour le même trafic applicatif. Une seule capture d'écran montrant 60 octets est insuffisante.
Pour comparaison, utilisez un court message connu dans un environnement de test isolé ou une fenêtre de maintenance approuvée. Conservez les captures d'origine et les paramètres d'acquisition des deux extrémités. Confirmez que l'application extrait uniquement son contenu valide et que les communications ordinaires se poursuivent. Un tel test valide cette configuration et ce chemin ; l'affichage d'un outil ne définit pas chaque interface et commutateur.
Enfin, observez si l'anomalie suit un port, un câble ou une méthode de capture. Conservez les preuves brutes plutôt que seulement des captures d'écran annotées. Le principe est simple : la trame externe a un format minimal, l'application interne a sa propre limite de longueur, et le logiciel de capture enregistre une étape de traitement. Garder ces trois éléments séparés aide à localiser un véritable défaut.
Sources et preuves produit
Wireshark : Ethernet; IETF RFC 894, avril 1984; Document de dépannage Cisco sur le remplissage, mis à jour en juillet 16, 2021. Les mécanismes généraux ne transfèrent pas de commandes propres à une plateforme ni de conclusions de défaut à d'autres équipements. Preuve produit : Mini commutateur Fast Ethernet cinq ports à rail DIN FCTEL, page en chinois. Vérifiez la version choisie. Les illustrations sont des concepts génériques réalisés avec l'aide de l'IA.
Traduit de l'article technique chinois : Lire l'article original en chinois.
Questions pratiques courantes
Une capture de 60 octets est-elle une trame courte invalide ?
Pas nécessairement. Une capture courante omet le FCS de quatre octets. Vérifiez le point d'observation, la longueur d'origine et la longueur capturée.
Le remplissage devient-il une nouvelle commande d'automate ?
Il ne devrait pas. Un analyseur doit utiliser la longueur du protocole de couche supérieure plutôt que de traiter le remplissage externe comme des données applicatives supplémentaires.
Chaque court message a-t-il besoin de 18 octets de remplissage ?
Non. Dix-huit octets ne s'appliquent qu'à l'exemple non étiqueté de cet article ; le contenu d'origine et l'encapsulation déterminent le remplissage réel.
Portée et lectures complémentaires
Concepts génériques de remplissage Ethernet et de capture, et non des mesures ou un comportement garanti propre à un modèle.
Guide connexe sur le CRC et le FCS · Guide connexe sur le préambule et l'intervalle inter-trames
