it-swarm.com.de

IP-Fragmentierung und -Reassembly

Ich gehe gerade durch meine Netzwerkfolien und habe mich gefragt, ob mir jemand beim Konzept der Fragmentierung und des Wiederaufbaus helfen könnte.

enter image description here

Ich verstehe, wie es funktioniert, nämlich wie Datagramme in kleinere Blöcke aufgeteilt werden, da Netzwerkverbindungen eine MTU haben. Das Beispiel auf dem Bild verwirrt mich jedoch.

Die ersten beiden Abschnitte zeigen also eine Länge von 1500, weil dies die MSU ist, aber sollte das nicht heißen, dass der letzte 1000 (für insgesamt 4000 Bytes) und nicht 1040 haben sollte? Woher kommen diese zusätzlichen 40 Bytes? Meine Vermutung ist, dass, weil die beiden vorherigen Fragmente einen Header von 20 Bytes hatten, diese zusätzlichen 40 Bytes Daten benötigt wurden, um irgendwo hin zu gehen, also werden sie im letzten Fragment ankommen?

Fragflag bedeutet im Wesentlichen, dass es ein anderes Fragment gibt, daher haben alle ein Fragflag von 1, mit Ausnahme des letzten Fragments, das bei Null liegt. Ich verstehe jedoch nicht, was der Versatz ist oder wie er berechnet wird. Warum ist der erste Versatz Null? Warum haben wir die Bytes im Datenfeld (1480) durch 8 dividiert, um den zweiten Offset zu erhalten? Woher kommen diese 8? Abgesehen davon gehe ich davon aus, dass jeder Versatz nur um diesen Wert zunimmt.

Zum Beispiel hat das erste Fragment einen Versatz von 0, das zweite 185, das dritte 370 und das vierte 555? (370 + 185)

Danke für jede Hilfe!

19
JimmyK

In jedem Paket befindet sich ein 20-Byte-Header. Das Originalpaket enthält also 3.980 Byte Daten. Die Fragmente enthalten 1480, 1480 und 1020 Bytes Daten. 1480 + 1480 + 1020 = 3980

Jedes Bit in der Kopfzeile ist wertvoll. Wenn der Versatz durch 8 geteilt wird, kann er in 13 Bits anstelle von 16 eingefügt werden. Dies bedeutet, dass jedes Paket, aber das letzte eine Anzahl von Datenbytes enthalten muss, die ein Vielfaches von 8 ist.

16
David Schwartz

Die Fragmentierung und Wiedereinbau wurde ausschließlich in RFC 791 erläutert. Gehen Sie durch die Internet Protocol Specification RFC . Der RFC enthält verschiedene Abschnitte, in denen die Fragmentierung und der Zusammenbau der Proben erläutert werden. Alle Ihre Zweifel und Fragen sind gut darauf abgestimmt. 

Ans 1: Über die Länge des Pakets: Das ursprüngliche Paket enthält 4000 Bytes. Dieses Paket ist ein vollständiges IP-Paket und enthält daher auch den IP-Header. Somit ist die Nutzlastlänge tatsächlich 4000 - (IP-Header-Länge d. H. 20). 

Tatsächliche Nutzlastlänge = 4000 - 20 = 3980 

Jetzt ist das Paket fragmentiert, da die Länge größer ist als die MTU (1500 Bytes).

Somit enthält das 1. Paket 1500 Bytes, einschließlich IP-Header + Payload-Bruch. 

1500 = 20 (IP-Header) + 1480 (Datennutzlast) 

Ähnlich für das andere Paket. 

Das dritte Paket enthält verbleibende Restdaten (3980 - 1480 - 1480) = 1020

Die Länge des Pakets beträgt also 20 (IP-Header) + 1020 (Nutzlast) = 1040 

Ans 2: Der Offset ist die Adresse oder der Locator, von dem aus die Daten mit Bezug auf die ursprüngliche Datennutzlast beginnen. Für IP umfasst die Datennutzlast alle Daten, die nach dem IP-Header und dem Options-Header liegen. Somit nimmt das System/der Router die Nutzlast und teilt sie in kleinere Teile auf und verfolgt den Versatz in Bezug auf das ursprüngliche Paket, so dass der Zusammenbau möglich ist. 

Wie im RFC Seite 12 angegeben. 

"Das Fragmentoffsetfeld teilt dem Empfänger die Position eines Fragments im ursprünglichen Datagramm mit. Der Fragmentoffset und die Länge bestimmen den Teil des ursprünglichen Datagramms , Das von diesem Fragment abgedeckt wird ) das letzte Fragment. Diese Felder enthalten ausreichende Informationen, um Datagramme wieder zusammenzusetzen. "

Der Fragmentversatz wird in Einheiten von jeweils 8 Byte gemessen. Es hat ein 13-Bit-Feld im IP-Header. Wie auf der RFC-Seite 17 erwähnt 

"Dieses Feld gibt an, wohin dieses Fragment im Datagramm gehört. Der Fragmentversatz wird in Einheiten von 8 Oktetten (64 Bits) gemessen. Das erste Fragment hat einen Offset von Null."

Wie Sie in der Frage gefragt haben, woher diese 8 stammt, ist dies der Standard, der für die IP-Protokollspezifikation definiert wurde, wobei 8 Oktette als ein Wert verwendet werden. Dies hilft uns auch dabei, große Pakete zu übertragen. 

Seite 28 des RFC schreibt: * Fragmente werden in Einheiten von 8 Oktetten gezählt. Die Fragmentierungsstrategie ist so ausgelegt, dass ein nicht-fragmentiertes Datagramm alle Informationen zur Fragmentierung ohne Null enthält (MF = 0, Fragmentversatz = 0). Wenn ein Internet-Datagramm fragmentiert ist, muss sein Datenteil An 8-Oktett-Grenzen gebrochen sein. Dieses Format erlaubt 2 ** 13 = 8192 Fragmente von jeweils 8 Oktetten für insgesamt 65.536 Oktette. Beachten Sie, dass dies mit dem Feld Gesamtlänge von Datagram übereinstimmt (natürlich wird der Header in der Gesamtlänge von gezählt und nicht in den Fragmenten). *

15
Ankan Seth

die Offsetgröße beträgt 13 Bit im IP-Header, aber im schlimmsten Fall benötigen wir 16 Bit. Wir verwenden also einen Skalierungsfaktor von 8, d. H. (2 ^ 16/2 ^ 13).

1
pallavi

dies sind keine zusätzlichen Bits, sondern die Gesamtlänge des letzten Fragments. Da 1500 MTU bedeutet, können 1500 Byte Daten in einem Fragment enthalten sein, einschließlich Header. Der Header wird mit jedem Fragment angehängt. Dies bedeutet in Fragment, dass wir in der Lage sind, 1500-20 = 1480 Byte Daten zu senden. Es wird angegeben, dass 4000B Datagramm vorhanden ist .Datagram ist nichts anderes als eine Paketkapselung von Daten auf Netzwerkebene. Die Gesamtzahl der zu sendenden Daten beträgt also 4000-20 = 3980. dann wird es in 3 Teile (Ceil (3980/1480)) mit jeweils einer Länge von 1480, 1480, 1020 fragmentiert. Wenn also der 20B-Header an das letzte Fragment angehängt wird, wird seine Länge 1020 + 20 = 1040. 

0
codie