Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

TCP Verbindung Verständnis

Frage Netzwerke Netzwerkprotokolle

Mitglied: xmenchen

xmenchen (Level 1) - Jetzt verbinden

24.08.2007, aktualisiert 29.10.2007, 6344 Aufrufe, 11 Kommentare

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 !

52f33f5e979d1172f0501f8731c0a1d5-3way - Klicke auf das Bild, um es zu vergrößern
Mitglied: aqui
24.08.2007 um 17:17 Uhr
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
Bitte warten ..
Mitglied: lowbyte1
25.08.2007 um 08:05 Uhr
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]
Bitte warten ..
Mitglied: xmenchen
25.08.2007 um 09:54 Uhr
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"
Bitte warten ..
Mitglied: lowbyte1
26.08.2007 um 02:44 Uhr
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]
Bitte warten ..
Mitglied: aqui
26.08.2007 um 09:05 Uhr
@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 !
Bitte warten ..
Mitglied: xmenchen
26.08.2007 um 11:51 Uhr
@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...
Bitte warten ..
Mitglied: aqui
27.08.2007 um 14:04 Uhr
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
Bitte warten ..
Mitglied: xmenchen
27.08.2007 um 14:52 Uhr
@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!!!
Bitte warten ..
Mitglied: aqui
28.08.2007 um 17:57 Uhr
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...
Bitte warten ..
Mitglied: xmenchen
28.08.2007 um 18:18 Uhr
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
Bitte warten ..
Mitglied: haktop70
29.10.2007 um 13:10 Uhr
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
Bitte warten ..
Neuester Wissensbeitrag
Ähnliche Inhalte
Router & Routing
OpenVpn Verbindung Synology NAS hinter Zywall USG 40 (2)

Frage von Tirgel zum Thema Router & Routing ...

Webbrowser
gelöst Firefox 50 downloads stocken ohne Internet Verbindung (2)

Frage von LordXearo zum Thema Webbrowser ...

Windows Tools
Zwischenspeicher TS RDP-Verbindung (3)

Frage von Yannosch zum Thema Windows Tools ...

Heiß diskutierte Inhalte
Windows Userverwaltung
Ausgeschiedene Mitarbeiter im Unternehmen - was tun mit den AD Konten? (33)

Frage von patz223 zum Thema Windows Userverwaltung ...

LAN, WAN, Wireless
Server erkennt Client nicht wenn er ausserhalb des DHCP Pools liegt (22)

Frage von Mar-west zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
FritzBox, zwei Server, verschiedene Netze (21)

Frage von DavidGl zum Thema LAN, WAN, Wireless ...

Viren und Trojaner
Aufgepasst: Neue Ransomware Goldeneye verbreitet sich rasant (20)

Link von Penny.Cilin zum Thema Viren und Trojaner ...