10
TCP Segmente zusammenfügen
Hallo miteinander
Meine Frage betrifft den Fall dass z.B. ein grosses Bild per HTTP von einem Server angefragt wird. Aufgrund der MTU wird der TCP Stack des Server die Pakete so aufteilen dass sie über die Leitung gehen.
Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP Segmente in richtiger Reihenfolge präsentieren. Nun die Frage:
Wie weiss der Client (hier Browser) wie er die einzelnen Datenfragmente welche er vom OSI Stack hochgeliefert bekommt zu behandeln hat, sodass die "Grenzen" stimmen. Die Clientapplikation wird für den GET Request einen Socket eröffnet haben und dort werden die Daten dann abgeliefert. Aber wie weiss er nun: Jetzt sind alle Daten da um ein sinnvolles Muster zu ergeben. Hier also die grosse Datei welche in kleinen Stücken versendet wurde.
Wenn mir da jemand helfen könnte wäre ich dankbar.
Vielen Dank
Meine Frage betrifft den Fall dass z.B. ein grosses Bild per HTTP von einem Server angefragt wird. Aufgrund der MTU wird der TCP Stack des Server die Pakete so aufteilen dass sie über die Leitung gehen.
Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP Segmente in richtiger Reihenfolge präsentieren. Nun die Frage:
Wie weiss der Client (hier Browser) wie er die einzelnen Datenfragmente welche er vom OSI Stack hochgeliefert bekommt zu behandeln hat, sodass die "Grenzen" stimmen. Die Clientapplikation wird für den GET Request einen Socket eröffnet haben und dort werden die Daten dann abgeliefert. Aber wie weiss er nun: Jetzt sind alle Daten da um ein sinnvolles Muster zu ergeben. Hier also die grosse Datei welche in kleinen Stücken versendet wurde.
Wenn mir da jemand helfen könnte wäre ich dankbar.
Vielen Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 280128
Url: https://administrator.de/forum/tcp-segmente-zusammenfuegen-280128.html
Ausgedruckt am: 27.12.2024 um 01:12 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
für das zusammensetzen ist die Klient-Applikation wie zum Beispiel der Browser
selber zuständig, also das dort ein Bild angezeigt wird.
Weg von der Seite die Du aufrufst bis zu Dir und somit kann ein Paket was später los geschickt
wurde dennoch als erstes bei Dir eintreffen und von daher werden diese Pakete Nummeriert
und dann weiß das TCP/IP Protokoll welches Paket nicht oder eben schon vorhanden ist.
Eventuell gehen Pakete unterwegs auch verloren weil eine Verbindung zusammenbricht
und müssen neu angefordert werden dazu muss man natürlich auch wissen welche
Paketnummer man noch einmal anfordern muss.
das TCP/IP Protokoll zuständig.
Gruß
Dobby
für das zusammensetzen ist die Klient-Applikation wie zum Beispiel der Browser
selber zuständig, also das dort ein Bild angezeigt wird.
Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP
Segmente in richtiger Reihenfolge präsentieren. Nun die Frage:
Von wegen in Reihenfolge präsentiert! Die Datenpakete nehmen einen völlig autonomenSegmente in richtiger Reihenfolge präsentieren. Nun die Frage:
Weg von der Seite die Du aufrufst bis zu Dir und somit kann ein Paket was später los geschickt
wurde dennoch als erstes bei Dir eintreffen und von daher werden diese Pakete Nummeriert
und dann weiß das TCP/IP Protokoll welches Paket nicht oder eben schon vorhanden ist.
Eventuell gehen Pakete unterwegs auch verloren weil eine Verbindung zusammenbricht
und müssen neu angefordert werden dazu muss man natürlich auch wissen welche
Paketnummer man noch einmal anfordern muss.
Meine Frage betrifft den Fall dass z.B. ein grosses Bild per HTTP von einem Server angefragt wird.
Aufgrund der MTU wird der TCP Stack des Server die Pakete so aufteilen dass sie über die Leitung
gehen.
Der Stack ist vor Ort im OS oder einer Applikation implementiert und für den Transport ist dannAufgrund der MTU wird der TCP Stack des Server die Pakete so aufteilen dass sie über die Leitung
gehen.
das TCP/IP Protokoll zuständig.
Gruß
Dobby
Danke für die Antwort, das hilft mir weiter.
Bezüglich der Reihenfolge hast du mich evtl falsch verstanden. Mit "Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP Segmente in richtiger Reihenfolge präsentieren." meinte ich, dass es die Aufgabe des Transport Layers ist für die korrekte Reihenfolge der Pakete zu sorgen VOR dem Abliefern an den oberen Layer, für welchen die unteren ja transparent sind. Dass die wegen Routing, Congestion, Media Failure oder was auch immer in unterschiedlicher Reihenfolge an der NIC ankommen ist natürlich klar. TCP muss die halt im Buffer behalten und ggf. die Reihenfolge ändern bis es stimmt.
Übrigens und nur als Randbemerkung habe ich die Antwort betreffend HTTP im spezifischen noch gefunden falls sich jemand fragt wie der Browser weiss wie er die erhaltenen Daten zusammenfügen muss damit es Sinn ergibt. (So zusagen Grenzen zwischen den Daten die er erhält) Gemäss RFC gibt es im HTTP Header die Angabe der Content Length oder alternativ die Angabe dass alles was ankommt in "chunks" ist.
Bezüglich der Reihenfolge hast du mich evtl falsch verstanden. Mit "Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP Segmente in richtiger Reihenfolge präsentieren." meinte ich, dass es die Aufgabe des Transport Layers ist für die korrekte Reihenfolge der Pakete zu sorgen VOR dem Abliefern an den oberen Layer, für welchen die unteren ja transparent sind. Dass die wegen Routing, Congestion, Media Failure oder was auch immer in unterschiedlicher Reihenfolge an der NIC ankommen ist natürlich klar. TCP muss die halt im Buffer behalten und ggf. die Reihenfolge ändern bis es stimmt.
Übrigens und nur als Randbemerkung habe ich die Antwort betreffend HTTP im spezifischen noch gefunden falls sich jemand fragt wie der Browser weiss wie er die erhaltenen Daten zusammenfügen muss damit es Sinn ergibt. (So zusagen Grenzen zwischen den Daten die er erhält) Gemäss RFC gibt es im HTTP Header die Angabe der Content Length oder alternativ die Angabe dass alles was ankommt in "chunks" ist.
behalten und ggf. die Reihenfolge ändern bis es stimmt.
Man kann sich das auch so vorstellen, dass nicht einfach etwas "abgeholt" wird, sondern manveranlasst das einem die Pakete zugeschickt werden und dann kann man sich das noch in etwa
so vorstellen als wenn der Sender der Pakete einem sagt;
"Ich schicke jetzt das Paket 1005 von 55612 Paketen los"
und wenn das zu lange dauert, wartet derjenige, der das ganze angefordert hat nicht
so lange wie möglich, sondern nur eine vorgegebene Zeitspanne und wenn das Paket
dann nicht eingetroffen ist wird es einfach noch einmal angefordert. Bis man dann
55612 von 55612 Paketen empfangen hat.
Gruß
Dobby
Ok, nicht abgeholt sondern einen Layer hochgereicht beim empfangen trifft es wohl eher. Was aber nicht stimmt ist die Aussage "Ich schicke jetzt das Paket 1005 von 55612 Paketen los". TCP hat keine Ahnung die wievielte Nachricht es ist. Es führt nur die Sequenznummer (welche hochzählt für jeden Peer einzeln und jeweils um die TCP Segment PDU) im Paket welche dann von der Gegenstelle mit einem ACK SEQ Nr+1 beantwortet wird, wobei zu beachten ist dass nicht jedes Segment einzeln mit einem ACK bestätigt werden muss. Am Schluss wird dann die Verbindung abgebaut und gut ist.
Dasselbe gilt für die Retransmission. Es ist ein irrglaube dass der Client TCP Pakete nochmals anfordert. Der SERVER sendet nach Ablauf des Retransmission Timers (oder nach dem erhalten einer festgelegten Anzahl Dup ACKs) ohne erhalt des zugehörigen ACK das Paket nochmals, welches er bis zum erhalten des ACKs in einer speziellen Queue vorhält und erst daraus löscht wenn er dafür ein ACK erhalten hat.
Dasselbe gilt für die Retransmission. Es ist ein irrglaube dass der Client TCP Pakete nochmals anfordert. Der SERVER sendet nach Ablauf des Retransmission Timers (oder nach dem erhalten einer festgelegten Anzahl Dup ACKs) ohne erhalt des zugehörigen ACK das Paket nochmals, welches er bis zum erhalten des ACKs in einer speziellen Queue vorhält und erst daraus löscht wenn er dafür ein ACK erhalten hat.
Moin,
das ist ganz einfach. TCP benuzt eien Sequenznummer, die angibt, an welcher stelle des Streams sich das gerade veschickte Paket befindet. Damit kann der Empfänger ohne weiteres die Reihenfolge eines TCP-Streams wieder richtig sortieren.
Genaueres kannst Du im RFC oder z.B. bei Netzmafia nachlesen. Google ist da auch geeignet, Dir Lesematerial zuzuführen.
lks
PS: "Überlappende" TCP-Pakete boten mal gute Möglichkeiten eine Zielkiste zu übernehmen. Abr die meisten TCP/IP-Stacks haben das inzwischen korrigiert.
das ist ganz einfach. TCP benuzt eien Sequenznummer, die angibt, an welcher stelle des Streams sich das gerade veschickte Paket befindet. Damit kann der Empfänger ohne weiteres die Reihenfolge eines TCP-Streams wieder richtig sortieren.
Genaueres kannst Du im RFC oder z.B. bei Netzmafia nachlesen. Google ist da auch geeignet, Dir Lesematerial zuzuführen.
lks
PS: "Überlappende" TCP-Pakete boten mal gute Möglichkeiten eine Zielkiste zu übernehmen. Abr die meisten TCP/IP-Stacks haben das inzwischen korrigiert.
Hallo,
für de Sequenznummer gibt es eine gute Erklärung der Uni Bielefeld...
Sequence Number, Acknowledgement Number:
Die Sequenznummer und die Bestätigungsnummer sind jeweils 32-Bit-Zahlen. Die Nummern geben die Stellung der Daten des Segments innerhalb des in der Verbindung ausgetauschten Datenstroms an. Die Sequenznummer gilt in Senderichtung, die Bestätigungsnummer für Empfangsquittungen. Jeder der beiden TCP-Verbindungspartner generiert beim Verbindungsaufbau eine Sequenznummer, die sich während des Zeitraums der Verbindung nicht wiederholen darf. Dies ist allerdings durch den großen Zahlenraum von 232 wohl ausreichend gesichert. Diese Nummern werden beim Verbindungsaufbau ausgetauscht und gegenseitig quittiert. Bei der Datenübertragung wird die Sequenznummer vom Absender jeweils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer gibt der Empfänger an, bis zu welchem Byte er die Daten bereits korrekt empfangen hat. Die Nummer gibt allerdings nicht an, welches Byte zuletzt korrekt empfangen wurde, sondern welches Byte als nächstes zu erwarten ist.
Quelle
Und eine etwas generellere Erklärung findest du hier
Hier das ganze zum Thema TCP
brammer
für de Sequenznummer gibt es eine gute Erklärung der Uni Bielefeld...
Sequence Number, Acknowledgement Number:
Die Sequenznummer und die Bestätigungsnummer sind jeweils 32-Bit-Zahlen. Die Nummern geben die Stellung der Daten des Segments innerhalb des in der Verbindung ausgetauschten Datenstroms an. Die Sequenznummer gilt in Senderichtung, die Bestätigungsnummer für Empfangsquittungen. Jeder der beiden TCP-Verbindungspartner generiert beim Verbindungsaufbau eine Sequenznummer, die sich während des Zeitraums der Verbindung nicht wiederholen darf. Dies ist allerdings durch den großen Zahlenraum von 232 wohl ausreichend gesichert. Diese Nummern werden beim Verbindungsaufbau ausgetauscht und gegenseitig quittiert. Bei der Datenübertragung wird die Sequenznummer vom Absender jeweils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer gibt der Empfänger an, bis zu welchem Byte er die Daten bereits korrekt empfangen hat. Die Nummer gibt allerdings nicht an, welches Byte zuletzt korrekt empfangen wurde, sondern welches Byte als nächstes zu erwarten ist.
Quelle
Und eine etwas generellere Erklärung findest du hier
Hier das ganze zum Thema TCP
brammer
Hallo miteinander
Ohne jemand angreifen zu wollen, aber nach mehreren solcher Kommentare muss ich das loswerden weil ich das in den letzten Jahren vermehrt in dem Forum festgestellt habe: Lest ihr die Kommentare durch welche der Thread Opener jeweils abgibt? Dann hättet ihr gemerkt dass eure Antworten kein Stück weiterhelfen ausser der erste Teil von Dobby indem er sagt dass das Layer 7 Protokoll dafür Verantwortlich ist die Grenzen zu kennen. Was dann auch die Antwort war. Danach habe ich sogar noch auf ein RFC Dokument verwiesen im spezifischen HTTP Fall. Die Thematik die ihr dann alle aufrollt mit Sequenznummer und ACKs und Reihenfolge blablabla habe ich ebenfalls 2 mal durchgekaut und hat auch nichts im geringsten mit der Frage zu tun. Über die Funktionsweise des TCP Layers bin ich mir sehr wohl bewusst.
Verzeiht mir diesen Kommentar aber der Zweck eines Forums ist in meinen Augen präzise Antworten ohne künstliches aufblähen eines ganzen Themas durch Informationen welche nichts mit dem Thema zu tun haben.
Einen schönen Tag wünsche ich euch
Gruss
Ohne jemand angreifen zu wollen, aber nach mehreren solcher Kommentare muss ich das loswerden weil ich das in den letzten Jahren vermehrt in dem Forum festgestellt habe: Lest ihr die Kommentare durch welche der Thread Opener jeweils abgibt? Dann hättet ihr gemerkt dass eure Antworten kein Stück weiterhelfen ausser der erste Teil von Dobby indem er sagt dass das Layer 7 Protokoll dafür Verantwortlich ist die Grenzen zu kennen. Was dann auch die Antwort war. Danach habe ich sogar noch auf ein RFC Dokument verwiesen im spezifischen HTTP Fall. Die Thematik die ihr dann alle aufrollt mit Sequenznummer und ACKs und Reihenfolge blablabla habe ich ebenfalls 2 mal durchgekaut und hat auch nichts im geringsten mit der Frage zu tun. Über die Funktionsweise des TCP Layers bin ich mir sehr wohl bewusst.
Verzeiht mir diesen Kommentar aber der Zweck eines Forums ist in meinen Augen präzise Antworten ohne künstliches aufblähen eines ganzen Themas durch Informationen welche nichts mit dem Thema zu tun haben.
Einen schönen Tag wünsche ich euch
Gruss
Dann stell Deine Fragen so, daß wir nicht den Eindruck haben, Dir TCP erklären zu müssen. Du hast die MTU ins Spiel gebracht und die hat mit OSI Schicht 7 soviel zu tun wie eine einzelne Zelle mit einem Säugetier.
lks
lks
Hallo,
da kann ich @Lochkartenstanzer nur Recht geben....
Wer seinen Thread abschließt mit dem Satz
möchte informationen zu seinem Problem haben.
Deine Fragestellung basiert auf deiner Interpretation eines TCP Paketes durch das OSI Modell.
Die Sequenznummer, die dir anscheinend nicht voll umfänglich verständlich war, war ja letztendlich die Lösung.
Wenn du deine Frage präzise beantwortet haben möchtest dann stelle die Frage bitte entsprechend präzise.
Im übrigen finde ich es prersönlich immer sinnvoll auch mal über den Tellerrand zu schauen, um damit evtl. einen besseren Überblick über das hinterfragte Problem zu bekommen
Wenn du das nicht möchtest solltest du deine Fragen auf die Antworten "ja" oder "nein" ausrichten.
@Frank hat das im About der Webseite sehr passend zusammengefasst...
brammer
da kann ich @Lochkartenstanzer nur Recht geben....
Wer seinen Thread abschließt mit dem Satz
Wenn mir da jemand helfen könnte wäre ich dankbar.
möchte informationen zu seinem Problem haben.
Deine Fragestellung basiert auf deiner Interpretation eines TCP Paketes durch das OSI Modell.
Die Sequenznummer, die dir anscheinend nicht voll umfänglich verständlich war, war ja letztendlich die Lösung.
Wenn du deine Frage präzise beantwortet haben möchtest dann stelle die Frage bitte entsprechend präzise.
Im übrigen finde ich es prersönlich immer sinnvoll auch mal über den Tellerrand zu schauen, um damit evtl. einen besseren Überblick über das hinterfragte Problem zu bekommen
Wenn du das nicht möchtest solltest du deine Fragen auf die Antworten "ja" oder "nein" ausrichten.
@Frank hat das im About der Webseite sehr passend zusammengefasst...
Helfe gemeinschaftlich anderen Menschen mit Deinem Wissen und Deiner Erfahrung weiter! Erweitere Deinen Horizont, treffe andere Administratoren > in unseren Inhalten und tausche Dich über das interne Nachrichtensystem mit ihnen aus. Schreibe eigene Anleitungen, Tipps oder erstelle hilfreiche
Erfahrungsberichte über Produkte, die Du schon kennst. Um auf möglichst viele Beiträge, Probleme oder Fragen antworten zu können, brauchen wir
Dich!
https://administrator.de/aboutus/Erfahrungsberichte über Produkte, die Du schon kennst. Um auf möglichst viele Beiträge, Probleme oder Fragen antworten zu können, brauchen wir
Dich!
brammer
1
Ich würde sagen dass wir da auf keinen Nenner kommen und wir können uns den schwarzen Peter endlos zuschieben.
Was zu meiner Frage noch zu sagen wäre ist, dass die eure Antworten betreffend Sequenznummer und korrekte Reihenfolge dank TCP bereits beantwortet. Meine Aussage "Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP Segmente in richtiger Reihenfolge präsentieren." geht natürlich nicht ins Detail wie TCP das macht, aber grundsätzlich so korrekt. Spätestens dort hätte es klar sein müssen.
Die MTU muss ins Spiel gebracht werden damit TCP überhaupt weiss wie gross das MSS anzulegen ist, was ja wiederum für die Nutzdaten der oberen Layer gebraucht wird. Dass Layer 7 davon nicht mitbekommt ist klar, nur weil beide Ausdrücke in einem Satz vorkommen kann man nicht darauf schliessen dass man gemeint hat das eine hätte was mit dem anderen zu tun und überhaupt stand die MTU klar geschrieben im Bezug zu TCP (Stack) und NICHT wie von dir behauptet mit Layer 7.
An brammer:
Nein das war nicht die Lösung, was wieder beweist, dass ihr die Kommentare nicht durchlest. Ich habe oben auf den HTTP RFC verwiesen.
Nachtrag: Und wenn wir schon auf genauen Angaben herumreiten möchte ich dich noch darauf hinweisen dass es sowas wie ein TCP Paket nicht gibt
Layer1: Bit
Layer2: Frame
Layer3: Pakete/Datagram
Layer4 TCP: Segmente
Layer4 UDP: Datagram
Für mich ist das Thema damit beendet und wünsche euch beiden noch einen schönenTag und wie bereits gesagt: Es ist und war nie böse gemeint!
Gruss
Was zu meiner Frage noch zu sagen wäre ist, dass die eure Antworten betreffend Sequenznummer und korrekte Reihenfolge dank TCP bereits beantwortet. Meine Aussage "Beim Client wird dank TCP dem aufrufenden Programm (hier Browser) die TCP Segmente in richtiger Reihenfolge präsentieren." geht natürlich nicht ins Detail wie TCP das macht, aber grundsätzlich so korrekt. Spätestens dort hätte es klar sein müssen.
Die MTU muss ins Spiel gebracht werden damit TCP überhaupt weiss wie gross das MSS anzulegen ist, was ja wiederum für die Nutzdaten der oberen Layer gebraucht wird. Dass Layer 7 davon nicht mitbekommt ist klar, nur weil beide Ausdrücke in einem Satz vorkommen kann man nicht darauf schliessen dass man gemeint hat das eine hätte was mit dem anderen zu tun und überhaupt stand die MTU klar geschrieben im Bezug zu TCP (Stack) und NICHT wie von dir behauptet mit Layer 7.
An brammer:
Nein das war nicht die Lösung, was wieder beweist, dass ihr die Kommentare nicht durchlest. Ich habe oben auf den HTTP RFC verwiesen.
Nachtrag: Und wenn wir schon auf genauen Angaben herumreiten möchte ich dich noch darauf hinweisen dass es sowas wie ein TCP Paket nicht gibt
Layer1: Bit
Layer2: Frame
Layer3: Pakete/Datagram
Layer4 TCP: Segmente
Layer4 UDP: Datagram
Für mich ist das Thema damit beendet und wünsche euch beiden noch einen schönenTag und wie bereits gesagt: Es ist und war nie böse gemeint!
Gruss
