Fragmentation et réassemblage IP
Je suis en train de parcourir mes diapositives de réseau et je me demandais si quelqu'un pourrait m'aider avec le concept de fragmentation et de réassemblage.
Je comprends son fonctionnement, notamment la façon dont les datagrammes sont divisés en fragments plus petits, car les liaisons réseau ont un MTU. Cependant, l'exemple sur la photo m'embrouille.
Ainsi, les deux premières sections montrent une longueur de 1500, car il s’agit de la MSU, mais cela ne signifie-t-il pas que la dernière devrait en contenir 1000 (pour un total de 4000 octets) et non pas 1040? D'où viennent ces 40 octets supplémentaires? Je suppose que parce que les deux fragments précédents avaient tous les deux un en-tête de 20 octets, ces 40 octets supplémentaires de données devaient être acheminés quelque part, de sorte qu'ils arriveraient dans le dernier fragment?
Fragflag signifie essentiellement qu'il y a un autre fragment, donc ils auront tous un Fragflag de 1 sauf le dernier fragment qui sera à zéro. Cependant, je ne comprends pas ce qu'est l'offset ni comment il est calculé. Pourquoi le premier décalage est-il à zéro? Pourquoi avons-nous divisé les octets du champ de données (1480) par 8 pour obtenir le second décalage? D'où vient ce 8? En dehors de cela, je suppose que chaque fragment décalé augmentera simplement 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!
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 partie de l'en-tête est précieuse. Diviser le décalage par 8 lui permet de contenir 13 bits au lieu de 16. Cela signifie que chaque paquet, sauf le dernier, doit contenir un nombre d'octets de données multiple de 8, ce qui n'est pas un problème.
La fragmentation et le réassemblage ont été exclusivement expliqués dans la RFC 791. Consultez le Internet Protocol Specification RFC . La RFC comprend différentes sections expliquant la fragmentation et le réassemblage des échantillons. Tous vos doutes et vos questions y sont bien traités.
Réponse 1: Concernant les longueurs du paquet: Le paquet d'origine contient 4000 octets. Ce paquet est un paquet entièrement IP et contient donc aussi l'en-tête IP. Ainsi, la longueur de la charge utile est en réalité de 4000 - (longueur d’en-tête IP, par exemple 20).
Longueur de la charge utile réelle = 4000 - 20 = 3980
Maintenant, le paquet est fragmenté en raison du fait que la longueur est supérieure à la MTU (1500 octets).
Ainsi, le premier paquet contient 1500 octets, qui comprend l'en-tête IP + la fraction de charge utile.
1500 = 20 (en-tête IP) + 1480 (charge utile de données)
De même pour l'autre paquet.
Le troisième paquet doit contenir les données restantes (3980 - 1480 - 1480) = 1020
Ainsi, la longueur du paquet est de 20 (en-tête IP) + 1020 (charge utile) = 1040
Ans 2: le décalage est l'adresse ou le localisateur à partir duquel les données commencent par une référence à la charge de données d'origine. Pour IP, la charge de données comprend toutes les données qui se trouvent 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 par rapport au paquet d'origine afin qu'un réassemblage puisse être effectué.
Comme indiqué dans la RFC page 12.
"Le champ offset de fragment indique au destinataire la position d'un fragment dans le datagramme d'origine. Le décalage et la longueur du fragment déterminent la partie du datagramme d'origine Couverte par ce fragment. L'indicateur more-fragments indique (par réinitialisation ) 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 RFC page 17
"Ce champ indique l'endroit dans le datagramme auquel ce fragment appartient. Le décalage de fragment est mesuré en unités de 8 octets (64 bits). Le premier fragment a un décalage de zéro."
Ainsi, comme vous l'avez demandé à la question d'où provient cette 8 source, c'est la norme 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.
La page 28 de la RFC écrit: * Les fragments sont comptés en unités de 8 octets. La stratégie de fragmentation est conçue de manière à ce qu'un datagramme non fragmenté ait toutes les informations de fragmentation nulles (MF = 0, fragment offset = 0). Si un datagramme Internet est fragmenté, sa partie de données doit être Fractionnée sur une limite de 8 octets. Ce format autorise 2 ** 13 = 8192 fragments de 8 octets chacun pour un total de 65 536 octets. Notez que cela est cohérent avec le champ de longueur totale Datagramme (bien sûr, l'en-tête est compté dans la longueur totale et non dans les fragments). *
la taille du décalage est de 13 bits dans l'en-tête IP, mais il faut 16 bits comme dans le pire des cas. Nous utilisons donc un facteur d’échelle de 8, à savoir (2 ^ 16/2 ^ 13).
ce ne sont pas des bits supplémentaires, mais la longueur totale du dernier fragment . 1500 étant un MTU, cela signifie qu'il peut y avoir 1 500 octets de données dans un fragment, en-tête compris. L'en-tête est ajouté à chaque fragment. cela signifie que nous sommes en mesure d'envoyer par fragment 1500-20 = 1480 octets de données. il est donné qu’il ya 4000B datagramme .datagram n’est rien qu’une encapsulation par paquet de données au niveau de la couche réseau. Ainsi, le total des données que nous devons envoyer est 4000-20 = 3980. puis il est fragmenté en 3 parties (ceil (3980/1480)) chacune de longueur respectivement 1480,1480,1020. par conséquent, lorsque l'en-tête 20B est ajouté au dernier fragment, sa longueur devient 1020 + 20 = 1040.