OSI: Datensegment

Status
Für weitere Antworten geschlossen.

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Guten Tag

Ich habe folgendes auf Wikipedia gefunden:
Ein Datensegment ist ein Datagramm, das zur Datenkapselung im OSI-Modell auf der vierten Schicht (Transportschicht) verwendet wird. Ein Datensegment besteht aus Protokollelementen, die Schicht-4-Steuerungsinformationen enthalten. Als Adressierung wird dem Datensegment eine Schicht-4-Adresse vergeben, also ein Port. Das Datensegment wird in der Schicht 3 in ein Datenpaket gekapselt.

Quelle: Wikipedia

Auf diesen Satz möchte ich gerne genauer hinschauen: "Ein Datensegment besteht aus Protokollelementen, die Schicht-4-Steuerungsinformationen enthalten."

Was heisst das genau? Ich konnte für Datenframe und Paket anhand Raster sehen was darin in diesem Frame oder Paket genau inbegriffen ist. Im Datensegment fehlt das. Wie sieht den so ein Datensegment aus ich denke nicht das nur ein Port als Datensegment bezeichnet wird.



Liebe Grüsse
Nico
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Ja, wie ist das den? Beim Layer zuvor dem 3. wurde das Datenframe in Datenpaket gekapselt. Dann greift z. B das TCP auf dieses Datenpaket zu und entnimmt die Daten?

Werden die Datenpakete Segmentiert? Segmentierung = Aufteilung des Datenstroms also werden auch Frames, Pakete sowie Daten segmentiert?
Ein Datensegment besteht aus Protokollelementen, die Schicht-4-Steuerungsinformationen enthalten. Als Adressierung wird dem Datensegment eine Schicht-4-Adresse vergeben, also ein Port. Das Datensegment wird in der Schicht 3 in ein Datenpaket gekapselt.
Quelle:Wikipedia

Damit Daten über beliebige Stationen übertragen werden können, müssen die Übertragungspakete unterschiedliche Pakete haben. Diese Unterteilung nennt man Segmentierung.

Quelle Wikipedia

Von was ist hier die Rede von welchem Übertragungspaket? Im Datenpaket wird ja nicht z. B das TCP eingebettet oder? Die haben unterschiedliche Aufgaben.
Ich verstehe nicht genau was mit diesen Sätzen gemeint wird.

Das Datensegment wird in der Schicht 3 in ein Datenpaket gekapselt.
Wie ist das möglich? Ich sehe kein Feld mit einer Port-Adresse in einem Datenpaket, im TCP hingegen existiert das Feld (Source Port) + Destination Port. Verwechslung?
 
Zuletzt bearbeitet:

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Ja, wie ist das den? Beim Layer zuvor dem 3. wurde das Datenframe in Datenpaket gekapselt. Dann greift z. B das TCP auf dieses Datenpaket zu und entnimmt die Daten?

Werden die Datenpakete Segmentiert? Segmentierung = Aufteilung des Datenstroms also werden auch Frames, Pakete sowie Daten segmentiert?
Ein Frame (L2) kann nicht aufgeteilt werden. Der hat eine feste Maximalgröße (idR max. 1500 Bytes - das kann aber je nach Layer2-Protokoll und Tunnelling unterschiedlich sein). Ein IPv4-Paket (L3) kann fragmentiert werden, also sich über mehrere Frames erstrecken. Das wird aber heutzutage duch PTMU-Discovery effektiv verhindert. Bei IPv6 gibts gar keine Fragemtierung mehr. Ein TCP Segment muss in ein IP-Paket passen.

Einen Exkurs in andere Protokolle spare ich mir, TCP/IP hat sich als De-Facto-Standard durchgesetzt und andere Protokollstacks gibs eigentlich nur noch in legacy-Installationen. Das OSI-Modell ist auch nicht so richtig prickeld um TCP/IP zu beschreiben, weil es sich nicht 1:1 auf TCP/IP abbilden lässt. Die OSI-Protokollsuite selbst ist ja hoffentlich vollständig vom Erdball verschwunden.

Von was ist hier die Rede von welchem Übertragungspaket? Im Datenpaket wird ja nicht z. B das TCP eingebettet oder?
Doch, natürlich. Ein TCP-Segment ist ein ein IP-Paket gekapselt. Sonst würde es ja nicht ankommen.

