Quelle est la taille «dans le fil» d'une trame Ethernet? 1518 ou 1542?

Selon le tableau ici , il indique que MTU = 1500 octets et que la partie de la charge utile est de 1500 à 42 octets ou 1458 octets (<- c'est en fait faux!). Maintenant, en plus de cela, vous devez ajouter des en-têtes IPv4 et UDP, qui sont de 28 octets (20 IP + 8 UDP). Cela laisse mon message d'application maximum possible à 1430 octets! Mais en cherchant ce numéro sur Internet, je vois 1472 à la place. Suis-je en train de faire ce calcul mal ici?

Tout ce que je veux savoir, c'est le message d'application maximum que je peux envoyer par fil sans risque de fragmentation. Ce n'est certainement pas 1500 car cela inclut les en-têtes de cadre. Quelqu'un peut-il aider?

La confusion est que le PAYLOAD peut en fait être aussi grand que 1500 octets et c'est le MTU. Alors maintenant, quelle est la taille dans le fil pour une charge utile de 1500? À partir de ce tableau, il peut atteindre 1542 octets.

Ainsi, le nombre maximal de messages d'application que je peux envoyer est de 1472 (1500 - 20 (ip) - 8 (udp)) pour un maximum dans la taille de fil de 1542. Cela m'étonne de voir comment les choses peuvent devenir si compliquées quand elles sont en fait simples. Et je ne sais pas comment quelqu'un a trouvé le numéro 1518 si le tableau dit 1542.

Le diagramme sur Wikipédia est horrible. J'espère que ce que je vais écrire est plus clair.

La charge utile maximale dans Ethernet 802.3 est de 1 500 octets.
Ce sont les données que vous essayez d'envoyer sur le fil (et à quoi le MTU fait référence).
[payload]<- 1500 octets

La charge utile est encapsulée dans une trame Ethernet (qui ajoute le MAC source / destination, la balise VLAN, la longueur et la somme de contrôle CRC. Cela représente un total de 22 octets de "trucs" supplémentaires
[SRC+DST+VLAN+LENGTH+[payload]+CRC]<- 1522 octets

Le cadre est transmis sur le fil - avant que votre carte Ethernet ne le fasse, il se lève et crie vraiment fort pour s'assurer que personne d'autre n'utilise le fil (CSMA / CD) - Il s'agit du délimiteur de préambule et de début de cadre (SFD) - 8 octets supplémentaires, nous avons donc maintenant:
[Preamble+SFD+[Ethernet Frame]]<- 1530 octets

Enfin, lorsqu'un émetteur-récepteur Ethernet envoie une trame, 802.3 doit transmettre 12 octets de silence ("Interframe Gap") avant de pouvoir envoyer sa trame suivante.
[Preamble+SFD+[Ethernet Frame]+Silence]<- 1542 octets transmis sur le fil.

Le préambule, le SFD et l'intervalle entre les images ne comptent pas comme faisant partie de l'image. Ils sont une structure de support pour le protocole Ethernet lui-même.

Le MTU s'applique à la charge utile - c'est la plus grande unité de données que vous pouvez entasser dans le paquet. Ainsi, un paquet Ethernet avec une MTU de 1500 octets sera en fait une trame de 1522 octets et 1542 octets sur le câble (en supposant qu'il y ait une balise vLAN).

Donc, la réponse à votre question - Quel est le plus gros paquet que je puisse envoyer sur Ethernet 802.3 sans fragmentation? - représente 1 500 octets de données utiles .

TOUTEFOIS, la couche Ethernet peut ne pas être votre facteur limitant. Pour découvrir si quelque chose en cours de route limite la MTU à une taille inférieure à 1 500 octets de données utiles, utilisez l'une des méthodes suivantes:

• Windows: ping hostname -f -l sizeofdata(technique mentionnée par John K)
• BSD: ping -D -s sizeofdata hostname
• Linux: ping -M do -s sizeofdata hostname

La plus grande valeur de sizeofdatacela fonctionne est le MTU (sur le chemin particulier emprunté par vos données).

Cela dépend de la quantité de données que vous mettez dans le cadre. Si vous mettez 1500 octets de données dans une trame, votre taille totale de trame sera de 1518 octets. Avec 1472 octets de données, vous vous retrouverez avec une taille totale de trame de 1500 ..

http://en.wikipedia.org/wiki/Ethernet_frame

Cela étant dit, si vous êtes vraiment intéressé par le test de la fragmentation, un bon moyen de le tester est avec un bon vieux ping avec quelques indicateurs:

ping hostname -f -l sizeofdata

L'indicateur -f entraînera l'échec du ping si le paquet est fragmenté. La clé à comprendre ici est que "sizeofdata" est la quantité de données que vous pouvez mettre dans un message sans fragmenter - donc si vous envoyez une charge utile de 1500, vous commencerez à fragmenter en parcourant plus de 1500 octets. Cependant, diminuez cela à 1472 (1500 - les frais généraux de 18 octets), et vous verrez les pings passer.

Pour la trame Ethernet_II de base, la taille de la trame est de 1518 octets (sur ou hors du câble). Il est composé de 6 octets pour chacune des adresses de destination et source, 2 octets pour le champ type entre 46 et 1500 octets pour la charge utile (dans votre cas, le paquet IP entier avec son en-tête IP et son en-tête UDP) et 4 octets pour le FCS. En plus de cela, il existe une restriction sur la taille d'une trame (64 octets). C'est pourquoi la plage est de 46 octets (ajoutez ceci aux deux adresses et au type et au FCS et vous obtenez 64 octets - 46 + 6 + 6 + 2 + 4 = 64).

Si le cadre est sur un réseau qui prend en charge plusieurs réseaux locaux virtuels et que vous devez marquer le cadre avec une balise vlan, un champ supplémentaire est ajouté avant le champ type. C'est 4 octets. Cela signifie maintenant que la plage de tailles pour la charge utile peut être réduite de 4 octets à l'extrémité inférieure et avoir encore 64 octets au minimum. D'où le 42. (Donc 42 + 6 + 6 + 2 + 4 + 4 pour la balise vlan = 64)

Ainsi, lorsque la plage est écrite entre 1500 et 42, cela ne signifie pas 1500 moins 42, cela signifie que tout ce qui va de 1500 à 42 octets est valide. Sur le fil, cette trame étiquetée peut atteindre 1522 octets (si une seule étiquette est utilisée, ou 1526 si deux étiquettes sont utilisées). Rien de tout cela n'explique le nombre 1542.

Pour arriver à ce nombre, vous devez considérer comment une trame peut être envoyée sur Ethernet. Il n'y a pas d'horloge sur un LAN Ethernet, donc une série de 1 et de 0 est envoyée par l'émetteur d'une trame pour régler une horloge. C'est ce qu'on appelle le préambule. Tous les auditeurs n'entendront pas tout le préambule, mais la plupart devraient en entendre une partie. Pour signaler la fin du préambule, l'un des 8 derniers bits envoyés est inversé de sorte qu'au lieu de 10101010, il devienne 10101011. Cet octet est appelé le début du délimiteur de trame (SDF). Ce n'est pas techniquement utile pour capturer sur le fil, donc les 7 octets du préambule et le SDF 1 octet ne sont normalement pas comptés mais s'ils étaient notre 1518 original serait maintenant 1526. Toujours pas 1542 ..

Après qu'une trame a été envoyée, il y a un silence forcé sur le fil qui est appelé l'intervalle entre trames. Cela équivaut à une transmission de 12 octets. Ce n'est pas non plus compté ou capturé, mais s'il l'était, cela nous amènerait à 1538 octets. La seule façon de passer à 1542 à partir de 1538 est de dire que la trame est balisée (c'est-à-dire qu'elle contient la balise de plan à 4 octets). Ouf, 1542 enfin.

Tout est dans la terminologie. Une trame standard est de 1518 octets sur le fil (en ce qui concerne tout périphérique de capture). Une trame balisée (balise unique) fait 1522 octets sur le fil. Ceux-ci occupent 1538 octets ou 1542 octets d'espace de transmission sur le câble.

J'espère que cela aide à clarifier ..

non, vous voulez que la fragmentation se produise, c'est pourquoi vous obtenez un paquet doit être fragmenté, mais le jeu df le prend comme ceci une autoroute à 2 voies avec tout un tas de demi-finales vs la même autoroute avec tout un tas de petites voitures intelligentes qui vont toutes les deux les mêmes demi-destinations de destination transportent plus de charge utile mais sont plus lentes et peuvent encombrer plus facilement les petites voitures transportent moins mais voyagent plus vite MSS n'est pas la même chose que MTU non plus