Daniel schrieb:
> Frage1: Was teilt Sender dem Empfänger mit. Window seines TCP stacks
> oder äussert er den Wunsch über Windowgrösse des Empfängers?
"Window" teilt jeweils der anderen Seite mit, wie viel Platz man
selbst noch an Puffer zur Verfügung hat, d. h. wie viele Oktetts
derjenige, der das empfängt, unbestätigt versenden darf. Das ist ja
die ganze Crux dabei: dass man entsprechend viele Daten ohne Vorliegen
einer Empfangsbestätigung bereits vorab sendet.
Kurzer historischer Abriss dazu (da es leider auch heute gern noch
falsch gemacht wird, siehe STK500-Protokoll oder dergleichen):
ursprünglich liegt natürlich die Idee nahe, dass man für eine
gesicherte Übertragung ein request-response-Protokoll aufbaut. Auf
jedes gesendete Paket folgt eine Bestätigung, erst danach macht der
Absender weiter. Ein solches Verfahren ist zwar sicher, aber es hat
einen wesentlichen Nachteil: wenn die Latenz zwischen Sender und
Empfänger hoch ist (lange Übertragungszeiten), dann wird viel Zeit
verwartet, und man kann die u. U. existierende Bandbreite gar nicht
ausnutzen. Der Extremfall in dieser Richtung wäre ein Satelliten-
Link, der mit einer Latenz im Bereich einiger 100 ms arbeitet, aber
riesige Bandbreiten anbietet.
Daher ging man schon sehr frühzeitig dazu über (bspw. bei UUCP), ein
"Window" einzuführen, eine Anzahl von Paketen (oder eben Oktetts), die
unbestätigt versendet werden dürfen. Mit der Konfiguration des
Windows kann man sich nun auf die Gegebenheiten des Mediums
einstellen. Hat man ein Medium mit hoher Latenz, aber guter
Bandbreite und sicherer Übertragung, dann kann man durch ein großes
Window trotzdem die Bandbreite nutzen. Hat man dagegen ein stark
verlustbehaftetes Medium (Analogmodem ohne Fehlerkorrektur), dann
macht man das Window eher klein, damit die Bestätigungen (und
Wiederholungen) möglichst zeitnah erfolgen.
TCP hat dieses Prinzip dann zum "sliding window" ausgebaut, d. h. die
Größe des Windows wird aktuell an die mit dem Übertragungskanal
gesammelten Erfahrungen angepasst und laufend der Gegenseite
mitgeteilt.
> Frage2: Wenn in diesem Packet nichts über Win und WS steht, heisst das,
> dass beide default 65535 Bytes verwenden?
Meiner Meinung nach (ich müsste es aber im RFC nachlesen) kann dieser
Fall gar nicht eintreten, da eben ein Grundprinzip des sliding windows
ist, dass man die verfügbare Größe des Windows immer der Gegenseite
mitteilt, d. h. jedes Datenpaket oder auch ein reines ACK enthält
diese Größe immer mit in den TCP-Datenfeldern. Zusätzlich ist es noch
möglich, einen Paketaustausch ohne zusätzliche Anlässe zu aktivieren,
der nur eine neue Größe des Windows überträgt (window update). Damit
erledigt TCP das flow control, d. h. wenn eine Seite vorübergehend
die Datenübertragung ausbremsen musste, weil sie die Daten nicht mehr
an die höheren Schichten losgeworden ist (dann ist irgendwann das
Window 0), kann sie durch ein window update den Datenstrom neu
anschieben.
wireshark.png
(3,6 KB)