Wie ist das möglich? Ich sehe kein Feld mit einer Port-Adresse in einem Datenpaket, im TCP hingegen existiert das Feld (Source Port) + Destination Port. Verwechslung?
Den TCP-Header kannst Du Dir hier angucken. Der steht vor den Nutzdaten und ist ins IP-Paket ("Datenpaket") eingekapselt. Also TCP-Header+Payload sind genau die Payload vom IP-Paket (welches wiederum die Daten des L2-Frames repräsentiert).

Das würde für andere L3 und L4 Protokolle sinngemäß auch gelten, ist aber wie gesagt derzeit eher akademisch.
 

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Ein Frame (L2) kann nicht aufgeteilt werden. Der hat eine feste Maximalgröße (idR max. 1500 Bytes - das kann aber je nach Layer2-Protokoll und Tunnelling unterschiedlich sein). Ein IPv4-Paket (L3) kann fragmentiert werden, also sich über mehrere Frames erstrecken. Das wird aber heutzutage duch PTMU-Discovery effektiv verhindert. Bei IPv6 gibts gar keine Fragemtierung mehr. Ein TCP Segment muss in ein IP-Paket passen.

Einen Exkurs in andere Protokolle spare ich mir, TCP/IP hat sich als De-Facto-Standard durchgesetzt und andere Protokollstacks gibs eigentlich nur noch in legacy-Installationen. Das OSI-Modell ist auch nicht so richtig prickeld um TCP/IP zu beschreiben, weil es sich nicht 1:1 auf TCP/IP abbilden lässt. Die OSI-Protokollsuite selbst ist ja hoffentlich vollständig vom Erdball verschwunden.
Verstehe ich nicht ganz, also ist es möglich das ein Datenpaket mit einem verkapselten Datensegment in mehrere Frames muss?
Die Frames sind meistens kleiner als Datenpakete oder? Aber im Normalfall wenn ich z. B Google.de öffne beginnt das Prozedere bei Layer 1 und endet bei Layer 7 wofür muss also ein Datenpaket mit Datagramm platz in einem Dateframe haben?


Den TCP-Header kannst Du Dir hier angucken. Der steht vor den Nutzdaten und ist ins IP-Paket ("Datenpaket") eingekapselt. Das würde für andere L3 und L4 Protokolle sinngemäß auch gelten, ist aber wie gesagt derzeit eher akademisch.
Also ist der Inhalt (Body) eines IP-Datenpaket IMMER das Datensegment (Header+Payload)?


Also TCP-Header+Payload sind genau die Payload vom IP-Paket (welches wiederum die Daten des L2-Frames repräsentiert).
Also wie sieht das den aus? Also ist wiederrum der Payload von Datenframe der Header+Payload vom TCP?
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Verstehe ich nicht ganz, also ist es möglich das ein Datenpaket mit einem verkapselten Datensegment in mehrere Frames muss?
Genau so ist das. Das IP-Datenpaket (incl. Payload natürlich) wird dann fragmentiert und bekommt nur im ersten Frame einen vollen IP-Header, in den weiteren Paketen einen Teilheader mit der restlichen Payload. Details in Fachbüchern oder RFCs.

Die Frames sind meistens kleiner als Datenpakete oder? Aber im Normalfall wenn ich z. B Google.de öffne beginnt das Prozedere bei Layer 1 und endet bei Layer 7 wofür muss also ein Datenpaket mit Datagramm platz in einem Dateframe haben?
Ein Frame ist immer genau so groß, dass das Datenpaket und der Frame-Header reinpasst (ausser bei synchronen L2-Protokollen, da spricht man aber von Zellen - die sind immer gleich groß und werden dann mit Padding-Bits, idr Nullen aufgefüllt).

Und der Datentransfer beginnt bei L7 und vom sendenden System wird dann alles ineinander eingepackt bis man bei L2 ist - der Frame wird dann der Netzwerkkarte übergeben und dort vom PHY-Teil in L1 verwandelt (also Elektrik bzw. Optik). Bei jedem Router geht das Spiel von L1-L3 weiter. Das L3 Paket wird dann ausgepackt damit der Router eine Routingentscheidung treffen kann und an der richtigen Ausgangsschnittstelle wieder in einen neuen Frame gepackt und weitergeschickt (Performanceoptimierungen wie L3- oder gar L7-Switching lasse ich mal aussen vor, das ändert nichts am Prinzip). Erst im Zielsystem wird dann wieder alles ausgepackt (ist zwar de fakto bei solchen Großservices wie google auch nicht ganz richtig, weil oft schon ein Content Switch/Loadbalancer das ganze Paket auspackt aber vom Prinzip her schon richtig).

