Fragmentation et réassemblage de la propriété intellectuelle
je suis actuellement en train de parcourir mes diapositives de réseautage et je me demandais si quelqu'un pourrait m'aider avec le concept de fragmentation et de réassemblage.
je comprends comment cela fonctionne, à savoir comment les datagrammes sont divisés en petits morceaux parce que les liens réseau ont un MTU. Cependant, l'exemple de la photo me trouble.
ainsi les deux premières sections montrent une longueur de 1500, parce que c'est le MSU, mais cela ne devrait pas signifier que le dernier on devrait avoir 1000 (pour un total de 4000 octets) et pas 1040? D'où viennent ces 40 octets supplémentaires? À mon avis, 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 ils arriveront dans le dernier fragment?
Fragflag signifie essentiellement qu'il y a un autre fragment, donc tous auront un Fragflag de 1 sauf le dernier fragment qui sera à zéro. Cependant je ne comprends pas ce décalage est ou comment il est calculé. Pourquoi le premier décalage est-il à zéro? Pourquoi avons-nous divisé les octets dans le datafield (1480) par 8 pour obtenir le second décalage? D'où vient cette 8 viennent de? Mis à part cela, je suppose que chaque fragment compensé augmentera juste de cette valeur?
Par exemple, le premier fragment aura un décalage de 0, la deuxième 185, le troisième 370 et le quatrième 555? (370+185)
merci de votre aide!
4 réponses
il y a un en-tête de 20 octets dans chaque paquet. Ainsi, le paquet original contient 3980 octets de données. Les fragments contiennent 1480, 1480 et 1020 octets de données. 1480 + 1480 + 1020 = 3980
chaque morceau dans l'en-tête est précieux. Diviser l'offset par 8 lui permet de tenir en 13 bits au lieu de 16. Cela signifie que chaque paquet sauf 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.
la fragmentation et le réassemblage ont été expliqués exclusivement dans la RFC 791. Faire passer par le spécification de protocole Internet RFC. Le RFC comporte diverses sections expliquant la fragmentation de l'échantillon et le réassemblage. Tous vos doutes et questions sont les bienvenus.
Ans 1: en ce qui concerne la longueur du paquet: le paquet original contient 4000 octets. Ce paquet est un paquet IP complet et contient donc aussi l'en-tête IP . Ainsi, la longueur de la charge utile est en fait 4000 - ( en-Tête IP en Longueur je. e. 20 ).
Longueur Réelle De La Charge Utile = 4000-20 = 3980
maintenant le paquet est fragmenté en raison du fait que la longueur est plus grande que le MTU ( 1500 octets).
ainsi le premier paquet contient 1500 octets qui inclut 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 reste des données ( 3980 - 1480 -1480 ) = 1020
ainsi la longueur du paquet est 20 (en-tête IP ) + 1020 (charge utile ) = 1040
Sna 2: Le décalage est l'adresse ou le localisateur d'où les données commence par référence aux données de la charge utile. Pour IP, la charge utile de données comprend toutes les données qui suivent L'en-tête IP et L'en-tête Options. Ainsi, le système/routeur prend la charge utile et le divise en parties plus petites et garde la trace de l'offset avec référence au paquet original pour que le réassemblage puisse être fait.
Comme indiqué dans le RFC Page 12.
" le champ fragment offset indique au récepteur la position d'un fragment dans le datagramme original. L'offset et la longueur du fragment déterminent la partie du datagramme original couvert par ce fragment. Le drapeau more-fragments indique (en étant réinitialisé) le dernier fragment. Ces champs fournissent suffisamment d'informations pour reconstituer les datagrammes. "
le fragment offset est mesuré en unités de 8 octets chacune. Il a un champ de 13 bits dans l'en-tête IP. Comme il est dit dans le RFC page 17
"Ce champ indique où dans le datagramme ce fragment appartient.Le fragment offset 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é dans la question d'où vient ce 8, c'est la norme qui a été définie pour la spécification du protocole IP, où 8 octets sont pris comme une valeur. Cela nous aide aussi à transmettre de grands paquets par ce biais.
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 zéro (MF = 0, décalage de fragment = 0). Si un datagramme internet est fragmenté, sa portion de données doit être cassée sur les limites de 8 octets. Ce format Permet 2**13 = 8192 fragments de 8 octets chacun pour un total de 65 536 Octuor. Notez que ceci est cohérent avec le datagramme longueur totale terrain (bien sûr, l'en-tête est compté dans le longueur totale et pas dans les fragments).*
la taille de l'offset 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 à savoir (2^16/2^13).
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 incluant l'en-tête. L'en-tête est ajouté avec chaque fragment. cela signifie qu'en fragment nous sommes capables d'envoyer 1500-20 =1480 octets de données. il est donné qu'il y a 4000B datagramme .le datagramme n'est rien d'autre qu'une encapsulation de paquets de données à la couche réseau.donc le total des données que nous devons envoyer est 4000-20=3980 . il est ensuite fragmenté en 3 parties (ceil(3980/1480)) chacune d'une longueur de 1480.1480.1020 respectivement . ainsi, lorsque L'en-tête 20B est ajouté au dernier fragment, sa longueur devient 1020+20=1040 .