Que se passe-t-il quand un paquet IP est rout\u00e9 \u00e0 travers plusieurs r\u00e9seaux de types diff\u00e9rents ? Il est encapsul\u00e9 dans diverses couches de niveaux 2 successives. Mais ces couches peuvent mettre en oeuvre des protocoles de niveau 2 diff\u00e9rents, si les r\u00e9seaux physiques sont diff\u00e9rents. Par exemple, en passant d’un LAN Ethernet \u00e0 un LAN Token Ring vous changez de protocole de niveau 2. L’un utilise le MAC Ethernet et l’autre le MAC Token Ring, qui sont totalement diff\u00e9rents.<\/p>\n
Si ces protocoles sont diff\u00e9rents, leurs caract\u00e9ristiques le sont \u00e9galement (la palisse !<\/em>). Une des caract\u00e9ristiques qui risque fort de diff\u00e9rer et qui nous int\u00e9resse ici est la taille de la MTU<\/strong> !<\/p>\n Qu’est-ce donc encore que ce truc ? La MTU<\/strong>, pour M<\/strong>aximum T<\/strong>ransmission U<\/strong>nit est la taille du champ information de la trame. C’est \u00e0 dire la taille du champ o\u00f9 l’on va placer le paquet IP ! Vous voyez o\u00f9 je veux en venir ?<\/p>\n Si au cours du transfert du paquet IP une passerelle doit le r\u00e9-encapsuler dans une trame ayant un champ information plus petit que la taille du paquet IP, elle va devoir sortir la presse ou la tron\u00e7onneuse !<\/p>\n IP n’a pas choisi la presse, il pr\u00e9f\u00e8re la tron\u00e7onneuse ! Mais rassurez-vous, il est respectueux de vos paquets de donn\u00e9es ch\u00e9ris ! Il fait \u00e7a bien, sans effusions de sang inutiles ! C’est propre, net et sans cicatrice !<\/p>\n IP a donc pr\u00e9vu un m\u00e9canisme de fragmentation qui lui permet de d\u00e9couper un paquet en plusieurs fragments, puis lui permet de reconstituer le paquet original \u00e0 l’arriv\u00e9e !<\/p>\n Un protocole non connect\u00e9, comme son nom l’indique, n’\u00e9tabli pas de connexion avec son correspondant avant d’entamer un transfert de donn\u00e9es. Le chemin parcouru par les donn\u00e9es dans le r\u00e9seau n’est donc pas pr\u00e9alablement fix\u00e9 ! Pire ! Ce chemin peut varier d’un paquet \u00e0 l’autre !<\/strong><\/p>\n A chaque chemin correspond un d\u00e9lai d’acheminement qui lui est propre. Celui-ci est fonction du nombre de passerelles \u00e0 traverser, des d\u00e9bits et de la charge des liaisons, des d\u00e9lais de transit sur ces liaisons (surtout sensible dans le cas des liaisons satellites 2*36 000 Km = 72 000 Km de long. Vous savez que l’altitude d’un satellite g\u00e9o-stationnaire est de 36 000 Km n’est ce pas ?<\/em>).<\/p>\n En cons\u00e9quence, il est possible qu’un paquet IP \u00e9mis apr\u00e8s un autre, arrive \u00e0 destination avant l’autre (je vous accorde que ce n’est pas souvent, mais \u00e7a peut arriver !). On dit qu’en mode non connect\u00e9 le s\u00e9quencement des paquets en r\u00e9ception n’est pas garanti identique au s\u00e9quencement des paquets \u00e0 l’\u00e9mission. En v\u00e9rit\u00e9, comme on aime pas les phrases longues on dit : il n’y a pas de garantie du s\u00e9quencement<\/strong> ! (c’est plus court non ?<\/em>).<\/p>\n Retenez-bien cette contrainte ! Parce que dans le cas de la fragmentation, c’est loin de nous simplifier la vie !<\/p>\n Rappelez-vous le format du paquet IP (je sais … C’est loin d\u00e9j\u00e0 !<\/em>). Les octets 5 \u00e0 8 de l’ent\u00eate se nomment Identificateur<\/strong>, Flag<\/strong> et Fragment Offset<\/strong>. Nous avions dit que ces octets \u00e9taient r\u00e9serv\u00e9s \u00e0 la fragmentation (ou segmentation, comme vous voulez !<\/em>).<\/p>\n Expliquons un peu mieux \u00e0 quoi servent ces octets :<\/p>\n Cela vous para\u00eet un peu n\u00e9buleux ? Pas clair ? La d\u00e9monstration par l’exemple sera sans doute plus efficace !<\/p>\n L’offset est en r\u00e9alit\u00e9 calcul\u00e9 en mot de 20 octets et non pas \u00e0 l’octet pr\u00eat ! Pour des raisons de simplification j’ai ci-dessous consid\u00e9r\u00e9 que l’on pouvait tron\u00e7onner par paquet de 1000 octets et que l’offset serait de 0, 1000, 2000, etc. alors que l’offset serait de 0, 50, 100, etc. La logique ci-dessous est donc correcte mais fausse dans ses valeurs d’offset. A vous de corriger pour vous entra\u00eener !<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Supposons que deux stations, A et B, \u00e9mettent des paquets vers un serveur S. Les paquets transitent \u00e0 travers un r\u00e9seau dans lequel il est n\u00e9cessaire de fragmenter les paquets d’origine qui sont trop volumineux pour passer sur un des supports du r\u00e9seau. Imaginons que les paquets de d\u00e9parts ont une taille de 4024 octets (4000 octets de donn\u00e9es et 24 octets d’ent\u00eate IP<\/em>). Dans le r\u00e9seau une MTU d’un support est limit\u00e9e \u00e0 1024 octets !<\/p>\n La station A \u00e9met deux paquets \u00e0 la suite pour S et la station B n’en \u00e9met qu’un ! Enfin, pour faire simple, apr\u00e8s l’endroit de fragmentation dans le r\u00e9seau, le s\u00e9quencement des paquets n’est pas respect\u00e9 suite \u00e0 une reconfiguration automatique du routage. Cela a eu pour effet d’envoyer les premiers paquets sur une route charg\u00e9e alors que les paquets suivants ont emprunt\u00e9 une route non charg\u00e9e. En cons\u00e9quence les paquets arrivent dans le d\u00e9sordre au serveur !<\/p>\n Question<\/strong> : Combien de fragment vont \u00eatre g\u00e9n\u00e9r\u00e9 par paquet de 4 000 octets \u00e9mis ?<\/p>\n R\u00e9ponse<\/strong> : Chaque fragment ne peut d\u00e9passer 1024 octets dont 24 octets d’en-t\u00eate, il v\u00e9hiculera donc 1 000 octets utiles. Comme le paquet d’origine fait 4024 octets dont 24 octets d’ent\u00eate, il a 4 000 octets utiles. Il faut donc 4000\/1000 fragments soit 4 fragments par paquet de 4024 octets. Comme il y a trois paquets \u00e9mis au total par A et B, le serveur recevra 12 paquets !<\/p>\n Emission de A<\/span><\/strong> :<\/p>\n A envoie son premier paquet PA1 <\/strong>vers S<\/strong>. Ce paquet fait 4024 octets, \u00e0 l’adresse IP source @IPA<\/strong> et l’adresse destination @IPS<\/strong> du serveur. Le paquet n’est pas fragment\u00e9, c’est le paquet originel donc MF(PA1) = 0<\/strong> et Offset(PA1) = 0<\/strong>. Un num\u00e9ro d’identification est fix\u00e9 ID(PA1) = 1000<\/strong>. La fragmentation est autoris\u00e9e donc DF(PA1) = 0<\/strong>.<\/p>\n Puis imm\u00e9diatement \u00e0 la suite A<\/strong> envoie son deuxi\u00e8me paquet PA2<\/strong> vers S<\/strong>. Ce paquet fait 4024 octets, \u00e0 l’adresse IP source @IPA<\/strong> et l’adresse destination @IPS<\/strong> du serveur. Le paquet n’est pas fragment\u00e9, c’est le paquet originel donc MF(PA2) = 0<\/strong> et Offset(PA2) = 0<\/strong>. Le num\u00e9ro d’identification est incr\u00e9ment\u00e9 car c’est le deuxi\u00e8me paquet \u00e0 destination de S, il est fix\u00e9 \u00e0 ID(PA2) = 1001<\/strong>. La fragmentation est autoris\u00e9e donc DF(PA2) = 0.<\/strong><\/p>\n Emission de B<\/strong> <\/span>:<\/p>\n Juste apr\u00e8s que A est envoy\u00e9 son premier paquet, et avant que A n’envoie son deuxi\u00e8me paquet, B \u00e9met son propre paquet<\/strong>. Elle \u00e9met PB1<\/strong> vers S<\/strong>. Ce paquet fait 4024 octets, \u00e0 l’adresse IP source @IPB<\/strong> et l’adresse destination @IPS<\/strong> du serveur. Le paquet n’est pas fragment\u00e9, c’est le paquet originel donc MF(PB1) = 0<\/strong> et Offset(PB1) = 0<\/strong>. Un num\u00e9ro d’identification est fix\u00e9 ID(PB1) = 1000<\/strong> (Je fais expr\u00e8s de prendre le m\u00eame que A, bien que les chances que cela se produise sont tr\u00e8s faibles, pour vous montrer que c’est pas grave !<\/em>). La fragmentation est autoris\u00e9e donc DF(PB1) = 0.<\/strong><\/p>\n Dans le r\u00e9seau une passerelle re\u00e7oit les paquets<\/strong> <\/span>dans l’ordre PA1<\/strong>, PB1<\/strong>, PA2<\/strong>, elle doit les fragmenter :<\/p>\n Fragmentation de PA1 :<\/span><\/strong><\/p>\n Fragmentation de PA2<\/span><\/strong>, le principe est le m\u00eame que pour PA1 :<\/p>\n Fragmentation de PB1<\/span><\/strong>, c’est le m\u00eame m\u00e9canisme ! Je vous laisse faire ?<\/p>\n Il y a donc 12 fragments \u00e9mis par la passerelle vers le serveur S. Sur le chemin, entre la passerelle et le serveur, une reconfiguration dynamique du routage a lieu apr\u00e8s le passage de F1PA1 \u00e0 F2PA2. Les fragments F3PA2 a F3PB1 sont \u00e9mis sur une route diff\u00e9rente, plus rapide. Le serveur re\u00e7oit donc dans l’ordre : F3PA2, F4PA2, F1PB1 \u00e0 F4PB1 puis F1PA1 \u00e0 F2PA2. Le quart\u00e9 dans le d\u00e9sordre !<\/p>\n R\u00e9assemblage des paquets par le serveur :<\/span><\/strong><\/p>\n Toute machine IP maintien des buffers m\u00e9moire dans lesquels elle stocke les paquets en attente de r\u00e9assemblage. La zone m\u00e9moire allou\u00e9e a une taille d\u00e9finie par la taille du paquet. Cette taille varie en fonction des fragments qui arrivent au fil de l’eau. Le d\u00e9but de la zone est marqu\u00e9 par le premier fragment, la fin de zone par le dernier fragment. Il y a une zone m\u00e9moire par couple ID-@SourceIP<\/strong>.<\/p>\n IMPORTANT<\/strong> <\/span>: La m\u00e9thode de gestion de l’allocation m\u00e9moire pr\u00e9sent\u00e9e ici est une supposition<\/strong>. Il n’existe, \u00e0 ma connaissance, pas de description normalis\u00e9e de ces op\u00e9rations. En cons\u00e9quence cette m\u00e9thode peut diff\u00e9rer d’une impl\u00e9mentation IP \u00e0 une autre. Quelle qu’elle soit pr\u00e9cis\u00e9ment, le principe est bien de stocker les fragments en tampon, jusqu’\u00e0 reconstitution compl\u00e9te du paquet originel.<\/p>\n Logique appliqu\u00e9e :<\/strong><\/p>\n Lorsque le serveur re\u00e7oit un paquet, il examine l’adresse source (on suppose que l’adresse destination a d\u00e9j\u00e0 \u00e9t\u00e9 valid\u00e9e), l’ID, l’offset et le bit MF :<\/p>\n Le serveur consid\u00e8re la file d’attente compl\u00e8te quand il a plac\u00e9 le premier et le dernier fragment ainsi que tous les fragments interm\u00e9diaires (v\u00e9rification de la valeur d’offset + longueur de chaque fragment). Il remonte alors la partie Data au protocole identifi\u00e9 par le champ Protocole de l’ent\u00eate IP du paquet originel reconstitu\u00e9.<\/p>\n S\u00e9quencement de reconstitution des paquets de A et B<\/strong> <\/span>:<\/p>\n Voil\u00e0 ! Tous les paquets ont \u00e9t\u00e9 reconstitu\u00e9s par le serveur ! Vous avez pu remarquer que c’\u00e9tait du travail n’est-ce-pas ? Pendant que le serveur g\u00e9re ces files il ne fait pas vraiment ce pour quoi il est pay\u00e9 (pas cher, c’est vrai !<\/em>).<\/p>\n REMARQUE<\/strong> : Nous ne traitons pas dans ce cours des interactions de ce m\u00e9canisme avec la couche TCP, mais pour information, sachez qu’en fait l’en-t\u00eate TCP (ou UDP) comportant par exemple les num\u00e9ros de ports sera v\u00e9hicul\u00e9e dans le dernier paquet (MF=0) avec les \u00e9ventuelles donn\u00e9es r\u00e9siduelles.<\/p>\n Il est \u00e9vident qu’il \u00e9tait imp\u00e9ratif d’inclure un m\u00e9canisme de fragmentation dans le protocole IP, notamment en raison du fait qu’il peut \u00eatre v\u00e9hicul\u00e9 dans diff\u00e9rents protocoles de couche 2, ne pr\u00e9sentant pas toujours les m\u00eames MTU. Cependant si on peut \u00e9viter de fragmenter c’est pr\u00e9f\u00e9rable. En effet :<\/p>\n Toutes ses raisons expliquent que l’on utilise tr\u00e8s rarement, pour ne pas dire jamais, la taille maximum du paquet IP. La majorit\u00e9 des stacks IP proposent des tailles standards comprises en 128 et 512, voir 1024 octets. La fragmentation est ainsi plus rarement employ\u00e9e et les buffers des stations sont moins sollicit\u00e9s.<\/p>\n Au chapitre 3, dans la description de l’ent\u00eate IP, nous avons pr\u00e9sent\u00e9 le champ TTL<\/strong> (T<\/strong>ime T<\/strong>o L<\/strong>ive). Ce champ, d\u00e9fini sur un octet, permet d’indiquer une dur\u00e9e de vie<\/strong> au datagramme \u00e9mis.<\/p>\n En effet, le mode non connect\u00e9, sans contr\u00f4le du s\u00e9quencement, ni reprise sur erreur du protocole IP, induit qu’un paquet peut \u00eatre supprim\u00e9 sans avertir qui que ce soit<\/strong>. Les principes de routage dynamique peuvent \u00e9galement conduire \u00e0 g\u00e9n\u00e9rer des boucles (momentan\u00e9ment, rassurez-vous !) dans le r\u00e9seau. Pour \u00e9viter qu’un paquet tourne ind\u00e9finiment dans le r\u00e9seau ou soit conserv\u00e9 en file d’attente ind\u00e9finiment, on lui donne une dur\u00e9e de vie par le champ TTL.<\/p>\n A l’\u00e9mission le TTL est g\u00e9n\u00e9ralement fix\u00e9 \u00e0 sa valeur maximum, soit 255<\/strong>.<\/p>\n Chaque fois que le paquet va traverser une passerelle, celle-ci d\u00e9cr\u00e9mente le TTL de 1<\/strong>. Donc en th\u00e9orie un paquet IP ne pourra jamais traverser plus de 255 routeurs ! C’est d\u00e9j\u00e0 bien suffisant ! Mais s’il \u00e9tait n\u00e9cessaire de d\u00e9passer cette limite on pourrait utiliser une astuce nomm\u00e9e : tunneling<\/strong> (mais ne nous \u00e9loignons pas du sujet ! Je peux pas tout vous dire ! Il faut laisser un peu de travail \u00e0 d’autres !<\/em>).<\/p>\n Lorsqu’une passerelle passe le TTL \u00e0 0, elle d\u00e9truit le paquet et \u00e9ventuellement envoie un paquet ICMP Time Exceded<\/strong> \u00e0 l’\u00e9metteur du paquet pour l’informer de sa destruction.<\/p>\n Lorsqu’une passerelle fragmente un paquet, tous les fragments partent avec la valeur du TTL d’arriv\u00e9e (paquet originel) moins 1<\/strong> !<\/p>\n Que se passe-t-il si une station de destination re\u00e7oit 3 fragments sur 4 ? Si le dernier fragment n’arrive jamais ? La station conserve-t-elle ind\u00e9finiment les 3 fragments re\u00e7us en zone m\u00e9moire tampon ? Vous imaginez bien que non !! Si cela se produit trop fr\u00e9quemment, elle risque de saturer ses buffers !<\/p>\n C’est pourquoi la station va continuer de d\u00e9cr\u00e9menter le TTL de l’ent\u00eate qu’elle a stock\u00e9 en d\u00e9but de zone m\u00e9moire. Cette ent\u00eate est celle du premier fragment re\u00e7u, donc le plus ancien en m\u00e9moire. Toutes les secondes elle d\u00e9cr\u00e9mente ce TTL<\/strong>. S’il atteint la valeur 0 avant que l’ensemble du paquet originel ait \u00e9t\u00e9 reconstitu\u00e9, l’ensemble de la file m\u00e9moire est effac\u00e9e !<\/p>\n La station pourra \u00e9galement retourner un ICMP Time Exceded \u00e0 l’\u00e9metteur pour l’informer de la destruction de son paquet !<\/p>\n Bien s\u00fbr, si le dernier fragment arrive apr\u00e8s la destruction de sa file (\u00e0 la bourre le fragment !), il sera stock\u00e9, comme pr\u00e9c\u00e9demment dans une nouvelle file, en attente des autres fragments, qui n’arriveront jamais puisqu’ils ont \u00e9t\u00e9 d\u00e9truit ! Mais \u00e0 expiration de son TTL, il sera \u00e9galement d\u00e9truit !<\/p>\n REMARQUE<\/strong> : Le principe de d\u00e9cr\u00e9mentation du TTL toutes les secondes est \u00e9galement appliqu\u00e9e dans les files d’attentes des passerelles. Tant qu’un paquet IP reste en m\u00e9moire (surcharge du lien de sortie, surcharge CPU, ou autres<\/em>), son TTL est d\u00e9cr\u00e9ment\u00e9. Cependant si vous avez souvent des paquets qui restent bloqu\u00e9s plus d’une seconde dans votre routeur, je vous conseille de revoir le dimensionnement de votre r\u00e9seau ! Une seconde de transfert dans une passerelle est un d\u00e9lai intol\u00e9rable ! Les moyennes accept\u00e9es sont plut\u00f4t de 2 milli-secondes !<\/p>\n Tout au long de ce chapitre nous avons constamment \u00e9voqu\u00e9 les op\u00e9rations de r\u00e9assemblage du paquet originel sur la station de destination du paquet. On aurait pu penser que le r\u00e9assemblage aurait \u00e9t\u00e9 effectu\u00e9 par un \u00e9quipement plus proche de la passerelle qui a r\u00e9alis\u00e9 la fragmentation, par exemple son voisin direct ! Pourquoi n’est-ce jamais le cas ?<\/p>\n Il y a deux bonnes raisons \u00e0 cela :<\/p>\n Nous en resterons l\u00e0, pour le chapitre de la fragmentation. Il y a encore sans doute beaucoup \u00e0 dire, mais nous avons \u00e9voqu\u00e9, je pense, l’essentiel !<\/p>\n Nous avons jusqu’ici d\u00e9crit les m\u00e9canismes majeurs du protocole IP :<\/p>\n Dans aucun des chapitres nous n’avons \u00e9voqu\u00e9 de contr\u00f4le d’erreur (hormis le checksum sur l’ent\u00eate<\/em>) ou de reprise sur erreur. Nous savons \u00e9galement qu’IP fonctionne en mode non connect\u00e9. En fait ![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S1P5I3.gif\")
<\/p>\nIP : un protocole en mode non connect\u00e9 !<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/NOCIRCUIT.gif\")
Mais avant d’\u00e9tudier la m\u00e9thode de fragmentation, il faut se rappeler un point important : IP est un protocole de niveau 3 en mode non connect\u00e9<\/strong>. Je vous invite \u00e0 r\u00e9viser cette notion dans le chapitre 8 du cours OSI.<\/p>\nFragmentation et en-t\u00eate IP<\/h2>\n
\n
\n
Comment \u00e7a marche ?<\/h2>\n
\n\n
\n \n ATTENTION !<\/span><\/h6>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Trois remarques sur la fragmentation<\/h2>\n
Si on peut l’\u00e9viter, tant mieux !<\/h3>\n
\n
L’influence du TTL<\/h3>\n
Pourquoi est-ce toujours la station de destination qui r\u00e9assemble ?<\/h3>\n
\n
\n
Conclusion du chapitre<\/h2>\n
\n