Also ist der Inhalt (Body) eines IP-Datenpaket IMMER das Datensegment (Header+Payload)?
Korrekt. Das ist ja genau das Grundprinzip des Schichtenmodells: Jede Dateneinheit einer Schicht wird in die Dateneinheit der darunterliegenden Schicht eingepackt.

Also wie sieht das den aus? Also ist wiederrum der Payload von Datenframe der Header+Payload vom TCP?
Korrekt. Das ist z.B. auf Fig 1-3 dieser Seite visualisiert.

Ich empfehle, falls Dich das alles interessiert, zwei zwar etwas betagte, aber immer noch sehr gute Bücher (ja richtig aus totem Baum und so). TCP/IP-Spezifisch und dort in die Tiefe gehend "TCP/IP Illustrated" von W. Richard Stevens. Das mit großem Abstand beste Buch in diesem Bereich - da schon fast 20 Jahre alt leider nur IPv4 und ohne aktuelle Neuerungen. Für eine etwas allgemeinere Betrachtungsweise von Andrew S. Tanenbaum "Computer Networks". Das gibt es glaube ich auch in einer deutschen Übersetzung.

Lass die Finger von Büchern, die heute noch von "Class-A, B und C-Netzen" faseln. Die gibt es seit über 20 Jahren nicht mehr und die Autoren haben offensichtlich nur von alten Büchern abgeschrieben ohne selbst eine Peilung von TCP/IP zu haben. In den aktuellen Cisco-Schulungsunterlagen werden Classful-Netze zwar tatsächlich auch noch behandelt, aber auch nur deshalb, weil man Cisco-Equipment noch für Classful-Netze einstellen kann und die Besonderheiten von Classful-Routing betont werden. Das funktioniert nämlich in vielen Bereichen völlig anders als das heute übliche Classless-Routing.
 

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Hallo

Lange her aber sollte kein Problem sein.

Genau so ist das. Das IP-Datenpaket (incl. Payload natürlich) wird dann fragmentiert und bekommt nur im ersten Frame einen vollen IP-Header, in den weiteren Paketen einen Teilheader mit der restlichen Payload. Details in Fachbüchern oder RFCs.

Was heisst vollen IP-Header also der Header der vorherigen Schichten nehme ich an? Alle diese sind im ersten Frame? Was heisst Teilheader welcher Teil? Ich bin davon ausgegangen, dass das Datenpaket in kleine Frame fragmentiert wird und dabei der Header immer gleich bleibt nur der Payload wird halt aufgeteilt damit halt die Grösse nicht überschritten wird. Payload ist ja der grösste Teil eines Datenpakets oder Frames oder allgemein. Wie geht das ?


Ein Frame ist immer genau so groß, dass das Datenpaket und der Frame-Header reinpasst (ausser bei synchronen L2-Protokollen, da spricht man aber von Zellen - die sind immer gleich groß und werden dann mit Padding-Bits, idr Nullen aufgefüllt).

Aber ein Frame ist doch kleiner als ein Datenpaket darum gibt es doch die Fragmentierung. Was meinst du den genau damit ?


---


Und der Datentransfer beginnt bei L7 und vom sendenden System wird dann alles ineinander eingepackt bis man bei L2 ist - der Frame wird dann der Netzwerkkarte übergeben und dort vom PHY-Teil in L1 verwandelt (also Elektrik bzw. Optik).

Das hier ist die Kapselung oder? Also wenn ich Google öffne beginnt der Server mit mir ab L7 bis zu L1 zu kommunizieren? Aber Google muss doch zuerst wissen wer Fragt damit er Antworten kann.

Bei jedem Router geht das Spiel von L1-L3 weiter. Das L3 Paket wird dann ausgepackt damit der Router eine Routingentscheidung treffen kann und an der richtigen Ausgangsschnittstelle wieder in einen neuen Frame gepackt und weitergeschickt (Performanceoptimierungen wie L3- oder gar L7-Switching lasse ich mal aussen vor, das ändert nichts am Prinzip). Erst im Zielsystem wird dann wieder alles ausgepackt (ist zwar de fakto bei solchen Großservices wie google auch nicht ganz richtig, weil oft schon ein Content Switch/Loadbalancer das ganze Paket auspackt aber vom Prinzip her schon richtig).

