Fragmentation et réassemblage IP

Question

Je suis en train de parcourir mes diapositives de réseautage et je me demandais si quelqu'un pouvait m'aider avec le concept de fragmentation et de réassemblage.

Je comprends comment cela fonctionne, à savoir comment les datagrammes sont divisés en plus petits morceaux parce que les liens du réseau ont une MTU. Cependant l'exemple dans l'image me confond. Donc, les deux premières sections montrent une longueur de 1500, parce que c'est le MSU, mais cela ne devrait-il pas signifier que le dernier devrait avoir 1000 (pour un total de 4000 octets) et non 1040? D'où viennent ces 40 octets supplémentaires? Ma conjecture est que parce que les deux fragments précédents avaient tous deux un en-tête de 20 octets, ces 40 octets supplémentaires de données devaient aller quelque part, donc il arrivera dans le dernier fragment? Fragflag signifie essentiellement qu'il existe un autre fragment, de sorte que tous auront un Fragflag de 1 sauf le dernier fragment qui sera à 0. Cependant, je ne comprends pas ce que le décalage est ou comment il est calculé. Pourquoi le premier décalage est-il nul? Pourquoi avons-nous divisé les octets dans le champ de données (1480) par 8 pour obtenir le deuxième décalage? D'où est-ce que cela vient? En dehors de cela, je suppose que chaque décalage de fragments va juste augmenter de cette valeur?

Par exemple, le premier fragment aura un décalage de 0, le second 185, le troisième 370 et le quatrième 555? (370 + 185)

Merci pour toute aide!

Answer 1

Il y a un en-tête de 20 octets dans chaque paquet. Le paquet d'origine contient donc 3 980 octets de données. Les fragments contiennent 1480, 1480 et 1020 octets de données. 1480 + 1480 + 1020 = 3980

Chaque bit de l'en-tête est précieux. La division du décalage par 8 lui permet de s'adapter à 13 bits au lieu de 16. Cela signifie que chaque paquet, mais le dernier doit contenir un nombre d'octets de données qui est un multiple de 8, ce qui n'est pas un problème.

Answer 2

la taille de décalage est de 13 bits dans l'en-tête IP, mais nous avons besoin de 16 bits comme dans le pire des cas. Nous utilisons donc un facteur d'échelle de 8 c'est-à-dire (2^16/2^13).

Answer 3

La fragmentation et le réassemblage ont été exclusivement expliqués dans la RFC 791. Passez par le Internet Protocol Specification RFC. Le RFC comporte différentes sections expliquant la fragmentation et le réassemblage de l'échantillon. Tous vos doutes et questions sont bien pris en compte. Ans 1: En ce qui concerne les longueurs du paquet: Le paquet d'origine contient 4000 octets. Ce paquet est un paquet entièrement IP et contient donc également l'en-tête IP. Ainsi, la longueur de la charge utile est en réalité de 4000 - (longueur d'en-tête IP, c'est-à-dire 20).

réelle Longueur Payload = 4000 - 20 = 3980

Maintenant, le paquet est fragmenté dû au fait que la longueur est supérieure à la MTU (1500 octets).

Ainsi, le 1er paquet contient 1500 octets qui inclut l'en-tête IP + la fraction utile.

1500 = 20 (en-tête IP) + 1480 (Payload Data)

De même pour l'autre paquet.

Le troisième paquet comprend les renseignements suivants restant à gauche sur les données (3,98 mille - 1480 -1480) = 1020

longueur Ainsi du paquet est 20 (en-tête IP) + 1020 (charge utile) = 1040

2 Ans : Le décalage est l'adresse ou le localisateur d'où les données commencent par référence à la charge utile de données d'origine. Pour IP, la charge utile de données comprend toutes les données après l'en-tête IP et l'en-tête Options. Ainsi, le système/routeur prend la charge utile et la divise en parties plus petites et conserve la trace du décalage en référence au paquet d'origine, de sorte que le réassemblage peut être effectué.

Comme indiqué dans le RFC page 12.

"Le champ de décalage fragment indique au récepteur la position d'un fragment dans le datagramme d'origine. Le fragment de décalage et la longueur déterminent la partie du datagramme original couverte par Le fragment more-fragments indique (en réinitialisant) le dernier fragment Ces champs fournissent des informations suffisantes pour réassembler les datagrammes "

Le décalage de fragment est mesuré en unités de 8 octets chacune. Il a un champ de 13 bits dans l'en-tête IP. Comme indiqué dans la page RFC 17

« Ce champ indique où dans le datagramme ce fragment fragment appartient.Procédé décalage est mesuré en unités de 8 octets (64 bits). Le premier fragment a décalage d'origine. »

Ainsi, comme vous l'avez demandé dans la question d'où vient cette 8, c'est la norme qui est définie pour la spécification du protocole IP, où 8 octets sont pris comme une valeur. Cela nous aide également à transmettre de gros paquets via cela.

Page 28 du RFC écrit: * Les fragments sont comptés en unités de 8 octets. La stratégie de fragmentation est conçue de telle sorte qu'un datagramme non fragmenté ait toutes les informations de fragmentation nulles (MF = 0, décalage de fragment = 0). Si un datagramme Internet est fragmenté, sa partie de données doit être brisée sur les limites de 8 octets. Ce format permet 2 ** 13 = 8192 fragments de 8 octets chacun pour un total de 65 536 octets. Notez que cela est compatible avec le champ de longueur totale Datagram (bien sûr, l'en-tête est compté dans la longueur totale et non dans les fragments). *

Answer 4

ce ne sont pas des bits supplémentaires, mais la longueur totale du dernier fragment . comme 1500 est MTU cela signifie qu'il peut y avoir 1500 octets de données dans un fragment, y compris en-tête. L'en-tête est ajouté avec chaque fragment. cela signifie en fragment que nous sommes capables d'envoyer 1500-20 = 1480 octets de données. il est donné il ya 4000B datagramme .datagram n'est rien mais un paquet d'encapsulation de données à la couche réseau.so les données totales que nous devons envoyer est 4000-20 = 3980. alors il est fragmenté en 3 parties (ceil (3980/1480)) chacune de longueur 1480,1480,1020 respectivement. par conséquent, lorsque l'en-tête 20B est ajouté au dernier fragment, sa longueur devient 1020 + 20 = 1040.