Diskussion:TCP Receive Window

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Nicht aufschlussreich[Quelltext bearbeiten]

Die Erklärung ist wie ich finde nicht sehr aufschlussreich und auch die niedrige MTU ist meiner Meinung nach nicht optimal betitelt. Es wäre super wenn sich da noch jemand erbarmen würde. (nicht signierter Beitrag von 84.137.144.14 (Diskussion) 17:42, 19. Sep. 2005)

RWin-Standardwert ausreichend?[Quelltext bearbeiten]

Es wird die Aussage getroffen, das der Standardwert von 16 Kbyte in den meisten Fällen ausreichend ist, außer bei sehr breitbandigen Verbindungen.Was ist eine sehr breitbandige Verbindung..? Wie sich aus diversen Hilferufen in Netzwerkforen gezeigt hat, ist der Standard RWIN ab einer DSL Bandbreite von ca. 3000-6000Kbit/sec. nicht mehr ausreichend, je nach Latenz des Servers. Man kann dies ganz einfach ausrechnen, mit dem BDP.

Bandwidth x Delay Product

RWIN = Bandbreite in Kbyte/sec. x Latenz in ms

Z.B. für DSL16000, Latenz mit 100ms angenommen

RWIN = 2048 Kbyte/sec. x 100 ms = 204800

Das ganze sollte dann noch auf ein Vielfaches der MSS "aligned" werden, also z.B. 205860 für 141 x MSS von 1460

Die angenommene Latenz (und damit der RWIN) ist ein Kompromiß, da jeder Server im Internet (besser gesagt, jeder Pfad zu einem Internet-Server) eine andere Latenz hat. Bei Servern in Fernost kann die Latenz schonmal 500ms betragen, während sie bei den meisten deutschen Servern unter 50ms liegen wird. Die in der BDP Rechnung angenommene Latenz sollte der maximal in der Praxis vorkommenden Latenz entsprechen. Je höher die zu Grunde gelegte Latenz, desto höher der RWIN Wert. Ein unnötig zu hoch gesetzter RWIN kann aus bestimmten Gründen gegenteilig wirken, d.h. kann den effektiven Durchsatz verringern anstatt zu erhöhen.

Unter www.speedguide.net/analyzer.php kann man seine aktuellen TCP Parameter überprüfen.

Für die Einstellung des RWIN unter Windows(XP) bietet sich der TCPOptimizer an, den man ebenfalls unter www.speedguide.net findet. Dieses Tool hat auch einen pingtest eingebaut, um die durchschnittliche Latenz zu ermitteln. Erwähnenswert wäre noch, das diese Parameter für jede Netzwerkkarte getrennt eingestellt werden können (und meist auch müssen!). Seit Windows Vista gibt es ein "Auto-Tuning" für den RWIN, er wird je nach Verbindung automatisch nachgestellt. Die hier erwähnte Methode funktioniert unter Vista nicht mehr. (Der vorstehende, nicht signierte Beitrag stammt von 88.76.205.182 (DiskussionBeiträge) 00:14, 17. Aug. 2007)

Was heißt „wie sich gezeigt hat“? Was heißt „ist nicht mehr ausreichend“? Wie äußert sich das in der Praxis? Was ist „BDP“? Woher kommt die Formel und unter welchen Bedingungen kann man sie anwenden? Wie wirkt sich ein so modifizierter RWin-Wert in der Praxis aus? --TM 08:40, 17. Aug. 2007 (CEST)Beantworten

Was heißt „wie sich gezeigt hat“?

Das Problem mit dem zu kleinen RWIN trat erst zutage, als schnelle Breitbandverbindungen für die breite Masse verfügbar wurden. In einem lokalen Netzwerk mit sehr kleinen Latenzen gibt es dieses Problem nicht, es entsteht erst durch die Verwendung von breitbandingen Internetverbindungen mit - im Vergleich zu einem LAN - relativ hohen Latenzzeiten.Der Windows Standard Wert für den RWIN (Windows XP z.B.) wurde festgelegt, als diese breitbandigen Verbindungen noch nicht für jedermann verfügbar waren bzw. nicht in den heute üblichen Geschwindigkeiten. Als sich die DSL Geschwindigkeiten in immer schnellerer Folge verdoppelten, trat dieses Problem massiv bei einer Vielzahl von Usern zutage. "Wie sich gezeigt hat" meint hier die lawinenartige Zunahme von Beiträgen in den enstprechenden Netzwerk- und DSL Foren im Internet, in denen User sich darüber beschweren, das sie die erwartete Geschwindigkeit am DSL Anschluß nicht erreichen, nachdem sie z.B. von DSL2000 auf DSL6000 umgestellt haben.

