Die Fragmentierung ist nicht immer für alle oberen Ebenen unsichtbar. Einige frühe (und wahrscheinlich sogar aktuelle) TCP / IP-Stacks von Mikrocontrollern implementierten nicht die vollständigen Funktionen wie die Fragmentierungsbehandlung. Die Verwendung des Flags in dieser Situation würde sicherstellen, dass das Paket in seiner ursprünglichen Form angekommen ist, anstatt vieler Fragmente, die das andere Ende nicht verarbeiten konnte.
Außerdem müssen bei der Verwendung von UDP nicht alle Fragmente am Ziel ankommen. Fragmentierung bedeutet also, dass die Nachricht entweder ankommt oder nicht ankommt - es gibt keine Möglichkeit, dass nur ein Teil des UDP-Datagramms vorhanden ist erreiche das Ziel. Ich kann mich nicht erinnern, wie lange der TCP / IP-Stack auf unzusammengesetzten IP-Paketen festhielt, die auf fehlende Fragmente warteten, aber die Verwendung des DF-Flags bedeutete, dass während dieser Zeit keine unnötigen Ressourcen gebunden waren.
Schließlich können Sie es zum Testen des Verhaltens der Netzwerkinfrastruktur verwenden, z. B. was passiert, wenn Sie ein Paket erhalten, das größer ist als die maximale Übertragungseinheit (DF verhindert, dass das Paket fragmentiert wird, um sich durch das Loch zu quetschen).
Zusätzlich zu @ Pax's Antwort (oder vielleicht als Teil der Tests, die er erwähnt hat), die DP-Flagge wird auch in Pfad MTU Entdeckung
Es ist oft nützlich, eine Fragmentierung zu vermeiden, auch wenn Protokolle auf höherer Ebene theoretisch von der Mechanik isoliert sind, sie können dennoch die Konsequenzen "spüren". Wenn eine einzelne Anwendungsebene write()
für den Netzwerk-Socket fragmentiert wird, weil sie zu groß ist und eines der Fragmente im Netzwerk verloren geht, geht das gesamte IP-Paket verloren. Dies beeinflusst natürlich den Durchsatz.
Beachten Sie, dass es keinen Standard gibt, DF in C zu setzen. Unter Linux funktioniert dieser Code:
%Vor%aber nicht auf FreeBSD 6
Außerdem ist die Pfad-MTU-Erkennung im realen Internet äußerst unzuverlässig. Zu viele kaputte Firewalls und Middleboxes filtern ICMP "Paket zu groß" Nachrichten aus (hier ist eine gute Möglichkeit einen Kandidaten Netzwerkadministrator während eines Interviews zu testen: Bitten Sie ihn / sie zu pingen und er / sie wird wahrscheinlich komplett ICMP blockieren.) Siehe RFC 2923: "TCP-Probleme mit Path MTU Discovery"
Das ist der Grund, warum die IETF nun eine neue Möglichkeit zum Testen der MTU vorschlägt, ohne auf Path MTU Discovery zu setzen: RFC 4821: "Paketierung Layer Path MTU Discovery"
Tags und Links c c++ networking network-programming network-protocols