Verstehe ich nicht ganz. Anhand der Beispiele wer beginnt zu senden ich oder Google. Doch ich weil Ich etwas von Google will und er gibt mir es dann. Also beginn ich doch bei L1 zu L7 (senden). Oder wie geht das?
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Ich empfehle Dir dringend ein gutes Buch zu kaufen, wenn Du das verstehen willst (z.B. TCP/IP Illustrated von W.Richard Stevens). Du bringts hier wirklich alles durcheinander und hast offenbar noch nicht mal die Grundkonzepte verstanden. In diesem Stadium ergibt es noch keinen Sinn, konkrete Fragen zu stellen. Wenn Du mal einen TCP/IP Kurs durchgearbeitet hast und dann noch Fragen hast, kannst Du es hier nochmal versuchen.

Viel Erfolg!
 

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Habe mich doch informiert über Wikipedia und anderen Quellen. Beantworte mir doch bitte die Fragen...
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Sorry, aber Deine Fragen zeigen, dass Dir das allergrundlegendste Verständnis fehlt. Wenn Du z.B. sagst "ein Frame ist doch kleiner als ein Datenpaket" dann hast Du überhaupt nicht kapiert, was da eigentlich vor sich geht. Wie willst Du ein Datenpaket in einen Frame packen, der zu klein dafür ist? Und "wenn ich google öffne" - da werden zig Pakete an unterschiedliche Hosts geschickt bevor zum ersten Mal Daten zurückkommen. Das alles zu erklären ist zuviel für einen Forumspost. Da brauchts einen Kurs dafür.
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Alleine die richtige Benennung ist sehr wichtig, denn "Nutzdaten", "Header" usw. haben in den Schichten teils abweichende Namen.
Ich verweise mal auf folgendes:
http://stackoverflow.com/questions/...-units-fragment-segment-packet-frame-datagram
Das ist aber auch bei weitem keine vollständige Liste (sondern bezieht sich ausschließlich auf die Frage welche dort eingangs gestellt wird). So hart das sein mag, aber ich gebe schmadde absolut recht. Rein aus Internetquellen, insbesondere Wikipedia, ist das Thema kaum zu durchsteigen.

MfG Matthieu
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Alleine die richtige Benennung ist sehr wichtig, denn "Nutzdaten", "Header" usw. haben in den Schichten teils abweichende Namen.
Ich verweise mal auf folgendes:
http://stackoverflow.com/questions/...-units-fragment-segment-packet-frame-datagram
Das würde ich jetzt nicht unbedingt als Referenz heranziehen. Die Nomenklatur ist tatsächlich nicht ganz so standardisiert, wie man denken würde. Einzig "Frame" für ein Layer 2 Datenhäppchen (oder wie sagt man für "Protocol Data Unit" auf Deutsch?) und "Packet" für eine Layer 3 PDU ist universell gebräuchlich. "Segment" ist für eine TCP PDU der offizielle Terminus, dann wirds schwierig.

Fragmentierung würde ich übrigens mal gar nicht erst versuchen zu verstehen, das wird heute eh nicht mehr gemacht und bei IPv6 ist es gar nicht erst vorgesehen. Das haben ganz ganz früher Router mal gemacht, als die WAN-Leitungen noch langsam waren und verschiedenst MTUs gebräuchlich.
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Fragmentierung würde ich übrigens mal gar nicht erst versuchen zu verstehen, das wird heute eh nicht mehr gemacht und bei IPv6 ist es gar nicht erst vorgesehen.
Fragment Header? Siehe RFC 2460, 4.5
Die ganzen Extension Header sind ja einer der großen Benefits von IPv6 (gibt noch deutlich mehr als in der 2460 spezifiziert, weil dafür teilweise eigene RFCs bestehen) - würden sie nicht von Middleboxes teilweise wieder verworfen oder gar unterbunden.

Das mit der Namensgebung ist mir noch gar nicht aufgefallen. Ich bin bisher immer davon ausgegangen, dass es entsprechend auch in den Standards auftaucht, aber bei IPv6 bspw. taucht nur "packet" auf. Der Nutzdatenteil heißt da schlicht "payload".

MfG Matthieu
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Stimmt, das hatte ich ganz vergessen. Aber das ist schon was anderes, weil hier die Fragmentierung nicht von dem Router am Übergang zu Netzen mit kleinerer MTU gemacht wird, sondern vom sendenden Host. Und dort ergibt das nun überhaupt keinen Sinn. In Sektion 5 dieses RFC steht auch explizit drin, dass Fragmentierung bei IPv6 nicht erwünscht ist.
 