Dies konnte man vermehrt beobachten, als die DSL6000 Anschlüsse massenhaft verfügbar wurden.

Was heißt „ist nicht mehr ausreichend“?

Nicht mehr ausreichend bedeutet, das durch den zu kleinen Buffer zu wenig Daten am Stück rausgesendet werden.Bei Pfaden/Leitungen mit hoher Latenz müssen optimalerweise soviele Pakete an einem Stück gesendet werden, das sie die Leitung "befüllen", ihre "Sendezeit" also zur Latenz der Leitung äquivalent ist. Das letzte Paket darf nicht schon rausgesendet sein, bevor das erste Paket den Empfänger erreicht hat. Sonst entstehen Wartezeiten, während der Sender auf die Bestätigung wartet (Acknowledge ), was den effektiven Durchsatz vermindert. Der Extremfall wäre, wenn man nach jedem gesendeten Paket auf die Bestätigung warten würde. Bei einer Leitung mit 100ms Latenz wäre der Durchsatz auf höchstens 60Kbit/sec. begrenzt, das das Paket erst 100ms zum Empfänger benötigt und nach mind. weiteren 100ms erst die Bestätigung eintrifft, weshalb nur alle 200ms ein Paket rausgeschickt werden kann.

Wie äußert sich das in der Praxis?

In der Praxis äußert sich ein zu kleiner (bzw. nicht der Latenz der Leitung angepaßter) RWIN darin, das die maximal mögliche Übertragungsrate (also bei z.b. DSL6000 ~ 6000kbit) nicht erreicht wird. Je schneller die Internet-Geschwindigkeit und je größer die Latenz eines bestimmten Pfades zu einem bestimmten Server, umso mehr tritt dies zutage.

Bei FastPath Verbindungen kann der RWIN wegen der geringeren Latenz kleiner ausfallen als bei einer Verbindung ohne Fastpath (also Interleave).

Was ist „BDP“?

BDP bedeutet einfach BandwidthDelayProduct. Ich dachte, das ging aus dem Text klar hervor. Es steht dort auch drin.

Woher kommt die Formel und unter welchen Bedingungen kann man sie anwenden?

Ich kann nicht sagen, woher die Formel kommt, aber man kann sie sogar im englischen Wikipedia finden: http://en.wikipedia.org/wiki/Bandwidth-delay_product Webpages, die sich mit der Thematik beschäftigen, benutzen sie ebenfalls, z.B. www.speedguide.net .Allerdings kommt man automatisch auf die Formel, wenn ausrechnen will, wiviele Bytes bei einer bestimmten Geschwindigkeit in eine Leitung einer bestimmten Latenz reinpassen ("Leitung befüllen").

Wie wirkt sich ein so modifizierter RWin-Wert in der Praxis aus?

Er wird im Optimalfall bewirken, das die maximale Geschwindigkeit einer Internet-Verbindung erreicht werden kann, z.B. bei einem Download. Es gibt allerdings eine Vielzahl von Faktoren, die die Geschwindigkeit beeinträchtigen können, RWIN ist nur einer davon. Im Gegensatz zum Glauben einiger User kann ein optimaler RWIN die Geschwindigkeit nicht über das gebuchte Maximum heben, sondern nur aus einer sub-optimalen Verbindung eine optimale machen. Aus meiner Praxis kann ich sagen, das viele "System Optimierer" oder "Tuning Tools" ebenfalls an den TCP Werten wie RWIN "herumschrauben" und das Problem oft noch schlimmer machen.

TW (nicht signierter Beitrag von 152.62.109.164 (Diskussion) 10:59, 17. Aug. 2007)

Schlechte / Falsche Erklärung[Quelltext bearbeiten]

