Pourquoi Ethernet a-t-il une taille de trame minimale spécifiée?


12

Je pense que le minimum est de 64 octets. Pourquoi ce minimum est-il nécessaire?

Réponses:


16

En faisant une lecture rapide, il semble que cela soit lié à la partie Détection de collision de CSMA / CD. Si les images étaient trop petites sur les anciens supports de diffusion, certaines collisions seraient indétectables. Poursuivant mon thème des analogies automobiles aujourd'hui, c'est pour la même raison que nous n'autorisons pas les vélos sur les autoroutes à grande vitesse - ce n'est tout simplement pas sûr pour eux.


3
+1, je ne savais pas ça sur les vélos ...
Kyle Brandt

6
+1 La détection de collision en est la raison. 64 octets correspond à 0,04 ms à des vitesses Ethernet de 10 Mo. Toute collision plus petite et non détectée (en 1982).
sysadmin1138

Si je vous comprends bien, la raison du minimum de 64 octets est de donner suffisamment de temps aux autres stations pour le remarquer?
CodyBugstein

1
Pouvez-vous expliquer pourquoi les collisions seraient indétectables?
problemofficer

1
Je suis sûr qu'une collision de vélo sur une autoroute à grande vitesse serait détectable. Et de toute façon, les vélos sont autorisés sur les autoroutes dans la plupart des États de l'ouest des États-Unis, donc je ne sais pas trop à quel point l'analogie est appropriée. :)
Michael Hampton

4

En plus de la réponse (absolument correcte) de mfinni, la définition d'une taille de trame minimale vous permet de passer plusieurs cycles de réception à vérifier les sommes de contrôle de vos trames. Dans Ye Olde Days, on peut facilement imaginer une puce qui traite un bit par cycle, mais prend de nombreux cycles pour calculer une somme de contrôle sur une voie dédiée parallèle à la voie de réception. La réception de nombreux messages courts peut entraîner une altération de cette logique de somme de contrôle en déclenchant plusieurs opérations simultanées. La suppression de tout élément inférieur à un certain seuil de taille vous permet d'éviter ce problème de manière simple.


Je crois que cette réponse est fausse; cela a à voir avec le retard de propagation dans le milieu et la détection de collision.
Andrew Wagner

@AndrewWagner, Comme je l'ai déjà dit dans ma réponse, la réponse de mfinni ci-dessus, qui concerne la détection des collisions, est correcte. Mon point était que cette "bizarrerie" de la spécification permet également aux concepteurs de matériel de prendre quelques raccourcis qui leur sont propres.
BMDan

2

Ethernet est conçu pour fonctionner sur un support partagé (l'éther!). Les expéditeurs sont capables de détecter quand le signal avec lequel ils conduisent l'éther est différent de celui qui est sur l'éther.

Malheureusement, tous les médias ont un retard de propagation (malheureusement, même la lumière se déplace à une vitesse finie).

Supposons que vous envoyez une trame très courte. Pour détecter si le récepteur transmet correctement en même temps qu'il recevait votre trame, vous devez attendre que le signal qu'il envoie vous atteigne, vous devez donc attendre / écouter deux fois le délai de propagation du support avant de savoir s'il y a eu une collision à l'extrémité de réception.

Maintenant, au lieu de simplement écouter (envoyer du silence) pendant ce temps, vous pourriez aussi bien aller de l'avant et envoyer des informations utiles pendant ce temps.

La norme définit donc la taille de trame minimale comme étant la quantité de données que vous pouvez envoyer dans DEUX FOIS le délai de propagation le plus défavorable dans le support partagé.

Donc, si vous n'êtes pas satisfait parce que les grands cadres ne semblent pas optimisés pour votre petit message, pensez à cet espace supplémentaire dans le paquet comme une opportunité de trouver autre chose à envoyer, alors que vous auriez autrement à envoyer des zéros de toute façon.

Bien sûr, il existe de nombreuses autres façons de gérer les collisions et les retards de propagation dans une norme de réseau local, mais ce ne serait pas Ethernet, et je pense que nous pouvons tous convenir qu'Ethernet est plutôt agréable.


Question: Je comprends donc pourquoi vous avez besoin d'un minimum ou 2 x PDmais d'où vient 64 octets? Cela ne devrait-il pas dépendre de la longueur / du type de câble? 64 octets semble arbitraire
CodyBugstein

Cela revient à l'ancien compromis efficacité VS complexité. Vous pouvez créer un système pour mesurer automatiquement le réseau et sélectionner une taille de paquet minimale appropriée, mais cela ajouterait une complexité non triviale pour un gain relativement faible.
Peter Green

0

Pour que CSMA / CD fonctionne correctement, vous voulez une détection de collision cohérente.

Si le récepteur voit une collision et que l'expéditeur ne le voit pas, le paquet sera perdu. De même, si l'expéditeur voit une collision, mais pas le récepteur, vous obtiendrez un paquet en double après que l'expéditeur a retransmis. Ni l'un ni l'autre n'est souhaitable.

Étant donné que les données voyagent à une vitesse limitée, une taille de paquet minimale était requise pour garantir que si une collision se produisait, elle se produisait partout. Plus vous augmentez la taille minimale des paquets, plus le réseau est grand et / ou rapide avant la panne de CSMA / CD.

Quant à savoir pourquoi 64 octets, je ne sais pas avec certitude, mais je m'attends à ce que ce soit juste un chiffre rond qui "semblait juste à l'époque", compte tenu des vitesses auxquelles ils fonctionnaient, de la taille attendue des réseaux Ethernet et de la taille attendue de paquets de niveau supérieur.


0

La longueur minimale de paquet de 64 octets n'est pas un nombre arbitraire. Dans une couche physique 10Base5 (coaxial "Fat Ethernet", l'une des couches physiques spécifiées à l'origine, qui a les câbles les plus longs autorisés), il en résulte une longueur de paquet minimale, en microsecondes, qui est le double du temps d'aller-retour de la longueur maximale câble, qui est de 2500 mètres, composé de cinq segments de 500 mètres avec quatre répéteurs. Cela permet de garantir que les paquets transmis par les côtés opposés du câble entrent en collision complète à chaque point du câble, pour une détection fiable des collisions dans tous les nœuds.

Anecdote:

  • C'est deux fois le montant minimum pour des frais généraux de sécurité
  • La détection de collision dans le câble coaxial peut être effectuée par un comparateur de tension analogique (car les paquets entrés en collision génèrent deux fois la tension de signal normale)
  • La vitesse de l'électricité dans le câble en cuivre est d'environ 200 000 kilomètres par seconde
  • Chaque bit dans Ethernet 10Base5 mesure 20 mètres de long dans le câble
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.