wireshark: 3 wege handshake, Aushandlung der Verbindungsoptionen

[Daniel (Gast)]

Hallo Leute,

kurze Frage an wireshark user bzw TCP Kenner.
man kann anhand des Bildes sehen, dass Sender/Empfänger
unterschiedliche Windows Sizes und Window Skalierung verwenden.

Frage1: Was teilt Sender dem Empfänger mit. Window seines TCP stacks
oder äussert er den Wunsch über Windowgrösse des Empfängers?
Sprich .. allokiere wenn du kannst so und so viel RAM.
(dasselbe gilt für window skalierung)
Ich vermute, dass er eigenen Puffer mitteilt.

Nach dem Hin und Zurück, schickt der Sender wieder ein Packet zum 
Empfänger.
Frage2: Wenn in diesem Packet nichts über Win und WS steht, heisst das,
dass beide default 65535 Bytes verwenden? - Da sie sich in dem Fall oben
uneinig waren. ODER heißt das, dass die vorher mitgeteilten 
Einstellungen
nun gültig sind. (und vom Kommunikationspartner in Anspruch genommen
werden können)

Ich habe dazu nichts gefunden (in 5 min). Sicher steht das in einem
guten Buch auf der Seite 327 ... ;-)

Grüße
Daniel

[Daniel (Gast)]

Daniel schrieb:
> ODER heißt das, dass die vorher mitgeteilten
> Einstellungen nun gültig sind. (und vom Kommunikationspartner in Anspruch > 
genommen werden können)

ups, nachdem ich genauer hingeschaut habe, scheint so, dass der Sender
sich nun für Win=17152 entscheidet. Und das gilt jetzt für beide Seiten?
Müssen denn die Win buffer gleich groß sein?

[Jörg W. (dl8dtl) (Moderator)]

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.

[Daniel (Gast)]

Jörg Wunsch schrieb:
> 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.

wenn ich das recht verstehe, macht es dann absolut keinen Sinn
gleich grosse Buffer zu reservieren. Alleine schon weil es in vielen
Fällen Sender gibt, die dauernd senden und Empfänger quittieren nur.
(typischer download Fall) Gleich grosser Buffer wäre Verschwendung
auf einer Seite.

Danke für den ausführlichen Beitrag

Gibt es in Wireshark ein Short Cut für den Filter
(ip.src==A and ip.dst==B) or (ip.src==B and ip.dst==A)

um die Kommunikationspackete einer Verbindung herauszufiltern?

[Jörg W. (dl8dtl) (Moderator)]

Daniel schrieb:

> wenn ich das recht verstehe, macht es dann absolut keinen Sinn
> gleich grosse Buffer zu reservieren.

Doch.  Solange die Leitung gut ist, stört es ja auch nicht wenn
der, der nicht so viel empfangen muss, trotzdem anzeigt, dass er
noch viel mehr zu empfangen bereit wäre.

> Gibt es in Wireshark ein Short Cut für den Filter
> (ip.src==A and ip.dst==B) or (ip.src==B and ip.dst==A)

Nicht dass ich wüsste.

> um die Kommunikationspackete einer Verbindung herauszufiltern?

Analyze -> Follow TCP Stream -> Filter out this stream

Aus'm Kopf, habe jetzt nicht genau nachgesehen.  Kann auch sein, dass
es nicht unter "Analyze" steht, sodern im Kontextmenü (rechte
Maustaste) eines beteiligten TCP-Pakets.