11
TCP Verbindung Verständnis
Kann mir jemand sagen wieviele Bytes Rechner 1 zwischen Zeitpunkt 1 und Zeitpunkt 2 von Rechner 2 korrekt empfangen hat?
bzw. wieviele Bytes Rechner 2 zwischen den beiden Zeitpunkten von Rechner 1 korrekt empfangen hat ?
Steig da momentan nicht so ganz durch !
bzw. wieviele Bytes Rechner 2 zwischen den beiden Zeitpunkten von Rechner 1 korrekt empfangen hat ?
Steig da momentan nicht so ganz durch !
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: 67011
Url: https://administrator.de/contentid/67011
Ausgedruckt am: 24.11.2024 um 11:11 Uhr
11 Kommentare
Neuester Kommentar
Wie meinst du das ??? Bezogen auf die Header daten oder auch Payload ??? Die Aussage zur Payload ist unmöglich, da man bei der ungenauen Skizze niemal schlussfolgern kann welche Packetgröße benutzt wurde. Wie du ja sicher weisst kann ein Ethernet Packet zwischen 64 Byte und 1500 Byte groß sein.
Nur die Header Daten kannst du anhand der Sequence Nummern rausbekommen und abzählen. Wieviel das letztlich sind weist du nach Lektüre von:
http://de.wikipedia.org/wiki/Transmission_Control_Protocol
Nur die Header Daten kannst du anhand der Sequence Nummern rausbekommen und abzählen. Wieviel das letztlich sind weist du nach Lektüre von:
http://de.wikipedia.org/wiki/Transmission_Control_Protocol
hallo
ja es kommt immer auf gewisse faktoren an...
protokolle
payload
anfrage antwort
flags
os
event. fak.
es gibt nur eins 0 or 1 [lowbyte]
ja es kommt immer auf gewisse faktoren an...
protokolle
payload
anfrage antwort
flags
os
event. fak.
es gibt nur eins 0 or 1 [lowbyte]
Hallo,
eigentlich geht es mir darum wieviele Bytes empfangen und jeweils bestätigt wurde. Also in einer TCP-Verbindung werden die Pakete ausgetauscht, nun dachte ich kann man anhand der SEQ Nr ablesen was jeweils noch angefordert wird, also daraus schließen das vorausgegangene bytes(Pakete) empfangen worden sind, da ja bestätigt mit ACK.
Meine gedachte Lösung !?
Rechner 1 erhält 3600 – 3300 = 300 Bytes von Rechner 2 korrekt
Rechner 2 erhält 3100 – 3000 = 100 Bytes von Rechner 1 korrekt
Ob richttig oder Falsch...keine Ahnung.
Werd mal die wiki Seite über TCP wie von aqui empfohlen "durchackern"
eigentlich geht es mir darum wieviele Bytes empfangen und jeweils bestätigt wurde. Also in einer TCP-Verbindung werden die Pakete ausgetauscht, nun dachte ich kann man anhand der SEQ Nr ablesen was jeweils noch angefordert wird, also daraus schließen das vorausgegangene bytes(Pakete) empfangen worden sind, da ja bestätigt mit ACK.
Meine gedachte Lösung !?
Rechner 1 erhält 3600 – 3300 = 300 Bytes von Rechner 2 korrekt
Rechner 2 erhält 3100 – 3000 = 100 Bytes von Rechner 1 korrekt
Ob richttig oder Falsch...keine Ahnung.
Werd mal die wiki Seite über TCP wie von aqui empfohlen "durchackern"
hallo am besten installierst du dir einen packet sniffer
1.wireshark
2.windump für win32
3.tcpdump für linux
danach kanst du dir das selber erechnen....
und etwas noch eine ethernet adresse kann sehr wohl kleiner sein etwa 16 byte
das bringt jedoch nichts da die reassemblierung auf dem remotehost zu stark wäre...
und so zu einem denial of service füren würde....
es gibt nur eins 0 or 1 [lowbyte]
1.wireshark
2.windump für win32
3.tcpdump für linux
danach kanst du dir das selber erechnen....
und etwas noch eine ethernet adresse kann sehr wohl kleiner sein etwa 16 byte
das bringt jedoch nichts da die reassemblierung auf dem remotehost zu stark wäre...
und so zu einem denial of service füren würde....
es gibt nur eins 0 or 1 [lowbyte]
@xmenchen
Das ist doch Unsinn ! Die Sequenznummern sagen doch rein gar nichts ueber die Packetlaenge aus ??? Wie denn auch das ist eine reine sequenzielle Nummerierung der Packete sonst nichts !
Deshalb kannst du ja gerade NICHTS ueber die Anzahl der uebertragenen Bytes aussagen sondern lediglich ueber die Anzahl der Packete.
Wenn du nur den TCP Header rechnen wuerdest dann wuerde man es ggf. machen koennen aber solche Packete sind ja nur fiktiv, in der Realitaet gibts das natuerlich nicht, da dort ja immer auch irgendwie Daten dranhaengen !
Das ist doch Unsinn ! Die Sequenznummern sagen doch rein gar nichts ueber die Packetlaenge aus ??? Wie denn auch das ist eine reine sequenzielle Nummerierung der Packete sonst nichts !
Deshalb kannst du ja gerade NICHTS ueber die Anzahl der uebertragenen Bytes aussagen sondern lediglich ueber die Anzahl der Packete.
Wenn du nur den TCP Header rechnen wuerdest dann wuerde man es ggf. machen koennen aber solche Packete sind ja nur fiktiv, in der Realitaet gibts das natuerlich nicht, da dort ja immer auch irgendwie Daten dranhaengen !
@aqui
Unsinn, weiß ich nicht...Das ganze entstammt einer Klausuraufgabe. Dafür muss es doch eine Lösung geben !???
Wort wörtlich:
In einer TCP Verbindung werden die folgenden Pakete ausgetauscht. Dabei bezeichnet SEQ die sequence number und ACK die acknowledgement number. Wieviele Bytes hat Rechner 1 zwischen Zeitpunkt 1 und Zeitpunkt 2 von Rechner 2 korrkekt empfangen.
Wieviele Bytes hat Rechner 2 zwischen Zeitpunkt 1 und Zeitpunkt 2 von Rechner 1 korrkekt empfangen.
Begründen Sie ihre Antworten!
Es gibt auch "nur" 6 Punkte, also kann die Lösung eigentlich ja nicht so "schwer" herzuleiten sein...
Ich verstehs ja leider auch nicht...
Unsinn, weiß ich nicht...Das ganze entstammt einer Klausuraufgabe. Dafür muss es doch eine Lösung geben !???
Wort wörtlich:
In einer TCP Verbindung werden die folgenden Pakete ausgetauscht. Dabei bezeichnet SEQ die sequence number und ACK die acknowledgement number. Wieviele Bytes hat Rechner 1 zwischen Zeitpunkt 1 und Zeitpunkt 2 von Rechner 2 korrkekt empfangen.
Wieviele Bytes hat Rechner 2 zwischen Zeitpunkt 1 und Zeitpunkt 2 von Rechner 1 korrkekt empfangen.
Begründen Sie ihre Antworten!
Es gibt auch "nur" 6 Punkte, also kann die Lösung eigentlich ja nicht so "schwer" herzuleiten sein...
Ich verstehs ja leider auch nicht...
Mmmmhhh...kommt immer drauf an was der Dozent für einen Hintergrund hat. Eine Universitäts Klausur ist das mit Sicherheit nicht, dafür wäre die Frage zu unpräzise und sie hört sich eher nach einer Berufsschul Klausur an...na ja egal..
Normal lässt sich diese Frage nicht beantworten, denn der Klausur Verfasser scheint sich nicht in der Tiefe Gedanken über den Aufbau von Ethernet bzw. TCP/IP Packten gemacht zu haben, den Vorwurf müsste er sich gefallen lassen.
Vermutlich geht er nur von einem reinen TCP Header aus, denn der ist konstant in einem TCP Packet. Das ist der einzige verlässliche Byte Wert den du ja hast. Damit lässt sich diese Aufgabe auch lösen. Zwar mit irrealem Ergebnis aber wenigstens was den Header angeht stimmt es dann...
Es ist aber eine rein fiktive theoretische Schulfrage mit der Praxis bzw. Realität hat das rein gar nichts zu tun, da es solche Packete schlicht nicht gibt.... Darauf würde ich den Verfasserr mal ansprechen, was er dazu sagt.
Die Antwort wäre sehr spannend
Normal lässt sich diese Frage nicht beantworten, denn der Klausur Verfasser scheint sich nicht in der Tiefe Gedanken über den Aufbau von Ethernet bzw. TCP/IP Packten gemacht zu haben, den Vorwurf müsste er sich gefallen lassen.
Vermutlich geht er nur von einem reinen TCP Header aus, denn der ist konstant in einem TCP Packet. Das ist der einzige verlässliche Byte Wert den du ja hast. Damit lässt sich diese Aufgabe auch lösen. Zwar mit irrealem Ergebnis aber wenigstens was den Header angeht stimmt es dann...
Es ist aber eine rein fiktive theoretische Schulfrage mit der Praxis bzw. Realität hat das rein gar nichts zu tun, da es solche Packete schlicht nicht gibt.... Darauf würde ich den Verfasserr mal ansprechen, was er dazu sagt.
Die Antwort wäre sehr spannend
@aqui
die Frage wurde von einem Prof.Dr. und angesehenem Dozenten an einer FH in einer Klausur im Jahre 2003 gestellt. Ich denke schon das der sich in der Tiefe mit der Materie auskennen tut
Also meine weiter oben gepostete Lösung kann doch im Grunde nur richtig sein:
Rechner 1 erhält 300 Bytes von Rechner 2 korrekt, abzulesen an der ACK (3301 - 3001)
Rechner 2 erhält 100 Bytes von Rechner 1 korrekt (3101 - 3001)
Sie hier: http://de.wikipedia.org/wiki/Bild:Tcp_transfer.png...
in dem Bild kann man auch anhand der ACK einfach ablesen wieviel bytes empfangen wurden!!!
die Frage wurde von einem Prof.Dr. und angesehenem Dozenten an einer FH in einer Klausur im Jahre 2003 gestellt. Ich denke schon das der sich in der Tiefe mit der Materie auskennen tut
Also meine weiter oben gepostete Lösung kann doch im Grunde nur richtig sein:
Rechner 1 erhält 300 Bytes von Rechner 2 korrekt, abzulesen an der ACK (3301 - 3001)
Rechner 2 erhält 100 Bytes von Rechner 1 korrekt (3101 - 3001)
Sie hier: http://de.wikipedia.org/wiki/Bild:Tcp_transfer.png...
in dem Bild kann man auch anhand der ACK einfach ablesen wieviel bytes empfangen wurden!!!
Wie bereits gesagt in der Sequence Number steht nichts über die Anzahl der übertragenen Bytes drin, das ist lediglich eine Nummer sonst nichts. Hier die Definition der Sequence Number:
TCP betrachtet die zu übertragenden Daten als numerierten Bytestrom, wobei die Nummer des ersten Bytes beim Verbindungsaufbau festgelegt wird. Dieser Bytestrom wird bei der Übertragung in Blöcke (TCP-Segmente) aufgeteilt. Die 'Sequence Number' ist die Nummer des ersten Datenbytes im jeweiligen Segment (--> richtige Reihenfolge über verschiedene Verbindungen eintreffender Segmente wiederherstellbar).
Daran kann man also nicht auf die Byte Anzahl schliessen. Vielmehr anhand der SN abzählen wieviel Packete geflossen sind und dann danach die Standard Header Bytes zusammenzählen. Nicht realistisch aber immerhin...
TCP betrachtet die zu übertragenden Daten als numerierten Bytestrom, wobei die Nummer des ersten Bytes beim Verbindungsaufbau festgelegt wird. Dieser Bytestrom wird bei der Übertragung in Blöcke (TCP-Segmente) aufgeteilt. Die 'Sequence Number' ist die Nummer des ersten Datenbytes im jeweiligen Segment (--> richtige Reihenfolge über verschiedene Verbindungen eintreffender Segmente wiederherstellbar).
Daran kann man also nicht auf die Byte Anzahl schliessen. Vielmehr anhand der SN abzählen wieviel Packete geflossen sind und dann danach die Standard Header Bytes zusammenzählen. Nicht realistisch aber immerhin...
Sequence Number:
- Nummer zur Identifizierung der Position der Daten im Bytestrom der Applikation.
- wird beim Verbindungsaufbau für jede Richtung auf einen pseudozufälligen Wert gesetzt und
gemäß der Anzahl der gesendeten Datenbytes inkrementiert.
Also im Grunde so wie deine Definition. Nur bedeutet das doch das man anhand meiner Skizze genau sehen kann wieviele Datenbytes "erfolglreich" geflossen sind. (mit ack bestätigt)
Das Beispiel macht doch nichts anderes: http://de.wikipedia.org/wiki/Bild:Tcp_transfer.png...
Verstehe nicht genau warum du immernoch dagegen argumentierst...
Wir sind uns doch bei der Lösung der Aufgabe mit der Skizze einig
- Nummer zur Identifizierung der Position der Daten im Bytestrom der Applikation.
- wird beim Verbindungsaufbau für jede Richtung auf einen pseudozufälligen Wert gesetzt und
gemäß der Anzahl der gesendeten Datenbytes inkrementiert.
Also im Grunde so wie deine Definition. Nur bedeutet das doch das man anhand meiner Skizze genau sehen kann wieviele Datenbytes "erfolglreich" geflossen sind. (mit ack bestätigt)
Das Beispiel macht doch nichts anderes: http://de.wikipedia.org/wiki/Bild:Tcp_transfer.png...
Verstehe nicht genau warum du immernoch dagegen argumentierst...
Wir sind uns doch bei der Lösung der Aufgabe mit der Skizze einig
Hi,
also, zunächstmal stehen die TCP Sequence Numbers in direktem Zusammenhang zu den übertragenen Bytes, den TCP Bytes wohlgemerkt!!!. Daher ist dein Ansatz ganz sicher "kein Unsinn".
Hier mal ein Beispiel (Header eines TCP Paketes aus einem packettrace):
Transmission Control Protocol
Source port: 8081
Destination port: 1211
Sequence number: 1 (relative sequence number)
[Next sequence number: 1461 (relative sequence number)]
Acknowledgement number: 474 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 6432
Checksum: 0x35e0 [correct]
Data (1460 bytes)
Also, wie du siehst ist hier das Segment (bei TCP spricht man übrigens nicht von Paketen, sondern von Segmenten!) mit der SeqNr "1" übertragen worden. Das Segment enthält genau 1460 Byte, also enthält das nächste zu übertragende Segment die SeqNr "1461" (1460+1).
Ich möchte mich ím Moment nicht festnageln, aber ich meine die initiale SeqNr einer TCP Verbindung kann willkürlich sein, daher muss sie nicht bei 1 beginnen. Aber alle übertragenen Bytes des jew. Hosts werden draufgerechnet. Die SEQs von Sender und Empfänger sind also voneinander unabhängig. Die ACK Nr bezieht sich immer auf die SEQ des nächst zu erwartenden Paketes des Partners. Die Formel lautet also SEQ des zuletzt empfangenen Segmentes + Payloadbytes.
In deinem Fall bin ich mir nicht ganz sicher.
Host1, Paket1 (vereinfacht Host/Paket = 1/1) hat SEQ=3000 und ACK=3001. Das bedeutet demnach, dass bisher 3000 Bytes übertragen worden (angenommen die Session beginnt bei SEQ=1) und als nächstes das Paket mit SEQ=3001 von Host2 erwartet wird. Da Paket 1/2 die SEQ=3100 beinhält, müsste das Paket 1/1 wohl 100 Bytes Payload übertragen haben. Hier erkenne ich auch schon eine Diskrepanz, denn das ACK von Paket 2/1 hat den Wert 3001 (sollte 3100 sein).
Um auf deine Frage einzugehen: Host-2 hat warscheinlich 300 Bytes zwischen Zeitpunkt 1 und 2 gesendet (SEQ=3600 von 2/2 - SEQ=3300 von 2/1 = 300 Bytes). Bei Host-1 kann ich allerdings nur raten, dass die o.g. 100 Bytes gemeint sind (???). Nach Zeitpunkt 1 wird nur das Paket mit der SEQ=3100 gesendet, der Payload ist hier noch unbestimmt. Host-2 ACKed daraufhin mit ACK=3101 - das nächste zu erwartende Paket. Das würde bedeuten, dass hier nur "1" Byte übertragen wurde. Sehr unwarscheinlich !?!?! Also interviewe deinen Prof. doch bitte nochmal. Ich denke hier stimmt was nicht!
Gruß haktop
also, zunächstmal stehen die TCP Sequence Numbers in direktem Zusammenhang zu den übertragenen Bytes, den TCP Bytes wohlgemerkt!!!. Daher ist dein Ansatz ganz sicher "kein Unsinn"
.Hier mal ein Beispiel (Header eines TCP Paketes aus einem packettrace):
Transmission Control Protocol
Source port: 8081
Destination port: 1211
Sequence number: 1 (relative sequence number)
[Next sequence number: 1461 (relative sequence number)]
Acknowledgement number: 474 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 6432
Checksum: 0x35e0 [correct]
Data (1460 bytes)
Also, wie du siehst ist hier das Segment (bei TCP spricht man übrigens nicht von Paketen, sondern von Segmenten!) mit der SeqNr "1" übertragen worden. Das Segment enthält genau 1460 Byte, also enthält das nächste zu übertragende Segment die SeqNr "1461" (1460+1).
Ich möchte mich ím Moment nicht festnageln, aber ich meine die initiale SeqNr einer TCP Verbindung kann willkürlich sein, daher muss sie nicht bei 1 beginnen. Aber alle übertragenen Bytes des jew. Hosts werden draufgerechnet. Die SEQs von Sender und Empfänger sind also voneinander unabhängig. Die ACK Nr bezieht sich immer auf die SEQ des nächst zu erwartenden Paketes des Partners. Die Formel lautet also SEQ des zuletzt empfangenen Segmentes + Payloadbytes.
In deinem Fall bin ich mir nicht ganz sicher.
Host1, Paket1 (vereinfacht Host/Paket = 1/1) hat SEQ=3000 und ACK=3001. Das bedeutet demnach, dass bisher 3000 Bytes übertragen worden (angenommen die Session beginnt bei SEQ=1) und als nächstes das Paket mit SEQ=3001 von Host2 erwartet wird. Da Paket 1/2 die SEQ=3100 beinhält, müsste das Paket 1/1 wohl 100 Bytes Payload übertragen haben. Hier erkenne ich auch schon eine Diskrepanz, denn das ACK von Paket 2/1 hat den Wert 3001 (sollte 3100 sein).
Um auf deine Frage einzugehen: Host-2 hat warscheinlich 300 Bytes zwischen Zeitpunkt 1 und 2 gesendet (SEQ=3600 von 2/2 - SEQ=3300 von 2/1 = 300 Bytes). Bei Host-1 kann ich allerdings nur raten, dass die o.g. 100 Bytes gemeint sind (???). Nach Zeitpunkt 1 wird nur das Paket mit der SEQ=3100 gesendet, der Payload ist hier noch unbestimmt. Host-2 ACKed daraufhin mit ACK=3101 - das nächste zu erwartende Paket. Das würde bedeuten, dass hier nur "1" Byte übertragen wurde. Sehr unwarscheinlich !?!?! Also interviewe deinen Prof. doch bitte nochmal. Ich denke hier stimmt was nicht!
Gruß haktop
