Ovion schrieb
Dennoch würde ich dich gerne noch mit ein paar Fragen zu deiner Erklärung löchern 😉:
Gerne doch, wenn ich Zeit habe Antworte ich auch immer gern 😃
Ovion schrieb
Die Windowsize gibt die Datenmenge an, die übertragen werden kann, bevor der Computer auf das ACK-Paket besteht, wenn ich das richtig nachgelesen habe? Geht's hierbei um den ACK-Vorgang zwischen Server und meinem Rechner?
Das ist nicht ganz richtig.
Die Windowsize gibt an, wieviel Bytes mir die Gegenstelle senden darf. Diese wird nur kleiner wenn der Client nicht mehr nachkommt und dadurch sagt mach mal langsamer oder bei einer Windowsize von 0 mach mal Pause liebe Gegenstelle. Ein Client schickt normal nach ca. 2 Packeten ein ACK, dadurch weiß die Gegenstelle, was das letzte erhaltene Paket ist und dadurch verringert sich der Wert der BiF (Bytes in Flight) erreicht der BiF die Windowsize, sendet der Server keine Daten mehr, bis er ACKs erhält oder die BiF sich automatisch bedingt durch den RTO verringert (Performance Probleme). Die Windowsize ist sonst nur bei Dicken Leitungen mit hoher Delay relevant, das zu erklären wird aber das Forum sprengen, kann jedoch gern ein Workshop halten 😃 😃 😃.
Ovion schrieb
Das würde aber nur dann Bandbreitendiskrepanzen hervorrufen, wenn man häufig Verbindungen herstellt, nicht aber beim Herunterladen einer großen Datei, sehe ich das richtig?
Nicht wirklich, grade bei großen Dateien ist dies relevanter :-).
Ovion schrieb
Und wie bekomme ich raus, ob mein System SACK benutzt und was genau macht SACK anders als seine Vorgänger?
Das siehst du bei einem Verbindungsaufbau im Header, genauer gesagt nach dem TCP Header im Bereich der TCP Optionen, vor dem Payload.
Wenn du mehr über SACK wissen willst siehe
http://de.wikipedia.org/wiki/SACK. Ich finde den Artikel recht oberflächlich und nicht soooo gut erklärt man könnte auch sagen gar nicht 😃, ich habe das früher bei meinen Schulungen, in meinem alten Job besser gemacht und auch mit Bildern und anhand echten Beispielen...
Du kannst dir gern auch die RFC durchlesen
http://tools.ietf.org/html/rfc2018, erfahrungsgemäß sind diese jedoch immer sehr abstrakt geschrieben und ich musste schon einige lesen :-).
Der Vorteil ist halt, dass die Gegenstelle genau weiß welches Paket fehlt und nur dies nachschickt und die Pakete, die nach dem fehlenden eingetroffen sind, auch geACKt (ich weiß ganz böses deutsch :-) ) werden und so die BiF reduziert werden ohne das ggf. der RTO auslöst und erhaltene Pakete dennoch verschickt werden, bloß wegen einem fehlenden.
So kann es zu einem bösen Kreis mit vielen Retransmissions kommen, die die Performance grundlos ins bodenlose zieht.
Wichtig ist noch, dass beide Seiten SACK sprechen müssen, um es nutzen zu können.
Ebenfalls ist noch zu beachten, dass SACK nicht unendlich viele Ranges im SACK handhaben kann (Maximal 3).
Sollte man so viele Probleme haben, dass selbst SACK nicht viel hilft, hat man meist aber eh ganz andere Probleme 😃.