Netzwerk-Verständnissfrage: TCP Segmentierung vs IP Fragmentierung?
-
Hallo
TCP hat einen Segmentierungs-Mechanismus, d.h. große Blöcke werden auf mehrere Pakete aufgeteilt und am anderen Ende (für die Anwendungsschicht transparent) wieder zusammengefügt.
Wozu besteht nun der Unterschied zur Fragmentierung von IP, die auch große Pakete in kleinere zerlegt und wieder zusammenfügt.
Redundant oder verschiedene Anwendungsbereiche??
-
hi,
ich hab mir grad nur kurz den Headeraufbau von eines TCP Packets reingezogen (RFC793 unter 3.1) und kann keinen Segmentierungsmechanismus erkennen. Meinst du vllt die SequenceID mit Segmentierung. Die ist imho aber nur dazu da, um ein Packet eindeutig in Reihenfolge zu anderen bereits davor/danach eingegangenen/gehenden Packeten zu bringen.
-
Hmm, vielleicht verwechsel ich da was.
Hier
http://de.wikipedia.org/wiki/Transmission_Control_Protocol
steht eben:Aufteilen der Anwendungsdaten auf TCP/IP-Pakete
Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der MSS. Die Anwendung, die Daten versenden möchte, beispielsweise ein Webserver, legt zum Beispiel einen 10 Kilobyte großen Datenblock im Buffer ab. Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden? Ganz einfach, man teilt die Daten auf mehrere Pakete auf, fügt einen TCP-Header hinzu und versendet die TCP-Segmente, der Vorgang heißt Segmentierung. [...]
Die Problematik, die mit dem "1460 Byte großen Nutzdatenfeld" angesprochen wird läuft für mich aber ganz klar auf IP-Fragmentierung hinaus, deshalb die Verwirrung.
-
Hi,
bei IP heisst das MTU (Maximum Transfer Unit) und bei TCP MSS (Maximum Segment Size). Der Zusammenhang wird evtl. hier klar:
http://www.tcpipguide.com/free/t_TCPMaximumSegmentSizeMSSandRelationshiptoIPDatagra.htmUnd evtl. hier:
http://www.elektronik-kompendium.de/sites/net/0812211.htm
http://www.tweakmaster.com/kb/qa0041.php
-
Die einzelnen Begriffe sind mir durchaus klar.
Ich versteh auch, dass man für praktische Implementierungs-Zwecke für TCP ein MSS definiert.
Der Zusammenhang wird aber auch hier nicht erklärt.
Ich wär ja auch glücklich wenn es da gar keinen Zusammenhang geben würde!
Aber im letzten Link kommt dann wieder das Unbehagen:
"[...] MSS which is normally MTU-40 bytes."Wieso soll/muss MSS = MTU-40 sein???
TCP kann es doch völlig Wurst sein wie gross die MTU ist. Fragmentierung ist doch Sache von IP!
-
Naja, obwohl TCP und IP auf unterschiedlichen OSI-Schichten liegen, sind die beiden wohl fester "verdrahtet" als Du dachtest...
-
die mss gibt es, damit tcp ein komplettes paket (segment) einschliesslich tcp-header versenden kann. die vermittlungsschicht hat meistens eine begrenzte paketgrösse (bei ethernet z.b. 1536 bytes). die darf tcp nicht überschreiten, deshalb wird bei der verbindungsaufnahme die mss-option ausgetauscht. ansonsten könnte tcp z.b. 64kbyte grosse pakete erzeugen, die könnte man zwar mit ip-fragmentierung wieder klein kriegen, hätte dann aber nur einen tcp-header im ersten paket d.h. tcp müsste alles wegschmeissen, wenn ein fehler drin ist. je unzuverlässiger das medium, desto kleiner wird die mss gewählt. bei modemverbindungen z.b. sind das nicht selten 512 oder nur 256 bytes.
-
[...] je unzuverlässiger das medium, desto kleiner wird die mss gewählt.
Ok, das Argument nehm ich als Daseinsberechtigung für die mss an.
[...] die vermittlungsschicht hat meistens eine begrenzte paketgrösse (bei ethernet z.b. 1536 bytes).
Das nicht!
(s.o.)
Naja, letztlich läuft es wohl auf praktische/Performance-Gründe hinaus (das was von Sgt.Nukem angesprochen wurde)
Ok, Danke an alle.
-
scrontch schrieb:
[...] je unzuverlässiger das medium, desto kleiner wird die mss gewählt.
Ok, das Argument nehm ich als Daseinsberechtigung für die mss an.
[...] die vermittlungsschicht hat meistens eine begrenzte paketgrösse (bei ethernet z.b. 1536 bytes).
Das nicht!
(s.o.)
Naja, letztlich läuft es wohl auf praktische/Performance-Gründe hinaus (das was von Sgt.Nukem angesprochen wurde)
Ok, Danke an alle.Vor allem (IMHO) wohl eher, daß TCP/IP & Co. stinkend alt sind und kurz nach der Christenverfolgung entwickelt wurden, lange bevor OSI und Co. lustige idealisierte Modelle entwickelten, wie es SEIN SOLLTE...
Ich denke doch mal, Du willst einfach darauf hinaus, daß keine strenge Schichtentrennung bei TCP/IP stattfindet, so wie Du es über OSI gelernt hast...
Vielleicht macht Dich das was schlauer:
<a href= schrieb:
TCP/IP bei Wikipedia">Protokollstapel
Historisch bedingt sind die Protokolle der Internet-Protokoll-Familie nicht nach dem heute üblichen ISO-OSI-Referenzmodell aufgebaut. Um trotzdem die Schichtung der einzelnen Protokolle übersichtlich zu beschreiben, greift man daher auf ein eigenes Referenzmodell, das TCP/IP-Referenzmodell, zurück. Dieses Modell ist gröber, weniger streng geschichtet und erlaubt den Zugriff von einzelnen Schichten auf beliebige andere, auch höhere Schichten, was allerdings eine eindeutige Einordnung in Schichten für einige Protokolle unmöglich macht.
Beispiele für solche schwer einzuordnenden Protokolle sind:
* BGP, ein Routing-Protokoll und der Aufgabe nach eindeutig der Netzschicht zuzuordnen, benutzt zum Transport von Daten das Protokoll TCP der Transportschicht
* ICMP, ein Protokoll, mithilfe dessen IP Steuerinformationen austauscht, benutzt selbst wieder IP Pakete zum Transport der Daten
-
Die an einer TCP-Verbindung beteiligten Endpunkte können nicht wissen, wie hoch die maximale Paketgröße der Vermittlungsschicht ist. Erstens würde das der Schichtentrennung widersprechen, das ist aber nicht wirklich das Problem, zweitens können sie die Route, die die Pakete nehmen, nicht wissen und drittens ist diese Route auch noch variabel, d.h. für jedes Segment gelten potentiell unterschiedliche MTUs. Schick ein Segment über eine Route, in der Brieftauben sitzen, die nur 100 Bytes auf einmal tragen können ...
Segmentierung muss schlicht und einfach deshalb gemacht werden, weil TCP nach oben hin ein Stream ist und nach unten auf einer paketbasierten Vermittlungsschicht aufsetzt. Fragmentierung muss dagegen gemacht werden, wenn ein solches Paket durch eine Leitung (Schicht 2) muss, die solche großen Frames nicht unterstützt.
Die Kopplung der beiden Größen aneinander geschieht aus praktischen Erwägungen, weil die meisten Verbindungen im Internet Ethernet o.ä. mit ähnlicher MTU sind, auf Brieftauben und Bongotrommeln wird nicht gesondert Rücksicht genommen
-
Bashar schrieb:
auf Brieftauben und Bongotrommeln wird nicht gesondert Rücksicht genommen
...was ich sehr schade finde, da beides arschgeile Projekte waren...
-
scrontch schrieb:
Wieso soll/muss MSS = MTU-40 sein???
weil die headers (also ip und tcp) zusammen 40 bytes belegen.
scrontch schrieb:
[...] die vermittlungsschicht hat meistens eine begrenzte paketgrösse (bei ethernet z.b. 1536 bytes).
Das nicht!
(s.o.)
ist aber so. ein tcp erzeugt immer komplette paket, die in einem rutsch versendet werden können d.h braucht erstmal keine ip-fragmentierung. wenn man dagegen mit udp ein 10kbytes grosses paket sendet, wird das mit ip-fragmentierung in häppchen zerstückelt damit die paketvermittlungsschicht das auch senden kann. beispiel: dns-anfragen über eine modemverbindung. wenn dein ppp 512 bytes mtu angemeldet hat, kommen eventuell antworten (udp-pakete) die länger sind als 512 bytes. die kommen aber als ip-fragmente daher...
-
Sgt. Nukem schrieb:
Bashar schrieb:
auf Brieftauben und Bongotrommeln wird nicht gesondert Rücksicht genommen
...was ich sehr schade finde, da beides arschgeile Projekte waren...
Also für's erste gibt's ja schon seit langem die RFC 1149 : http://www.ietf.org/rfc/rfc1149.txt
(ich nehm mal an du kanntest es noch nicht)
-
net schrieb:
[...] blubb [...]
Du redest an meiner Frage vorbei. (siehe Bashar, der hat's vertsanden).
-
scrontch schrieb:
Sgt. Nukem schrieb:
Bashar schrieb:
auf Brieftauben und Bongotrommeln wird nicht gesondert Rücksicht genommen
...was ich sehr schade finde, da beides arschgeile Projekte waren...
Also für's erste gibt's ja schon seit langem die RFC 1149 : http://www.ietf.org/rfc/rfc1149.txt
(ich nehm mal an du kanntest es noch nicht)Höh?? Doch klar. Ich kenne auch die Projektdurchführung...