Je suis curieux de savoir où le bit "DF" des drapeaux IP "Do not Fragment" est utilisé. Comme la fragmentation est invisible pour les couches supérieures et elles ne s'en soucient pas trop.Où est utilisé le bit Do Not Fragment des drapeaux IP?
Je cherche aussi un exemple.
Merci beaucoup d'avance.
La fragmentation n'est pas toujours invisible pour toutes les couches supérieures. Certaines piles TCP/IP de microcontrôleurs précoces (et probablement même actuelles) n'ont pas implémenté toutes les fonctionnalités telles que la gestion de la fragmentation. L'utilisation du drapeau dans cette situation assurerait que le paquet est arrivé dans sa forme originale au lieu de beaucoup de fragments que l'autre extrémité ne pourrait pas manipuler. En outre, lors de l'utilisation de UDP, il n'est pas nécessaire que tous les fragments parviennent à la destination. Ainsi, empêcher la fragmentation signifie que le message arrive ou n'arrive pas - il n'y a aucune possibilité qu'un seul bit du datagramme UDP atteindra la destination. Je ne peux pas me rappeler combien de temps la pile TCP/IP s'est maintenue sur des paquets IP non assemblés en attente de fragments manquants, mais l'utilisation de l'indicateur DF signifiait qu'il n'y avait pas de ressources inutiles bloquées pendant ce temps. Enfin, vous pouvez l'utiliser pour tester le comportement de l'infrastructure réseau, par exemple, ce qui se passe lorsque vous obtenez un paquet plus grand que l'unité de transmission maximale (DF empêchera ce fragment d'être fragmenté pour «passer dans le trou»). .
En plus de @Pax's answer (ou peut-être dans le cadre du test qu'il a mentionné), le drapeau DP est également utilisé dans . C'est quand vous essayez de comprendre quel est le plus gros paquet qui peut être envoyé sans être fragmenté, pour un lien donné.
Il est souvent utile d'éviter la fragmentation, même si les protocoles de haut niveau sont en théorie isolés de la mécanique, ils peuvent encore "sentir" les conséquences. Si un seul niveau d'application write() sur la socket réseau finit par être fragmenté parce qu'il est trop volumineux et qu'un des fragments est perdu dans le réseau, le paquet IP entier sera perdu. Cela affecte bien sûr le débit. Pour cette raison, il est souvent souhaitable de connaître l'unité de transmission maximale , c'est-à-dire le plus grand paquet qui peut être envoyé à une destination sans être fragmenté. La découverte de chemin MTU est utilisée pour trouver cette taille, en définissant simplement le bit DF et en envoyant des paquets successivement plus grands jusqu'à ce que le réseau signale (plus de ICMP) une panne.
Prenez note qu'il n'y a aucun moyen standard pour définir DF C ce code fonctionne sur Linux,:
result = setsockopt(mysocket, IPPROTO_IP,
IP_MTU_DISCOVER, IP_PMTUDISC_DO, sizeof(int));
mais il ne sur FreeBSD 6
En outre, la détection du MTU est extrêmement peu fiable sur le vrai Internet. Trop de pare-feu cassés et de boîtiers de filtres filtrent les messages ICMP "Packet too big" (voici un bon moyen de tester un administrateur réseau candidat lors d'une interview: demandez lui d'arrêter ping et il/elle bloquera probablement complètement ICMP). RFC 2923: "problèmes TCP avec path MTU Discovery"
C'est la raison pour laquelle l'IETF suggère maintenant une nouvelle façon de tester la MTU, sans compter sur path MTU Discovery: RFC 4821: "Layer Packetization path MTU Discovery"
C'est très pratique à savoir. +1 – paxdiablo