2. satz zeile 5: "RWin beschreibt die maximale Datenmenge, die ein Computer sendet, bevor eine Empfangsbestätigung eingeholt wird."

der satz ist falsch, komplett. kann missverstanden werden, und damit er richtig ist muss der leser erst umdenken!

RWin steht für Receive Window, also „Empfangsfenster(größe)“, auch bezeichnet als "window size" im TCP Header. ;) also muss der satz lauten: "RWin beschreibt die maximale Datenmenge, die ein Computer empfangen kann, bevor der Sender eine Empfangsbestätigung einholen muss."

WEIL so wie er jetzt dort steht würde das bedeuten: wenn ich TCP pakete versende und der header "TCP Window Size" (RWIN) hat den wert 60000, kann ich 60000 senden und muss dann eine empfangsbestätigung einholen. DAS STIMMT ABER NICHT! der wert 60000 teilt demjenigen mit was ich empfangen kann! also was er mir senden darf, bis er eine empfangsbestätigung einholen muss! nicht anders.

wenn der satz nicht innerhalb von zweich wochen geändert wird, dann, na ja ;) werd ich es mal ändern (nicht signierter Beitrag von 92.226.193.48 (Diskussion) 04:08, 20. Dez. 2007)

Falsche Berechnug der maximalen RWin-size?[Quelltext bearbeiten]

Ich vermute, dass sich bei der Berechnug der maximalen RWIN-Size ein Fehler eingeschlichen hat. Hier wird behauptet, dass das Größenfeld auf 32 BIt erweitert worden ist, dies entspräche 4294967296, was aber falsch ist. der richtige wert is 16 bit * 14 Bit (laut http://tools.ietf.org/html/rfc1323#page-11 ) = 30 Bit und diese Zahl ist wiederum 1073741824 -1 (nicht signierter Beitrag von 84.161.104.245 (Diskussion) 22:06, 17. Jan. 2008)

Beispielrechnung[Quelltext bearbeiten]

Die Rechnung ist falsch. Es wurde geschrieben das der Sender 100ms weg ist. Heisst mit Antwortzeit sind wir dann bei 200ms und pro Sekunde wären dann nur 5 hin und her möglich. Ausgehend bei DSL 6000 mit 750kbyte/s sollte der dann schon bei 150000 liegen wenn man von einer mittleren Entfernung von 100ms ausgeht. (nicht signierter Beitrag von 213.191.86.173 (Diskussion) 18:05, 15. Okt. 2008)

Bestimmung eines optimalen Wertes / Beispiel[Quelltext bearbeiten]

Für einen ADSL-Anschluss (PPPoe, MTU = 1492, MSS = 1452) heißt das: RWin = 1452 x 52 = 75504 Byte.

Ich bin mit der Berechnung nicht zufrieden. Hier wird der Rwin mit 52 Multipliziert? Meine Frage lautet, warum?

Wie oben im Artikel schon richtig steht ist 65535 die Maximale größe. Bei ADSL ist dies mit dem Faktor 45 Multipliziert, der Rwin 65340. Soweit sogut.

Nun steht geschrieben: "Der window scale Faktor ist eine Potenz von 2 (2,4,8,16,32 usw.) und bleibt somit für die Dauer einer Verbindung fest."

Also wird der Rwin (65340) mit einer Potenz multipliziert. In dem genannten Beispiel mit der zwei. Man kommt dann auf einen Rwin von 130680. So wird der Rwin korrekt berechnet und nicht wie oben genannt (Rwin x 52). (nicht signierter Beitrag von 85.179.199.34 (Diskussion) 04:08, 16. Feb. 2009)

Welche Größen für RWin benutzen Windows Vista und Windows 7?[Quelltext bearbeiten]

Vermutlich ändern die neueren Betriebssysteme die Werte nicht und belassen es auf den bereits bewährten 16 Kilobyte, oder? -- Johnny76 22:27, 26. Apr. 2010 (CEST)Beantworten

Ab Windows Vista gibt es ein sogenanntes Auto-Tuning, das heißt die Werte werden ganz automatisch optimal eingestellt. Ich habe das ergänzt. --TMg 03:06, 22. Okt. 2010 (CEST)Beantworten