Quelle est la taille "dans le fil" d'un cadre Ethernet? 1518 ou 1542?
Selon -- le tableau ici , il dit que MTU = 1500 octets et que la partie de charge utile est de 1500 à 42 octets ou 1458 octets (<- Ceci est en fait faux!). Maintenant, en plus de cela, vous devez ajouter des en-têtes IPv4 et UDP, qui sont 28 octets (20 IP + 8 UDP). Cela laisse mon message d'application maximum possible à 1430 octets! Mais en cherchant ce nombre sur Internet, je vois 1472 à la place. Est-ce que je fais ce calcul faux ici?
Tout ce que je veux savoir, c'est le message d'application maximum que je peux envoyer sur le 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 la charge utile peut réellement être aussi grande que 1500 octets et c'est le MTU. Alors maintenant, quelle est la taille dans le fil pour une charge utile de 1500? De cette table, il peut être aussi grand que 1542 octets.
Donc, les messages d'application maximum que je peux envoyer sont 1472 (1500 - 20 (IP) - 8 (UDP)) pour un maximum de la taille du fil de 1542. Il m'améliore comment les choses peuvent être si compliquées quand elles sont en réalité simple. Et je n'ai aucune idée de la façon dont quelqu'un est venu avec le numéro 1518 si la table indique 1542.
Le diagramme sur Wikipedia est horrible. Espérons que ce que je suis sur le point d'écrire est plus clair.
Le maximum la charge utile Dans 802.3 Ethernet est de 1500 octets.
[.____] Il s'agit des données que vous essayez d'envoyer sur le fil (et de ce que le MTU fait référence à).
[.____] [payload] <- 1500 octets
La charge utile est encapsulée dans un Cadre Ethernet (qui ajoute le Mac source/destination, VLAN étiquette, longueur et checksum de la CRC. Ceci est 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 se lève-t-elle essentiellement et crie vraiment fort pour que personne d'autre n'utilise le fil (CSMA/CD) - c'est le Préambule et Délimiteur de démarrage (SFD) - 8 octets supplémentaires, alors maintenant nous avons:
[.____] [Preamble+SFD+[Ethernet Frame]] <- 1530 octets
Enfin, lorsqu'un émetteur-récepteur Ethernet a effectué une image, il est requis par 802.3 pour transmettre 12 octets de silence ("écart interfromate") avant qu'il soit autorisé à envoyer son prochain cadre.
[.____] [Preamble+SFD+[Ethernet Frame]+Silence] <- 1542 octets transmis sur le fil.
Le préambule, la SFD et l'interface interférum ne comptent pas dans le cadre du cadre. 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 créer dans le paquet. Ainsi, un paquet Ethernet avec un MTU de 1500 octets sera réellement un cadre de 1522 octets et 1542 octets sur le fil (en supposant qu'il y a une balise VLAN).
Donc, la réponse à votre question - Quel est le plus grand paquet que je puisse envoyer plus de 802,3 Ethernet sans fragmentation ? -1500 octets de données de charge utile.
[~ # ~] Cependant [~ # ~ ~] La couche Ethernet peut ne pas être votre facteur de limitation. Pour découvrir si quelque chose sur le chemin se limite à ce que le MTU soit inférieur à 1500 octets de données de charge utile, utilisez l'une des opérations suivantes:
- Les fenêtres:
ping hostname -f -l sizeofdata(Technique John K mentionné) - BSD:
ping -D -s sizeofdata hostname - Linux:
ping -M do -s sizeofdata hostname
La plus grande valeur de sizeofdata qui fonctionne est la MTU (sur le chemin particulier que vos données prennent).
Cela dépend de la quantité de données que vous avez placées dans le cadre. Si vous mettez 1500 octets de données dans une image, votre taille totale de l'image sera de 1518 octets. Avec 1472 octets de données, vous vous retrouverez avec une taille totale de l'image de 1500 ..
http://en.wikipedia.org/wiki/ethernet_frame
Cela étant dit, si vous êtes vraiment intéressé par la fragmentation des tests, un bon moyen de tester cela est avec un bon vieux ping avec quelques drapeaux:
ping Hostname -f -L Taillefdata
Le drapeau -f provoquera l'échec du ping si le paquet est fragmenté. La clé pour comprendre ici est "Tailleofdata" 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 lorsque vous passez plus de 1500 octets. Tournez cela jusqu'à 1472 (1500 - la surcharge de 18 octets), et vous verrez les pingés.
Pour la trame Ethernet_II de base, la taille du cadre est de 1518 octets (sur ou hors du fil). Ceci est composé de 6 octets pour chacune de la destination et l'adresse source, 2 octets pour le champ de type entre 46 et 1500 octets pour la charge utile (dans votre cas tout le paquet IP 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 façon dont la petite image peut être (64 octets). C'est pourquoi la plage est de 46 octets (ajoutez ceci aux deux adresses et le type et le 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 VLAN et vous devez étiqueter le cadre avec une balise VLAN, un champ supplémentaire est ajouté avant le champ Type. C'est 4 octets. Cela signifie désormais que la gamme de tailles pour la charge utile peut être réduite de 4 octets à l'extrémité inférieure et ont toujours 64 octets au minimum. D'où les 42. (SO 42 + 6 + 6 + 6 + 2 + 4 + 4 pour la balise VLAN = 64)
Ainsi, lorsque la plage est écrite 1500-42, cela ne signifie pas 1500 moins 42, cela signifie que tout ce qui est de 1500 à 42 octets est valide. Un fil, ce cadre marqué pourrait être aussi grand que 1522 octets (si une seule étiquette est utilisée, ou 1526 si deux balises sont utilisées). Aucun de cela n'explique le numéro 1542.
Pour arriver à ce numéro, vous devez déterminer comment un cadre peut être envoyé sur Ethernet. Il n'y a pas d'horloge sur un réseau local Ethernet, une série de 1 et 0 est envoyée par l'émetteur d'un cadre pour définir une horloge. Ceci s'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 renversé de manière à ce que 10101010, il devienne 10101011. Cet octet s'appelle le début du délimiteur de trame (SDF). Ceci n'est pas techniquement utile de capturer le fil du fil, de sorte que les 7 octets du préambule et le SDF 1 octet ne sont normalement pas comptés, mais s'ils étaient notre original 1518 serait maintenant 1526. Toujours pas 1542 ..
Une fois qu'un cadre a été envoyé, il y a un silence exécuté sur le fil qui s'appelle l'écart intermédiaire. Cela équivaut à une transmission de 12 octets. Ceci n'est pas non plus compté ni capturé, mais s'il s'agissait de 1538 octets. Le seul moyen d'arriver à 1542 à partir de 1538 est de dire que le cadre est étiqueté (c'est-à-dire qu'il contient la balise de plan de 4 octets). Phew, 1542 enfin.
Tout est dans la terminologie. Un cadre standard est de 1518 octets sur le fil (dans la mesure où tout dispositif de capture est concerné). Un cadre marqué (étiquette unique) est de 1522 octets sur le fil. Celles-ci occupent 1538 octets ou 1542 octets d'espace de transmission sur le fil.
J'espère que cela aide à clarifier ..