TCP Ablauf... Unklarheiten

[Hawkster]

Hallo liebe Community,

bitte entschuldigt die Störung mit solch einem Thema, aber ich bin einfach nicht sicher was richtig ist und wie es zu deuten ist.
Für ein Studienfach muss ich eine Anwendung schreiben welche den TCP-Ablauf simuliert. Dazu wird die Größe einer willkürlichen Datei genommen und das Programm soll den Ablauf des TCP Protokolles wiedergeben.

So, dazu haben wir folgenden Beispielablauf von dem Prof bekommen:


Der Verbindungsaufbau (1, 2, 3) ist mir soweit klar, das passt auch mit dem was ich im Internet gefunden habe. Habe dieses Verhalten auch mit Wireshark betätigen können.

Nun kommen wir zur Datenübertragung. Bzgl. der ControlFlags und der SeqNr + AckNr gibt es keine Fragen. Mein Problem ist folgendes: Der Client hat einen Empfangspuffer von 3072 Byte und der Server einen Puffer von 4096 Byte (so interpretiere ich es jedenfalls).
Mein Problem beginnt leider schon beim Paket 4. Es werden 2048 Byte übertragen... warum 2048? Woher weiß der Client das?
Daraufhin bestätigt der Server das Paket durch erhöhen der AckNr um die 2048. Dazu wird wohl auch das WinSize gesendet. Hierbei interpretiere ich nun rein, das es die Angabe ist, wie viel Byte an Daten der Puffer vom Server noch annehmen kann.
Also schickt der Client nochmal 2048 Byte und der Server bestätigt das Paket und meldet das der Puffer voll ist (WinSize 0).
Im Paket 8 meldet der Server dann dem Client "Hey, hab wieder Platz, schick weiter". Aber nun auch hier die Frage: Wieso nur 2048? Warum ist der Puffer hier nicht ganz leer und stellt 4096 Byte zur Verfügung?

Und nun zum Verbindungsabbau: Hier sagt der Server "Ich bin Fertig!". Woher weiß der Server das Bitte? Es wurde (soweit ich das erkenne) nie gemeldet wann der Client alle Daten übertragen hat. Laut Wireshark meldet der Client das er Fertig ist...
Meines Erachtens müsste bei dem Verbindungsabbau Paket 10+11 mit Paket 12+13 vertauscht werden (mit Anpassung der Seq- und AckNr.)


Habe nun auch versucht die Antworten im Internet zu finden... aber es widerspricht sich einfach so viel...

Deswegen würde ich euch bitten, mir zu erklären wo mein Denkfehler ist. Vielleicht hat auch der Prof einen Fehler gemacht...

Mit freundlichen Grüßen,
Hawkster

 

[Harrier]

Hi,

also was den Verbindungabbau angeht: auf Transportebene (TCP) wissen weder Client noch Server, wann sie "fertig" sind. Das muss auf höherer Ebene (typischerweise der Anwendungsebene) entschieden werden. In diesem Fall ist es so, dass die Anwendung auf dem Server erkannt hat, dass die Verbindung abgebaut werden muss. (z.b. könnte der Client eine "QUIT"-Message übertragen haben, oder der Server ist der Meinung, der Client hat genug übertragen, das Server-System wird heruntergefahren oder was auch immer). Ein TCP-FIN ist von Client und Server gleichermaßen plausibel, weil TCP eben nicht über den Verbindungsabbau entscheidet. (Es sei denn es tritt ein Problem auf dieser Ebene auf).

Was die Datenmenge angeht: Die wird nicht (direkt) vom receive window entschieden, sondern durch das congestion window beeinträchtigt. Warum das jetzt in dem Beispiel genau 1/2*receive window ist, fällt mir gerade auch nicht ein, aber beschäftige dich mal mit congestion control (slow start, congestion avoidance) - ich bin mir ziemlich sicher, dass die Antwort dort zu finden ist.

Viel Glück noch,
Harrier