Zuletzt bearbeitet:

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Empfohlen wird stattdessen die vorherige Ermittlung der Maximum Path MTU lt. RFC 1981. Dann kann die Applikation Pakete generieren, welche zwischen 1280 und der ermittelten Path MTU liegt. Bei Anwendungen mit hohen Anforderungen an Performance, halte ich eine Optimierung der Paketgrößen schon heute für absolut notwendig.
Ich muss da immer an die 1492 Byte bei PPP denken. Das schönste Beispiel für die Bedeutung von gut gewählten Paketgrößen/MTUs. Damit kann man sich die Performance jedes heimschen DSL-Anschlusses ruinieren.

MfG Matthieu
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
PMTUD ist seit 20 Jahren Standard! Ich kann mich noch erinnern, als wir von SunOS4 auf Solaris umgestellt haben und dann Riesenprobleme bekommen haben bei der Kommunikation zwischen FDDI (MTU 4.500) und Ethernet (MTU 1.500). Damals war PMTUD noch relativ neu. Heute macht das jedes ernstzunehmende OS.
 

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Oh da habe ich wohl was falsch verstanden:

"
Da ein IP-Paket 64 kB groß sein kann, würde es nicht in einen Datenframe passen. Deshalb wird ein IP-Paket vor der Übertragung zur Schicht 2 so zerlegt, dass es in einen Datenframe passt. Diese Zerlegung wird Fragmentierung genannt
" Quelle: Wikipedia.org

Will doch nicht viel wissen sondern nur das wo ich gefragt habe.
 

schmadde

Benutzer
Mitglied seit
15. Jan 2011
Beiträge
253
Punkte für Reaktionen
6
Punkte
18
Das ist so wie es dasteht Quatsch. Wo genau steht denn das (Link)? Ein IP-Paket kann 64kB groß sein, das ist richtig und wenn es nicht in den Frame passt wird es fragmentiert. Das passiert aber unterwegs, wenn das Paket längst losgeschickt wird bei irgendeinem Router wenn in ein Netz weitergeleitet wird, dessen MTU kleiner ist als das Paket.

Man könnte zwar auf dem Host auch fragmentieren, aber das ergibt keinen Sinn. Da packt man lieber gleich kleinere Pakete. In den Fällen wo Pakete zu groß sind (z.B. UDP) hat jemand was falsch gemacht...
 

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Das ist so wie es dasteht Quatsch. Wo genau steht denn das (Link)? Ein IP-Paket kann 64kB groß sein, das ist richtig und wenn es nicht in den Frame passt wird es fragmentiert. Das passiert aber unterwegs, wenn das Paket längst losgeschickt wird bei irgendeinem Router wenn in ein Netz weitergeleitet wird, dessen MTU kleiner ist als das Paket.

Man könnte zwar auf dem Host auch fragmentieren, aber das ergibt keinen Sinn. Da packt man lieber gleich kleinere Pakete. In den Fällen wo Pakete zu groß sind (z.B. UDP) hat jemand was falsch gemacht...

Immerhin eine kleine Neuigkeit - etwas mehr an Informationen.

Ich such mir ein anderes Forum. Danke trotzdem für die Hilfe...

Danke.
 

schwiz19

Benutzer
Mitglied seit
16. Sep 2012
Beiträge
39
Punkte für Reaktionen
0
Punkte
0
Sorry, aber Deine Fragen zeigen, dass Dir das allergrundlegendste Verständnis fehlt. Wenn Du z.B. sagst "ein Frame ist doch kleiner als ein Datenpaket" dann hast Du überhaupt nicht kapiert, was da eigentlich vor sich geht. Wie willst Du ein Datenpaket in einen Frame packen, der zu klein dafür ist? Und "wenn ich google öffne" - da werden zig Pakete an unterschiedliche Hosts geschickt bevor zum ersten Mal Daten zurückkommen. Das alles zu erklären ist zuviel für einen Forumspost. Da brauchts einen Kurs dafür.

Es steht doch deutlich bei Wikipedia:

Da ein IP-Paket 64 kB groß sein kann, würde es nicht in einen Datenframe passen. Deshalb wird ein IP-Paket vor der Übertragung zur Schicht 2 so zerlegt, dass es in einen Datenframe passt. Diese Zerlegung wird Fragmentierung genannt.
Quelle: wikiped.org

Zudem kann ein Datenpakets bis zu 65535 bytes an Daten enthalten der Body eines Datenframes nur einige Tausend (1500 Byte).... Oder lese ich falsch?
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat