[ Main | Local ]

Im Fall von TCP senden die beteiligten Partner nummerierte Datenmengen über ein Netz. Dabei werden die Datenbytes nummeriert (die Sequenznummer) und der Empfänger teilt dem Sender per ACK mit, welches Byte er gerne als nächstes empfangen möchte (die Acknowledgementnummer).

Jetzt braucht so ein Paket mit einer gewissen Anzahl an Datenbytes bekanntlicherweise eine gewisse Zeit, um über das Netz zu laufen. Es wäre also nicht effektiv, wenn man ein reines Ping-Pong spielt macht: während der Ball fliegt, sind beide Maschinen untätig, und jede Maschine für sich ist vom senden des Paketes bis zum Empfang der Antwort untätig.

Es ist also nur vernünftig, das Netzwerk als eine Art Puffer zu betrachten, und davon auszugehen, das schon alles gut ankommt. Dann kann man während der Wartezeit auf die direkte Antwort schon weitersenden, solange, bis der gedacht Puffer voll ist. Erst dann muß wieder gewartet werden. Im Idealfall spielt sich so ein konstanter Fluß ein.

Damit das funktioniert, muß der Puffer entweder immer gleich groß sein (das kann man im Netzwerk vergessen) oder man versucht, ihn dynamisch zu bestimmen.

Die Theorie zeigt, das der Puffer das Produkt der vorhandenen Bandweite des Netzwerkes und der Rundlaufzeit eines Paketes ist. Also bei 100 Mbit/s und einer Rundlaufzeit von 5 msec passen genau 100x10^6 bit/s mal 5x10^-3 s = 500x10^3 Bit (das durch 8 sind 65 kByte). Jetzt kann man für ein Ethernet mit etwa 1400 Byte Nutzlast rechnen, also ergeben sich 46 Pakete, die gerade on the fly durch Netz zischen bzw. zischen können, ohne daß das Acknowledge des ersten Paketes beim Sender angekommen ist.

Das Ganze ist natürlich schon deshalb theoretisch, weil man ja nie die ganze Bandbreite für sich hat, und man auch nicht genau sagen kann, wieviel man gerade jetzt wirklich hat.

Daher treffen Sender und Empfänger nach eigener Last (Maschine unter Wasser) und Messungen der Netzlast eine Schätzung der momentanen (gedachten) Puffergröße und teilen das der anderen Seite mit. Diese wird dann den Puffer nur bis zum kleineren der beiden Werte füllen, also nur eine entsprechende Anzahl an Paketen auf die ungewisse Reise lassen.

Das Ganze wird dynamisch nachgeführt, es gibt verschiedene Fenster, die sich Öffnen und Schliessen. Dadurch wird eine Kontrolle des Paket-Flußes möglich, der dann zwar ungleich groß, aber stetig vorgeht.

Jetzt ein Bild, damit es ein bischen klarer wird. Ansonsten sei wieder auf den Stevens verwiesen, dort finden sich schönere und bessere Bilder.

 
                        TCP Window
Sender             |  Transmit Window  | 
                   |  Receive Window   |       Empfänger
WWWWWWWWWWWWWWWWWWWIIIIIIIIIIIIIIIIIIIIIAAAAAAAAAAAAAAAA
Datenstrom ==> 

W = Bytes, die noch nicht gesendet sind.
I = Bytes "in transit", also auf dem Netz.
A = Bytes, die der Empfänger empfangen und Acknowledged hat.

Der Sender darf jetzt solange fröhlich senden, bis das Fenster voll ist (in unserem Fall 21 Byte ;-). Dann muß er warten, bis er ein ACK vom Empfänger erhalten hat.

Der Empfänger sendet jetzt ein ACK der ersten 10 Byte:

 
                        TCP Window
Sender             |  Transmit Window  | 
                   |  Receive Window   |       Empfänger
WWWWWWWWWWWWWWWWWWWIIIIIIIIIII         aaaaaaaaaaAAAAAAA
Datenstrom ==> 

W = Bytes, die noch nicht gesendet sind.
I = Bytes "in transit", also auf dem Netz.
A = Bytes, die der Empfänger empfangen und Acknowledged hat.
a = Gerade empfangene Bytes.

Der Sender darf jetzt wieder 10 Byte senden.

Sender und Empfänger sehen dasselbe Fenster, nennen es aber einmal Transmit Window (Sender) und einmal Receive Window (Empfänger). Beide können es nach eigenen Bedürfnissen vergrößen bzw. verkleinern; es gilt immer der kleinere Wert. Dadurch erfolgt die Regelung des Flußeses der Bytes. Diese Technik nennt sich TCP Sliding Window.

Der Empfänger verkleinert jetzt das Receive Window, z.B. weil er unter Druck ist, oder sein Netzsegment unter Wasser ist.

 
                        TCP Window
Sender             |  Transmit Window  | 
                             | Rec Win |       Empfänger
WWWWWWWWWWWWWWWWWWWIIIIIIIIIII         aaaaaaaaaaAAAAAAA
Datenstrom ==> 

Der Sender darf jetzt nichts senden, den das TCP Window ist ja immer noch übervoll:

                        TCP Window
Sender             |  Transmit Window  | 
                             | Rec Win |       Empfänger
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWIIIIIIIIIIIaaaaaaaaaaAAAAAAA
Datenstrom ==> 

Der Empfänger hat jetzt ein ACK für 5 weiter Byte geschickt, Der Sender sendet jetzt auf der Basis des neuen, kleineren Fensters.

                        TCP Window
Sender             |  Transmit Window  | 
                             | Rec Win |       Empfänger
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWIIIIII    aaaaaAAAAAAAAAAAA
Datenstrom ==> 

Natürlich kann auch der Sender Gründe haben, das Fenster zu verkleinern.

Obwohl es dynamisch gesetzt wird, verbinden sich mit dem TCP Sliding Window eine ganze Reihe Parameter, die man Anpassen kann. Allerdings sind viele Auswirkungen implizit, man muß also wissen, was man tut (Stevens...).

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]